e00a905ce8a1a1cf3fb62c12b4ec5d7cc77c0c69
7
Commits
| 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]>
|
||
|
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
|
||
|
DogFatherGit
|
6261d548d0 |
Die Einblendung nimmt die Farbe des Bereichs an, in dem sie steht
Filipe, 27.09.2026: „nimm dann doch die seiten vom community bereich
ne?"
Er hatte recht, und es war derselbe Fehler noch einmal. Beim ersten
Mal stand die Buehne in einer Farbe aus einem fremden Bereich
(#9cde90, die Notizen-Kachel aus dem Team). Beim zweiten Mal stand
sie in EINER Farbe fuer alles -- und jeder Bereich des Treffs hat
seine eigene:
Rudel-Chat #5499ff Wunschliste #abff96
Highlights #f60684 Dogi-Media #918a01
Anschlagbrett #ffabff Mitmachen #577ecc
Was ansteht #2dc9ba Unterstuetzen #e76006
Ein Video ueber Dogi-Media mit violetten Einblendungen sind zwei
Sachen nebeneinander. Mit der Farbe des Bereichs ist es eine.
ABGELESEN, NICHT ABGESCHRIEBEN
Die Buehne fragt nach jedem Seitenwechsel
`getComputedStyle(document.body).--ton` -- genau den Wert, den die
Seite selbst benutzt. Eine Liste hier waere eine zweite Wahrheit, die
irgendwann von der ersten abweicht; tools/treff-farben.mjs liest
dieselben zwei Quellen (workspace.js fuer die Nummer, start.css fuer
den Farbwert), wenn man sie nachsehen will.
AUFGEHELLT, BIS ES LESBAR IST
#918a01 ist als Flaeche schoen und als Schrift auf dunklem Grund
unlesbar (1,9:1). Die Buehne mischt Weiss dazu, bis 4,5:1 erreicht
sind -- dieselbe Rechnung wie bei den Namen im Chat. Balken, Schein
und Vorhang bekommen den rohen Ton, die brauchen keinen Kontrast.
DER ABSPANN BLEIBT MARKE
Er ist in allen vier Videos derselbe und faellt deshalb auf
--violett/--akzent zurueck, egal auf welcher Seite er steht. Wer drei
Videos gesehen hat, soll den vierten am Schluss wiedererkennen.
UND EIN EIGENER FEHLER, GEMESSEN STATT UEBERSEHEN
Das Ablesen stand zuerst in `auf()` -- und `auf()` laeuft vor jeder
Karte, jedem Untertitel und jedem Rollen. Ueber hundert zusaetzliche
Wege in den Browser fuer eine Antwort, die sich nur beim
Seitenwechsel aendern kann. Video 1 wuchs dadurch von 32,9 auf
36,1 s. Jetzt wird beim Seitenwechsel gelesen: 32,0 s.
Alle vier neu gedreht: 24 bis 34 s, 1080x1920.
|
||
|
DogFatherGit
|
a28a8ea2e3 |
Die Buehne der Videos ist gestaltet statt hingestellt
Filipe, 27.09.2026: „die graphik sieht scheisse aus und so. mach das
hoch profissionel und nicht so eine halbe geschissene scheisse."
Er hat recht gehabt, und der Grund war nicht Geschmack.
DIE FARBE GEHOERTE NIRGENDWO HIN
Karten und Untertitel standen in #9cde90 -- das ist der Ton der
NOTIZEN-Kachel aus dem Teambereich. In diesen Videos ist die
Community-Seite zu sehen, und die laeuft auf --violett #a98bff und
--akzent #8ec9ff ueber --tinte #07060f (crew-haus.css). Eine
Einblendung in einer Farbe, die im Bild gar nicht vorkommt, sieht
immer aufgeklebt aus, egal wie sauber sie gebaut ist. Das war der
eigentliche Befund; alles andere kam obendrauf.
WAS JETZT STEHT
Die Karte: Zierzeile „- TEAM DOGI -" wie ueber dem Titel in der App,
Ueberschrift mit ausgeglichenen Zeilen, langsame Kamerafahrt von drei
Prozent ueber zweieinhalb Sekunden, feines Korn gegen Streifen in
dunklen Flaechen. Der Abspann bekommt eine eigene hellere Flaeche und
einen Strich -- er ist das Einzige, was der Mensch danach noch tun
soll.
Der Untertitel: Glasflaeche mit Farbstreifen links. Rechts bleiben
17 % frei, dort liegt auf TikTok die Knopfreihe; unten bleibt Platz
fuer Beschreibung und Ton. Vorher war es ein graues Kaestchen mit
gruenem Rand ueber die ganze Breite.
Der Vorhang: Jeder Seitenwechsel laeuft dahinter. Vorher war jeder
Wechsel im Bild -- „Eintraege werden geladen ...", halb aufgebaute
Raster, ein kurzes Aufblitzen. Zusammen sah das nach
Bildschirmaufnahme aus und nicht nach Film.
EINE FUNKTION STATT EINER ZEICHENKETTE
Die Buehne war ein Text, der im Browser ausgewertet wurde, und darin
noch ein Text fuer das Stilblatt -- zwei Ebenen Anfuehrungszeichen, in
denen jedes Backtick von Hand entschaerft werden musste. Dabei ist
jede zweite Aenderung kaputtgegangen. Playwright nimmt auch eine echte
Funktion und reicht ein Argument durch; die ganze Schicht faellt weg.
VIER FEHLER, DIE NUR DAS EINZELBILD GEZEIGT HAT
1. WAISEN IN DER ZEILE. „Ein Kommentar ist nach / nach / drei
Sekunden weg." -- ein von Hand gesetztes <br> traf eine Zeile,
die ohnehin umbrach. Ein Umbruch, den jemand vor drei Tagen
gesetzt hat, weiss nichts von der Schriftgroesse von heute.
`text-wrap: balance` rechnet ihn aus; die elf Handumbrueche
sind weg.
2. DER STRICH UNTER DEM ABSPANN WAR NIE ZU SEHEN. Er steht in
einem <span>, und ein span ist inline -- Hoehe, Breite und
margin:auto gelten dort nicht. Gebaut, unsichtbar, und ohne das
Bild haette ich weiter geglaubt, er sei da.
3. DER VORHANG GING ZU FRUEH AUF, dreimal aus drei Gruenden. Erst
standen 700 ms -- eine Zahl. Dann eine einmalige Frage „steht
irgendwo, dass geladen wird?" -- und die traf den Moment, BEVOR
die Seite ihren Ladehinweis gezeichnet hatte. Dann 450 ms Ruhe
-- zu kurz, weil eine Seite ihre Abschnitte nacheinander laedt
und es zwischen zweien kurz still ist. Jetzt: 650 ms am Stueck
ohne Hinweis, ein Aufflackern setzt die Uhr zurueck.
4. DAS LEUCHTEN AUF DEN BLAUEN WOERTERN war zu breit und hat die
Buchstabenkanten gefressen; im Video wurde daraus Matsch.
NICHT `networkidle` ABGEWARTET, UND ZWAR ABSICHTLICH: Der Chat haelt
einen Ereignisstrom offen, der nie endet. Ein Warten darauf liefe dort
immer in die Frist und haenge jedem Seitenwechsel neun Sekunden an --
dieselbe Falle wie am 06.09.2026 bei `await antwort.text()` auf einen
Stream.
Alle vier Videos neu gedreht: 1080x1920, 24 bis 33 s, Lecksuche
unveraendert scharf.
|
||
|
DogFatherGit
|
d465c89289 |
Ein Werkzeug, das abstuerzt, soll abstuerzen
Das Videowerkzeug hat zweimal zwoelf Minuten lang an nichts
gearbeitet. Es war nicht langsam, es war tot: Beim Fuellen des
Medienregals warf es 'no such table: material', und index.js faengt
uncaughtException ab und protokolliert nur. Fuer den Betrieb ist das
richtig -- ein Fehler in einer Nebensache darf die Website nicht
offline nehmen. Wer die Datei importiert, erbt das Netz, und der
laufende HTTP-Server haelt den Prozess danach am Leben.
Von aussen sieht das aus wie 'rechnet noch'. Ein Stillstand ist
schlimmer als ein Fehlschlag: Ein Fehlschlag ist rot und steht da.
Genau diese Falle steht seit dem 06.09.2026 in den Projektregeln
('Auffangnetze im Betrieb sind Fallen in der Pruefung'), und ich bin
trotzdem hineingelaufen -- weil ich das Werkzeug nicht als Pruefung
verbucht habe, sondern als Werkzeug. Der Unterschied ist keiner:
Entscheidend ist, wer index.js importiert.
process.on ERGAENZT, es ersetzt nicht. Die Meldung von index.js kommt
weiterhin, danach endet der Lauf mit Rueckgabewert 8.
Beide Richtungen nachgefahren: PROBE_ABSTURZ=ja endet sofort mit 8,
ein normaler Lauf endet mit 0 und einem fertigen Video. Ein Netz, das
man nie hat reissen sehen, ist eine Hoffnung.
|
||
|
DogFatherGit
|
cf6c72b3d8 |
Beim Laden stand "SPICY MEDIA - Zentrale" auf jeder Startseite
WAS DAS BILD GEZEIGT HAT
Beim Durchsehen der Einzelbilder einer Videoaufnahme -- vier
Sekunden lang, gleich nach dem Laden:
---- SPICY MEDIA ----
Zentrale
WIRD GELADEN
Und zwar auf der Startseite eines COMMUNITY-MITGLIEDS.
In start.html steht die Vorgabe des Agenturhauses. Das Teamhaus
bekommt eigene Worte ("Team Dogi" / "Die IrrenAnstalt"), aber erst
wenn /api/ich geantwortet hat. Bis dahin las jeder Modi und jedes
Community-Mitglied die Marke der Agentur in der groessten Schrift
der Seite. Auf einem langsamen Telefon sekundenlang, bei jedem
Aufruf.
Das ist kein Schoenheitsfehler. Spicy Media ist der Betrieb hinter
der Agentur, und seit dem 24.09. sind die beiden Haeuser getrennt.
Genau diese Zeile hat die Trennung bei jedem Seitenaufruf kurz
aufgehoben -- und niemandem ist es aufgefallen, weil die Seite
DANACH richtig aussah. Wer hinsieht, sieht den Endzustand.
GELOEST OHNE SPRUNG
`data-wartet` macht die zwei Zeilen durchsichtig, nicht leer -- der
Platz bleibt stehen, es ruckt nichts. start.js nimmt das Merkmal
weg, sobald es weiss, in welchem Haus es ist; gemessen dauert das
351 ms.
Eine Notbremse in der Seite nimmt es nach vier Sekunden notfalls
selbst weg. Ohne sie waere die groesste Schrift der Seite fuer immer
unsichtbar, falls start.js gar nicht erst laeuft -- und "unsichtbar"
waere schlimmer als das falsche Wort.
DIE PRUEFUNG DAZU -- UND ZWEI MESSFEHLER DARIN
pruef-start-ansicht misst ab jetzt beide Richtungen: nach dem Laden
muessen beide Zeilen sichtbar sein, mit gesetztem `data-wartet`
unsichtbar. Ohne die zweite Haelfte koennte die Regel spurlos
verschwinden, ohne dass etwas rot wird.
Die Pruefung selbst hat mich zweimal getaeuscht, und beide Male
lehrreich:
1. Sie mass 900 ms nach der Anmeldung -- eine feste Pause. Ob
/api/ich in dieser Zeit geantwortet hat, haengt vom Rechner ab.
Dieselbe Pruefung war einmal gruen und einmal rot, bei
unveraendertem Code. Gewartet wird jetzt auf das Merkmal selbst,
und wie lange es gedauert hat, steht im Meldetext.
2. `opacity` hat einen Uebergang von 180 ms, und getComputedStyle
liefert waehrenddessen den laufenden Zwischenwert statt des
Ziels. Erst meldete die Gegenprobe "nicht verdeckt", dann die
Messung davor "nicht sichtbar" -- beide Male war die Regel in
Ordnung und nur die Animation im Weg. Fuer die Messung wird der
Uebergang jetzt abgeschaltet.
DAS VIDEOWERKZEUG
server/tiktok-videos.mjs nimmt die vier Clips auf. Sechs Aenderungen,
jede aus einem Einzelbild:
- DIE NACHTRUHE HAT DIE VORBEREITUNG MITBLOCKIERT. Video 2 zeigte
einen leeren Chat. Gemeldet wurde "gefuellt", weil nur geprueft
war, dass es den RAUM gibt. Jetzt werden die Nachrichten
zurueckgelesen und gezaehlt; unter acht wird nicht gefilmt.
- DOGI-MEDIA WAR LEER -- ein Video ueber Material zum Mitnehmen,
und auf dem Bildschirm stand "Gerade ist nichts frei". Sechs
echte Marken-Bilder werden eingestellt, zwei davon schon
genommen, damit die Aussage des Films auch im Bild steht.
- "WILL ICH AUCH - 0" an jedem Wunsch, waehrend der Untertitel
sagte "die anderen sehen, wer mitwill". Ein Versprechen, das das
Bild gleich wieder einkassiert, ist schlimmer als ein leeres
Brett. Jetzt wird ueber die echte Route gestimmt, absteigend
6/5/4 -- unter zehn Stimmen wird nicht gefilmt.
- DER WAECHTER FUER VIDEO 2 verglich zwei feste Zahlen
(TREFF_NACHT_AB === "0"). Das ist die Abschrift einer Einstellung
und keine Frage nach dem Zustand: Jedes andere Fenster, das den
Chat genauso schlafen legt, wurde abgewiesen. Gefragt wird jetzt
`istNachtruhe()` -- dieselbe Funktion, die auch die Seite
befragt. Mit 12 bis 6 steht im Bild "Ab 06:00 Uhr geht es
weiter" statt "Ab 24:00 Uhr", und das ergibt fuer einen
Zuschauer ueberhaupt erst Sinn.
- ROLLEN IM KASTEN STATT IN DER SEITE. `window.scrollBy` bewegt
die Seite; im Chat rollt aber der Verlauf in seinem eigenen
Kasten. Drei Bilder hintereinander sahen gleich aus.
- EINE FESTE PIXELZAHL TRAF DEN FALSCHEN BLOCK. Video 4 filmte
den Katalog der fertigen Vorschlaege statt der Wuensche, weil
"480 nach unten" zufaellig dort endete. `b.zu(wahl)` misst, wo
das Element steht.
Dazu: Umlaute in allen Bildtexten ("Tueren" stand im Video), der
Abspann bleibt am Ende stehen (vorher sah man die letzte Sekunde
wieder die App), und die Dateigroessen im Regal sind echt.
KEIN LINK, UND ZWAR GEMESSEN
Nach jedem Seitenwechsel wird der SICHTBARE Text nach Adressen
abgesucht -- dogfather-universe, https://, www., jeder Domainname.
Bei einem Fund bricht die Aufnahme ab, und es wird keine Datei
geschrieben. Das mit dem Auge zu pruefen waere genau die Sorte
Kontrolle, die beim vierten Video nachlaesst.
Mit PROBE_LECK=ja schiebt die Suche selbst eine Adresse ins Bild --
nachgefahren, Rueckgabewert 2. Eine Suche, die nur "nichts gefunden"
sagen kann, hat nichts bewiesen.
Gemessen: pruef-start-ansicht 160/0 (vorher 157), pruef-buehne
242/0, pruef-handy 177/0, pruef-kachelraster 24/0,
pruef-css-klassen 33/0.
|
||
|
DogFatherGit
|
9c45cdc218 |
Drei Pixel breite Kacheln auf kleinen Handys -- und der Block war auf
der Pruefadresse tot DER RASTERFEHLER Auf einem 320 px breiten Geraet waren "Rudel-Chat" und "Anschlagbrett" DREI PIXEL breit: ein senkrechter Strich mit abgeschnittenem Text. Bei 360 px waren es 43 px. Gefunden habe ich es nicht mit einer Pruefung, sondern mit dem Auge, in einem Einzelbild einer Videoaufnahme. Die Ursache stand in start.css: Unter 380 px wird das Kachelraster einspaltig (`grid-template-columns: 1fr !important`), die Willkommenskachel behielt aber ihr `grid-column: span 2` aus einem Block, der 2600 Zeilen spaeter steht und deshalb gewinnt. Ein Gitter mit einer erklaerten Spalte und einem Kind, das zwei braucht, erfindet die zweite -- und teilt den Platz 3 zu 281. WARUM ES KEINE PRUEFUNG GEMERKT HAT, und das ist der eigentliche Befund: pruef-handy misst Ueberhang und Beruehrziele. Eine 3 px breite Kachel ragt nicht hinaus, und ihr Link ist 142 px HOCH -- die Mindestgroesse fuer den Finger war also erfuellt. Beide Pruefungen waren gruen, und die Kachel war unbenutzbar. pruef-kachelraster misst deshalb ab jetzt die BREITE jeder Kachel mit, bei 320, 360 und 390 px. Die Grenze ist abgeleitet und nicht gesetzt: Eine Kachel muss mindestens ein Drittel der Inhaltsbreite haben -- schmaler waere sie auch bei drei Spalten nicht. Dazu wird gezaehlt, wie viele Spuren das Gitter wirklich hat; eine erfundene Spalte faellt damit auf, bevor jemand sie sieht. Gegenprobe gefahren: Ohne die neue Regel meldet die Pruefung "320 px: schmalste Kachel 3 px -- Rudel-Chat 3px, Anschlagbrett 3px" und wird rot. 15 -> 24 Punkte, 0 Fehler. DER NOTIZBLOCK AUF DER PRUEFADRESSE pruef-handy meldete auf notizen.html einen 404 in der Konsole, auf allen drei Geraetebreiten. Kein Anzeigefehler: Die Seite lud, der Block blieb leer. Meine Schranke fragte `haus !== "crew"`. Das klingt richtig und ist es nicht -- auf einer Pruefadresse (127.0.0.1) hat niemand ein Haus, `person.haus` ist dort absichtlich `null`, damit die Pruefungen des Hauses nicht still blind werden. Damit antwortete JEDER Aufruf des Blocks dort mit 404. hausWo() in workspace.js macht es seit dem 24.09. richtig herum: Ist das Haus weder crew noch agentur, wird NICHT gefiltert. Die Schranke folgt jetzt derselben Regel und weist das ANDERE Haus ab statt "alles ausser crew". Die Trennung bleibt unveraendert scharf. pruef-notizen misst ab jetzt BEIDE Enden -- auf `workspace.` 404, auf der Pruefadresse 200. Wer nur eins misst, kann die Schranke jederzeit wieder zu scharf stellen, ohne dass etwas rot wird. 76 -> 79 Punkte. DAS WERKZEUG FUER DIE VIDEOS server/tiktok-videos.mjs nimmt vier Clips ueber die App auf (eigene Wegwerf-Datenbank, eigener Port, nie die echte). Eingebaut ist eine Lecksuche: Nach jedem Seitenwechsel wird der SICHTBARE Text nach Adressen abgesucht, und bei einem Fund bricht die Aufnahme ab. Filipe am 27.09.: "es darf kein link zu sehen sein." Das mit dem Auge zu pruefen waere genau die Sorte Kontrolle, die beim vierten Video nachlaesst. Mit PROBE_LECK=ja laesst sich zeigen, dass sie anschlaegt -- nachgefahren, Rueckgabewert 2. Gemessen: pruef-handy 177/0 (vorher 3 Fehler), pruef-kachelraster 24/0, pruef-notizen 79/0, pruef-start-ansicht 157/0, pruef-handy-teamdogi 0 Befunde. |