dogfather-universe

658 Commits 2 Branches 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
DogFatherGitandClaude Opus 5	4eab64bd20	Eine neue Form fuer jedes Modul -- und der Kalender zeigt nur noch, was einen angeht Filipe: "DU HAST WIEDER EINE KLEINE AENDERUNG UEBERALL GEMACHT ANSTATT EINE RIESEN AENDERUNG." Er hatte recht, und der Grund war jedes Mal derselbe: Ich habe das MATERIAL getauscht (Mattglas, Leuchtschiene, Verlauf) und die FORM gelassen. Ein abgerundetes Rechteck bleibt ein abgerundetes Rechteck -- und die Silhouette ist das Einzige, was man aus fuenf Metern erkennt. Jetzt ist die Form eine andere: abgeschnittene Ecke oben links (clip-path, echte Silhouette), ein Kantenlicht in der Kategoriefarbe darauf, Eckwinkel unten rechts, ein feines Raster statt Koernung. 35 Bauteile auf allen 18 Seiten, in einer eigenen Datei (module.css). DREI DINGE, DIE DABEI SCHIEFGINGEN UND JETZT ABGESICHERT SIND 1. Die Regeln standen in :where() -- Spezifitaet null, also gewann jede aeltere .kachel::before-Regel. Jetzt :is(). 2. module.css stand an DRITTER Stelle im Ladeweg. Auf Calls, Automationen, Bereich und Dateien hat sie damit gar nichts bewirkt: Die Seitendateien setzen dort selbst border-radius und box-shadow und kommen spaeter. Genau das ergab wieder "ueberall ein bisschen". Sie wird jetzt als LETZTE geladen, geprueft auf allen 18 Seiten. 3. Die Klassenliste steht siebenmal in der Datei (CSS kennt keine Variable fuer Selektoren). Eine vergessene Kopie faellt niemandem auf -- pruef-css-klassen vergleicht sie deshalb alle, mit Gegenprobe. DER KALENDER: NUR NOCH, WAS EINEN ANGEHT Filipe: "calls oder termine soll jeder nur sehen die er selber macht oder jeden betrifft." Das gilt auch fuer DogFather, und das ist die eigentliche Aenderung -- er bekam bisher 1=1. "Jeden betrifft" heisst: ohne Gegenueber und ohne Teilnehmerliste. Wer niemanden eintraegt, meint alle. Die Rollenfrage entfaellt im Kalender damit vollstaendig. SECHS PRUEFUNGEN, DIE EINE WELT GEMESSEN HABEN, DIE ES NICHT MEHR GIBT Alle sechs wurden auf die neue Regel umgeschrieben, keine geloescht -- loeschen haette die Zahl gesenkt und den neuen Weg ungeprueft gelassen: ics, serien, sicht, spicy, teilnehmer, tagesblick, team. UND VIER ECHTE FUNDE, DIE DABEI HERAUSFIELEN * pruef-workspace-seiten war seit dem Bildumbau von heute Frueh auf ALLEN 32 Seiten rot: Sie verlangte noch das eine Motiv. Die neue Bedingung ist schaerfer als beide alten -- das geladene Bild muss zu dem Merkmal passen, das die Seite selbst traegt. Und die Meldung sagt jetzt, WELCHE Bedingung gefallen ist. * pruef-leistung-optik hat sich selbst ausgesperrt (meldete sich als Manager an, der die Zahlen seit Filipes Anweisung nicht mehr sehen darf) und stuerzte danach ab: 2 Pruefungen statt 56. Der Absturz hat verdeckt, dass sie sieben Fingerziele als "zu klein" meldete -- es waren die unsichtbaren Knoepfe der zugeklappten Woche, 0x0. * personen.html beim Manager: Der Erklaersatz ("Codes, Sperren und das Protokoll bleiben bei DogFather") kam nie an -- das Element gab es nicht, und das && davor hat den Fehlgriff verschluckt. Die Liste stand ausserdem dauerhaft auf aria-busy="true": fuer einen Screenreader lud die Seite fuer immer. * pruef-schranke hielt personen.html noch fuer DogFather-only. Die Seite wechselt jetzt die Erwartung, statt aus der Pruefung zu verschwinden: Seite auf fuer die Leitung, Verwaltungsdaten dahinter weiterhin zu. Die Anmeldeseite wurde nicht angefasst (nur ihr Versionsstempel). Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-07 07:12:48 +02:00
DogFatherGitandClaude Opus 5	bede91921d	Der sechste Bereich, und zwei Pruefungen, die den Lauf lahmgelegt haben DER AGENTUR-BEREICH (Stufe 4 des Plans) Kernprinzip 04 des Konzepts lautet woertlich "Die Agentur bleibt angebunden" -- und dafuer gab es bis heute nichts. Fuenf Bereiche standen, der sechste fehlte vollstaendig. Damit stand nirgends, welche Kampagne laeuft, welche Schulung ansteht und wie ein Anliegen an die Agentur ausgegangen ist. Das lief ueber private Nachrichten: nicht auffindbar, nicht nachvollziehbar, beim naechsten Mal von vorn. Vier Arten, und die vierte ist der Punkt: kampagne, schulung, anliegen und ZUSTAENDIGKEIT. Die letzte ist keine Verlegenheit, sondern das, was das Konzept ausdruecklich fordert -- Betreuung und Umsetzung sind unsere Seite, offizielle Wege sind Agenturseite. Solange das nur im Kopf steht, wird es bei jedem Streitfall neu verhandelt. Der Umbau war das eigentliche Risiko, nicht der Bereich: Ein CHECK laesst sich in SQLite nicht aendern, die Tabelle muss neu gebaut werden -- und dabei werden ALLE vorhandenen Eintraege umgeschrieben. Deshalb geht pruef-agentur.mjs (31 Pruefungen) den Weg wirklich: Sie baut eine Datenbank im ALTEN Stand nach, fuellt sie mit allen fuenf Bereichen, laesst die echte Anwendung darueberlaufen und zaehlt danach jede Zeile UND jedes Feld nach -- auch die seltenen Spalten (hook, creator_extern), die man beim Abschreiben des Bauplans vergisst. Wichtigste Gegenprobe: Der CHECK muss danach noch BEISSEN. Eine Umstellung, die nebenbei die Schranke entfernt, sieht aus wie ein Erfolg und ist der schlimmere Ausgang. Nebenbei drei abgeschriebene Bereichslisten beseitigt (Wochenbericht, Suche, Report-Ziele). Im Wochenbericht waere der neue Bereich sonst schlicht nicht vorgekommen -- ohne Fehler, ohne Luecke, einfach nicht da. ZWEI PRUEFUNGEN, DIE DEN GESAMTLAUF ZUM STILLSTAND BRACHTEN pruef-call-kategorien.mjs hing DREI STUNDEN. Ursache war ein Zeitzuender in ihr selbst: Sie legte Calls auf "heute 18:00" und erwartete zwei davon unter "Heute". Ab 18 Uhr sind die vorbei, der Server schiebt sie nach "Protokoll fehlt", und die Oberflaeche unterteilt erst ab FUENF anstehenden. Uebrig blieben vier, die Bloecke verschwanden, und die Pruefung wartete auf einen Klick auf einen Block, den es nicht gab. Genau die Sorte Fehler, vor der die Projektnotiz vom 06.09. warnt: Sie war um 17:59 gruen und um 18:01 rot, ohne dass sich am Code etwas geaendert hatte. Jetzt liegen alle Zeiten RELATIV zu jetzt, und die Erwartung wird mit derselben Vorschrift gerechnet, die calls.js benutzt -- statt Zahlen, die nur zu einer bestimmten Tageszeit stimmen. Und der Grund, warum daraus ein Stillstand statt eines Fehlers wurde: index.js setzt bewusst zwei Auffangnetze (uncaughtException, unhandledRejection). Fuer den Betrieb richtig -- ein Fehler darf die Website nicht offline nehmen. Fuer eine Pruefung fatal: Sie importiert index.js in denselben Prozess und erbt die Netze. Ihr eigener Absturz wird dann nur protokolliert, und der Express-Server haelt den Prozess danach ewig am Leben. Kein Fehler, kein Ergebnis, kein Ende. Deshalb zwei Abhilfen, die zusammengehoeren: * server/helfer-notbremse.mjs -- haengt eigene Zuhoerer DANEBEN (process.on ergaenzt, es ersetzt nicht) und beendet den Lauf mit Fehler; dazu ein Wecker. In alle 42 Browserpruefungen eingebaut. Der Betrieb bleibt unveraendert. * tools/alles-pruefen.mjs gibt jeder Datei eine Frist von 600 s. Wer sie reisst, wird abgebrochen und ZAEHLT ALS FEHLGESCHLAGEN, mit der letzten Ausgabe davor als Beleg. Einzelne Dateien nachzuruesten hilft nur bis zur naechsten ohne Notbremse -- deshalb sitzt sie dort, wo sie fuer alle gilt, auch fuer die, die es noch nicht gibt. AUSSERDEM: pruef-breiten.mjs pruefte 16 Seiten aus einer Liste von Hand, chat.html und leistung.html fehlten darin. Der Chat war bei keiner einzigen der neun Breiten je gemessen worden. Wie bei pruef-handy kommt die Liste jetzt aus dem Verzeichnis. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-06 22:06:49 +02:00
DogFatherGitandClaude Opus 5	23429627ef	Termine, die von allein weiterlaufen -- bis man sie abstellt Wunsch: "ich will dass ich da im kalender auch sachen machen die jede woche jeden monat automatisiert immer weiter laufen so wie ich es auswaehle bis ich es selber deaktiviere. aktiviere diese option fuer jeden." Acht Rhythmen (taeglich, werktags, woechentlich, alle zwei Wochen, monatlich am Datum, am Monatsletzten, am n-ten Wochentag, jaehrlich), wahlweise mit Enddatum oder ohne Ende. Fuer JEDE Rolle -- Creator und Scouts legen sie fuer sich selbst an, mit denselben Grenzen wie beim einzelnen Termin. WARUM ECHTE TERMINE UND KEINE GERECHNETEN AUSPRAEGUNGEN Der naheliegende Weg waere gewesen, die Wiederholung nur beim Anzeigen auszurechnen. Das waere ein stiller Ausfall geworden: ACHT andere Stellen lesen die Tabelle termine direkt -- Calls, Protokolle, Berichte, Hinweise/Ampel, Suche, Aufgaben ("naechster Termin"), Uebersicht und die Startseite. In all diesen Ansichten haette schlicht nichts gestanden, und aufgefallen waere es erst Monate spaeter. Stattdessen macht ein Nachfueller aus der Regel echte Zeilen (Horizont 180 Tage) -- jedes andere Modul sieht sie mit, ohne dass dort eine Zeile geaendert werden musste. Beim geplanten ICS-Abo gilt dasselbe. KEIN ZEITGEBER. Der Nachfueller laeuft beim Serverstart, beim Anlegen und Aendern und beim Oeffnen des Kalenders (dort hoechstens alle fuenf Minuten). Er ist idempotent. Ein Cron waere eine weitere Sache gewesen, die stillschweigend ausfallen kann. WAS BEIM ABSTELLEN PASSIERT: Vergangene Termine und alles, was jemand von Hand angefasst hat (verschoben, umbenannt, abgehakt), bleibt stehen. Nur die unberuehrte Zukunft wird aus dem Kalender genommen. Wer einen einzelnen Tag loescht, streicht nur diesen einen -- der Tag wird als Ausnahme vermerkt, sonst legte der Nachfueller ihn wieder an. ZEITUMSTELLUNG: Gerechnet wird auf reinen Datumstexten in UTC-Mittag, die Uhrzeit wird als Text angehaengt. 18:00 bleibt dadurch 18:00 und wandert im Oktober nicht auf 17:00. DIE SICHTBARKEITSREGEL STEHT JETZT NUR NOCH EINMAL (workspace.js, termineSichtbar) statt zweimal fast gleich. Zwei Fassungen waeren auseinandergelaufen -- und dann haette eine Wiederholung jemandem etwas gezeigt, was der einzelne Termin ihm verbirgt. IN DER OBERFLAECHE beschriften sich die Rhythmen nach dem gewaehlten Datum ("jeden Dienstag", "jeden Monat am letzten Dienstag") statt abstrakt ("woechentlich"), inklusive des ehrlichen Hinweises, dass "jeden 31." den Februar auslaesst. Darunter steht der ganze Satz in Worten. Eine neue Leiste "Laeuft von allein" zeigt alle laufenden Wiederholungen mit Abstell-Schalter -- was von selbst weiterlaeuft, muss man sehen koennen. GEPRUEFT: 67 Pruefungen (server/pruef-serien.mjs), darunter von Hand nachgeschlagene Datumsangaben fuer jeden Takt (der letzte Dienstag im Dezember 2026 ist der 29., nicht der 22.; der 29. Februar nur in Schaltjahren) und vier GEGENPROBEN, die beweisen, dass die Pruefungen auch "nicht in Ordnung" sagen koennen. Die Anzahl der Pruefungen steht in der Bedingung, nicht nur im Meldetext. Bestehende Pruefungen unveraendert gruen: Kalender 84, Sicht 48, Startansicht 133, Protokoll 52, Ampel 47, Handy 50, Aufgabenbrett 44, Sprung 43, Personen-Loeschen 40, Uebersicht 33, Workspace-Seiten 32, Formulare 19, Betreuung 18, Grosscheck 15, Lesbarkeit 14. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-02 17:12:00 +02:00

