dogfather-universe

902 Commits 2 Branches 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
DogFatherGitandClaude Opus 5	6e46a08543	Portnummern werden abgeleitet, nicht mehr vergeben Gemessen: 165 Pruefdateien, 129 verschiedene Nummern -- NEUNZEHN doppelt, vier davon dreifach. Niemand hatte das gewollt; jede neue Pruefung wurde von einer vorhandenen abgeschrieben, und die Nummer kam mit. Meine eigene Notiz sagte "sieben" -- auch eine Bestandsliste altert. Der Waechter faengt den Schaden ab, aber er kann nur melden, was schon passiert ist: Zwei Pruefungen mit derselben Nummer koennen nie gleichzeitig laufen, und ein liegengebliebener Prozess der einen laesst die andere abbrechen mit einer Meldung, die wie ein Befund aussieht. Genau das ist mir am 20.09. zweimal passiert. Jetzt leitet jede Datei ihre Nummer aus ihrer STELLE IM ALPHABET ab (eigenerPort in helfer-port.mjs), zwei je Datei. Nicht ueber eine Pruefsumme: Bei 165 Namen in 4900 Nummern waeren nach dem Geburtstagsproblem rund DREI Zusammenstoesse zu erwarten -- ein Hash tauscht eine sichtbare Doppelung gegen eine unsichtbare. Die Stelle im Alphabet ist eindeutig von der Bauart her. --- ZWEI FEHLER AUF DEM WEG, BEIDE LEHRREICH ------------------------- 1. DER ERSTE VERSUCH WAR GRUEN UND KAPUTT. Ersetzt wurde mit einem Muster: "([^"]4231[^"])". Das hielt { host: "127.0.0.1", port: 4231, path: "/404.html" } fuer eine Zeichenkette -- ein Muster kann eine oeffnende nicht von einer schliessenden Anfuehrung unterscheiden. Heraus kam { host: "127.0.0.1`, port: ${PORT}, path: `/404.html" } also GUELTIGER Code ohne port-Feld. `node --check` sagte gruen fuer alle 164 Dateien. Aufgefallen ist es erst, weil ich vier Vertreter gegen eine vorher gemessene Grundlinie laufen liess: pruef-schranke 39/0 vorher, 38/1 nachher. Alles zurueckgenommen und mit einem Zerleger neu gemacht, der weiss, ob eine Stelle Code, Zeichenkette, Vorlage, Kommentar oder regulaerer Ausdruck ist. In pruef-ics stand die Nummer in einem regulaeren Ausdruck -- der wird jetzt gebaut statt hingeschrieben. 2. EIN MODUL, DAS BEIM IMPORTIEREN ARBEITET, IST EINE FALLE. Der zweite Durchgang importierte den ersten, um seine Mechanik zu benutzen -- und fuehrte dessen Hauptlauf gleich mit aus. Die zweiten Nummern wurden dadurch als erste behandelt, zwei Aufrufe bekamen dieselbe Nummer, und in pruef-content stand `const PORT` zweimal. --- WAS DAS DAUERHAFT HAELT ----------------------------------------- pruef-portnummern.mjs (neu, 8 Pruefungen) fragt nicht "welche Nummern sind doppelt", sondern "wer traegt ueberhaupt noch eine von Hand ein" und "wer startet einen Server, ohne seine Nummer abzuleiten". Die zweite Frage hat sofort etwas gefunden, das in KEINER Doppelungsliste stand: pruef-push-weg belegte 4341 und 4342, rief den Waechter aber gar nicht auf -- dieselbe Nummer wie pruef-agentur. Eine Liste zeigt nur, was auf ihr steht. Mit Gegenprobe: Eine unbekannte Datei bekommt keine geratene Nummer, sondern einen Abbruch, und eine dritte Nummer je Datei gibt es nicht. --- NACHGEMESSEN ---------------------------------------------------- Sechzehn Pruefungen gegen ihre vorher gemessene Grundlinie, je eine Vertreterin jeder umgestellten Bauweise (eine Nummer, zwei Nummern, Nummer in einer Zeichenkette, in einer Vorlage, in einem regulaeren Ausdruck, dynamische Einfuhr, Nachtlauf mit zwei Laeufen): crew-adresse 132/0 · schranke 39/0 · content 45/0 · entwicklung 46/0 anruf 127/0 · ics 37/0 · push-weg 20/0 · arten 28/0 · video 67/0 kanalzeile 14/0 · agentur 62/0 · spicy 83/0 · creator-anlegen 50/0 push-ziel 10/0 · portnummern 8/0 Alle exakt wie vorher. Zwei waren schon vorher rot und sind es unveraendert geblieben (crew-wand-bild 41/4, teilen 14/3) -- per `git stash` belegt, nicht angenommen. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-20 22:51:21 +02:00
DogFatherGitandClaude Opus 5	586eb51504	Profilfotos im Chat, rechte Hand zuerst, Karten lesbar ---- SCREEN 9: DIE FOTOS ------------------------------------------- Filipe: "da soll man im chat auch die profilfotos von den leuten sehen wenn die schon eins drin haben." ZWEI Luecken, beide an Stellen, wo ein Feld weggeworfen wurde: 1. Die GESPRAECHSLISTE bekam kein Bild. `teilnehmerVon` liest es aus der Datenbank, die Detailansicht nimmt es mit -- die Zeile fuer die Liste warf es weg. Folge: im offenen Gespraech ein Gesicht, in der Liste daneben ein Buchstabe. Vom selben Menschen. 2. Eine FRISCH GESENDETE Nachricht trug kein Bild. Der Verlauf beim Laden schon. Folge: Wer gerade zusieht, bekommt einen Buchstaben; wer neu laedt, ein Gesicht -- der Unterschied haengt nur daran, wann man geschaut hat. Der Buchstabe bleibt als Unterlage LIEGEN und wird nicht ersetzt: Laedt das Bild nicht, steht dort weiterhin etwas Sinnvolles statt eines kaputten Bildsymbols. Vier Stellen, ein Verhalten. ---- SCREEN 3: REIHENFOLGE UND AUSSEHEN ---------------------------- Filipe: "ich will dass hier wie ueberall die reihenfolge immer rechte hand und dan erst die modis." Die Abfrage sortierte nach `aktiv DESC, name` -- die ROLLE wurde nicht einmal mitgelesen. Die Seite konnte gar nicht wissen, wer rechte Hand ist; sie sortierte alphabetisch, und damit stand Diene vor Funny, weil D vor F kommt. Jetzt mit ROLLEN_SORTIERUNG -- derselben Regel, die auch Personenliste, Chat und Rechtetafel benutzen. "die kiste von rechte hand soll auch noch vieeeeeel krasser und spezieller aussehen ... der hintergrund von den kacheln soll auch viel krasser und geiler sein und so dass man texte und so besser erkennt. weil gerade ist es schwer lesbar." ZUERST DAS LESEN: Der Grund fuer die schlechte Lesbarkeit war der durchscheinende Untergrund -- die Karten lagen auf dem Buehnenbild, und ein Foto wird stellenweise hell. Sie bekommen jetzt eine DECKENDE Unterlage und erst darueber die Verlaeufe. Die Verlaeufe sieht man weiterhin, nur nicht mehr das Bild dahinter. DANN DAS BESONDERE: Die rechte Hand bekommt einen goldenen Ton, eine deutlich hellere Kante und eine schmale Leiste an der linken Seite -- man sieht den Rang aus zwei Metern, ohne ein Wort zu lesen. KEIN zweiter Bauplan: dieselbe Karte, dieselben Felder, nur ein Merkmal am Element. Zwei Karten zu bauen hiesse, jede kuenftige Aenderung zweimal zu machen. ---- EINE PRUEFUNG, DIE EINE POSITION FESTNAGELTE ------------------ `ok(leute[0]?.id === idMarina, "die Aktiven stehen oben")` wurde rot, sobald die rechte Hand nach vorn sortierte. Richtig wurde sie dadurch nicht: Die Aussage "die Aktiven stehen oben" hat mit Marinas Platz nichts zu tun. Jetzt prueft sie die EIGENSCHAFT (keine Pause vor einer Aktiven) -- eine Pruefung, die eine Position festnagelt, verbietet jede Umsortierung, auch die gewollte. GEPRUEFT: pruef-team-stufen 28/0 (zwei Aussagen mehr), pruef-erwaehnung 69/0 (zwei mehr: das Bild kommt in der Liste an, und wer keines hat, bekommt auch keines vorgegaukelt), pruef-css-klassen. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-20 19:07:06 +02:00
DogFatherGitandClaude Opus 5	2a26a49f91	Mit "@" jemanden im Chat ansprechen Filipe: "ich will das man die leute mit @ markieren kann im chat." MARKIEREN IST KEINE FARBE, SONDERN EINE ANSPRACHE. Sie funktioniert nur, wenn drei Dinge zusammen stimmen: Der Richtige ist gemeint, er MERKT es, und man sieht es im Satz. Fehlt eines davon, ist es eine Attrappe -- und zwar eine, die gut aussieht. WER GEMEINT IST, ENTSCHEIDET DER SERVER. Der Browser schickt nur Text. Damit wirkt ein von Hand getipptes "@VanVan" genauso wie eines aus der Auswahlliste, und niemand kann jemanden ansprechen, der gar nicht im Raum sitzt -- auch nicht ueber die Schnittstelle. Die Regeln stehen in server/chat-erwaehnung.js, jede mit Begruendung. Zwei davon sind keine Feinheit, sondern der Unterschied zwischen brauchbar und laestig: * Das Zeichen VOR dem "@" darf kein Buchstabe sein. Sonst piepst jede E-Mail-Adresse im Chat jemanden an ("[email protected]"). * Das Zeichen DANACH auch nicht, und der laengste Name gewinnt. Sonst spricht "@Tilikum" Tili an. MAN MERKT ES AUCH OHNE OFFENEN RAUM. Eine Zahl in der Gespraechsliste sagt "hier ist etwas" -- nicht, ob es an dich war. Wer morgens vier Raeume mit Zahlen sieht, macht den lautesten zuerst auf, und dort steht selten das, was auf ihn wartet. Jetzt steht ein "@" daneben. UND DIE MELDUNG AUFS HANDY SAGT ES: "VanVan hat dich erwaehnt" statt "Nachricht von VanVan". Als EIGENE Art, die sich getrennt abschalten laesst -- wer den lauten Chat stumm stellt, will trotzdem wissen, wenn ihn jemand direkt anspricht. Ohne Ausnahme von der Ruhezeit: Ein Anruf wartet auf eine Antwort, ein "@Anna" nicht. DIE AUSWAHL BEIM TIPPEN loest drei Dinge, die man sonst selbst wissen muesste: wie die Person genau heisst, wer ueberhaupt im Raum ist, und ob man sich vertippt hat. Tastatur zuerst (Pfeile, Enter, Tab, Escape). Sie erzwingt nichts -- wer weitertippt, schreibt einfach weiter. ZWEI RECHNUNGEN, EINE ANTWORT: Der Browser braucht dieselbe Aufloesung, um sofort hervorzuheben. Genau dort laufen Dinge auseinander, und dann haette die Seite jemanden hervorgehoben, den niemand benachrichtigt hat. pruef-erwaehnung LIEST die Browserfassung aus der Datei und fuehrt sie aus -- ein Nachbau wuerde pruefen, ob ich zweimal dasselbe schreiben kann. ---- DABEI GEFUNDEN: "gelesen bis 999999" ---------------------------- Der Server nahm fuer den Lesestand JEDE ganze Zahl an. Wer einmal eine Zahl hinter allem Vorhandenen schickte, sah in diesem Gespraech nie wieder einen Zaehler und nie wieder ein @-Zeichen: Alles Kuenftige galt als gelesen, bevor es geschrieben war. Das faellt niemandem als Zusammenhang auf -- man merkt nur, dass "die Benachrichtigungen nicht gehen". Der Browser schickt heute immer die letzte gesehene Nummer, ist also nicht der Grund. Aber eine Grenze, die nur davon lebt, dass der Aufrufer sich benimmt, ist keine. Jetzt wird auf die juengste Nachricht des Raums begrenzt -- abgeleitet, nicht geraten. Gefunden hat es meine eigene Pruefung: Sie setzte zum Aufraeumen 99999 und wunderte sich danach, warum das frische "@" nicht leuchtete. WOHER MAN ERFAEHRT, DASS ES DAS GIBT: Im Chat gibt es keinen Hilfeknopf. Der Hinweis steht deshalb im Leersatz einer neuen Gruppe -- dort, wo man beim ersten Oeffnen ohnehin hinsieht, und nur ab drei Leuten. In einem Zweiergespraech waere er Ballast. GEPRUEFT: pruef-erwaehnung 67/0 (neu) -- 13 Regelfaelle ohne Server, der Weg durch die Schnittstelle, das Zeichen in der Liste samt Gegenprobe bei jemandem, der dabei aber nicht gemeint war, beide Aufloesungen nebeneinander, und der ganze Ablauf am echten Bildschirm bis "Enter waehlt und schickt NICHT ab". Dazu pruef-chat 48/0, pruef-chat-optik 36/0, pruef-treffchat 110/0, pruef-chat-kanaele 79/0, pruef-glocke 31/0, pruef-push 24/0, pruef-anruf-klingelt, pruef-css-klassen, pruef-meldungen, pruef-nachfrage, pruef-tippziele. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-20 17:54:16 +02:00

Author

SHA1

Message

Date

DogFatherGitandClaude Opus 5

6e46a08543

Portnummern werden abgeleitet, nicht mehr vergeben

Gemessen: 165 Pruefdateien, 129 verschiedene Nummern -- NEUNZEHN
doppelt, vier davon dreifach. Niemand hatte das gewollt; jede neue
Pruefung wurde von einer vorhandenen abgeschrieben, und die Nummer kam
mit. Meine eigene Notiz sagte "sieben" -- auch eine Bestandsliste
altert.

Der Waechter faengt den Schaden ab, aber er kann nur melden, was schon
passiert ist: Zwei Pruefungen mit derselben Nummer koennen nie
gleichzeitig laufen, und ein liegengebliebener Prozess der einen laesst
die andere abbrechen mit einer Meldung, die wie ein Befund aussieht.
Genau das ist mir am 20.09. zweimal passiert.

Jetzt leitet jede Datei ihre Nummer aus ihrer STELLE IM ALPHABET ab
(eigenerPort in helfer-port.mjs), zwei je Datei. Nicht ueber eine
Pruefsumme: Bei 165 Namen in 4900 Nummern waeren nach dem
Geburtstagsproblem rund DREI Zusammenstoesse zu erwarten -- ein Hash
tauscht eine sichtbare Doppelung gegen eine unsichtbare. Die Stelle im
Alphabet ist eindeutig von der Bauart her.

--- ZWEI FEHLER AUF DEM WEG, BEIDE LEHRREICH -------------------------

1. DER ERSTE VERSUCH WAR GRUEN UND KAPUTT. Ersetzt wurde mit einem
   Muster: "([^"]*4231[^"]*)". Das hielt

     { host: "127.0.0.1", port: 4231, path: "/404.html" }

   fuer eine Zeichenkette -- ein Muster kann eine oeffnende nicht von
   einer schliessenden Anfuehrung unterscheiden. Heraus kam

     { host: "127.0.0.1`, port: ${PORT}, path: `/404.html" }

   also GUELTIGER Code ohne port-Feld. `node --check` sagte gruen fuer
   alle 164 Dateien. Aufgefallen ist es erst, weil ich vier Vertreter
   gegen eine vorher gemessene Grundlinie laufen liess: pruef-schranke
   39/0 vorher, 38/1 nachher.

   Alles zurueckgenommen und mit einem Zerleger neu gemacht, der weiss,
   ob eine Stelle Code, Zeichenkette, Vorlage, Kommentar oder
   regulaerer Ausdruck ist. In pruef-ics stand die Nummer in einem
   regulaeren Ausdruck -- der wird jetzt gebaut statt hingeschrieben.

2. EIN MODUL, DAS BEIM IMPORTIEREN ARBEITET, IST EINE FALLE. Der
   zweite Durchgang importierte den ersten, um seine Mechanik zu
   benutzen -- und fuehrte dessen Hauptlauf gleich mit aus. Die
   zweiten Nummern wurden dadurch als erste behandelt, zwei Aufrufe
   bekamen dieselbe Nummer, und in pruef-content stand `const PORT`
   zweimal.

--- WAS DAS DAUERHAFT HAELT -----------------------------------------

pruef-portnummern.mjs (neu, 8 Pruefungen) fragt nicht "welche Nummern
sind doppelt", sondern "wer traegt ueberhaupt noch eine von Hand ein"
und "wer startet einen Server, ohne seine Nummer abzuleiten". Die
zweite Frage hat sofort etwas gefunden, das in KEINER Doppelungsliste
stand: pruef-push-weg belegte 4341 und 4342, rief den Waechter aber
gar nicht auf -- dieselbe Nummer wie pruef-agentur. Eine Liste zeigt
nur, was auf ihr steht.

Mit Gegenprobe: Eine unbekannte Datei bekommt keine geratene Nummer,
sondern einen Abbruch, und eine dritte Nummer je Datei gibt es nicht.

--- NACHGEMESSEN ----------------------------------------------------

Sechzehn Pruefungen gegen ihre vorher gemessene Grundlinie, je eine
Vertreterin jeder umgestellten Bauweise (eine Nummer, zwei Nummern,
Nummer in einer Zeichenkette, in einer Vorlage, in einem regulaeren
Ausdruck, dynamische Einfuhr, Nachtlauf mit zwei Laeufen):

  crew-adresse 132/0 · schranke 39/0 · content 45/0 · entwicklung 46/0
  anruf 127/0 · ics 37/0 · push-weg 20/0 · arten 28/0 · video 67/0
  kanalzeile 14/0 · agentur 62/0 · spicy 83/0 · creator-anlegen 50/0
  push-ziel 10/0 · portnummern 8/0

Alle exakt wie vorher. Zwei waren schon vorher rot und sind es
unveraendert geblieben (crew-wand-bild 41/4, teilen 14/3) -- per
`git stash` belegt, nicht angenommen.

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

2026-09-20 22:51:21 +02:00

DogFatherGitandClaude Opus 5

586eb51504

Profilfotos im Chat, rechte Hand zuerst, Karten lesbar

---- SCREEN 9: DIE FOTOS -------------------------------------------

Filipe: "da soll man im chat auch die profilfotos von den leuten sehen
wenn die schon eins drin haben."

ZWEI Luecken, beide an Stellen, wo ein Feld weggeworfen wurde:

1. Die GESPRAECHSLISTE bekam kein Bild. `teilnehmerVon` liest es aus
   der Datenbank, die Detailansicht nimmt es mit -- die Zeile fuer die
   Liste warf es weg. Folge: im offenen Gespraech ein Gesicht, in der
   Liste daneben ein Buchstabe. Vom selben Menschen.

2. Eine FRISCH GESENDETE Nachricht trug kein Bild. Der Verlauf beim
   Laden schon. Folge: Wer gerade zusieht, bekommt einen Buchstaben;
   wer neu laedt, ein Gesicht -- der Unterschied haengt nur daran, wann
   man geschaut hat.

Der Buchstabe bleibt als Unterlage LIEGEN und wird nicht ersetzt: Laedt
das Bild nicht, steht dort weiterhin etwas Sinnvolles statt eines
kaputten Bildsymbols. Vier Stellen, ein Verhalten.

---- SCREEN 3: REIHENFOLGE UND AUSSEHEN ----------------------------

Filipe: "ich will dass hier wie ueberall die reihenfolge immer rechte
hand und dan erst die modis."

Die Abfrage sortierte nach `aktiv DESC, name` -- die ROLLE wurde nicht
einmal mitgelesen. Die Seite konnte gar nicht wissen, wer rechte Hand
ist; sie sortierte alphabetisch, und damit stand Diene vor Funny, weil
D vor F kommt. Jetzt mit ROLLEN_SORTIERUNG -- derselben Regel, die auch
Personenliste, Chat und Rechtetafel benutzen.

"die kiste von rechte hand soll auch noch vieeeeeel krasser und
spezieller aussehen ... der hintergrund von den kacheln soll auch viel
krasser und geiler sein und so dass man texte und so besser erkennt.
weil gerade ist es schwer lesbar."

ZUERST DAS LESEN: Der Grund fuer die schlechte Lesbarkeit war der
durchscheinende Untergrund -- die Karten lagen auf dem Buehnenbild, und
ein Foto wird stellenweise hell. Sie bekommen jetzt eine DECKENDE
Unterlage und erst darueber die Verlaeufe. Die Verlaeufe sieht man
weiterhin, nur nicht mehr das Bild dahinter.

DANN DAS BESONDERE: Die rechte Hand bekommt einen goldenen Ton, eine
deutlich hellere Kante und eine schmale Leiste an der linken Seite --
man sieht den Rang aus zwei Metern, ohne ein Wort zu lesen. KEIN
zweiter Bauplan: dieselbe Karte, dieselben Felder, nur ein Merkmal am
Element. Zwei Karten zu bauen hiesse, jede kuenftige Aenderung zweimal
zu machen.

---- EINE PRUEFUNG, DIE EINE POSITION FESTNAGELTE ------------------

`ok(leute[0]?.id === idMarina, "die Aktiven stehen oben")` wurde rot,
sobald die rechte Hand nach vorn sortierte. Richtig wurde sie dadurch
nicht: Die Aussage "die Aktiven stehen oben" hat mit Marinas Platz
nichts zu tun. Jetzt prueft sie die EIGENSCHAFT (keine Pause vor einer
Aktiven) -- eine Pruefung, die eine Position festnagelt, verbietet jede
Umsortierung, auch die gewollte.

GEPRUEFT: pruef-team-stufen 28/0 (zwei Aussagen mehr),
pruef-erwaehnung 69/0 (zwei mehr: das Bild kommt in der Liste an, und
wer keines hat, bekommt auch keines vorgegaukelt), pruef-css-klassen.

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

2026-09-20 19:07:06 +02:00

DogFatherGitandClaude Opus 5

2a26a49f91

Mit "@" jemanden im Chat ansprechen

Filipe: "ich will das man die leute mit @ markieren kann im chat."

MARKIEREN IST KEINE FARBE, SONDERN EINE ANSPRACHE. Sie funktioniert
nur, wenn drei Dinge zusammen stimmen: Der Richtige ist gemeint, er
MERKT es, und man sieht es im Satz. Fehlt eines davon, ist es eine
Attrappe -- und zwar eine, die gut aussieht.

WER GEMEINT IST, ENTSCHEIDET DER SERVER. Der Browser schickt nur Text.
Damit wirkt ein von Hand getipptes "@VanVan" genauso wie eines aus der
Auswahlliste, und niemand kann jemanden ansprechen, der gar nicht im
Raum sitzt -- auch nicht ueber die Schnittstelle.

Die Regeln stehen in server/chat-erwaehnung.js, jede mit Begruendung.
Zwei davon sind keine Feinheit, sondern der Unterschied zwischen
brauchbar und laestig:

  * Das Zeichen VOR dem "@" darf kein Buchstabe sein. Sonst piepst
    jede E-Mail-Adresse im Chat jemanden an
    ("[email protected]").
  * Das Zeichen DANACH auch nicht, und der laengste Name gewinnt.
    Sonst spricht "@Tilikum" Tili an.

MAN MERKT ES AUCH OHNE OFFENEN RAUM. Eine Zahl in der Gespraechsliste
sagt "hier ist etwas" -- nicht, ob es an dich war. Wer morgens vier
Raeume mit Zahlen sieht, macht den lautesten zuerst auf, und dort
steht selten das, was auf ihn wartet. Jetzt steht ein "@" daneben.

UND DIE MELDUNG AUFS HANDY SAGT ES: "VanVan hat dich erwaehnt" statt
"Nachricht von VanVan". Als EIGENE Art, die sich getrennt abschalten
laesst -- wer den lauten Chat stumm stellt, will trotzdem wissen, wenn
ihn jemand direkt anspricht. Ohne Ausnahme von der Ruhezeit: Ein Anruf
wartet auf eine Antwort, ein "@Anna" nicht.

DIE AUSWAHL BEIM TIPPEN loest drei Dinge, die man sonst selbst wissen
muesste: wie die Person genau heisst, wer ueberhaupt im Raum ist, und
ob man sich vertippt hat. Tastatur zuerst (Pfeile, Enter, Tab, Escape).
Sie erzwingt nichts -- wer weitertippt, schreibt einfach weiter.

ZWEI RECHNUNGEN, EINE ANTWORT: Der Browser braucht dieselbe Aufloesung,
um sofort hervorzuheben. Genau dort laufen Dinge auseinander, und dann
haette die Seite jemanden hervorgehoben, den niemand benachrichtigt
hat. pruef-erwaehnung LIEST die Browserfassung aus der Datei und fuehrt
sie aus -- ein Nachbau wuerde pruefen, ob ich zweimal dasselbe
schreiben kann.

---- DABEI GEFUNDEN: "gelesen bis 999999" ----------------------------

Der Server nahm fuer den Lesestand JEDE ganze Zahl an. Wer einmal eine
Zahl hinter allem Vorhandenen schickte, sah in diesem Gespraech nie
wieder einen Zaehler und nie wieder ein @-Zeichen: Alles Kuenftige galt
als gelesen, bevor es geschrieben war. Das faellt niemandem als
Zusammenhang auf -- man merkt nur, dass "die Benachrichtigungen nicht
gehen".

Der Browser schickt heute immer die letzte gesehene Nummer, ist also
nicht der Grund. Aber eine Grenze, die nur davon lebt, dass der
Aufrufer sich benimmt, ist keine. Jetzt wird auf die juengste
Nachricht des Raums begrenzt -- abgeleitet, nicht geraten.

Gefunden hat es meine eigene Pruefung: Sie setzte zum Aufraeumen 99999
und wunderte sich danach, warum das frische "@" nicht leuchtete.

WOHER MAN ERFAEHRT, DASS ES DAS GIBT: Im Chat gibt es keinen
Hilfeknopf. Der Hinweis steht deshalb im Leersatz einer neuen Gruppe --
dort, wo man beim ersten Oeffnen ohnehin hinsieht, und nur ab drei
Leuten. In einem Zweiergespraech waere er Ballast.

GEPRUEFT: pruef-erwaehnung 67/0 (neu) -- 13 Regelfaelle ohne Server,
der Weg durch die Schnittstelle, das Zeichen in der Liste samt
Gegenprobe bei jemandem, der dabei aber nicht gemeint war, beide
Aufloesungen nebeneinander, und der ganze Ablauf am echten Bildschirm
bis "Enter waehlt und schickt NICHT ab".
Dazu pruef-chat 48/0, pruef-chat-optik 36/0, pruef-treffchat 110/0,
pruef-chat-kanaele 79/0, pruef-glocke 31/0, pruef-push 24/0,
pruef-anruf-klingelt, pruef-css-klassen, pruef-meldungen,
pruef-nachfrage, pruef-tippziele.

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

2026-09-20 17:54:16 +02:00