ad5e758721069654d084e8df4819e2bedc71fbb7
7
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
ea53d950cd |
Fingermass: beide Grundlinien auf NULL -- kein blindes Telefonfenster mehr
Seit dem 29.09. haelt pruef-fingermass zwei Zahlen, und beide muessen
GENAU stimmen: waechst eine, ist eine neue blinde Messung dazugekommen;
sinkt sie, deckt sie Platz fuer die naechste. Nach dem Grosscheck von
heute sagte die Pruefung selbst, was zu tun ist:
FEHL Nur noch 0 blinde Fenster — die Grundlinie steht auf 1.
Bitte in pruef-fingermass.mjs auf 0 senken.
FEHL 0 Fenster mit Variable und ohne hasTouch (Grundlinie 2).
Beide Zahlen zaehlten dasselbe: `pruef-grosscheck`. Im Kommentar stand
seit dem 01.10. woertlich, warum sie stehen blieben -- „die Datei zu
aendern waere ein Zweizeiler; sie zu pruefen hiesse, 206 Seiten ueber
vier Rollen laufen zu lassen, und das braucht Filipes Zusage. Eine
Aenderung, die ich nicht pruefen darf, liefere ich nicht aus."
Die Zusage kam heute („mach jetzt den prüf groß check"), der Lauf ist
gruen, also faellt die Ausnahme. Beide Grundlinien stehen auf 0.
DAS IST MEHR ALS EINE KLEINERE ZAHL: Es gibt im ganzen Haus kein
Telefonfenster mehr ohne Finger und keines, bei dem offenbleibt, ob am
Telefon mit Mauszeiger gemessen wird. Jedes neue ist ab jetzt ein
Befund und kein Bestand. 29 Dateien messen am Telefon, 28 Fenster
haben einen Finger, 0 blind.
pruef-fingermass: 5 Pruefungen, 0 Fehler
-------------------------------------------------------------------
NACHTRAG ZUR ZEITBOMBE VON HEUTE NACHT -- UND EINE KORREKTUR AN MIR
Heute Nacht war pruef-gifs rot, weil sie ins Treff-Gespraech schrieb,
wo zwischen 0 und 6 Uhr die Nachtruhe gilt. Repariert, indem sie sich
ein eigenes Gespraech anlegt.
Danach wollte ich wissen, ob noch andere Pruefungen dieselbe Bombe
tragen, und habe sie gestartet „solange das Fenster offen ist". Es war
NICHT offen: Im Protokoll stand 11:40 Uhr. Der Rechner war zwischendurch
aus, und ich hatte meine eigene, veraltete Zeitnotiz fuer die Gegenwart
gehalten -- genau der Fehler, vor dem in CLAUDE.md steht, dass auch
meine eigenen Notizen altern. Die erste Runde beantwortete die Frage
also gar nicht.
DIE NACHT BRAUCHT MAN DAFUER AUCH NICHT. Das Fenster ist eine
Einstellung (`TREFF_NACHT_AB` / `TREFF_NACHT_BIS`), und pruef-treffchat
macht es laengst so: Fenster verschieben statt Systemuhr. Damit laesst
sich die Nacht um 11:42 Uhr herstellen.
GEMESSEN, STATISCH AUSGEWAEHLT: Von 16 Pruefungen, die in einen Raum
schreiben, legen 13 ihn selbst an; uebrig blieben sechs Kandidaten.
Alle sechs mit kuenstlicher Nachtruhe (Fenster 11-13 Uhr, jetzt 11:42):
pruef-chat-kanaele 81 ok pruef-chat-aufloesen 126 ok
pruef-entwicklung 79 ok pruef-chatkachel 40 ok
pruef-loeschen 31 ok pruef-anruf 132 ok
489 Pruefungen, 0 Fehler. Keine weitere Zeitbombe dieser Art.
UND WEIL GRUEN NUR DANN ETWAS HEISST, WENN ES AUCH ROT WERDEN KANN --
drei Messungen statt einer Behauptung:
1. Kommt der Schalter an? istNachtruhe false -> TRUE
2. ALTE pruef-gifs, Nacht: 2 FEHL (die Methode findet es)
3. NEUE pruef-gifs, Nacht: 0 FEHL (die Reparatur haelt wirklich)
Ohne (2) waere (3) wertlos gewesen: Sechs gruene Laeufe sehen genauso
aus, wenn der Schalter gar nicht ankommt.
AM PRODUKT IST NICHTS GEAENDERT -- eine Pruefdatei, zwei Zahlen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
2f3b8630c7 |
Messungen am Telefon: 37 bekommen ihren Finger
Gestern Mittag gemessen: 39 `newContext`-Aufrufe nehmen ihre Breite
aus einer Variablen und setzen kein `hasTouch`. Ohne das meldet der
Browser `pointer: fine`, und KEINE Regel aus `@media (pointer:
coarse)` greift — dort stehen im ganzen Haus die 44-Pixel-
Beruehrziele, die ausgeblendeten Tastenkuerzel und die
eingeklappte Reiterleiste.
Was das anrichtet, war an pruef-breiten zu sehen: drei Befunde auf
320, 390 und 430 Pixeln, die mit dem Finger allesamt verschwanden —
Messfehler, keine Fehler.
37 DAVON HABEN IHN JETZT. Nur `hasTouch`, nicht `isMobile`: Gefragt
ist genau die eine Sache, um die es geht. `isMobile` waere eine
zweite Aenderung in derselben Zeile, und wenn danach etwas anders
aussieht, wuesste niemand, welche von beiden es war.
ZWEI BLEIBEN STEHEN, beide in pruef-grosscheck.mjs. Die Aenderung
dort waere ein Zweizeiler; sie zu pruefen hiesse, 206 Seiten ueber
vier Rollen laufen zu lassen, und das braucht Filipes Zusage. Eine
Aenderung, die ich nicht pruefen darf, liefere ich nicht aus.
Grundlinie in pruef-fingermass steht deshalb auf 2.
JEDE EINZELN NACHGELAUFEN — 37 Laeufe:
34 gruen, darunter pruef-handy 186, pruef-material 159,
pruef-start-ansicht 160, pruef-kalender 141, pruef-erwaehnung 129,
pruef-bewerbung-aufgaben 163, pruef-neue-seiten 109
3 mit Befunden, ALLE DREI VORBESTEHEND (Gegenprobe: alter Stand
derselben Datei, gleicher Lauf, gleiche Zahl):
pruef-browser 3 (WebKit startet auf diesem Rechner nicht)
pruef-chat-anhaenge 2
pruef-crew-wand-bild 3
EINE ZEITBOMBE GEFUNDEN UND ENTSCHAERFT
pruef-dabei-optik meldete „Haekchen: 0 -> 0" — aber nur, wenn vier
andere Pruefungen gleichzeitig liefen. Allein: „0 -> 1", gruen.
Dort stand `waitForTimeout(250)` mit der Begruendung „250 ms sind
reichlich ueber den 160" (der Dauer der Blende). Auf einem Rechner,
auf dem nebenher vier Browser messen, sind sie es nicht. Die
Pruefung war damit gruen, solange nichts anderes lief, und rot im
Gesamtlauf — also genau dann, wenn niemand sie einzeln nachstellen
kann.
Eine Wartezeit ist eine Annahme ueber den Rechner. Gewartet wird
jetzt auf das, worauf es ankommt: dass das Haekchen da ist. Laeuft
die Frist ab, faellt die Pruefung mit dem ECHTEN Wert um und nicht
mit einem Messfehler. Gegenprobe: unter derselben vierfachen Last,
die sie vorher rot gemacht hat, jetzt gruen.
UND DIE GRUNDLINIE WIEDER STRENG. Ich hatte sie kurz auf
„hoechstens" gestellt — damit haette ein Rueckgang stillschweigend
Platz fuer die naechste Suende gedeckt. Genau davor warnt der Kopf
derselben Datei bei der anderen Grundlinie, und ich habe es eine
Stunde spaeter selbst falsch gemacht.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
48470961c7 |
Reaktion am Handy: nichts liegt mehr auf einem Knopf
AUSGANGSLAGE, gemessen: pruef-breiten meldete auf sechs von neun
Breiten einen verdeckten Knopf, pruef-handy auf allen drei
Telefonen. Immer dieselbe Stelle: „Offen", „Team" und „Zu" aus dem
Chatkopf lagen auf dem Pult. Wer sie antippte, traf „Starten" oder
„Beenden".
ENDSTAND: pruef-breiten 23 Pruefungen / 0 Befunde, pruef-handy 186 / 0,
mess-quer „NICHTS rollt seitlich", pruef-reaktion 421 / 0.
Davon waren DREI VON VIER Befunden Messfehler. Gefunden, weil ich
ihnen nachgegangen bin statt ihnen zu glauben.
1. pruef-breiten MASS OHNE FINGER
newContext({ viewport: { width: breite, height: hoehe } })
Ohne `hasTouch` meldet der Browser `pointer: fine`, und KEINE
Regel aus `@media (pointer: coarse)` greift — dort stehen die
44-Pixel-Beruehrziele, die ausgeblendeten Tastenkuerzel und seit
heute die eingeklappte Reiterleiste. Auf 320, 390 und 430 Pixeln
wurde also eine Seite vermessen, die es auf keinem Telefon gibt.
Aufgefallen, weil mess-quer dieselbe Seite auf 390 MIT Finger
misst und dort nichts findet. -> 390 und 430 sofort gruen.
2. DER VERDECKUNGS-FINDER KANNTE KEINE ROLLKAESTEN
Gemeldet war auf 1024, 1920 und 2560 immer ein Feld AUS DEM PULT
„unter" der Transportleiste — und auf 1280 und 1440 nichts. Das
Pult rollt in sich; was unten herausgerollt ist, liegt
rechnerisch dort, wo die Leiste steht, und `elementFromPoint`
liefert die Leiste. Verdeckt ist da nichts — es ist weggerollt.
Das Fenster kannte der Finder schon (`r.bottom < 0`), den
Rollkasten nicht. -> drei Breiten gruen, die Gegenproben
(„ein echtes Hindernis wird gefunden") schlagen weiter an.
3. UND EIN ECHTER BEFUND, ZWEIMAL
a) Reiterleiste: acht Register brauchen am Handy zwei Zeilen
(100 px auf 360, 148 auf 320). Sie klappen jetzt hinter ihren
eigenen Wert — dasselbe Muster wie die Tempo-Gruppe, und der
Knopf zeigt, wo man steht. NICHT einzeilig zum Wischen:
Filipes Ansage vom 28.09. galt dem Wischen nach links und
rechts, und mess-quer misst genau das.
b) Bei OFFENER Regie nimmt das Pult auf 412x915 vierhundert-
vierundachtzig der 846 Pixel. Nebeneinander stehen Regie und
Bild erst ab 1100 px. Am Fingergeraet tritt die Chatschiene
deshalb beiseite, solange die Regie offen ist — wer etwas
einstellt, muss das Bild im Auge behalten, den Chat nicht, und
der ist einen Fingertipp entfernt.
4. MEINE EIGENE WACHE WAR BLIND — ZWEIMAL
pruef-fingermass sucht `width: <Zahl>`. In pruef-breiten stand
`width: breite`, eine Variable: kein Treffer, also „in Ordnung".
Sie meldete dabei brav „1 blindes Fenster, unveraendert zur
Grundlinie" — und war selbst blind. Jetzt gibt es einen dritten
Ausgang: Breite vorhanden, aber keine Zahl, und kein hasTouch
daneben -> „konnte nicht nachsehen", mit eigener Grundlinie.
Beim ersten Anlauf meldete der 45 Faelle, darunter jedes
`newContext({ permissions: [...] })`. Zu grob: Ein Fenster ganz
OHNE Breite ist das Standardfenster, kein Telefon. Enger gefasst.
UND DANN WAR DIE ZAHL 0 — WEIL DER AUSDRUCK TOT WAR. Das `\b` in
`/\bwidth\s*:/` war ein echtes Rueckschritt-Zeichen (0x08),
unsichtbar im Quelltext. Heute Nacht hat mich dasselbe schon
einmal eine halbe Stunde gekostet. Mit heilem Ausdruck sind es
39 echte Faelle — etwa mess-chat-liste bei 390 px ohne Finger.
Als Grundlinie festgehalten: Sie darf nur sinken, jede neue
faellt auf, und abgearbeitet wird Datei fuer Datei mit je einem
Lauf danach.
Ein Werkzeug sucht jetzt alle Steuerzeichen im ganzen Haus
(tools, gitignoriert). Es fand zwei: meins von heute und ein
aelteres in pruef-reaktion.mjs — `!/^none\b/.test(wert)` hat
dort nie gegriffen. Beide bytewise ersetzt, 830 Dateien sauber.
5. mess-quer MUSS TUN, WAS EIN MENSCH TUT
Es wartete auf eine SICHTBARE Reiterleiste und lief in die
Zeitsperre, seit sie zugeklappt startet. Jetzt wartet es auf die
Leiste und klappt auf — vor jedem Register, denn ein Klick
schliesst sie wieder.
WAS NICHT GEMACHT WURDE, UND WARUM: Die Messwerte im Pult („Sehen
zu", „Mit Bild", „Gaeste", „Upload") standen in meiner eigenen
Auswahl als Sparposten. Beim Nachsehen steht beim Upload die
Begruendung im Quelltext: „der Unterschied zwischen ,es ruckelt bei
euch?' und ,ich sehe, dass es zu viel wird'". 26 Pixel gegen echte
Information waehrend der Sendung — falscher Tausch.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGit
|
b846693de5 |
Die letzten fuenf blinden Messungen bekommen einen Finger
Die Grundlinie der Fingerwache sinkt von 6 auf 1.
DIE SCHWEREN FAELLE
pruef-notizen, pruef-teamlage-karten, pruef-terminregel,
pruef-werdegang, pruef-befinden.
Bei diesen fuenf stand mitten im Ablauf ein
`setViewportSize({ width: 390 })`. Das aendert nur die Groesse --
`hasTouch` gehoert zum KONTEXT und ist beim Anlegen entschieden.
Nachtragen geht nicht; es braucht ein zweites Fenster.
DAS MUSTER, DAS FUER ALLE FUENF GETRAGEN HAT
const handyKontext = await browser.newContext({
viewport: { width: 390, height: 844 }, hasTouch: true, isMobile: true });
await handyKontext.addCookies(await kontext.cookies());
const handy = await handyKontext.newPage();
await handy.goto(seite.url(), { waitUntil: "networkidle" });
Drei Entscheidungen darin:
- Die Anmeldung wandert als Keks mit, statt sie zu wiederholen.
Eine zweite Anmeldung waere eine zweite Stelle, die veralten
kann.
- Die Adresse kommt von `seite.url()`. Sie ein zweites Mal
hinzuschreiben waere eine zweite Wahrheit darueber, welche
Seite gemessen wird.
- Das fruehere Zuruecksetzen auf 1280 px faellt weg. Die breite
Seite war nie schmal -- es gibt nichts zurueckzustellen.
Bei pruef-terminregel liessen sich die vier Schritte, die den
schwebenden Hinweis erzeugen, nicht uebernehmen: Sie werden im
neuen Kontext nachgefahren (oeffnen, "Neu", Datum eintragen).
ALLE FUENF DANACH GRUEN
pruef-notizen EXIT 0
pruef-teamlage-karten EXIT 0 (39 geprueft)
pruef-terminregel EXIT 0 (35 Pruefungen)
pruef-werdegang EXIT 0
pruef-befinden EXIT 0
Diese Seiten halten die Fingerregeln also schon ein. Es hatte nur
nie jemand nachgesehen.
EINES BLEIBT: pruef-grosscheck
Die Datei zu aendern waere ein Zweizeiler. Sie zu PRUEFEN hiesse,
206 Seiten ueber vier Rollen und zwei Bildschirmgroessen laufen zu
lassen -- das braucht Filipes Zusage. Eine Aenderung, die ich nicht
pruefen darf, liefere ich nicht aus. Die Grundlinie steht deshalb
auf 1 und nicht auf 0.
GEPRUEFT
pruef-fingermass 3 / 0, neun Gegenproben, Grundlinie 1
|
||
|
DogFatherGit
|
d5e873d597 |
Zehn Messungen bekommen einen Finger -- und eine Zeitbombe faellt auf
Die Grundlinie der Fingerwache sinkt von 17 auf 6.
WAS UMGESTELLT WURDE
pruef-alter, pruef-countdown, pruef-gespraech, pruef-treffchat,
pruef-modi-verborgen, pruef-nachwuchs, pruef-personen-liste,
pruef-serien, pruef-team, pruef-kalender.
Alle zehn legen ein eigenes Handyfenster an; dort fehlte nur
`hasTouch`. Ohne ihn meldet der Browser einen feinen Zeiger, und
keine Regel aus `@media (pointer: coarse)` greift -- dort stehen die
44-Pixel-Beruehrziele.
JEDE EINZELN GELAUFEN, ALLE GRUEN
Diese Seiten halten die Fingerregeln also schon ein. Es hatte nur
nie jemand nachgesehen.
Vorher geprueft, wie gross jede ist: 1 bis 7 Seitenaufrufe, 1 bis 5
Fenster -- echte Einzelpruefungen. (Zum Vergleich: die Pruefung von
gestern Nacht hatte 244 Seitenaufrufe, und genau das hatte ich
vorher nicht nachgesehen.)
DIE ZEITBOMBE IN pruef-kalender
Beim Umstellen fiel sie rot aus -- zweimal, an einer Stelle, die mit
dem Finger nichts zu tun hat:
FEHL im naechsten Monat ist kein Tag mehr "heute"
Gegen den ausgelieferten Stand gemessen: identisch rot. Nicht
meine Aenderung, sondern der Kalender.
Heute ist der 29. September. Das Oktober-Raster zeigt in seiner
ersten Zeile die letzten Septembertage mit, und einer davon IST
heute. Die Anwendung macht dabei alles richtig: `kalender.js` setzt
die Marke an `tag === daten.heute`, also am DATUM und nicht an der
Rasterposition. Genau das sollte die Pruefung beweisen -- und schlug
an, weil die Anwendung es tat.
Geschrieben wurde sie an einem Tag in der Monatsmitte. Von da an war
sie richtig, bis der Kalender sie einholte. Dasselbe Muster wie
`gate-oeffnung.mjs` am 06.09.2026 im Shop: Ein Test, der die
Wanduhr als Annahme benutzt, misst irgendwann das Gegenteil.
Gefragt wird jetzt, was gemeint war: Ein EIGENER Tag des
Folgemonats darf nie „heute" sein; ein mitgezeigter Randtag
(`data-fremd="ja"`) dagegen sehr wohl, und zwar genau dann, wenn er
es ist. Das gilt an jedem Tag des Jahres. Die Meldung nennt jetzt
beide Zahlen:
ok im naechsten Monat ist kein EIGENER Tag mehr "heute"
(0 eigene, 1 mitgezeigte Randtage)
WAS UEBRIG BLEIBT: SECHS SCHWERE FAELLE
pruef-befinden, pruef-notizen, pruef-teamlage-karten,
pruef-terminregel, pruef-werdegang, pruef-grosscheck.
Dort schaltet `setViewportSize` mitten im Ablauf auf Handyformat um
-- und der Finger laesst sich nachtraeglich nicht setzen, er gehoert
zum Kontext. Jeder Fall braucht einen eigenen Kontext samt
Anmeldung: Umbau, nicht Einzeiler.
`pruef-grosscheck` bleibt unangetastet, bis Filipe einen Lauf
freigibt. Eine Aenderung, die ich nicht pruefen darf, liefere ich
nicht aus.
GEPRUEFT
alle zehn einzeln: EXIT 0, keine FEHL-Zeile
pruef-kalender EXIT 0 (vorher 2 Fehlschlaege, auch auf HEAD)
pruef-fingermass 3 / 0, Grundlinie 6
|
||
|
DogFatherGit
|
af61f77e92 |
Die Transportknoepfe sind am Daumen wieder 44 Pixel hoch
DER BEFUND
pruef-handy-teamdogi meldete auf iPhone UND Android, bei zwei
Rollen, denselben Mangel:
reaktion.html: zu kleine Tippziele --
button#v-zurueck 48x40, button#v-vor 48x40, button#v-naechstes 83x40
Die Grundregel von `.spur__knopf` steht auf `min-height: 40px`. Am
Rechner ist das richtig; am Finger sind es vier Pixel zu wenig, und
eine Ausnahme dafuer gab es nicht.
WARUM DAS ERST HEUTE AUFFAELLT
Die Transportleiste war am Handy bis gestern gar nicht erreichbar --
sie lag 162 Pixel unter dem Fensterrand, und der Koerper hat
`overflow: hidden`. Was nicht sichtbar ist, wird nicht gemessen. Die
Reparatur von gestern hat den Mangel also nicht verursacht, sondern
aufgedeckt.
Gemessen nach der Aenderung: Transportleiste 207 statt 203 Pixel,
Saal 775 = Leiste 101 + Kino 467 + Regie 336. Kein Knopf liegt ueber
einem anderen, die Leiste verdeckt kein Bedienelement der Regie.
DIE FINGERWACHE ZAEHLT JETZT FENSTER, NICHT DATEIEN
Die erste Fassung fragte: "Steht `hasTouch` irgendwo in der Datei?"
pruef-kalender allein hat sieben Fenster, davon drei schmale -- ein
einziges `hasTouch` haette alle drei freigesprochen. Genau diese
Mischung ist im Haus die Regel.
Die geschaerfte Fassung fand prompt zwei Dateien, welche die grobe
freigesprochen hatte. Beim Nachmessen:
- pruef-chat-optik: FEHLALARM. Ihr `setViewportSize` sitzt auf
einer Seite, deren Kontext `hasTouch: breite < 900` traegt --
wer danach nur die Groesse aendert, behaelt den Finger. Die
Wache zaehlt solche Stellen jetzt nur noch, wenn in der ganzen
Datei kein einziges `hasTouch` steht. Wo ich raten muesste,
zaehle ich nicht: Eine Wache, die im Zweifel meldet, wird
weggeklickt.
- pruef-handy-teamdogi: ECHTER FUND. Ihr zweiter Kontext hatte
keinen Finger, der erste schon. Repariert.
Grundlinie damit von 23 auf 17. Neun Gegenproben statt sechs,
darunter beide neuen Faelle.
Drei Anlaeufe, drei Zahlen: grep 18, Wache je Datei 16, Wache je
Fenster 17 (nach Abzug des Fehlalarms). Die erste Zahl, die eine
Wache liefert, ist selten die richtige.
NOCH OFFEN AUS DEMSELBEN LAUF
notizen.html, nur auf 412 px: `a.zurueck` „Team Dogi…" ist 0 Pixel
breit statt 82. Noch nicht angesehen.
GEPRUEFT
pruef-reaktion, -tippziele, -css-klassen: alle EXIT 0
pruef-fingermass 3 / 0
mess-reaktion EXIT 0, kein ACHTUNG, kein offener Punkt
|
||
|
DogFatherGit
|
315eb08cc4 |
Eine Wache dafuer, dass am Telefon mit dem Finger gemessen wird
DER FUND VON HEUTE WAR GROESSER ALS DIE EINE FUSSZEILE
`page.setViewportSize({ width: 412 })` aendert nur die Groesse.
`hasTouch` gehoert zum KONTEXT und laesst sich danach nicht mehr
setzen -- ohne ihn meldet der Browser `pointer: fine`, und KEINE
einzige Regel aus `@media (pointer: coarse)` greift. Dort stehen im
ganzen Haus die 44-Pixel-Beruehrziele.
Eine Messung mit Mauszeiger auf 412 Pixeln vermisst also eine Seite,
die es auf keinem Telefon gibt -- und meldet dabei "in Ordnung".
Das ist die dritte Sorte falscher Haken: nicht uebersprungen, nicht
rot, sondern gruen und wertlos.
GEZAEHLT: 30 Dateien oeffnen ein Telefonformat. 16 davon messen
darin Groessen, ohne einen Finger zu haben.
pruef-ueberlappung IST UMGESTELLT
Sie sucht Bedienelemente, die uebereinander liegen -- also genau die
Groessen, die erst unter `pointer: coarse` entstehen. Sie hat bis
heute mit dem Zeiger gemessen. Mit Finger: 20 Seiten-Breiten-Paare,
0 Befunde. Das ist zum ersten Mal wirklich geprueft und nicht nur
behauptet. Oberhalb von 860 px bleibt es beim Zeiger; ein Laptop
hat keinen Finger.
DIE UEBRIGEN 16 WERDEN NICHT HEUTE NACHT UMGESTELLT
Sechzehn Pruefungen anzufassen und jede einzeln neu laufen zu lassen
waere ein Gesamtlauf durch die Hintertuer -- und genau die Ausrede,
die in CLAUDE.md steht. Stattdessen haelt `pruef-fingermass.mjs`
eine Grundlinie: Sie meldet nicht 16 Fehler auf einmal (eine
Warnung, die immer kommt, wird weggeklickt und nimmt den echten Fund
mit), sondern schlaegt an, sobald eine SIEBZEHNTE dazukommt.
Sie schlaegt auch an, wenn die Zahl SINKT. Wer eine Messung
repariert und die Grundlinie stehen laesst, deckt Platz fuer die
naechste Suende. Das kostet eine Zeile und haelt die Wache scharf.
DIE ERSTE ZAHL EINER WACHE IST SELTEN DIE RICHTIGE
Mein grep hatte 18 gezaehlt. Zwei davon waren Zahlen in Kommentaren
("gemessen bei 412 px"), keine Fenster. Die Pruefung liest deshalb
nur die Stelle, die ein Fenster AUFMACHT, und blendet Kommentare
vorher aus.
DREI AUSGAENGE, SECHS GEGENPROBEN
Findet sie weniger als 50 Pruefdateien, ist das kein "alles in
Ordnung", sondern "konnte nicht nachsehen" (Rueckgabewert 2). Die
Gegenproben decken beide Richtungen ab, darunter der Fall
`setViewportSize` -- der kann `hasTouch` gar nicht nachtragen und
zaehlt deshalb immer.
`tools/alles-pruefen.mjs` liest den Ordner, keine gepflegte Liste --
die neue Wache laeuft ohne Zutun mit.
GEPRUEFT
pruef-fingermass 3 / 0 (neu)
pruef-ueberlappung EXIT 0 -- 20 Paare, 0 Befunde, jetzt mit Finger
pruef-portnummern 15 / 0
|