dogfather-universe

DogFatherGit/dogfather-universe

Fork 0

Commit Graph

Author	SHA1	Message	Date
DogFatherGitandClaude Opus 5	c5e3ab1c44	Zwei Meldungen aus dem Support: Auswahlmenues und die Stelle im Chat DIENE: "Beim Kalender laesst sich die Art noch nicht einstellen, das Menue ploppt nur ganz kurz auf und verschwindet direkt wieder. Das selbe bei den Wiederholungen." In wahl.js stand `addEventListener('resize', schliessen)`. Auf dem Rechner ist das harmlos -- dort aendert sich die Fenstergroesse nur, wenn jemand sie aendert. Auf einem Handy aendert sie sich BEIM BEDIENEN: Die Adressleiste faehrt beim kleinsten Scrollen ein und aus, die Tastatur kommt und geht, und jedes Mal feuert `resize`. Die Liste ging auf, der Browser meldete eine neue Hoehe, und sie war wieder zu. Es ist derselbe Fehler wie am 04.09. beim Scrollen ("wenn ich da scollen will geht das immer zu"), nur eine Zeile tiefer: Ein Ereignis, das beim BEDIENEN entsteht, wird als Grund zum Abbrechen genommen. Jetzt wird die Liste neu ausgerichtet statt geschlossen -- `stelle()` kann das ohnehin, und nach einer Groessenaenderung muss sie es sowieso. pruef-suchfeld 8 -> 15, an Dienes genauem Fall: Kalenderformular, beide Felder, echte Groessenaenderung dazwischen. Gemessen wird nicht nur "offen", sondern auch "sitzt noch am Knopf" (6 px) -- offen, aber verrutscht waere nur die halbe Antwort. Gegenprobe: mit der alten Zeile 4 Fehler. ---------------------------------------------------------------------- MISS: "Wenn ich auf den Chat gehen, komme ich zuerst auf die erste neue Nachricht, aber kurze Zeit spaeter springt er auf die zuletzt geschrieben Nachricht." In chat.js stand `unten = true; neuUnten = 0;` AUSSERHALB von `if (!sanft)` -- es lief also bei jedem Nachladen, auch beim sanften, das staendig passiert (Strom verbindet, jemand heftet etwas an, eine Nachricht kommt). Solange die Neu-Linie steht, faellt das nicht auf: Der Zweig darueber springt dorthin und kehrt zurueck, bevor `unten` gelesen wird. Die zweite Haelfte ist `wache` -- sie loescht den Sprung-Merker beim ersten FINGERTIPP auf den Verlauf, und das ist richtig so. Ab da ist der Weg frei, und das naechste sanfte Nachladen findet `unten === true` vor und reisst die Ansicht ans Ende. Genau ihre "kurze Zeit spaeter". Ein sanftes Nachladen ist kein Oeffnen. Wo jemand steht, weiss ab jetzt allein der Scroll-Horcher -- und der misst es, statt es anzunehmen. DREI FEHLVERSUCHE BIS ZUR MESSUNG, und sie gehoeren ins Protokoll: Erst sechs Sekunden Nichtstun, dann ein Fingertipp auf Koordinaten, dann ein Verbindungsabriss -- alle drei waren mit dem ALTEN Code gruen. Eine Pruefung, die den Fehler nicht herstellt, misst nichts, und ich haette sie beinahe als Beweis genommen. Was fehlte: Der Griff muss den Verlauf WIRKLICH treffen (Koordinaten gehen daneben), und es braucht einen echten sanften Nachlauf -- hier das Anheften, das ein `pin`-Ereignis an alle im Raum schickt. Erst damit flippt die Gegenprobe: ohne Korrektur 500 -> 7054 px und `amEnde: true`, mit Korrektur bleibt es bei 500. pruef-chat-neu-stelle 62 -> 69. Unterwegs wieder entfernt: ein Merker `schonGesprungen`, den ich zuerst eingebaut hatte. Nach der echten Korrektur ist er unerreichbar, und ich konnte ihn mit keiner Messung zum Greifen bringen. Ein Zweig, den nichts erreicht, sieht beim Lesen aus wie ein Fall, den es gibt. Gegengemessen: pruef-chat 80, pruef-chat-optik 84, pruef-freie-namen 32 -- 0 Fehler. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-10-05 22:41:18 +02:00
DogFatherGit	077925ab25	Dreizehn rote Pruefungen, eine Ursache: openssl steht nicht im PATH DER BEFUND Im naechtlichen Lauf standen dreizehn Pruefungen mit derselben Zeile rot: [uncaughtException] Error: spawnSync openssl ENOENT Kein Programmfehler. Die Pruefungen brauchen einen https-Vorbau (der Sitzungskeks des Hauses ist `secure` und kommt ueber http nicht an), und dafuer erzeugen sie ein Wegwerf-Zertifikat mit openssl. GEMESSEN, NICHT VERMUTET openssl liegt hier: C:\Program Files\Git\mingw64\bin\openssl.exe C:\Program Files\Git\usr\bin\openssl.exe im System-PATH steht: C:\Program Files\Git\cmd (nur git.exe) im Benutzer-PATH: nichts mit Git Wer aus Git Bash startet, erbt die mingw-Pfade und merkt nie etwas. Die Aufgabenplanung startet `node.exe` DIREKT, ohne Shell -- und bekommt sie nicht. Bei mir gruen, nachts rot, und der Grund steht nicht im Code. Das Schlimmste daran ist nicht der Ausfall: Dreizehn dauerhaft rote Zeilen in einer Notiz, die Filipe morgens liest, gewoehnen einem das Hinsehen ab -- und decken dabei die echten Befunde zu. DIE REPARATUR `server/helfer-openssl.mjs` sucht openssl erst im PATH (ohne `where` oder `which` -- beides sind selbst Programme und koennen genauso fehlen), danach an den Orten, an denen es auf einem Windows-Rechner mit Git wirklich liegt. Dazu `zertifikatBauen(schluessel, zertifikat, host)`. Die acht Aufrufformen im Haus waren identisch bis auf die Variablennamen (schl/zert, schluesselDatei/zertDatei, zKey/zCrt, sk/zt, key/crt) -- eine Stelle traegt alle neunundzwanzig. Zwei Tage zuvor war eine davon um ein `-addext` aermer als die anderen; gemerkt hat es niemand, weil der Browser den fehlenden Alternativnamen erst bei einer Weiterleitung anmahnt. Eine Stelle kann nicht von sich selbst abweichen. KEIN EINTRAG IN DEN SYSTEM-PATH. `mingw64\bin` enthaelt rund hundert Programme mit Unix-Namen (`find`, `sort`, `link`), die gleichnamige Windows-Befehle verdecken. Das fuer eine Pruefung zu aendern haette an ganz anderen Stellen Fehler verursacht, die niemand hierher zurueckverfolgt. GEGENPROBE IN BEIDE RICHTUNGEN, mit dem PATH des Nachtlaufs: vorher (direkter Aufruf): ABSTURZ: spawnSync openssl ENOENT nachher (ueber den Helfer): Zertifikat gebaut, 1236 Bytes Und eine echte Pruefung unter denselben Bedingungen: PATH ohne mingw64 -> pruef-chat-neu-stelle 63 Pruefungen, 0 Fehler, 0 Abstuerze Genau diese Datei stand im Nachtlauf mit ENOENT rot. EINE WACHE DAGEGEN pruef-struktur prueft ab jetzt, dass niemand openssl wieder direkt ruft -- der naechste merkt es dort und nicht erst in einem Nachtlauf, den niemand liest. Drei Gegenproben. Beim ersten Anlauf schlug sie auf ihre EIGENEN Probetexte an: Sie liest alle Serverdateien, und dazu gehoert sie selbst. Die Texte werden jetzt zusammengesetzt. Derselbe Selbsttreffer ist mir heute schon zweimal passiert. DER DRITTE AUSGANG BLEIBT, WO ER HINGEHOERT `helfer-kachel-echtfarbe.mjs` faengt den Fehler weiterhin ab und meldet `moeglich: false` mit Grund, statt abzubrechen. Eine Sicherung abzuschaffen, weil ihr Anlass gerade behoben ist, ist der Anfang des naechsten stillen Fehlschlags. NEBENBEI: pruef-community-sicht Sie war rot mit "ZU VIEL: reaktion.html" -- mein eigener Rueckstand vom 28.09. Die Reaction steht als Kachel im Community-Bereich; die Liste war nicht nachgezogen. Jetzt 10 / 0. Die Liste bleibt bewusst von Hand gepflegt: Sie ist eine ABSICHT, keine Ableitung. Aus rechte.js gelesen verglichen sich zwei Kopien derselben Quelle -- immer gruen, nie ein Beweis. GEPRUEFT pruef-struktur ALLES IN ORDNUNG (mit der neuen Wache) pruef-community-sicht 10 / 0 pruef-chat-neu-stelle 63 / 0 (mit dem PATH des Nachtlaufs) pruef-notizen, -teamlage-karten, -werdegang: EXIT 0, keine Abstuerze mess-quer EXIT 0 29 Dateien: node --check auf allen, kein direkter Aufruf mehr	2026-09-29 16:14:13 +02:00
DogFatherGitandClaude Opus 5	cdb6c46f8b	Der Chat oeffnet dort, wo das Neue anfaengt -- bei allen sechs Rollen Filipe: "wenn ich in den chat rein gehe und es neue kommentare gibt, will ich dass mein chat sich da öffnet wo die neuen nachrichten anfangen die ich noch nicht gesehen hab bitte und nicht immer ganz unten. sonst muss man immer hoch scrollen um die neuen zu lesen und das ist scheisse. perfektionier das bei allen rollen." DIE FUNKTION GAB ES SEIT DEM 09.09.2026 -- eine Linie „Ab hier neu" und einen Sprung darauf. Sie hat trotzdem nicht funktioniert, und zwar aus DREI Gruenden, die sich gegenseitig verdeckt haben. Gefunden hat sie keine Ueberlegung, sondern eine Messung in Pixeln: Wie weit ist die Linie vom oberen Rand entfernt? Ein negativer Wert heisst „darueber", also unsichtbar. 1. DER SPRUNG RECHNETE GEGEN DEN FALSCHEN PUNKT. `linie.offsetTop` ist der Abstand zum `offsetParent` -- und das ist nur dann der Verlauf, wenn dieser `position: relative` traegt. Tut er nicht. Gemessen auf 390 px landete die Linie 23 px OBERHALB des sichtbaren Bereichs: Man musste genau das tun, was Filipe nicht mehr tun wollte. Am Rechner stimmte es zufaellig, weil dort weniger dazwischenliegt -- deshalb ist es nie aufgefallen. Jetzt: Oberkante der Linie minus Oberkante des Verlaufs plus dessen Bildlaufposition. Das gilt immer, egal wer wessen offsetParent ist. 2. JEDES NACHLADEN LOESCHTE DIE LINIE. `gelesenBeimOeffnen` wurde bei JEDEM Aufruf gesetzt, auch beim sanften Nachladen. Sanft laedt der Verlauf staendig nach -- vor allem, wenn der Ereignisstrom sich verbindet. Die Seite laedt, zeichnet, meldet „gelesen bis hier", der Strom verbindet sich, laedt sanft nach -- und jetzt steht in `gelesen_bis` schon die letzte Nachricht. Keine Linie mehr, Sprung ans Ende. DAS IST DER FEHLER, DEN FILIPE GESEHEN HAT. Und er wuerfelte: Kommt die Verbindung vor dem ersten Zeichnen, passiert nichts; danach ist die Linie weg. Ueber sechs Rollen gemessen waren mal drei rot, mal zwei, mal andere -- bei unveraendertem Code. 3. UND EIN EINZIGER SPRUNG REICHT NICHT. Zwischen Sprung und fertigem Bild waechst die Hoehe noch: Schriften kommen an und setzen den Text um, Bilder melden ihre Groesse. Jetzt wird nachgezogen -- nach den Schriften, nach jedem Bild, nach zwei Bildwiederholungen -- und die Stelle haelt, bis der Mensch selbst scrollt. „Ich habe dich an die neue Stelle gesetzt" ist eine Zusage; sie beim naechsten Nachladen zu brechen waere schlimmer, als sie nie gegeben zu haben. GEMESSEN -- server/pruef-chat-neu-stelle.mjs (neu), 63 Pruefungen, 0 Fehler, zweimal hintereinander mit demselben Ergebnis: Sechs Rollen in beiden Haeusern (DogFather, rechte Hand, linke Hand, Modi auf crew.; Manager und Creator auf workspace.), je auf Handy (390 px) und Rechner (1280 px). Je Blick: Steht die Linie im Verlauf? Ist sie zu SEHEN? Steht Zusammenhang darueber? Und ist der Verlauf NICHT am Ende? Ergebnis: 115-118 px unter dem oberen Rand am Handy, 150-153 px am Rechner -- darueber jeweils die letzte alte Nachricht. Dazu drei Gegenproben: Ohne Ungelesenes gibt es keine Linie und der Verlauf steht am Ende (sonst laendete man grundlos mitten im Verlauf); und die Messung erkennt „nicht sichtbar" auch wirklich (-1403 px an einem absichtlich nach unten gescrollten Verlauf) -- sonst waere jede gruene Zeile darueber wertlos. DIE PRUEFUNG SELBST HAT ZWEIMAL DAS FALSCHE GEMESSEN, bevor sie das Richtige maass, und beides steht als Begruendung darin: Sie schickte `/gelesen` ohne `bis` (die Route verlangt eine Nummer und lehnt sonst ab -- der Lesestand blieb null, die Linie entstand nie), und sie benutzte einen Raum je Rolle fuer zwei Blicke, was einen Wettlauf mit der „gelesen"-Meldung erzeugte. Jetzt bekommt jeder Blick seinen eigenen Raum: mehr Aufbau, dafuer immer dasselbe Ergebnis. pruef-chat 63/0, pruef-chat-optik 62/0, pruef-chat-kanaele 81/0, pruef-treffchat 110/0, pruef-chat-neu 36/0, pruef-pin-fuer-mich 37/0, pruef-erwaehnung 129/0, pruef-gifs 17/0. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-25 14:40:01 +02:00