Author

SHA1

Message

Date

DogFatherGitandClaude Opus 5

4eab64bd20

Eine neue Form fuer jedes Modul -- und der Kalender zeigt nur noch, was einen angeht

Filipe: "DU HAST WIEDER EINE KLEINE AENDERUNG UEBERALL GEMACHT ANSTATT
EINE RIESEN AENDERUNG." Er hatte recht, und der Grund war jedes Mal
derselbe: Ich habe das MATERIAL getauscht (Mattglas, Leuchtschiene,
Verlauf) und die FORM gelassen. Ein abgerundetes Rechteck bleibt ein
abgerundetes Rechteck -- und die Silhouette ist das Einzige, was man aus
fuenf Metern erkennt.

Jetzt ist die Form eine andere: abgeschnittene Ecke oben links
(clip-path, echte Silhouette), ein Kantenlicht in der Kategoriefarbe
darauf, Eckwinkel unten rechts, ein feines Raster statt Koernung.
35 Bauteile auf allen 18 Seiten, in einer eigenen Datei (module.css).

DREI DINGE, DIE DABEI SCHIEFGINGEN UND JETZT ABGESICHERT SIND

1. Die Regeln standen in :where() -- Spezifitaet null, also gewann jede
   aeltere .kachel::before-Regel. Jetzt :is().
