f3d5bcf198e0da2bd17f5b189142df6ce85591e6
5
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
f701dae53e |
screen10: Der Tagesruf -- einmal am Tag, was noch offen ist
Wunsch Filipe: "ich will das neben diesem kreis auch ein kleiner button
ist fuer den wecker von den aufgaben, oder quasi eine taetige meldung
einmal am tag zu aktivieren wenn noch aufgaben auf sind."
Ein Wecker-Knopf unter der Glocke, neben der Uhr. Eingeschaltet meldet
er sich einmal taeglich zur eingestellten Zeit -- aber nur, wenn
wirklich noch etwas offen ist. Der Satz nennt die Zahl und die
Ueberfaelligen: "3 Aufgaben sind noch offen / Davon eine ueberfaellig."
ALS EINZIGE ART MIT `vorgabe: false`, und das ist keine
Nachlaessigkeit. Alle anderen Benachrichtigungen antworten auf ein
Ereignis, das gerade passiert ist. Der Tagesruf kommt ungefragt zur
selben Zeit, ob es etwas Neues gibt oder nicht -- so etwas schaltet man
sich selbst ein, sonst ist es Werbung. Bei null offenen Aufgaben kommt
nichts: Eine taegliche Meldung "du hast nichts zu tun" ist der
schnellste Weg, dass man die naechste nicht mehr liest.
EIN FENSTER VON DREI STUNDEN. Der Takt laeuft alle fuenf Minuten; ein
einfaches "jetzt >= eingestellte Zeit" wuerde nach einem Serverausfall
den Ruf fuer neun Uhr um zwanzig Uhr zustellen. Wer eine Erinnerung an
einen vergangenen Tag bekommt, schaltet sie ab. Faellt der Tag aus, ist
das die ehrlichere Antwort.
VIER DINGE, DIE ERST DAS NACHMESSEN GEZEIGT HAT:
1. DER KNOPF VERSPRACH ETWAS, DAS ER NICHT HALTEN KONNTE. Chromium
meldet `Notification.permission === 'denied'` -- gemessen, nicht
vermutet. Der Knopf sah einladend aus ("Einmal am Tag melden…") und
sagte erst NACH dem Antippen ab. Ein Bedienelement, das den Grund
erst hinterher nennt, ist die schlechtere Haelfte einer
Fehlermeldung. Jetzt steht er im Titel, und der Knopf ist gedimmt.
2. EINE UHRZEIT IN DER RUHEZEIT WAERE EIN STILLES NICHTS. Der Server
laesst zwischen 22 und 7 Uhr nichts durch. Wer 23:00 einstellt,
bekaeme nie etwas und saehe nur einen Knopf auf "an". Jetzt steht
der Hinweis dort, wo man es einstellt -- mit den Grenzen VOM SERVER,
nicht mit hier getippten Zahlen.
3. `wert` UND `an` SIND ZWEI ENTSCHEIDUNGEN. Wer nur den Schalter
umlegt, schickt kein `wert` -- stumpf `req.body.wert` zu schreiben
haette bei jedem Aus- und Einschalten die Uhrzeit geloescht, und
beim naechsten Mal staende wieder neun Uhr da. Ein Datenverlust, den
niemand meldet, weil er wie eine Vorgabe aussieht. Genau dieser Weg
wird jetzt geprueft.
4. pruef-css-klassen HATTE ZWEIMAL RECHT. Der Stil lag in heim.css
(nur Startseite), die Zeichen entstehen aber in glocke.js (18
Seiten) -- auf 17 davon waere ein nackter Knopf gestanden. Und die
beiden neuen Schriftgroessen (10 und 11 px) haetten die Grundlinie
von 43 zu kleinen Stellen still auf 45 gehoben. Beides behoben:
Stil nach start.css, Schrift auf 12 px.
NEUE PRUEFUNG server/pruef-tagesruf.mjs, drei Schichten getrennt, weil
sie getrennt kaputtgehen: Oberflaeche im Browser, Schalten ueber die
Schnittstelle (aus der SEITE heraus, damit Sitzung und
Herkunftspruefung mitgehen), Zeitentscheidung als reine Rechnung. Die
Entscheidung wurde dafuer aus dem Rundgang herausgeloest -- dazwischen
steckend haette man zum Pruefen Datenbank und Push-Versand aufbauen
muessen, also haette man sie nicht geprueft.
Die Erwartung der ersten Schicht richtet sich nach der GEMESSENEN
Berechtigung statt sie vorauszusetzen: Erlaubt eine kuenftige
Chromium-Fassung Benachrichtigungen von sich aus, waere ein fest
verdrahtetes "muss blockiert sein" ein Fehlalarm ohne Fehler.
Gegenproben sind dabei: "99:99", "7:30" ohne fuehrende Null und ein
Wert an einer Art, die keinen kennt, muessen abgelehnt werden -- sonst
bewiese der Bereichstest nichts.
Der reservierte Platz waechst von 46 auf 104 px, damit der zweite Knopf
die Kachelreihe darunter nicht nach unten schiebt; das Zeitfeld schwebt
statt zu schieben. Beides derselbe Grund wie bei der Glocke: Ein
Sprung ist kein Schoenheitsfehler, sondern der Grund, warum man auf den
falschen Knopf drueckt.
Geprueft: pruef-tagesruf (neu, alles in Ordnung), pruef-push,
pruef-css-klassen, pruef-start-ansicht -- alle in Ordnung.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
29785cc2a4 |
Abgebrochene Aufgaben mahnen nicht mehr -- an zwoelf Stellen, nicht an einer
Filipe, screen12: "die abgebrochenen sollen oben nicht mehr mit zaehlen
die sollen ihre eigenen kategorie kriegen".
DIE URSACHE war eine Bedingung, die harmlos aussieht: `a.status <>
'erledigt'`. Eine abgebrochene Aufgabe ist nicht "erledigt" -- also fiel
sie durch, und zwar in JEDE Zahl, die "noch zu tun" bedeutet. Eine
Aufgabe, die niemand mehr anfassen wird, mahnte weiter als ueberfaellig.
Das ist die Kehrseite einer bewussten Entscheidung: "abgebrochen" steht
absichtlich NICHT in STATUS, damit der normale Weg es nicht setzen kann.
Genau deshalb rutscht es aber durch jede Pruefung, die nur gegen
'erledigt' vergleicht.
FILIPE HAT EINE STELLE GESEHEN. Gesucht werden musste nach dem MUSTER:
Es waren zwoelf, in sieben Dateien.
workspace-aufgaben.js 2 ueberfaellig und heute (die Zahlen "oben")
workspace-hinweise.js 2 die Hinweiszeilen der Startseite
workspace-kalender.js 1 Aufgaben mit Frist im Kalender
workspace-personen.js 1 "offene_aufgaben" je Person
workspace-profil.js 1 dieselbe Zahl im Profil
workspace-push.js 2 ERINNERUNGEN, die verschickt werden
workspace-reports.js 3 Berichte
Am schwersten wiegt workspace-push.js: Dort gingen Push-Nachrichten
hinaus -- fuer Aufgaben, die laengst abgebrochen waren.
`NOT IN ('erledigt', 'abgebrochen')` statt einer zweiten Ungleichung: Wer
spaeter einen dritten Endzustand einfuehrt, ergaenzt eine Liste, statt
eine Kette von `<>` zu verlaengern, bei der das Vergessen niemandem
auffaellt.
DIE EIGENE KATEGORIE, die Filipe verlangt hat, gibt es jetzt in der
Schnittstelle (`abgebrochen`) und auf der Startseite -- hinten bei
"Erledigt", weil beides dasselbe bedeutet: vom Tisch.
GEGENPROBE an einer abgebrochenen Aufgabe mit Frist von gestern:
alte Bedingung "<> erledigt" -> ueberfaellig = 3
neue Bedingung "NOT IN (erledigt, abg)" -> ueberfaellig = 2
Unterschied 1 = genau die abgebrochene. Die Schnittstelle liefert 2
und abgebrochen = 1.
pruef-start-ansicht hat den Umbau bemerkt und "die Aufgabenzahlen stehen
(7)" gemeldet -- sie zaehlt die Kategorien und erwartete sechs. Die Zahl
steht in der Bedingung, nicht nur im Meldetext; deshalb faellt eine
Kategorie, die still verschwindet, sofort auf. Auf 7 nachgezogen:
EXIT=0, 140 Pruefungen. pruef-aufgabenbrett EXIT=0, 44.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
1c2e196d1d |
Der Wecker: mehrere Erinnerungen je Termin, jeder fuer sich
Filipe: "wie so ein wecker, den man auch in den eintraegen aktivieren
oder ausschalten kann, den soll man sogar so einstellen koennen, dass
er einen auch mehrmals informiert, einmal eine woche vorher, einmal
drei tage vorher und einmal am tag selber. das soll man auch selbst
jeder fuer sich einstellen koennen. hol die besten skills."
NACHGELESEN, NICHT GERATEN. Google Calendar erlaubt fuenf Erinnerungen
je Termin, Outlook genau eine, Apple zwei. Die verbreitete Empfehlung
fuer Wichtiges lautet "eine Woche, ein Tag, am Tag selbst" -- also
genau die Staffel, die Filipe genannt hat. Uebernommen: sechs Stufen
zur Wahl (Woche, drei Tage, ein Tag, selber Tag, Stunde, zehn Minuten),
hoechstens fuenf gleichzeitig.
EINE ZEILE IST EIN WECKER -- kein Feld am Termin mit einer Liste darin.
Mehrere Vorlaufzeiten UND "jeder fuer sich" sind zusammen eine
n:m-Beziehung; ein Feld mit kommagetrennten Zahlen waere beim ersten
"zeig mir alle faelligen Wecker" nicht mehr abfragbar.
DER ABSTAND STEHT IN DER DATENBANK, NICHT DER ZEITPUNKT. Ein Zeitpunkt
muesste bei jeder Terminverschiebung nachgezogen werden -- und genau
das vergisst man. Ein Abstand rechnet sich beim Wecken aus dem
aktuellen Beginn und ist damit immer richtig.
ZWEI GRENZEN IM WECKLAUF, und beide sind noetig: faellig (Weckzeit
erreicht) UND der Termin liegt noch vor uns. Ohne die zweite wuerde
beim ersten Lauf nach einem Ausfall jeder alte Wecker der letzten
Wochen nachtraeglich klingeln.
DER ABSTAND GEHOERT INS MERKMAL der Doppelsperre. Ohne ihn wuerde der
erste Wecker eines Termins alle weiteren sperren -- und genau das
Mehrfach-Wecken, um das es geht, faende nie statt.
DIE PRUEFUNG HAT SICH ZWEIMAL SELBST KORRIGIERT
1. Erster Lauf um 23:42: vier Fehler, keiner echt -- der Melder
schweigt zwischen 22 und 7 Uhr. Sie hat den Kalender gemessen,
nicht die Software, und waere am Vormittag gruen gewesen. Dass die
GEGENPROBE mitgefallen ist, war die eigentliche Auskunft: Waeren
nur die Grenzen falsch, haette sie gehalten. Die Ruhezeit ist
jetzt ueber die Umgebung einstellbar (Vorgabe unveraendert 22/7),
damit eine Pruefung ihre Voraussetzung herstellen kann.
2. Danach immer noch nichts: Ich hatte angenommen, der Melder trage
den Versand nach dem VERSUCH ein. Er traegt ihn nach der
erfolgreichen ZUSTELLUNG ein -- und das ist richtig so. Meine
Annahme war falsch, nicht der Code. Die Pruefung hat jetzt einen
winzigen echten Empfaenger; damit laeuft der ganze Versandweg mit,
Verschluesselung und VAPID inbegriffen.
pruef-wecker.mjs: 20 Pruefungen. Sie stellt alle vier Fehler nach, die
bei einem Wecker moeglich sind (klingelt nicht / doppelt / nur einmal
von dreien / nachtraeglich nach einem Ausfall) -- plus die Gegenprobe,
dass ein faelliger Wecker wirklich ankommt.
Zwoelf weitere Pruefungen gelaufen, alle gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
4637aa24e7 |
Chat zwischen Creator, Scouts und Managern
Wunsch Filipe, 06.09.2026: *"eine kategorie chat, wo die creator mit
ihren manager nachrichten austauschen koennen, wie erinnerungen, fragen
und noch vieles mehr."* Auf Nachfrage entschieden: Zweier-Gespraeche UND
Gruppen; Manager und Scouts duerfen sich auch ohne gemeinsamen Creator
schreiben.
WER MIT WEM steht an EINER Stelle: schreibbareIds() in workspace.js.
Bewusst getrennt von einladbareIds() (Terminwahl): Dort geht es darum,
wen man zu einem Kalendereintrag dazustellen darf -- harmlos. Ein Chat
legt ein dauerhaftes Gespraech an, schickt eine Benachrichtigung und
macht den eigenen Namen sichtbar. Zwei Fragen, zwei Funktionen.
Ein Creator erreicht seine Betreuer und DogFather, KEINEN fremden
Creator. Eine Gruppe ist kein Schlupfloch: Jede Nummer wird einzeln
gegen dieselbe Regel geprueft.
SOFORT STATT NACHFRAGEN IM TAKT (SSE). Ein Chat, der alle fuenf
Sekunden fragt, ist fuenf Sekunden langsam und stellt bei zehn
Angemeldeten 7200 Anfragen in der Stunde fuer Nachrichten, die es
meistens nicht gibt. Kein WebSocket: Hier fliesst alles in eine
Richtung, und SSE uebersteht einen Verbindungsabriss von selbst.
DIE ZAHL STEHT AUF JEDER SEITE, nicht nur im Chat. Eine Nachricht, die
man erst sieht, wenn man den Chat aufmacht, ist keine Nachricht --
sie ist ein Fundstueck.
Push aufs Handy nur an die, die NICHT gerade zusehen. Wer die Seite
offen hat, sieht es ohnehin; ihm zusaetzlich etwas aufs Handy zu
schicken ist der schnellste Weg, dass er Benachrichtigungen abschaltet.
WAS BEWUSST NICHT GEHT:
* Niemand liest fremde Gespraeche mit -- auch DogFather nicht. Ein
Chat, in dem der Chef stillschweigend mitliest, ist kein Chat.
Er kann jederzeit jedem schreiben, aber sichtbar.
* Eine abgeschickte Nachricht laesst sich nicht aendern, nur
zuruecknehmen. Wer Absprachen nachtraeglich umschreiben kann, macht
den Verlauf wertlos. Zurueckgenommenes hinterlaesst einen Hinweis
statt eines Lochs.
DAZU: CALL-LISTE NACH ZEIT GEGLIEDERT
Wunsch mit Bild von "STEHT AN 27": *"die liste soll kategorisiert sein
und werden mit einem button zum auf und zu machen."* Jetzt Heute /
Diese Woche / Naechste Woche / Spaeter, offen nur der erste gefuellte
Block. Nach ZEIT und nicht nach Titel: Auf dem Bild waren fast alle
"Community-Talk" -- nach Titel gruppiert haette man zwei Ueberschriften
und darunter dieselbe lange Liste.
DER FUND, DER DIE FUNKTION GERETTET HAT: Ein zugeklappter Block zeigte
seinen Inhalt trotzdem -- 367 Pixel Hoehe bei open=false. <details>
versteckt seinen Inhalt naemlich nur, solange niemand dem Inhalt eine
eigene display-Angabe gibt, und .gruppe__karten traegt display:grid.
Der Knopf haette sich bewegt und sonst nichts getan. Im Bildschirmfoto
fiel es nicht auf, weil der Ausschnitt genau darueber endete.
Ausserdem gefunden und behoben:
* Ein Wettlauf beim Abschicken: War der Ereignisstrom schneller als
die Antwort auf das POST, stand die eigene Nachricht zweimal im
Verlauf.
* Die Chatseite war zu hoch -- die Kopfleistenhoehe stand als fester
Wert (62 px) im CSS, am Handy ist sie doppelt so hoch. Das
Eingabefeld stand halb unter dem Bildschirmrand. Jetzt gemessen.
* Der Platzhalter "Enter schickt ..." brach am Handy um UND stimmte
dort nicht: Ohne Tastatur schickt Enter absichtlich nicht.
* Der Dialog benutzte Klassen aus aufgaben.css, das chat.html nicht
lud -- gemeldet von pruef-css-klassen, bevor jemand einen
ungestylten Dialog zu sehen bekam.
Pruefungen: pruef-chat (44 Punkte, Rechte und Sichtbarkeit),
pruef-chat-optik (24, zwei echte Browser schreiben sich),
pruef-call-kategorien (16).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
627f710d71 |
Aufgaben abbrechen, Teilnehmerwahl fuer alle, Benachrichtigungen
Zwei Wuensche vom 05.09.2026, dazu drei Fehler, die dabei ans Licht kamen.
ABBRECHEN (Wunsch: "in jedem status die aufgaben auch abbrechen koennen,
nur ich die manager und scouts")
Neuer Status mit Pflicht-Grund, aus jedem der vier Status heraus.
Festgehalten wird auch, WO die Aufgabe stand -- "im Review abgebrochen"
ist eine andere Aussage als "nie angefangen", und das Wiederaufnehmen
geht dorthin zurueck statt nach "offen".
Eigener Weg statt "abgebrochen" in der Statusliste: Dort entscheidet
darfAendern(), und das laesst auch den zustaendigen Creator aendern.
Der gewoehnliche PATCH kann diesen Zustand deshalb gar nicht erreichen
-- auch nicht fuer DogFather, sonst waere die Grund-Pflicht umgehbar.
Abgebrochenes steht in einem zugeklappten Bereich unter dem Brett, nicht
als fuenfte Spalte: Am Handy waeren dann alle fuenf unlesbar schmal.
Verschwinden darf es nicht, sonst waere der Abbruch ein Loeschen mit
Zwischenschritt.
Die Tabelle musste dafuer getauscht werden (SQLite kann CHECK nicht
aendern). Vorher auf einer Kopie durchgespielt: 40 von 40 Aufgaben,
Inhalte, Verweise und Indizes geprueft, Gegenprobe zeigt, dass der CHECK
noch lebt.
TEILNEHMERWAHL (Wunsch: "das soll viel besser aussehen und fuer jeden
verfuegbar sein")
Auf dem Bildschirm klebten die Namen aneinander: "DogfatherDogFather".
Ursache war, dass kalender.html das Stylesheet mit diesen Klassen nie
eingebunden hat -- sie standen in dateien.css. Vierzig gruene Pruefungen
zur Teilnehmerwahl hatten das nicht gemerkt, weil keine je gefragt hat,
ob es AUSSIEHT wie gedacht.
Jetzt eigene Klassen im eigenen Stylesheet, nach Rollen gruppiert: Die
Rolle steht einmal als Ueberschrift statt neunmal am Namen. Damit ist
das Kleben an der Wurzel weg, nicht zugepflastert.
"Fuer jeden" war mehr als ein hidden zu entfernen: darfEintragen() haette
einem Creator nur sich selbst erlaubt. Er haette seinen Scout gesehen,
angeklickt, und der Server haette ihn still weggelassen -- ein Knopf, der
nichts tut. einladbareIds() schaut jetzt in beide Richtungen, bewusst
getrennt von /api/personen: Wer die erweitert, gibt einem Creator
nebenbei die Moeglichkeit, seinem Scout Aufgaben zuzuweisen.
BENACHRICHTIGUNGEN (Wunsch: "sowas, und dass es perfekt funktioniert
fuer jeden")
Web Push nach RFC 8291/8292, ohne fremde Abhaengigkeit. Der Knopf sagt
in jeder Lage die Wahrheit, auch die unbequemen: abgelehnt (mit dem
Hinweis, wo man es zuruecknimmt), iPhone im Reiter (mit Anleitung),
Browser ohne Push. Ein Knopf, der bei abgelehnter Berechtigung nur
nichts tut, ist der sichere Weg zu "das funktioniert nicht".
DREI FEHLER, DIE DABEI AUFFIELEN
1. Ein defekter Zugangsdatensatz sperrte ALLE einer Rolle aus. Wirft
hashe() bei einer Person, flog die ganze Anmeldung in den catch: 503
"nicht verfuegbar" fuer jeden mit dieser Rolle. Aufgefallen durch
einen eigenen Testfehler. Jetzt wird die defekte Person uebersprungen
und laut protokolliert; die Gegenprobe zeigt, dass ein falscher Code
weiterhin abgelehnt wird.
2. Die Glocke sprengte die Kopfleiste -- zweimal. Bei 320 px lag die
Lupe des Suchknopfes auf dem Sicht-Umschalter (ein Knopf, der auf 12
Seiten ins Leere tippt), bei 768 px wurde der Abmelden-Knopf bis zu
15 px aus dem Bild geschoben, weil die Textgrenze auf 760 stand und
ein Tablet 768 hat. Nachgewiesen durch Messen mit und ohne Glocke,
nicht durch Vermuten.
3. .block__frage war viermal gestaltet und stand auf einer Seite, die
keine dieser Dateien laedt -- derselbe Fehler wie bei der
Teilnehmerwahl. Gefunden von der neuen Klassenpruefung beim ersten
Lauf.
NEUE PRUEFUNGEN
pruef-css-klassen jede gestaltete Klasse muss auf ihrer Seite ankommen
(unterscheidet Struktur-Anker von echtem Verlust)
pruef-dabei-optik die Wahl im Browser, an den echten Pixeln
pruef-abbrechen Umstellung auf einer Kopie, Rechte, Rueckweg
pruef-abbrechen-optik Knopf, Dialog, Bereich, Handy
pruef-glocke Zustaende, An/Abmelden, jede Rolle
pruef-push(-weg) Rechnung gegen die RFC-Vektoren, Zustellung
pruef-struktur prueft jetzt zusaetzlich, ob sich jedes Server-Modul als
ESM laden laesst. node --check auf einer .js-Datei prueft als CommonJS
und meldete "ok", waehrend der Import scheiterte.
Gesamtlauf: 55 von 55 Dateien, 1973 von 1973 Punkten.
Was NICHT geprueft werden konnte und deshalb dasteht: Der Schritt
"Browser holt eine Adresse beim Push-Dienst" braucht eine Verbindung zu
Googles FCM, die ein Pruef-Browser nicht hat. Die Pruefung misst das
zuerst und meldet es als dritten Ausgang, statt gruen zu sein.
Verschluesselung und Zustellung sind getrennt geprueft; diese eine
Strecke beweist sich erst auf dem Server.
Co-Authored-By: Claude Opus 5 <[email protected]>
|