dogfather-universe

DogFatherGit/dogfather-universe

Fork 0

Commit Graph

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	e7cd1984d8	Ein Rollenname im ausgelieferten Code, die Seite zu breit, und drei Pruefungen, die den Umbau verschlafen hatten Filipe: "falls es noch was gibt was fehlt oder nicht richtig funktioniert, auf dem handy oder auf dem pc, oder als installiert, ich will dass du das alles abcheckst und machst dass jede seite reibungslos klappt." Gemessen wurde der ganze Bestand: 26 Pruefdateien einzeln, dazu drei neue Messungen fuer Dinge, die keine Pruefung ansieht. Von 37 roten Meldungen aus dem Nachtlauf sind nach dieser Runde die haelfte erledigt -- und die Haelfte davon war gar nicht kaputt. === ECHTE FEHLER === 1. EIN ROLLENNAME STAND IM AUSGELIEFERTEN QUELLTEXT. `aufgaben.js` sagte "Modis moechten das uebernehmen -- du entscheidest". Diese Datei bekommt JEDER, der die Seite oeffnet: jeder Manager, jeder Scout, jeder Creator im anderen Haus. Der verborgene Zugang haelt genau so lange, wie der Name dort nicht steht. Er stammte aus der Bewerbungsspalte von gestern -- einen Tag alt, gefunden von pruef-modi-wortleck. Jetzt: "Jemand moechte das uebernehmen". Wer es ist, steht ohnehin mit Namen auf den Karten darunter, und die sieht nur, wer sie sehen darf. 2. DIE SUPPORT-SEITE WAR AUF JEDER BREITE UNTER 1440 px ZU BREIT -- 13 px auf dem Handy, 41 px auf dem Tablet quer, 30 px auf dem Laptop. Schuld war das weiche Licht, das ich in der Nacht eingebaut habe: `inset: -8% -4% 0`. Die vier Prozent rechts sahen nach einer Kleinigkeit aus; ein absolut gesetztes Element zaehlt aber zur Scrollbreite, auch mit `pointer-events: none` und `z-index: -1`. `pruef-breiten` hat es gemeldet und konnte nicht sagen, WAS es ist ("13px Ueberstand []") -- ein Pseudoelement hat keine Box im DOM. Gefunden hat es eine neue Messung, die JEDES echte Element abfragt: keines ragte heraus, und genau das war der Hinweis. Jetzt: 0 px auf allen neun Breiten, 38 Seiten, 84 252 Elemente. 3. EIN AUFGABENLINK IM REPORT WAR 27 x 18 px GROSS. Mit der Maus gut, mit dem Daumen nicht -- eine Fingerkuppe ist rund 45 px breit. Jetzt fuellt der Link die Zeile und ist 44 px hoch, aber nur auf schmalen Bildschirmen und an groben Zeigegeraeten. Die zweite Bedingung habe ich beim ersten Anlauf vergessen, und der Link blieb 27 x 21 -- eine Regel, die nur unter idealen Bedingungen greift, hilft niemandem auf dem halben Weg dorthin. 4. EINE SEITE LUD DAS FALSCHE MANIFEST. `anruf-probe.html` verwies fest auf `crew.webmanifest`; die Seite ist aber fuer ALLE Rollen offen und damit auf beiden Adressen erreichbar. Wer sie im Agenturhaus oeffnet und die App installiert, bekam "DogFather Universe" mit dem Crew-Symbol auf den Startbildschirm. Alle anderen 38 Seiten machen es richtig: `app.webmanifest`, und die Adresse biegt es um. 5. DER KNOPF "+ GIF HINZUFUEGEN" WAR 40 px HOCH, und der Kommentar daneben nannte das "die Hausgroesse". Die Hausgroesse sind 44 -- fuenfmal in derselben Datei so begruendet. Die erste Reparatur griff nicht: Die Fingerregel stand 400 Zeilen VOR der Grundregel, und bei gleicher Staerke gewinnt die spaetere. Jetzt steht sie direkt dahinter, und der Knopf misst 133 x 44 am Finger, 133 x 40 an der Maus. KEINE PRUEFUNG KONNTE DAS FINDEN: Die GIF-Tafel ist zu, solange niemand sie aufmacht, und alle Rundgaenge messen, was auf dem Bildschirm steht. Dafuer gibt es jetzt server/mess-gifs-handy.mjs. 6. ZWEI KLEINIGKEITEN AUS DER NACHT: eine Fehlerkennung ohne Satz (`unbekannter_punkt`) und eine Stelle in support.js, die den Serverfehler roh anzeigte statt durch `fehlerText` -- die zwei anderen Stellen derselben Datei machen es richtig. So entsteht eine Ausnahme: nicht aus Absicht, sondern weil man die Hausregel beim Neuschreiben nicht danebenliegen hatte. 7. TOTES CSS (.e-leerwahl, vier Regeln). Der Leerkasten ist am 24.09. auf Filipes Wunsch wieder verschwunden, sein Stil blieb einen Tag laenger stehen. === ROT, ABER NICHT KAPUTT === Drei Pruefungen haben den Umbau vom 24.09. nicht mitbekommen: pruef-anruf meldete 31 Fehler und "ein Gespraech entsteht (403)". Sie meldete DogFather auf der AGENTUR-Adresse an und liess ihn dann die rechte Hand anrufen -- die es dort seit der Haustrennung nicht gibt. Der Server hatte recht. Jetzt telefoniert Team Dogi auf crew., und der Creator bleibt auf workspace. -- seine Gegenprobe ist damit sogar schaerfer als vorher (ein Fremder aus dem ANDEREN Haus). 96 -> 127 Pruefungen, 0 Fehler. pruef-crew-wand-bild erwartete vier Rollen auf der Zugangswand. Es sind fuenf, seit die linke Hand am 21.09. dazukam. Die Zeile stand unter einem Kommentar, der wortwoertlich vor festen Namen in Pruefungen warnt ("eine Zeitbombe mit Datum") -- und war selbst einer. Jetzt leitet sie die Rollen aus `rollenImHaus("crew")` ab, derselben Quelle, aus der der Server die Wand baut. pruef-entwicklung-kacheln rechnete noch mit "x von 68". Seit Filipes Wunsch ("es sollen nur die menge angezeigt werden die wir zutragen") ist das Ganze das, was jemandem zugetragen ist. Sie baut jetzt BEIDE Faelle -- eine Person mit vier zugetragenen Punkten und eine ohne -- und misst Ring, Bogen, Zeile und Vorleseschild gegen die Zuteilung. Dazu eine Gegenprobe mit einer Einschaetzung auf einem NICHT zugetragenen Punkt: zaehlt die Uebersicht sie mit, stuende dort 2 statt 1. 31 -> 34 Pruefungen, 0 Fehler. === WAS DIE BILDSCHAU ANGEHT === Meine eigene Messung meldete erst "Mitte 174 von 640" -- die Schau sah kaputt aus. Sie war es nicht: `querySelector("img")` nahm das Husky-Zeichen in der Kopfzeile statt des Bildes. Nachgemessen am richtigen Element steht es auf 195 von 195 (Handy) und 640 von 640 (Rechner), und ein GIF oeffnet sich als GIF. Ein Messfehler, der wie ein Befund aussieht, kostet mehr Zeit als gar keine Messung -- deshalb steht die Begruendung jetzt im Quelltext der Messung. GEMESSEN: pruef-breiten (9 Breiten, 38 Seiten, 84 252 Elemente), pruef-support 63/0, pruef-gifs 17/0, pruef-chat 63/0, pruef-chat-optik 62/0, pruef-tippziele 11/0, pruef-css-klassen, pruef-struktur, pruef-meldungen, pruef-modi-wortleck, pruef-crew-adresse, pruef-installieren, pruef-aufgabenbrett, pruef-entwicklung -- alle 0 Fehler. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-25 12:31:21 +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

