dogfather-universe

DogFatherGit/dogfather-universe

Fork 0

Commit Graph

Author	SHA1	Message	Date
DogFatherGitandClaude Opus 5	d92ba76e33	Kategorie-Kanaele und angeheftete Ankuendigungen (Kapitel 7.2) Die vier Saetze aus dem Anforderungsdokument, der Reihe nach: Team- Gruppenchat, Kategorie-Kanaele mit Zugriff fuer Owner und rechte Hand, private 1:1-Chats OHNE diesen Zugriff, und Pin-Nachrichten an alle. EIN KANAL IST KEINE VIERTE TABELLE, sondern eine dritte Art Raum (`art = 'kanal'` neben 'direkt' und 'gruppe'). Damit gilt fuer ihn ohne eine einzige neue Zeile alles, was schon da ist: Verlauf, Anhaenge, Suche, Ungelesen-Zaehler, Live-Strom, Wegraeumen. Eine eigene Tabelle haette all das ein zweites Mal gebraucht -- und die zweite Fassung waere die gewesen, in der die Zugriffsregel fehlt. Welche Zustaendigkeit, kommt aus MODI_KATEGORIEN -- derselben Liste, aus der auch die Aufgaben ihre Kategorie nehmen. Der NAME kommt aus der Kategorie und ist kein freies Feld: "Clipping" neben "Clipping-Team" waeren zwei halbe Verlaeufe, und man merkt es erst, wenn jemand die Antwort im falschen sucht. Ein eindeutiger Teilindex haelt das auch dann fest, wenn zwei Anfragen im selben Augenblick ankommen. DIE ZUGRIFFSREGEL STEHT IN istDrin() -- der Funktion, durch die alle sieben lesenden und schreibenden Wege gehen. In den Routen stuende sie in sechs davon und in der siebten nicht. Sie gilt AUSDRUECKLICH nur fuer 'kanal': Zweier-Gespraeche bleiben zu, auch fuer DogFather (so steht es im Dokument), und Gruppen ebenfalls -- wer eine Gruppe aufmacht, hat sich fuer einen geschlossenen Kreis entschieden, und den nachtraeglich still zu oeffnen waere das Gegenteil dessen, was er getan hat. Wenn Filipe das anders will, ist es eine Zeile -- aber es waere seine Entscheidung und muesste fuer die Beteiligten SICHTBAR sein. istDrin() nimmt dafuer die PERSON statt ihrer Nummer und wirft bei einer Nummer einen Fehler, statt stillschweigend "nein" zu antworten. HOECHSTENS DREI ANKUENDIGUNGEN je Raum. Nicht eine (Regeln, Live-Plan und Frist muessen gleichzeitig oben stehen koennen) und nicht beliebig viele -- eine Pinnwand, die scrollt, ist ein zweiter Verlauf. Der Aushang hat eine EIGENE Abfrage, weil der Verlauf nur 200 Zeilen liefert: Eine Ansage von vorletzter Woche waere sonst genau dann weg, wenn sie am laengsten oben stehen sollte. Wird die Nachricht zurueckgenommen, faellt sie ab UND gibt den Platz frei. DREI DINGE, DIE ERST DAS HINSEHEN GEZEIGT HAT: Der frisch angelegte Kanal hatte zwei Leute statt vier. Die Personenauswahl zeichnete nach der Rollenfolge aus bereiche.js -- wer dort nicht steht, wurde NICHT GEZEICHNET. Team Dogi steht dort nicht und darf es auch nicht (der Rollenname gehoert in keine Datei, die jeder herunterlaedt). Folge: DogFather konnte ueber die Auswahl niemandem aus seinem Team schreiben. Der Server schickt die Ueberschrift jetzt mit; der Browser braucht dafuer keinen Rollennamen. Der Kommentar, der genau davor warnte, stand die ganze Zeit darueber. Dieser Fehler war nebenbei ein Netz: Was nicht gezeichnet wird, kann auch nicht falsch gezeichnet werden. Deshalb ist jetzt gemessen, dass ein Manager und Spicy Media Team Dogi gar nicht erst geschickt bekommen -- und dabei fiel auf, dass Spicy Media in der EIGENEN Auswahl stand: Sobald es jemanden zu verbergen gibt, schreibt ohneVerborgene() aus "sieht alles" eine echte Liste, und darin steckt man selbst. Am Fuss jeder Nachricht stehen jetzt vier Handgriffe statt drei. Bei 390 px -- der haeufigsten Handybreite -- stand "kopieren" 18 px ueber der Blase, bei 320 px 75. Behoben mit `flex-wrap: wrap` und nicht mit einer Schwelle: Eine Regel, die misst, bleibt beim fuenften Handgriff richtig; eine Zahl nicht. pruef-chat-optik misst es ab jetzt. NACHGEZOGEN, was pruef-css-klassen an MEINEM letzten Commit fand: teamlage.html lud kopf.js ohne wahl.js (der Sicht-Umschalter sah aus wie aus einem anderen Programm -- kaputt war nichts, und genau deshalb faellt es niemandem auf), und .tampel__tag stand auf 11,2 px. Beides war schon gepusht, weil ich die Pruefung nicht laufen liess. pruef-chat-kanaele 73 (neu) · pruef-chat 48 · pruef-chat-ausbau 64 · pruef-chat-anhaenge 60 · pruef-chat-optik 24 -> 26 · pruef-css-klassen gruen · pruef-rollen 274 · pruef-modi-verborgen 78 · pruef-team-ampel 28 · pruef-start-ansicht gruen · pruef-modi-wortleck 5 · pruef-zwischenspeicher 21. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-10 20:18:04 +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	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]>	2026-09-06 16:28:58 +02:00

Author

SHA1

Message

Date

DogFatherGitandClaude Opus 5