2. module.css stand an DRITTER Stelle im Ladeweg. Auf Calls,
   Automationen, Bereich und Dateien hat sie damit gar nichts bewirkt:
   Die Seitendateien setzen dort selbst border-radius und box-shadow und
   kommen spaeter. Genau das ergab wieder "ueberall ein bisschen". Sie
   wird jetzt als LETZTE geladen, geprueft auf allen 18 Seiten.
3. Die Klassenliste steht siebenmal in der Datei (CSS kennt keine
   Variable fuer Selektoren). Eine vergessene Kopie faellt niemandem
   auf -- pruef-css-klassen vergleicht sie deshalb alle, mit Gegenprobe.

DER KALENDER: NUR NOCH, WAS EINEN ANGEHT

Filipe: "calls oder termine soll jeder nur sehen die er selber macht
oder jeden betrifft." Das gilt auch fuer DogFather, und das ist die
eigentliche Aenderung -- er bekam bisher 1=1. "Jeden betrifft" heisst:
ohne Gegenueber und ohne Teilnehmerliste. Wer niemanden eintraegt, meint
alle. Die Rollenfrage entfaellt im Kalender damit vollstaendig.

SECHS PRUEFUNGEN, DIE EINE WELT GEMESSEN HABEN, DIE ES NICHT MEHR GIBT