e7cd1984d8

Ein Rollenname im ausgelieferten Code, die Seite zu breit, und drei Pruefungen, die den Umbau verschlafen hatten

Filipe: "falls es noch was gibt was fehlt oder nicht richtig funktioniert,
auf dem handy oder auf dem pc, oder als installiert, ich will dass du das
alles abcheckst und machst dass jede seite reibungslos klappt."

Gemessen wurde der ganze Bestand: 26 Pruefdateien einzeln, dazu drei neue
Messungen fuer Dinge, die keine Pruefung ansieht. Von 37 roten Meldungen
aus dem Nachtlauf sind nach dieser Runde die haelfte erledigt -- und die
Haelfte davon war gar nicht kaputt.

=== ECHTE FEHLER ===

1. EIN ROLLENNAME STAND IM AUSGELIEFERTEN QUELLTEXT.
   `aufgaben.js` sagte "Modis moechten das uebernehmen -- du
   entscheidest". Diese Datei bekommt JEDER, der die Seite oeffnet:
   jeder Manager, jeder Scout, jeder Creator im anderen Haus. Der
   verborgene Zugang haelt genau so lange, wie der Name dort nicht
   steht. Er stammte aus der Bewerbungsspalte von gestern -- einen Tag
   alt, gefunden von pruef-modi-wortleck. Jetzt: "Jemand moechte das
   uebernehmen". Wer es ist, steht ohnehin mit Namen auf den Karten
   darunter, und die sieht nur, wer sie sehen darf.

