dogfather-universe

1,115 Commits 2 Branches 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
DogFatherGitandClaude Opus 5	f6225d7341	Ports: auch die Messwerkzeuge leiten ihre Nummer ab GEMESSEN, BEVOR ICH ETWAS ANGEFASST HABE: 204 pruef-Dateien, abgeleitete Ports 5000-5409 (dicht belegt) 24 mess-Dateien, Nummern von Hand: 4471 bis 5493 davon IM Pruefbereich: 5387, 5397, 5397, 5399, 5399, 5401, 5403, 5405 untereinander doppelt: 5397, 5399, 5461, 5483, 5491 Aufgefallen ist es, weil mess-buehne und mess-reaktion beide auf 5483 lagen und ein haengengebliebener Lauf gestern einen ganzen Messlauf gekostet hat. Beim Umbau kam das Groessere heraus: EINUNDZWANZIG der 24 Messdateien hatten nicht nur eine Nummer von Hand, sondern ueberhaupt keinen Waechter -- schlicht `const PORT = 5397;`. Liegt dort schon ein Server, startet der eigene still nicht, und gemessen wird ab da ein fremder Stand. Genau der Fehler, gegen den helfer-port.mjs gebaut wurde; die Messdateien standen die ganze Zeit ausserhalb. WAS JETZT GILT Zwei Sorten, zwei Bereiche, beide abgeleitet aus der Stelle im Alphabet -- jede Sorte unter ihresgleichen, sonst verschoebe eine neue Pruefung die Nummern aller Messungen. Pruefungen ab 5000, Messungen ab MESS_BASIS = 5900. 5900 und nicht 5500: dazwischen bleibt Platz fuer 245 weitere Pruefdateien (bei 5500 waeren es 45). Nach oben 5948 + AUSWEICHEN 4000 = 9948, also unter 10080, der naechsten gesperrten Nummer. Nachgerechnet, nicht geschaetzt -- eine geschaetzte 4500 hatte bei BASIS schon einmal danebengelegen. Eine Wache dazu: Waechst der Pruefbereich bis an MESS_BASIS heran, bricht die Ableitung ab und sagt, was zu tun ist. Eine stille Ueberschneidung waere genau der Fehler, den das hier beseitigt. Die zweite Nummer kommt ueber nr=1, nie ueber `PORT + 1`: portNummer ueberspringt gesperrte Nummern, deshalb kann die naechste Zahl die Nummer der naechsten DATEI sein, sobald einmal eine Sperre dazwischenliegt. Heute liegt dort keine -- das ist Glueck, kein Entwurf. NEBENBEI GEFUNDEN UND MIT REPARIERT Sechs bild-*.mjs riefen den Waechter und warfen seine Antwort weg: await portMussFreiSein(4315, "das Bildwerkzeug"); process.env.PORT = "4315"; const BASIS = "http://127.0.0.1:4315"; Er lief, meldete nichts und wirkte nicht. Gibt das System den Port dauerhaft nicht her, weicht er auf Port + 4000 aus und GIBT DIE NEUE NUMMER ZURUECK -- diese Werkzeuge hoerten danach trotzdem auf der alten und stuerzten mit `listen EACCES` ab, also mit genau dem Fehler, gegen den er gebaut wurde. Dazu stand die Zahl dreimal je Datei. Jetzt einmal, und die Antwort wird benutzt. tiktok-videos.mjs hatte den Waechter ABGESCHRIEBEN -- eine kurze eigene Fassung ohne den dritten Ausgang: Bei EACCES meldete sie "belegt" und brach ab, statt auszuweichen. Auf diesem Rechner ist genau das am 23.09. eingetreten (Port 5040, Windows-Dienst). mess-fokus und mess-notizblock hatten dieselbe Abschrift. Eine abgeschriebene Sicherung ist dieselbe Falle wie eine abgeschriebene Liste. GEPRUEFT pruef-portnummern 15 -> 41 Pruefungen, 0 Fehler pruef-ports 8 -> 10 Pruefungen, 456 statt 408 Ports geprobt node --check auf allen 33 geaenderten Dateien Gegenproben, die wirklich rot werden: - eine Messdatei auf eine feste Nummer zurueckgesetzt -> 2 FEHL, danach wieder 41/0 - die Wache: in einem Wegwerf-Ordner mit 452 pruef-Dateien bricht eigenerPort ab statt still zu ueberlappen; eine Datei knapp darunter bekommt weiter ihre Nummer (5846) - die Erkennungen fuer feste Nummern, PORT + 1 und weggeworfene Waechterantworten je gegen einen gebauten Rueckschritt Am echten Verhalten gemessen: - mess-chat-liste und mess-alle-einzelsicht (beide vorher 5397) GLEICHZEITIG gestartet: 5906 und 5900, beide exit=0. Vorher war das unmoeglich. - die 48 neuen Nummern 5900-5947 auf diesem Rechner durchprobiert: keine belegt, keine vom System gesperrt - bild-chat.mjs durchgelaufen, drei Bilder, exit=0 Kein Eingriff am laufenden Dienst: helfer-port.mjs wird von index.js und workspace.js nicht geladen (nachgesehen), nur von Pruef- und Messwerkzeugen. Beide Haeuser unberuehrt -- es wird keine Zeile angefasst, die eine Seite ausliefert. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-10-01 01:19:41 +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	9d219e17ce	Ein Bild vom Aushang: zwei Knoepfe, und man sieht welcher mehr bewirkt server/mess-aushang.mjs zeigt, was pruef-pin-fuer-mich nicht messen kann -- wie die zwei Knoepfe nebeneinander aussehen. Drei Blicke: DogFather auf dem Handy (beide Knoepfe), ein Modi auf dem Handy (nur einer), DogFather am Rechner. Gemessen: „lösen" 52x50 in Grau, „bei allen" 68x50 in der Warnfarbe des Hauses. Beide ueber 44 px hoch, beide im Bild, und auf den ersten Blick unterscheidbar -- genau darum ging es: Zwei gleich aussehende Knoepfe nebeneinander waeren die schlechteste Loesung. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-25 14:14:35 +02:00