Author

SHA1

Message

Date

DogFatherGitandClaude Opus 5

c5e3ab1c44

Zwei Meldungen aus dem Support: Auswahlmenues und die Stelle im Chat

DIENE: "Beim Kalender laesst sich die Art noch nicht einstellen, das
Menue ploppt nur ganz kurz auf und verschwindet direkt wieder. Das
selbe bei den Wiederholungen."

In wahl.js stand `addEventListener('resize', schliessen)`. Auf dem
Rechner ist das harmlos -- dort aendert sich die Fenstergroesse nur,
wenn jemand sie aendert. Auf einem Handy aendert sie sich BEIM
BEDIENEN: Die Adressleiste faehrt beim kleinsten Scrollen ein und
aus, die Tastatur kommt und geht, und jedes Mal feuert `resize`. Die
Liste ging auf, der Browser meldete eine neue Hoehe, und sie war
wieder zu.

Es ist derselbe Fehler wie am 04.09. beim Scrollen ("wenn ich da
scollen will geht das immer zu"), nur eine Zeile tiefer: Ein
Ereignis, das beim BEDIENEN entsteht, wird als Grund zum Abbrechen
genommen. Jetzt wird die Liste neu ausgerichtet statt geschlossen --
`stelle()` kann das ohnehin, und nach einer Groessenaenderung muss
sie es sowieso.

pruef-suchfeld 8 -> 15, an Dienes genauem Fall: Kalenderformular,
beide Felder, echte Groessenaenderung dazwischen. Gemessen wird nicht
nur "offen", sondern auch "sitzt noch am Knopf" (6 px) -- offen, aber
verrutscht waere nur die halbe Antwort. Gegenprobe: mit der alten
Zeile 4 Fehler.

----------------------------------------------------------------------

MISS: "Wenn ich auf den Chat gehen, komme ich zuerst auf die erste
neue Nachricht, aber kurze Zeit spaeter springt er auf die zuletzt
geschrieben Nachricht."

In chat.js stand `unten = true; neuUnten = 0;` AUSSERHALB von
`if (!sanft)` -- es lief also bei jedem Nachladen, auch beim sanften,
das staendig passiert (Strom verbindet, jemand heftet etwas an, eine
Nachricht kommt).

Solange die Neu-Linie steht, faellt das nicht auf: Der Zweig darueber
springt dorthin und kehrt zurueck, bevor `unten` gelesen wird. Die
zweite Haelfte ist `wache` -- sie loescht den Sprung-Merker beim
ersten FINGERTIPP auf den Verlauf, und das ist richtig so. Ab da ist
der Weg frei, und das naechste sanfte Nachladen findet `unten ===
true` vor und reisst die Ansicht ans Ende. Genau ihre "kurze Zeit
spaeter".

Ein sanftes Nachladen ist kein Oeffnen. Wo jemand steht, weiss ab
jetzt allein der Scroll-Horcher -- und der misst es, statt es
anzunehmen.

DREI FEHLVERSUCHE BIS ZUR MESSUNG, und sie gehoeren ins Protokoll:
Erst sechs Sekunden Nichtstun, dann ein Fingertipp auf Koordinaten,
dann ein Verbindungsabriss -- alle drei waren mit dem ALTEN Code
gruen. Eine Pruefung, die den Fehler nicht herstellt, misst nichts,
und ich haette sie beinahe als Beweis genommen. Was fehlte: Der Griff
muss den Verlauf WIRKLICH treffen (Koordinaten gehen daneben), und es
braucht einen echten sanften Nachlauf -- hier das Anheften, das ein
`pin`-Ereignis an alle im Raum schickt.

Erst damit flippt die Gegenprobe: ohne Korrektur 500 -> 7054 px und
`amEnde: true`, mit Korrektur bleibt es bei 500.

pruef-chat-neu-stelle 62 -> 69.

Unterwegs wieder entfernt: ein Merker `schonGesprungen`, den ich
zuerst eingebaut hatte. Nach der echten Korrektur ist er
unerreichbar, und ich konnte ihn mit keiner Messung zum Greifen
bringen. Ein Zweig, den nichts erreicht, sieht beim Lesen aus wie ein
Fall, den es gibt.

Gegengemessen: pruef-chat 80, pruef-chat-optik 84, pruef-freie-namen
32 -- 0 Fehler.

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

2026-10-05 22:41:18 +02:00

DogFatherGit

077925ab25

Dreizehn rote Pruefungen, eine Ursache: openssl steht nicht im PATH

DER BEFUND

Im naechtlichen Lauf standen dreizehn Pruefungen mit derselben Zeile
rot:

    [uncaughtException] Error: spawnSync openssl ENOENT

Kein Programmfehler. Die Pruefungen brauchen einen https-Vorbau (der
Sitzungskeks des Hauses ist `secure` und kommt ueber http nicht an),
und dafuer erzeugen sie ein Wegwerf-Zertifikat mit openssl.

GEMESSEN, NICHT VERMUTET

  openssl liegt hier:   C:\Program Files\Git\mingw64\bin\openssl.exe
                        C:\Program Files\Git\usr\bin\openssl.exe
  im System-PATH steht: C:\Program Files\Git\cmd   (nur git.exe)
  im Benutzer-PATH:     nichts mit Git

Wer aus Git Bash startet, erbt die mingw-Pfade und merkt nie etwas.
Die Aufgabenplanung startet `node.exe` DIREKT, ohne Shell -- und
bekommt sie nicht. Bei mir gruen, nachts rot, und der Grund steht
nicht im Code.

Das Schlimmste daran ist nicht der Ausfall: Dreizehn dauerhaft rote
Zeilen in einer Notiz, die Filipe morgens liest, gewoehnen einem das
Hinsehen ab -- und decken dabei die echten Befunde zu.

DIE REPARATUR

`server/helfer-openssl.mjs` sucht openssl erst im PATH (ohne `where`
oder `which` -- beides sind selbst Programme und koennen genauso
fehlen), danach an den Orten, an denen es auf einem Windows-Rechner
mit Git wirklich liegt.

Dazu `zertifikatBauen(schluessel, zertifikat, host)`. Die acht
Aufrufformen im Haus waren identisch bis auf die Variablennamen
(schl/zert, schluesselDatei/zertDatei, zKey/zCrt, sk/zt, key/crt) --
eine Stelle traegt alle neunundzwanzig. Zwei Tage zuvor war eine
davon um ein `-addext` aermer als die anderen; gemerkt hat es
niemand, weil der Browser den fehlenden Alternativnamen erst bei
einer Weiterleitung anmahnt. Eine Stelle kann nicht von sich selbst
abweichen.

KEIN EINTRAG IN DEN SYSTEM-PATH. `mingw64\bin` enthaelt rund hundert
Programme mit Unix-Namen (`find`, `sort`, `link`), die gleichnamige
Windows-Befehle verdecken. Das fuer eine Pruefung zu aendern haette
an ganz anderen Stellen Fehler verursacht, die niemand hierher
zurueckverfolgt.

GEGENPROBE IN BEIDE RICHTUNGEN, mit dem PATH des Nachtlaufs:

  vorher (direkter Aufruf):  ABSTURZ: spawnSync openssl ENOENT
  nachher (ueber den Helfer): Zertifikat gebaut, 1236 Bytes

Und eine echte Pruefung unter denselben Bedingungen:

  PATH ohne mingw64 -> pruef-chat-neu-stelle
  63 Pruefungen, 0 Fehler, 0 Abstuerze

Genau diese Datei stand im Nachtlauf mit ENOENT rot.

EINE WACHE DAGEGEN

pruef-struktur prueft ab jetzt, dass niemand openssl wieder direkt
ruft -- der naechste merkt es dort und nicht erst in einem
Nachtlauf, den niemand liest. Drei Gegenproben.

Beim ersten Anlauf schlug sie auf ihre EIGENEN Probetexte an: Sie
liest alle Serverdateien, und dazu gehoert sie selbst. Die Texte
werden jetzt zusammengesetzt. Derselbe Selbsttreffer ist mir heute
schon zweimal passiert.

DER DRITTE AUSGANG BLEIBT, WO ER HINGEHOERT

`helfer-kachel-echtfarbe.mjs` faengt den Fehler weiterhin ab und
meldet `moeglich: false` mit Grund, statt abzubrechen. Eine
Sicherung abzuschaffen, weil ihr Anlass gerade behoben ist, ist der
Anfang des naechsten stillen Fehlschlags.

NEBENBEI: pruef-community-sicht

Sie war rot mit "ZU VIEL: reaktion.html" -- mein eigener Rueckstand
vom 28.09. Die Reaction steht als Kachel im Community-Bereich; die
Liste war nicht nachgezogen. Jetzt 10 / 0.

Die Liste bleibt bewusst von Hand gepflegt: Sie ist eine ABSICHT,
keine Ableitung. Aus rechte.js gelesen verglichen sich zwei Kopien
derselben Quelle -- immer gruen, nie ein Beweis.

GEPRUEFT
  pruef-struktur         ALLES IN ORDNUNG (mit der neuen Wache)
  pruef-community-sicht  10 / 0
  pruef-chat-neu-stelle  63 / 0  (mit dem PATH des Nachtlaufs)
  pruef-notizen, -teamlage-karten, -werdegang: EXIT 0, keine Abstuerze
  mess-quer              EXIT 0
  29 Dateien: node --check auf allen, kein direkter Aufruf mehr

2026-09-29 16:14:13 +02:00

DogFatherGitandClaude Opus 5

cdb6c46f8b

Der Chat oeffnet dort, wo das Neue anfaengt -- bei allen sechs Rollen

Filipe: "wenn ich in den chat rein gehe und es neue kommentare gibt,
will ich dass mein chat sich da öffnet wo die neuen nachrichten anfangen
die ich noch nicht gesehen hab bitte und nicht immer ganz unten. sonst
muss man immer hoch scrollen um die neuen zu lesen und das ist scheisse.
perfektionier das bei allen rollen."

DIE FUNKTION GAB ES SEIT DEM 09.09.2026 -- eine Linie „Ab hier neu" und
einen Sprung darauf. Sie hat trotzdem nicht funktioniert, und zwar aus
DREI Gruenden, die sich gegenseitig verdeckt haben. Gefunden hat sie
keine Ueberlegung, sondern eine Messung in Pixeln: Wie weit ist die
Linie vom oberen Rand entfernt? Ein negativer Wert heisst „darueber",
also unsichtbar.

1. DER SPRUNG RECHNETE GEGEN DEN FALSCHEN PUNKT.
   `linie.offsetTop` ist der Abstand zum `offsetParent` -- und das ist
   nur dann der Verlauf, wenn dieser `position: relative` traegt. Tut
   er nicht. Gemessen auf 390 px landete die Linie 23 px OBERHALB des
   sichtbaren Bereichs: Man musste genau das tun, was Filipe nicht mehr
   tun wollte. Am Rechner stimmte es zufaellig, weil dort weniger
   dazwischenliegt -- deshalb ist es nie aufgefallen.
   Jetzt: Oberkante der Linie minus Oberkante des Verlaufs plus dessen
   Bildlaufposition. Das gilt immer, egal wer wessen offsetParent ist.

2. JEDES NACHLADEN LOESCHTE DIE LINIE.
   `gelesenBeimOeffnen` wurde bei JEDEM Aufruf gesetzt, auch beim
   sanften Nachladen. Sanft laedt der Verlauf staendig nach -- vor
   allem, wenn der Ereignisstrom sich verbindet. Die Seite laedt,
   zeichnet, meldet „gelesen bis hier", der Strom verbindet sich, laedt
   sanft nach -- und jetzt steht in `gelesen_bis` schon die letzte
   Nachricht. Keine Linie mehr, Sprung ans Ende.
   DAS IST DER FEHLER, DEN FILIPE GESEHEN HAT. Und er wuerfelte: Kommt
   die Verbindung vor dem ersten Zeichnen, passiert nichts; danach ist
   die Linie weg. Ueber sechs Rollen gemessen waren mal drei rot, mal
   zwei, mal andere -- bei unveraendertem Code.

3. UND EIN EINZIGER SPRUNG REICHT NICHT.
   Zwischen Sprung und fertigem Bild waechst die Hoehe noch: Schriften
   kommen an und setzen den Text um, Bilder melden ihre Groesse. Jetzt
   wird nachgezogen -- nach den Schriften, nach jedem Bild, nach zwei
   Bildwiederholungen -- und die Stelle haelt, bis der Mensch selbst
   scrollt. „Ich habe dich an die neue Stelle gesetzt" ist eine Zusage;
   sie beim naechsten Nachladen zu brechen waere schlimmer, als sie nie
   gegeben zu haben.

GEMESSEN -- server/pruef-chat-neu-stelle.mjs (neu), 63 Pruefungen,
0 Fehler, zweimal hintereinander mit demselben Ergebnis:

  Sechs Rollen in beiden Haeusern (DogFather, rechte Hand, linke Hand,
  Modi auf crew.; Manager und Creator auf workspace.), je auf Handy
  (390 px) und Rechner (1280 px). Je Blick: Steht die Linie im
  Verlauf? Ist sie zu SEHEN? Steht Zusammenhang darueber? Und ist der
  Verlauf NICHT am Ende?

  Ergebnis: 115-118 px unter dem oberen Rand am Handy, 150-153 px am
  Rechner -- darueber jeweils die letzte alte Nachricht.

  Dazu drei Gegenproben: Ohne Ungelesenes gibt es keine Linie und der
  Verlauf steht am Ende (sonst laendete man grundlos mitten im
  Verlauf); und die Messung erkennt „nicht sichtbar" auch wirklich
  (-1403 px an einem absichtlich nach unten gescrollten Verlauf) --
  sonst waere jede gruene Zeile darueber wertlos.

DIE PRUEFUNG SELBST HAT ZWEIMAL DAS FALSCHE GEMESSEN, bevor sie das
Richtige maass, und beides steht als Begruendung darin: Sie schickte
`/gelesen` ohne `bis` (die Route verlangt eine Nummer und lehnt sonst
ab -- der Lesestand blieb null, die Linie entstand nie), und sie
benutzte einen Raum je Rolle fuer zwei Blicke, was einen Wettlauf mit
der „gelesen"-Meldung erzeugte. Jetzt bekommt jeder Blick seinen
eigenen Raum: mehr Aufbau, dafuer immer dasselbe Ergebnis.

pruef-chat 63/0, pruef-chat-optik 62/0, pruef-chat-kanaele 81/0,
pruef-treffchat 110/0, pruef-chat-neu 36/0, pruef-pin-fuer-mich 37/0,
pruef-erwaehnung 129/0, pruef-gifs 17/0.

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

2026-09-25 14:40:01 +02:00