2. DIE SUPPORT-SEITE WAR AUF JEDER BREITE UNTER 1440 px ZU BREIT --
   13 px auf dem Handy, 41 px auf dem Tablet quer, 30 px auf dem
   Laptop. Schuld war das weiche Licht, das ich in der Nacht eingebaut
   habe: `inset: -8% -4% 0`. Die vier Prozent rechts sahen nach einer
   Kleinigkeit aus; ein absolut gesetztes Element zaehlt aber zur
   Scrollbreite, auch mit `pointer-events: none` und `z-index: -1`.

   `pruef-breiten` hat es gemeldet und konnte nicht sagen, WAS es ist
   ("13px Ueberstand []") -- ein Pseudoelement hat keine Box im DOM.
   Gefunden hat es eine neue Messung, die JEDES echte Element abfragt:
   keines ragte heraus, und genau das war der Hinweis.
   Jetzt: 0 px auf allen neun Breiten, 38 Seiten, 84 252 Elemente.

3. EIN AUFGABENLINK IM REPORT WAR 27 x 18 px GROSS. Mit der Maus gut,
   mit dem Daumen nicht -- eine Fingerkuppe ist rund 45 px breit.
   Jetzt fuellt der Link die Zeile und ist 44 px hoch, aber nur auf
   schmalen Bildschirmen und an groben Zeigegeraeten. Die zweite
   Bedingung habe ich beim ersten Anlauf vergessen, und der Link blieb
   27 x 21 -- eine Regel, die nur unter idealen Bedingungen greift,
   hilft niemandem auf dem halben Weg dorthin.

4. EINE SEITE LUD DAS FALSCHE MANIFEST. `anruf-probe.html` verwies
   fest auf `crew.webmanifest`; die Seite ist aber fuer ALLE Rollen
   offen und damit auf beiden Adressen erreichbar. Wer sie im
   Agenturhaus oeffnet und die App installiert, bekam "DogFather
   Universe" mit dem Crew-Symbol auf den Startbildschirm. Alle anderen
   38 Seiten machen es richtig: `app.webmanifest`, und die Adresse
   biegt es um.

5. DER KNOPF "+ GIF HINZUFUEGEN" WAR 40 px HOCH, und der Kommentar
   daneben nannte das "die Hausgroesse". Die Hausgroesse sind 44 --
   fuenfmal in derselben Datei so begruendet. Die erste Reparatur
   griff nicht: Die Fingerregel stand 400 Zeilen VOR der Grundregel,
   und bei gleicher Staerke gewinnt die spaetere. Jetzt steht sie
   direkt dahinter, und der Knopf misst 133 x 44 am Finger, 133 x 40
   an der Maus.

   KEINE PRUEFUNG KONNTE DAS FINDEN: Die GIF-Tafel ist zu, solange
   niemand sie aufmacht, und alle Rundgaenge messen, was auf dem
   Bildschirm steht. Dafuer gibt es jetzt server/mess-gifs-handy.mjs.