Author

SHA1

Message

Date

DogFatherGitandClaude Opus 5

f6225d7341

Ports: auch die Messwerkzeuge leiten ihre Nummer ab

GEMESSEN, BEVOR ICH ETWAS ANGEFASST HABE:

  204 pruef-Dateien, abgeleitete Ports 5000-5409 (dicht belegt)
  24 mess-Dateien, Nummern von Hand: 4471 bis 5493
  davon IM Pruefbereich: 5387, 5397, 5397, 5399, 5399, 5401, 5403, 5405
  untereinander doppelt: 5397, 5399, 5461, 5483, 5491

Aufgefallen ist es, weil mess-buehne und mess-reaktion beide auf 5483
lagen und ein haengengebliebener Lauf gestern einen ganzen Messlauf
gekostet hat.

Beim Umbau kam das Groessere heraus: EINUNDZWANZIG der 24 Messdateien
hatten nicht nur eine Nummer von Hand, sondern ueberhaupt keinen
Waechter -- schlicht `const PORT = 5397;`. Liegt dort schon ein
Server, startet der eigene still nicht, und gemessen wird ab da ein
fremder Stand. Genau der Fehler, gegen den helfer-port.mjs gebaut
wurde; die Messdateien standen die ganze Zeit ausserhalb.

WAS JETZT GILT

Zwei Sorten, zwei Bereiche, beide abgeleitet aus der Stelle im
Alphabet -- jede Sorte unter ihresgleichen, sonst verschoebe eine
neue Pruefung die Nummern aller Messungen. Pruefungen ab 5000,
Messungen ab MESS_BASIS = 5900.

5900 und nicht 5500: dazwischen bleibt Platz fuer 245 weitere
Pruefdateien (bei 5500 waeren es 45). Nach oben 5948 + AUSWEICHEN
4000 = 9948, also unter 10080, der naechsten gesperrten Nummer.
Nachgerechnet, nicht geschaetzt -- eine geschaetzte 4500 hatte bei
BASIS schon einmal danebengelegen.

Eine Wache dazu: Waechst der Pruefbereich bis an MESS_BASIS heran,
bricht die Ableitung ab und sagt, was zu tun ist. Eine stille
Ueberschneidung waere genau der Fehler, den das hier beseitigt.