d92ba76e33

Kategorie-Kanaele und angeheftete Ankuendigungen (Kapitel 7.2)

Die vier Saetze aus dem Anforderungsdokument, der Reihe nach: Team-
Gruppenchat, Kategorie-Kanaele mit Zugriff fuer Owner und rechte Hand,
private 1:1-Chats OHNE diesen Zugriff, und Pin-Nachrichten an alle.

EIN KANAL IST KEINE VIERTE TABELLE, sondern eine dritte Art Raum
(`art = 'kanal'` neben 'direkt' und 'gruppe'). Damit gilt fuer ihn ohne
eine einzige neue Zeile alles, was schon da ist: Verlauf, Anhaenge,
Suche, Ungelesen-Zaehler, Live-Strom, Wegraeumen. Eine eigene Tabelle
haette all das ein zweites Mal gebraucht -- und die zweite Fassung waere
die gewesen, in der die Zugriffsregel fehlt.

Welche Zustaendigkeit, kommt aus MODI_KATEGORIEN -- derselben Liste, aus
der auch die Aufgaben ihre Kategorie nehmen. Der NAME kommt aus der
Kategorie und ist kein freies Feld: "Clipping" neben "Clipping-Team"
waeren zwei halbe Verlaeufe, und man merkt es erst, wenn jemand die
Antwort im falschen sucht. Ein eindeutiger Teilindex haelt das auch
dann fest, wenn zwei Anfragen im selben Augenblick ankommen.

DIE ZUGRIFFSREGEL STEHT IN istDrin() -- der Funktion, durch die alle
sieben lesenden und schreibenden Wege gehen. In den Routen stuende sie
in sechs davon und in der siebten nicht. Sie gilt AUSDRUECKLICH nur
fuer 'kanal': Zweier-Gespraeche bleiben zu, auch fuer DogFather (so
steht es im Dokument), und Gruppen ebenfalls -- wer eine Gruppe
aufmacht, hat sich fuer einen geschlossenen Kreis entschieden, und den
nachtraeglich still zu oeffnen waere das Gegenteil dessen, was er getan
hat. Wenn Filipe das anders will, ist es eine Zeile -- aber es waere
seine Entscheidung und muesste fuer die Beteiligten SICHTBAR sein.

istDrin() nimmt dafuer die PERSON statt ihrer Nummer und wirft bei
einer Nummer einen Fehler, statt stillschweigend "nein" zu antworten.

HOECHSTENS DREI ANKUENDIGUNGEN je Raum. Nicht eine (Regeln, Live-Plan
und Frist muessen gleichzeitig oben stehen koennen) und nicht beliebig
viele -- eine Pinnwand, die scrollt, ist ein zweiter Verlauf. Der
Aushang hat eine EIGENE Abfrage, weil der Verlauf nur 200 Zeilen
liefert: Eine Ansage von vorletzter Woche waere sonst genau dann weg,
wenn sie am laengsten oben stehen sollte. Wird die Nachricht
zurueckgenommen, faellt sie ab UND gibt den Platz frei.

DREI DINGE, DIE ERST DAS HINSEHEN GEZEIGT HAT:

  Der frisch angelegte Kanal hatte zwei Leute statt vier. Die
  Personenauswahl zeichnete nach der Rollenfolge aus bereiche.js -- wer
  dort nicht steht, wurde NICHT GEZEICHNET. Team Dogi steht dort nicht
  und darf es auch nicht (der Rollenname gehoert in keine Datei, die
  jeder herunterlaedt). Folge: DogFather konnte ueber die Auswahl
  niemandem aus seinem Team schreiben. Der Server schickt die
  Ueberschrift jetzt mit; der Browser braucht dafuer keinen
  Rollennamen. Der Kommentar, der genau davor warnte, stand die ganze
  Zeit darueber.

  Dieser Fehler war nebenbei ein Netz: Was nicht gezeichnet wird, kann
  auch nicht falsch gezeichnet werden. Deshalb ist jetzt gemessen, dass
  ein Manager und Spicy Media Team Dogi gar nicht erst geschickt
  bekommen -- und dabei fiel auf, dass Spicy Media in der EIGENEN
  Auswahl stand: Sobald es jemanden zu verbergen gibt, schreibt
  ohneVerborgene() aus "sieht alles" eine echte Liste, und darin steckt
  man selbst.

  Am Fuss jeder Nachricht stehen jetzt vier Handgriffe statt drei. Bei
  390 px -- der haeufigsten Handybreite -- stand "kopieren" 18 px ueber
  der Blase, bei 320 px 75. Behoben mit `flex-wrap: wrap` und nicht mit
  einer Schwelle: Eine Regel, die misst, bleibt beim fuenften Handgriff
  richtig; eine Zahl nicht. pruef-chat-optik misst es ab jetzt.

NACHGEZOGEN, was pruef-css-klassen an MEINEM letzten Commit fand:
teamlage.html lud kopf.js ohne wahl.js (der Sicht-Umschalter sah aus
wie aus einem anderen Programm -- kaputt war nichts, und genau deshalb
faellt es niemandem auf), und .tampel__tag stand auf 11,2 px. Beides
war schon gepusht, weil ich die Pruefung nicht laufen liess.

pruef-chat-kanaele 73 (neu) · pruef-chat 48 · pruef-chat-ausbau 64 ·
pruef-chat-anhaenge 60 · pruef-chat-optik 24 -> 26 · pruef-css-klassen
gruen · pruef-rollen 274 · pruef-modi-verborgen 78 · pruef-team-ampel 28
· pruef-start-ansicht gruen · pruef-modi-wortleck 5 ·
pruef-zwischenspeicher 21.

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

2026-09-10 20:18:04 +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

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

2026-09-06 16:28:58 +02:00