Alle sechs wurden auf die neue Regel umgeschrieben, keine geloescht --
loeschen haette die Zahl gesenkt und den neuen Weg ungeprueft gelassen:
ics, serien, sicht, spicy, teilnehmer, tagesblick, team.

UND VIER ECHTE FUNDE, DIE DABEI HERAUSFIELEN

* pruef-workspace-seiten war seit dem Bildumbau von heute Frueh auf
  ALLEN 32 Seiten rot: Sie verlangte noch das eine Motiv. Die neue
  Bedingung ist schaerfer als beide alten -- das geladene Bild muss zu
  dem Merkmal passen, das die Seite selbst traegt. Und die Meldung sagt
  jetzt, WELCHE Bedingung gefallen ist.
* pruef-leistung-optik hat sich selbst ausgesperrt (meldete sich als
  Manager an, der die Zahlen seit Filipes Anweisung nicht mehr sehen
  darf) und stuerzte danach ab: 2 Pruefungen statt 56. Der Absturz hat
  verdeckt, dass sie sieben Fingerziele als "zu klein" meldete -- es
  waren die unsichtbaren Knoepfe der zugeklappten Woche, 0x0.
* personen.html beim Manager: Der Erklaersatz ("Codes, Sperren und das
  Protokoll bleiben bei DogFather") kam nie an -- das Element gab es
  nicht, und das && davor hat den Fehlgriff verschluckt. Die Liste stand
  ausserdem dauerhaft auf aria-busy="true": fuer einen Screenreader lud
  die Seite fuer immer.
* pruef-schranke hielt personen.html noch fuer DogFather-only. Die Seite
  wechselt jetzt die Erwartung, statt aus der Pruefung zu verschwinden:
  Seite auf fuer die Leitung, Verwaltungsdaten dahinter weiterhin zu.

Die Anmeldeseite wurde nicht angefasst (nur ihr Versionsstempel).

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

2026-09-07 07:12:48 +02:00

DogFatherGitandClaude Opus 5

bede91921d

Der sechste Bereich, und zwei Pruefungen, die den Lauf lahmgelegt haben

DER AGENTUR-BEREICH (Stufe 4 des Plans)
Kernprinzip 04 des Konzepts lautet woertlich "Die Agentur bleibt
angebunden" -- und dafuer gab es bis heute nichts. Fuenf Bereiche
standen, der sechste fehlte vollstaendig. Damit stand nirgends, welche
Kampagne laeuft, welche Schulung ansteht und wie ein Anliegen an die
Agentur ausgegangen ist. Das lief ueber private Nachrichten: nicht
auffindbar, nicht nachvollziehbar, beim naechsten Mal von vorn.

Vier Arten, und die vierte ist der Punkt: kampagne, schulung, anliegen
und ZUSTAENDIGKEIT. Die letzte ist keine Verlegenheit, sondern das, was
das Konzept ausdruecklich fordert -- Betreuung und Umsetzung sind unsere
Seite, offizielle Wege sind Agenturseite. Solange das nur im Kopf steht,
wird es bei jedem Streitfall neu verhandelt.

Der Umbau war das eigentliche Risiko, nicht der Bereich: Ein CHECK
laesst sich in SQLite nicht aendern, die Tabelle muss neu gebaut werden
-- und dabei werden ALLE vorhandenen Eintraege umgeschrieben. Deshalb
geht pruef-agentur.mjs (31 Pruefungen) den Weg wirklich: Sie baut eine
Datenbank im ALTEN Stand nach, fuellt sie mit allen fuenf Bereichen,
laesst die echte Anwendung darueberlaufen und zaehlt danach jede Zeile
UND jedes Feld nach -- auch die seltenen Spalten (hook, creator_extern),
die man beim Abschreiben des Bauplans vergisst. Wichtigste Gegenprobe:
Der CHECK muss danach noch BEISSEN. Eine Umstellung, die nebenbei die
Schranke entfernt, sieht aus wie ein Erfolg und ist der schlimmere
Ausgang.

Nebenbei drei abgeschriebene Bereichslisten beseitigt (Wochenbericht,
Suche, Report-Ziele). Im Wochenbericht waere der neue Bereich sonst
schlicht nicht vorgekommen -- ohne Fehler, ohne Luecke, einfach nicht da.

ZWEI PRUEFUNGEN, DIE DEN GESAMTLAUF ZUM STILLSTAND BRACHTEN

pruef-call-kategorien.mjs hing DREI STUNDEN. Ursache war ein Zeitzuender
in ihr selbst: Sie legte Calls auf "heute 18:00" und erwartete zwei
davon unter "Heute". Ab 18 Uhr sind die vorbei, der Server schiebt sie
nach "Protokoll fehlt", und die Oberflaeche unterteilt erst ab FUENF
anstehenden. Uebrig blieben vier, die Bloecke verschwanden, und die
Pruefung wartete auf einen Klick auf einen Block, den es nicht gab.
Genau die Sorte Fehler, vor der die Projektnotiz vom 06.09. warnt: Sie
war um 17:59 gruen und um 18:01 rot, ohne dass sich am Code etwas
geaendert hatte. Jetzt liegen alle Zeiten RELATIV zu jetzt, und die
Erwartung wird mit derselben Vorschrift gerechnet, die calls.js benutzt
-- statt Zahlen, die nur zu einer bestimmten Tageszeit stimmen.

Und der Grund, warum daraus ein Stillstand statt eines Fehlers wurde:
index.js setzt bewusst zwei Auffangnetze (uncaughtException,
unhandledRejection). Fuer den Betrieb richtig -- ein Fehler darf die
Website nicht offline nehmen. Fuer eine Pruefung fatal: Sie importiert
index.js in denselben Prozess und erbt die Netze. Ihr eigener Absturz
wird dann nur protokolliert, und der Express-Server haelt den Prozess
danach ewig am Leben. Kein Fehler, kein Ergebnis, kein Ende.

Deshalb zwei Abhilfen, die zusammengehoeren:
  * server/helfer-notbremse.mjs -- haengt eigene Zuhoerer DANEBEN
    (process.on ergaenzt, es ersetzt nicht) und beendet den Lauf mit
    Fehler; dazu ein Wecker. In alle 42 Browserpruefungen eingebaut.
    Der Betrieb bleibt unveraendert.
  * tools/alles-pruefen.mjs gibt jeder Datei eine Frist von 600 s. Wer
    sie reisst, wird abgebrochen und ZAEHLT ALS FEHLGESCHLAGEN, mit der
    letzten Ausgabe davor als Beleg. Einzelne Dateien nachzuruesten hilft
    nur bis zur naechsten ohne Notbremse -- deshalb sitzt sie dort, wo
    sie fuer alle gilt, auch fuer die, die es noch nicht gibt.

AUSSERDEM: pruef-breiten.mjs pruefte 16 Seiten aus einer Liste von Hand,
chat.html und leistung.html fehlten darin. Der Chat war bei keiner
einzigen der neun Breiten je gemessen worden. Wie bei pruef-handy kommt
die Liste jetzt aus dem Verzeichnis.

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

2026-09-06 22:06:49 +02:00

DogFatherGitandClaude Opus 5

23429627ef

Termine, die von allein weiterlaufen -- bis man sie abstellt

Wunsch: "ich will dass ich da im kalender auch sachen machen die jede
woche jeden monat automatisiert immer weiter laufen so wie ich es
auswaehle bis ich es selber deaktiviere. aktiviere diese option fuer
jeden."

Acht Rhythmen (taeglich, werktags, woechentlich, alle zwei Wochen,
monatlich am Datum, am Monatsletzten, am n-ten Wochentag, jaehrlich),
wahlweise mit Enddatum oder ohne Ende. Fuer JEDE Rolle -- Creator und
Scouts legen sie fuer sich selbst an, mit denselben Grenzen wie beim
einzelnen Termin.

WARUM ECHTE TERMINE UND KEINE GERECHNETEN AUSPRAEGUNGEN

Der naheliegende Weg waere gewesen, die Wiederholung nur beim Anzeigen
auszurechnen. Das waere ein stiller Ausfall geworden: ACHT andere Stellen
lesen die Tabelle termine direkt -- Calls, Protokolle, Berichte,
Hinweise/Ampel, Suche, Aufgaben ("naechster Termin"), Uebersicht und die
Startseite. In all diesen Ansichten haette schlicht nichts gestanden, und
aufgefallen waere es erst Monate spaeter. Stattdessen macht ein
Nachfueller aus der Regel echte Zeilen (Horizont 180 Tage) -- jedes andere
Modul sieht sie mit, ohne dass dort eine Zeile geaendert werden musste.
Beim geplanten ICS-Abo gilt dasselbe.

KEIN ZEITGEBER. Der Nachfueller laeuft beim Serverstart, beim Anlegen und
Aendern und beim Oeffnen des Kalenders (dort hoechstens alle fuenf
Minuten). Er ist idempotent. Ein Cron waere eine weitere Sache gewesen,
die stillschweigend ausfallen kann.

WAS BEIM ABSTELLEN PASSIERT: Vergangene Termine und alles, was jemand von
Hand angefasst hat (verschoben, umbenannt, abgehakt), bleibt stehen. Nur
die unberuehrte Zukunft wird aus dem Kalender genommen. Wer einen
einzelnen Tag loescht, streicht nur diesen einen -- der Tag wird als
Ausnahme vermerkt, sonst legte der Nachfueller ihn wieder an.

ZEITUMSTELLUNG: Gerechnet wird auf reinen Datumstexten in UTC-Mittag, die
Uhrzeit wird als Text angehaengt. 18:00 bleibt dadurch 18:00 und wandert
im Oktober nicht auf 17:00.

DIE SICHTBARKEITSREGEL STEHT JETZT NUR NOCH EINMAL (workspace.js,
termineSichtbar) statt zweimal fast gleich. Zwei Fassungen waeren
auseinandergelaufen -- und dann haette eine Wiederholung jemandem etwas
gezeigt, was der einzelne Termin ihm verbirgt.

IN DER OBERFLAECHE beschriften sich die Rhythmen nach dem gewaehlten
Datum ("jeden Dienstag", "jeden Monat am letzten Dienstag") statt
abstrakt ("woechentlich"), inklusive des ehrlichen Hinweises, dass "jeden
31." den Februar auslaesst. Darunter steht der ganze Satz in Worten. Eine
neue Leiste "Laeuft von allein" zeigt alle laufenden Wiederholungen mit
Abstell-Schalter -- was von selbst weiterlaeuft, muss man sehen koennen.

GEPRUEFT: 67 Pruefungen (server/pruef-serien.mjs), darunter von Hand
nachgeschlagene Datumsangaben fuer jeden Takt (der letzte Dienstag im
Dezember 2026 ist der 29., nicht der 22.; der 29. Februar nur in
Schaltjahren) und vier GEGENPROBEN, die beweisen, dass die Pruefungen
auch "nicht in Ordnung" sagen koennen. Die Anzahl der Pruefungen steht in
der Bedingung, nicht nur im Meldetext. Bestehende Pruefungen unveraendert
gruen: Kalender 84, Sicht 48, Startansicht 133, Protokoll 52, Ampel 47,
Handy 50, Aufgabenbrett 44, Sprung 43, Personen-Loeschen 40, Uebersicht
33, Workspace-Seiten 32, Formulare 19, Betreuung 18, Grosscheck 15,
Lesbarkeit 14.

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

2026-09-02 17:12:00 +02:00