6. ZWEI KLEINIGKEITEN AUS DER NACHT: eine Fehlerkennung ohne Satz
   (`unbekannter_punkt`) und eine Stelle in support.js, die den
   Serverfehler roh anzeigte statt durch `fehlerText` -- die zwei
   anderen Stellen derselben Datei machen es richtig. So entsteht eine
   Ausnahme: nicht aus Absicht, sondern weil man die Hausregel beim
   Neuschreiben nicht danebenliegen hatte.

7. TOTES CSS (.e-leerwahl, vier Regeln). Der Leerkasten ist am
   24.09. auf Filipes Wunsch wieder verschwunden, sein Stil blieb
   einen Tag laenger stehen.

=== ROT, ABER NICHT KAPUTT ===

Drei Pruefungen haben den Umbau vom 24.09. nicht mitbekommen:

  pruef-anruf meldete 31 Fehler und "ein Gespraech entsteht (403)".
  Sie meldete DogFather auf der AGENTUR-Adresse an und liess ihn dann
  die rechte Hand anrufen -- die es dort seit der Haustrennung nicht
  gibt. Der Server hatte recht. Jetzt telefoniert Team Dogi auf crew.,
  und der Creator bleibt auf workspace. -- seine Gegenprobe ist damit
  sogar schaerfer als vorher (ein Fremder aus dem ANDEREN Haus).
  96 -> 127 Pruefungen, 0 Fehler.

  pruef-crew-wand-bild erwartete vier Rollen auf der Zugangswand. Es
  sind fuenf, seit die linke Hand am 21.09. dazukam. Die Zeile stand
  unter einem Kommentar, der wortwoertlich vor festen Namen in
  Pruefungen warnt ("eine Zeitbombe mit Datum") -- und war selbst
  einer. Jetzt leitet sie die Rollen aus `rollenImHaus("crew")` ab,
  derselben Quelle, aus der der Server die Wand baut.

  pruef-entwicklung-kacheln rechnete noch mit "x von 68". Seit
  Filipes Wunsch ("es sollen nur die menge angezeigt werden die wir
  zutragen") ist das Ganze das, was jemandem zugetragen ist. Sie baut
  jetzt BEIDE Faelle -- eine Person mit vier zugetragenen Punkten und
  eine ohne -- und misst Ring, Bogen, Zeile und Vorleseschild gegen
  die Zuteilung. Dazu eine Gegenprobe mit einer Einschaetzung auf
  einem NICHT zugetragenen Punkt: zaehlt die Uebersicht sie mit,
  stuende dort 2 statt 1. 31 -> 34 Pruefungen, 0 Fehler.

=== WAS DIE BILDSCHAU ANGEHT ===

Meine eigene Messung meldete erst "Mitte 174 von 640" -- die Schau sah
kaputt aus. Sie war es nicht: `querySelector("img")` nahm das
Husky-Zeichen in der Kopfzeile statt des Bildes. Nachgemessen am
richtigen Element steht es auf 195 von 195 (Handy) und 640 von 640
(Rechner), und ein GIF oeffnet sich als GIF. Ein Messfehler, der wie
ein Befund aussieht, kostet mehr Zeit als gar keine Messung -- deshalb
steht die Begruendung jetzt im Quelltext der Messung.

GEMESSEN: pruef-breiten (9 Breiten, 38 Seiten, 84 252 Elemente),
pruef-support 63/0, pruef-gifs 17/0, pruef-chat 63/0, pruef-chat-optik
62/0, pruef-tippziele 11/0, pruef-css-klassen, pruef-struktur,
pruef-meldungen, pruef-modi-wortleck, pruef-crew-adresse,
pruef-installieren, pruef-aufgabenbrett, pruef-entwicklung -- alle 0
Fehler.

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

2026-09-25 12:31:21 +02:00