Die zweite Nummer kommt ueber nr=1, nie ueber `PORT + 1`:
portNummer ueberspringt gesperrte Nummern, deshalb kann die naechste
Zahl die Nummer der naechsten DATEI sein, sobald einmal eine Sperre
dazwischenliegt. Heute liegt dort keine -- das ist Glueck, kein
Entwurf.

NEBENBEI GEFUNDEN UND MIT REPARIERT

Sechs bild-*.mjs riefen den Waechter und warfen seine Antwort weg:

    await portMussFreiSein(4315, "das Bildwerkzeug");
    process.env.PORT = "4315";
    const BASIS = "http://127.0.0.1:4315";

Er lief, meldete nichts und wirkte nicht. Gibt das System den Port
dauerhaft nicht her, weicht er auf Port + 4000 aus und GIBT DIE NEUE
NUMMER ZURUECK -- diese Werkzeuge hoerten danach trotzdem auf der
alten und stuerzten mit `listen EACCES` ab, also mit genau dem
Fehler, gegen den er gebaut wurde. Dazu stand die Zahl dreimal je
Datei. Jetzt einmal, und die Antwort wird benutzt.

tiktok-videos.mjs hatte den Waechter ABGESCHRIEBEN -- eine kurze
eigene Fassung ohne den dritten Ausgang: Bei EACCES meldete sie
"belegt" und brach ab, statt auszuweichen. Auf diesem Rechner ist
genau das am 23.09. eingetreten (Port 5040, Windows-Dienst).
mess-fokus und mess-notizblock hatten dieselbe Abschrift. Eine
abgeschriebene Sicherung ist dieselbe Falle wie eine abgeschriebene
Liste.

GEPRUEFT

  pruef-portnummern  15 -> 41 Pruefungen, 0 Fehler
  pruef-ports         8 -> 10 Pruefungen, 456 statt 408 Ports geprobt
  node --check auf allen 33 geaenderten Dateien

Gegenproben, die wirklich rot werden:
  - eine Messdatei auf eine feste Nummer zurueckgesetzt -> 2 FEHL,
    danach wieder 41/0
  - die Wache: in einem Wegwerf-Ordner mit 452 pruef-Dateien bricht
    eigenerPort ab statt still zu ueberlappen; eine Datei knapp
    darunter bekommt weiter ihre Nummer (5846)
  - die Erkennungen fuer feste Nummern, PORT + 1 und weggeworfene
    Waechterantworten je gegen einen gebauten Rueckschritt

Am echten Verhalten gemessen:
  - mess-chat-liste und mess-alle-einzelsicht (beide vorher 5397)
    GLEICHZEITIG gestartet: 5906 und 5900, beide exit=0. Vorher war
    das unmoeglich.
  - die 48 neuen Nummern 5900-5947 auf diesem Rechner durchprobiert:
    keine belegt, keine vom System gesperrt
  - bild-chat.mjs durchgelaufen, drei Bilder, exit=0

Kein Eingriff am laufenden Dienst: helfer-port.mjs wird von index.js
und workspace.js nicht geladen (nachgesehen), nur von Pruef- und
Messwerkzeugen. Beide Haeuser unberuehrt -- es wird keine Zeile
angefasst, die eine Seite ausliefert.

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

2026-10-01 01:19:41 +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

9d219e17ce

Ein Bild vom Aushang: zwei Knoepfe, und man sieht welcher mehr bewirkt

server/mess-aushang.mjs zeigt, was pruef-pin-fuer-mich nicht messen
kann -- wie die zwei Knoepfe nebeneinander aussehen. Drei Blicke:
DogFather auf dem Handy (beide Knoepfe), ein Modi auf dem Handy (nur
einer), DogFather am Rechner.

Gemessen: „lösen" 52x50 in Grau, „bei allen" 68x50 in der Warnfarbe
des Hauses. Beide ueber 44 px hoch, beide im Bild, und auf den ersten
Blick unterscheidbar -- genau darum ging es: Zwei gleich aussehende
Knoepfe nebeneinander waeren die schlechteste Loesung.

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

2026-09-25 14:14:35 +02:00