main
9
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
ae2f12c67d |
"Fuer wen"-Reihe weg -- aber nur bei Team Dogi
Filipe, mit Bildschirmfoto der Leiste "FUER WEN · Alle 3 2 ·
Marina 1 · Diene 0": "brauchen wir nicht auf der aufgaben seite."
GETRENNT GEFUEHRT, wie seit dem 24.09. fuer jeden Umbau. Es ist
DIESELBE Reihe in beiden Haeusern, aber nicht dieselbe Aufgabe:
Team Dogi -> "Fuer wen", darin drei, vier Modis, die ohnehin
alle auf einem Schirm stehen. Ein Filter fuer eine
Liste, die kuerzer ist als er. WEG.
Spicy Media -> "Alle Creator" / "Deine Creator". Scouts und
Manager filtern damit durch ihre Creator, und das
sind deutlich mehr. BLEIBT.
Die Trennung ist eine einzige Zeile an `ich.haus` -- das kommt vom
Server. Eine Rollenliste im Browser waere die zweite Wahrheit und fuer
DogFather, der in beiden Haeusern arbeitet, sogar falsch.
Der Zweig fuer die dritte Beschriftung ist mit entfernt, nicht
stehengelassen: "Fuer wen" ist von nirgends mehr erreichbar, und ein
Zweig, den niemand erreicht, sieht beim Lesen aus wie ein Fall, den
es gibt -- beim naechsten Umbau pflegt ihn jemand mit.
BEWIESEN IN BEIDE RICHTUNGEN, sonst waere die Trennung eine
Behauptung:
* pruef-handy-teamdogi (neu, 3 Pruefungen, 244 -> 247): auf crew.
im echten Browser ist die Reihe weg -- MIT der Gegenprobe, dass
die Seite ueberhaupt steht (4 Knoepfe in der Schwester-Reihe).
"Reihe nicht da" waere sonst auch auf einer kaputten Seite wahr.
* pruef-aufgabenbrett (49, unveraendert): bei Spicy Media steht sie
weiterhin da, mit "Alle, Tili, Luna" und der Beschriftung "Alle
Creator".
ZWEI DINGE AM PRUEFWERKZEUG, die mich heute Zeit gekostet haben:
1. `probleme` wurde seit jeher gefuellt und NIE ausgegeben. Am Ende
stand "1 Befund" und sonst nichts -- wer das liest, weiss DASS
etwas ist, nicht WAS, und muss den ganzen Lauf noch einmal
anstossen. Die Befunde stehen jetzt unter der Zahl.
2. Der Anmeldeweg stand in der Schleife, und fuer die neue Messung
habe ich ihn abgeschrieben -- dabei eine aeltere Fassung erwischt,
ohne `isVisible()` und mit `click()` statt `check()`. Ergebnis:
30 Sekunden Zeitablauf an der Altersfrage, die es fuer DogFather
gar nicht gibt. Jetzt ein Helfer, den beide Aufrufer benutzen.
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
|
59b2a6d0e5 |
Was nur fuer Vorleseprogramme dasteht, ist kein zerquetschter Text
DER BEFUND WAR EIN FEHLALARM pruef-handy-teamdogi meldete auf notizen.html, nur bei 412 px: Text auf fast nichts gedrueckt -- a.zurueck „Team Dogi…" 0 statt 82px Nachgemessen ist das Absicht. start.css setzt auf schmalen Schirmen `.kopfleiste .marke__text` auf 1x1 Pixel mit `clip-path: inset(50%)` -- das uebliche Muster fuer "bleibt fuer Vorleseprogramme, verschwindet fuer das Auge". Der Grund steht daneben: Der Text steht auf jeder Seite zwei Zeilen tiefer noch einmal als Ueberschrift. WARUM DIE ERKENNUNG DANEBENGRIFF `nurVorlesen()` gab es laengst -- sie sah aber nur das Element SELBST an. Der Link darin ist 0 Pixel breit, aber eine Zeile hoch, und traegt selbst kein `clip-path`. Er fiel damit durch beide Bedingungen. Die Funktion steigt jetzt die Kette der Vorfahren hoch. DAS MACHT DIE REGEL SCHAERFER, NICHT LAXER Ausgenommen wird nur, was in einem nachweislich abgeklemmten Kasten sitzt. Der echte Fund vom 20.09.2026 -- ein Gespraechsname, der in einer normalen Kopfzeile auf null gequetscht wurde -- hat keinen solchen Vorfahren und wird weiter gemeldet. Und das ist nicht behauptet, sondern gemessen: Die Gegenprobe bekommt ein PAAR statt eines Falls. Derselbe zerquetschte Text einmal in einem abgeklemmten Kasten (darf nicht gemeldet werden) und einmal ohne (muss gemeldet werden). Eine Regel, die enger misst, kann zu eng sein; dann faellt echter Schaden durch und der Lauf bleibt gruen. Sechs Gegenproben statt vier. GEMESSEN 244 Seitenaufrufe, 123409 Elemente, 5393 Bedienelemente 0 Befunde (vorher: 4-5, darunter die 40-Pixel-Knoepfe) alle sechs Gegenproben greifen, zweimal hintereinander gleich span#gp-laut „Dieser Name ist wirklich…" 0 statt 320px -> gemeldet span#gp-leise -> nicht OFFEN GEBLIEBEN Die Ueberstandsmessung derselben Datei nimmt abgeklemmte Elemente NICHT aus -- mein Gegenprobe-Element taucht dort als 523 px auf. Auf echten Seiten hat das keine Folgen (0 Befunde), aber es ist dieselbe Inkonsistenz an einer zweiten Stelle. Nicht angefasst, weil der Nachweis dafuer wieder den ganzen Lauf braucht. |
||
|
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
|
||
|
DogFatherGitandClaude Opus 5
|
65d278a18e |
Der Handy-Rundgang ist zum ersten Mal bei null Befunden
SECHS SACHEN, UND KEINE DAVON WAR DAS, WONACH ICH GESUCHT HABE. 1. ZWEI NATIVE prompt() IN teamlage.js -- die letzten im Haus. Sie halten die ganze Seite an, sehen auf jedem Browser anders aus als der Rest und koennen nicht sagen, was BLEIBT, wenn man absagt. Genau das ist dort die Frage, die jemand vor dem Klicken hat. Jetzt derselbe Dialog wie an den 42 anderen Stellen. 2. UND DER GRUND, WARUM SIE NIEMAND GEFUNDEN HAT. pruef-nachfrage suchte mit `(?:^|[^.\w])(confirm|prompt)\s*\(`. Das `[^.\w]` sollte fremde Methoden ausschliessen -- `angebot .prompt()` ist die Installations-Aufforderung des Browsers und kein nativer Dialog. Nur trifft dieser Ausschluss ausgerechnet die HAEUFIGSTE Schreibweise: `window.prompt(` hat einen Punkt davor. Die Pruefung war gruen, waehrend zwei native prompt() dastanden. Genau das Muster, vor dem dieses Haus warnt: eine Pruefung, die laeuft, gruen ist und das Falsche prueft. Die Gegenprobe kennt jetzt beide Schreibweisen -- haette sie das vorher getan, waere es am selben Tag aufgefallen. 3. willkommen.html LUD nachfrage.js NICHT. Gefunden von der geschaerften Pruefung. kopf.js ruft `frageNach(` ohne Absicherung -- auf dieser einen Seite haette ABMELDEN einen Absturz ausgeloest. Die Seite ist vom 21.09., die Luecke also einen Tag alt. 4. ZWEI FEHLALARME IM HANDY-RUNDGANG ABGESTELLT. Er meldete bei JEDEM Lauf dieselben drei Befunde: `button.schnitt bis 481px`, die Rechtetafel `table bis 877px`, `a.k-pille 8x8`. Nachgemessen bei 390 px: Das Dokument ist exakt 390 px breit, NICHTS laeuft ueber -- beide stehen in einem Kasten mit `overflow-x: auto`, und der rollt absichtlich. Die Kalenderpunkte tragen `pointer-events: none`; der Tipp gehoert der Tageszelle. Eine Warnung, die immer kommt, ist keine Warnung mehr (Hausregel vom 03.09.). Beide Regeln sind SCHMAL: nur ausdrueckliches `overflow-x: auto|scroll` (nicht `hidden` -- dort ist der Inhalt wirklich weg), nur ausdrueckliches `pointer-events: none`. Die Gegenprobe hat jetzt vier Faelle statt zwei: zwei, die gemeldet werden MUESSEN, und zwei, die es NICHT duerfen. Eine engere Messung kann auch zu eng sein. 5. DER LETZTE ECHTE BEFUND: 404 BEI JEDEM MODI. Der Rundgang meldete "404 (Not Found)" ohne Adresse -- eine Pruefung, die einen Fehler findet, ihn aber nicht auffindbar macht, kostet mehr Zeit als sie spart. Sie nennt jetzt die Adresse, und damit war es in einer Minute klar: `/workspace/api/werdegang/liste`. Der Code BEHANDELTE den 404 richtig, der Browser protokolliert ihn trotzdem -- derselbe Fall wie am 19.09. bei /anruf/adressen. Jetzt sagt der Server in /api/ich, ob jemand Team Dogi fuehrt. EIGENES FELD, kein Stellvertreter: `darf_verteilen` sieht aehnlich aus, ist aber nicht dasselbe -- ein Manager darf verteilen und fuehrt Team Dogi nicht. Dabei EINE Wartestelle statt zwei: `window.wennIchDaBin()`. `window.__ich` kommt ueber das Netz; zwei Seiten hatten dafuer jeweils ein eigenes setInterval. Zwei Fassungen desselben Wartens altern unterschiedlich. 6. pruef-werdegang MASS AUF DER FALSCHEN ADRESSE. Drei Pruefungen waren dauerhaft rot (`data-ton=null`) -- an einer Seite, die in Ordnung ist. Sie oeffnete `127.0.0.1`, also die Adresse der AGENTUR; dort ist `person.haus` nicht "crew" und die Kachelliste eine andere. Nachgemessen: Alle vier Rollen HABEN die Kachel, sobald das Haus stimmt. Jetzt derselbe https-Vorbau wie in pruef-willkommen und pruef-zuteilung. Beinahe haette ich hier etwas "repariert", das nicht kaputt war: Meine erste Messung rief `bereicheFuer(p, "crew")` auf -- das Haus wird aber aus `person.haus` gelesen, nicht als Argument. Sie sagte "DogFather hat keine Kachel". Eine plausible Herleitung ersetzt keine Messung, und eine falsch aufgesetzte Messung auch nicht. GEMESSEN: pruef-handy-teamdogi 214 Seitenaufrufe, 108.564 Elemente, 4.126 Bedienelemente -- 0 Befunde. Alle vier Rollen, beide Breiten. Zum ersten Mal. pruef-werdegang 103/0 (war 100/3), pruef-nachfrage 51/0 (war 49), pruef-stelle 15/0, pruef-entwicklung 48/0, pruef-start-ansicht 153/0, pruef-wege-nach-draussen 67/0, pruef-tippziele 11/0, pruef-treff 80/0, pruef-willkommen 67/0, pruef-sackgassen 13/0. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
6e46a08543 |
Portnummern werden abgeleitet, nicht mehr vergeben
Gemessen: 165 Pruefdateien, 129 verschiedene Nummern -- NEUNZEHN
doppelt, vier davon dreifach. Niemand hatte das gewollt; jede neue
Pruefung wurde von einer vorhandenen abgeschrieben, und die Nummer kam
mit. Meine eigene Notiz sagte "sieben" -- auch eine Bestandsliste
altert.
Der Waechter faengt den Schaden ab, aber er kann nur melden, was schon
passiert ist: Zwei Pruefungen mit derselben Nummer koennen nie
gleichzeitig laufen, und ein liegengebliebener Prozess der einen laesst
die andere abbrechen mit einer Meldung, die wie ein Befund aussieht.
Genau das ist mir am 20.09. zweimal passiert.
Jetzt leitet jede Datei ihre Nummer aus ihrer STELLE IM ALPHABET ab
(eigenerPort in helfer-port.mjs), zwei je Datei. Nicht ueber eine
Pruefsumme: Bei 165 Namen in 4900 Nummern waeren nach dem
Geburtstagsproblem rund DREI Zusammenstoesse zu erwarten -- ein Hash
tauscht eine sichtbare Doppelung gegen eine unsichtbare. Die Stelle im
Alphabet ist eindeutig von der Bauart her.
--- ZWEI FEHLER AUF DEM WEG, BEIDE LEHRREICH -------------------------
1. DER ERSTE VERSUCH WAR GRUEN UND KAPUTT. Ersetzt wurde mit einem
Muster: "([^"]*4231[^"]*)". Das hielt
{ host: "127.0.0.1", port: 4231, path: "/404.html" }
fuer eine Zeichenkette -- ein Muster kann eine oeffnende nicht von
einer schliessenden Anfuehrung unterscheiden. Heraus kam
{ host: "127.0.0.1`, port: ${PORT}, path: `/404.html" }
also GUELTIGER Code ohne port-Feld. `node --check` sagte gruen fuer
alle 164 Dateien. Aufgefallen ist es erst, weil ich vier Vertreter
gegen eine vorher gemessene Grundlinie laufen liess: pruef-schranke
39/0 vorher, 38/1 nachher.
Alles zurueckgenommen und mit einem Zerleger neu gemacht, der weiss,
ob eine Stelle Code, Zeichenkette, Vorlage, Kommentar oder
regulaerer Ausdruck ist. In pruef-ics stand die Nummer in einem
regulaeren Ausdruck -- der wird jetzt gebaut statt hingeschrieben.
2. EIN MODUL, DAS BEIM IMPORTIEREN ARBEITET, IST EINE FALLE. Der
zweite Durchgang importierte den ersten, um seine Mechanik zu
benutzen -- und fuehrte dessen Hauptlauf gleich mit aus. Die
zweiten Nummern wurden dadurch als erste behandelt, zwei Aufrufe
bekamen dieselbe Nummer, und in pruef-content stand `const PORT`
zweimal.
--- WAS DAS DAUERHAFT HAELT -----------------------------------------
pruef-portnummern.mjs (neu, 8 Pruefungen) fragt nicht "welche Nummern
sind doppelt", sondern "wer traegt ueberhaupt noch eine von Hand ein"
und "wer startet einen Server, ohne seine Nummer abzuleiten". Die
zweite Frage hat sofort etwas gefunden, das in KEINER Doppelungsliste
stand: pruef-push-weg belegte 4341 und 4342, rief den Waechter aber
gar nicht auf -- dieselbe Nummer wie pruef-agentur. Eine Liste zeigt
nur, was auf ihr steht.
Mit Gegenprobe: Eine unbekannte Datei bekommt keine geratene Nummer,
sondern einen Abbruch, und eine dritte Nummer je Datei gibt es nicht.
--- NACHGEMESSEN ----------------------------------------------------
Sechzehn Pruefungen gegen ihre vorher gemessene Grundlinie, je eine
Vertreterin jeder umgestellten Bauweise (eine Nummer, zwei Nummern,
Nummer in einer Zeichenkette, in einer Vorlage, in einem regulaeren
Ausdruck, dynamische Einfuhr, Nachtlauf mit zwei Laeufen):
crew-adresse 132/0 · schranke 39/0 · content 45/0 · entwicklung 46/0
anruf 127/0 · ics 37/0 · push-weg 20/0 · arten 28/0 · video 67/0
kanalzeile 14/0 · agentur 62/0 · spicy 83/0 · creator-anlegen 50/0
push-ziel 10/0 · portnummern 8/0
Alle exakt wie vorher. Zwei waren schon vorher rot und sind es
unveraendert geblieben (crew-wand-bild 41/4, teilen 14/3) -- per
`git stash` belegt, nicht angenommen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
75019ec8c3 |
Am Handy stand nicht da, mit wem man schreibt
Gemessen in der Kopfzeile eines Gespraechs, Name "Team-Runde":
360 px -> 0 px sichtbar (98 noetig)
390 px -> 12 px
412 px -> 33 px
1280 px -> passt
Auf JEDEM Telefon stand also kein Name da -- man oeffnet ein Gespraech
und sieht nicht, mit wem. Und weil die Zeile nicht leer aussieht
(Zurueck-Pfeil, fuenf Knoepfe), wirkt sie nicht kaputt, sondern eng.
URSACHE: `flex: 1` heisst ausgeschrieben `1 1 0%` -- Grundbreite NULL.
Damit "passt" der Name rechnerisch immer, egal wie eng es ist, und es
bricht nie etwas um. Die Knopfreihe daneben hat `flex: none` und
schrumpft nie; seit die Knoepfe am Finger 44 px breit sind, bleibt bei
sechs Knoepfen nichts uebrig.
Zwei Stellen setzten dieselbe Eigenschaft, die spezifischere gewann --
die erste Reparatur wirkte deshalb nur bei 360 px und sonst nicht.
Beide nennen jetzt dieselbe Grundbreite.
KEINE NEUE SCHWELLE: `flex-wrap` bricht genau dann um, wenn der Platz
wirklich nicht reicht. Dieses Haus ist an festen Breiten schon zweimal
gescheitert (Kopfleiste, 06.09.2026); kommt morgen ein siebter Knopf
dazu, stimmt es weiter. Ergebnis: 244 / 268 / 289 px statt 0 / 12 / 33.
---- WARUM DER HANDY-RUNDGANG DAS NICHT GEFUNDEN HAT ----------------
Zwei eigene Entscheidungen, jede fuer sich vernuenftig, zusammen ein
Loch:
1. `sichtbar()` verlangt `width > 0`. Ein auf null gequetschtes
Element ist unsichtbar -- und "unsichtbar" hiess "nichts zu
pruefen". Genau falsch herum: Nichts zu sehen IST der Befund.
2. `text-overflow: ellipsis` gilt als Absicht. Das stimmt auch --
ein langer Name soll gekuerzt werden. Es stimmt nur nicht mehr,
wenn nichts uebrig bleibt.
Die neue Regel ist bewusst schmal: gemeldet wird nur, was unter 40 px
sichtbar ist und mindestens das Doppelte braeuchte. "Jede Kuerzung
melden" waeren die ~350 Fehlalarme, die diese Pruefung schon einmal
zugedeckt haben.
NACHGEMESSEN: 206 Seitenaufrufe, 91 638 Elemente. Die Regel schlaegt
an genau EINER Stelle an (kalender.html, sechsmal) und sonst nirgends
-- 64 -> 70 Befunde. Die Pruefung ist genauer geworden, nicht die App
schlechter.
DER KALENDER-FUND BLEIBT OFFEN: Im Monatsraster ist ein Tag am Handy
36 px breit, ein Eintrag braucht 186 bis 317. Das ist kein Versehen im
Code, sondern die Frage, ob die Monatsansicht am Telefon ueberhaupt
die richtige Vorgabe ist -- eine Entscheidung, keine Reparatur.
GEPRUEFT: pruef-chat-optik 39/0 (drei neu, mit einer Gegenprobe, die
den gemessenen Fall HERSTELLT -- fuenf Knoepfe wie in einer Gruppe;
der erste Anlauf blieb gruen, weil in einem Zweiergespraech nur drei
stehen und der Platz auch ohne Reparatur reicht: 12 px mit der alten
Angabe, 268 mit der neuen, im selben Aufbau).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGit
|
c516aad4ed |
Nichts verschwindet mehr ohne eine Nachfrage, die sagt was passiert
Filipe: "Es darf vor allem keine Stellen geben, an denen ein Benutzer
etwas falsch machen kann, nur weil die Seite es nicht verstaendlich
genug erklaert."
Gemessen: 30 Stellen in 16 Dateien benutzten confirm() oder prompt().
Das Haus hatte die richtige Bauweise laengst -- einen <dialog>, in
aufgaben.html sogar ausfuehrlich begruendet -- aber sie stand IN EINER
SEITE. Wer anderswo etwas loeschen liess, hatte sie nicht.
confirm('Wirklich loeschen?') stellt die falsche Frage: Es fragt, ob
man sicher ist, und nennt nicht, WAS passiert, was BLEIBT und ob es
ZURUECK geht. Jetzt beantwortet jeder der 41 Dialoge alle drei.
Neu: workspace/assets/js/nachfrage.js -- window.frageNach() mit
Pflichtgrund, Zahlenfeld, einzeiliger Eingabe und Abtippsicherung.
Drei Ausgaenge: <dialog> / confirm()-Notnagel fuer Safari vor 15.4 /
Abbruch (Esc, Klick daneben, "Doch nicht" -- immer false).
DREIMAL DERSELBE FALLSTRICK, dreimal nachgemessen statt vermutet:
.dialog stand in aufgaben.css und leistung.css -> auf dateien.html
waere der Dialog ein weisser Systemkasten gewesen. 14 Regeln
klammergenau nach module.css verschoben (Klammern gezaehlt, nicht
per Muster geschnitten -- heute frueh hat ein nicht-gieriges
Muster schon einmal CSS zerrissen).
Das Formular trug .neu neu--blank -- und .neu gibt seine Abstaende
nur in aufgaben.css. Gemessen: padding 0px, und die Felder
verloren ihre height:44px. Jetzt steht alles unter
.nachfrage__form in module.css; der Dialog borgt nichts mehr.
Die erste Fassung der Pruefung zaehlte nachfrage.js SELBST als
Nutzer -- damit war jede Seite trivialerweise "Nutzer" und die
Pruefung gruen ohne Inhalt. Jetzt ausdruecklich ausgenommen.
ZWEI FUNDE NEBENBEI:
hilfeAufraeumen() wird im Betrieb NIE aufgerufen. Der Kommentar
behauptete "wird beim Start aufgerufen (siehe index.js)" -- das
war nie wahr; einziger Aufrufer ist die eigene Pruefung. Folge:
geschlossene vertrauliche Faelle bleiben unbegrenzt stehen. NICHT
eingeschaltet (das loescht echte Daten und ist Filipes
Entscheidung), sondern der Kommentar richtiggestellt.
Einen Hilfe-Fall zu schliessen ist endgueltig -- es gibt keine
Route, die ihn wieder oeffnet. Vorher stand darueber nur die
Frage nach einem Schlusswort. Jetzt sagt der Dialog es.
pruef-struktur hat meine eigene Pruefung von heute Nachmittag
erwischt: Sie bildete ihr Datum aus UTC. Beim Beheben erst
heuteLokal(datum) genommen -- die Funktion nimmt gar kein Argument
und haette still "heute" statt "+3 Tage" geliefert. Jetzt tagLokal(3),
nachgerechnet: Abstand 3 Tage.
Am Bildschirm angesehen (Rechner 1280, Handy 390): passt rein, Esc
ergibt false, Fokus liegt auf dem harmlosen Knopf, Knoepfe 44px auf
Touch. Der Platzhalter im Abtippfeld zeigte den erwarteten Namen --
das sah aus wie ein schon ausgefuelltes Feld, entfernt.
Neu: server/pruef-nachfrage.mjs -- 17/0, mit sechs Gegenproben und
beiden Richtungen (wer fragt, laedt die Datei; wer nie fragt, laedt
sie nicht -- sonst truege die Anmeldewand 4,8 KB fuer nichts).
pruef-meldungen 8/0, pruef-css-klassen gruen, pruef-struktur gruen,
pruef-leistung gruen.
|
||
|
DogFatherGitandClaude Opus 5
|
5c3bfcb47d |
Der Handy-Rundgang, den es fuer die Modis nie gab
Filipe: "mach einen kompletten check dass die app auf dem handy perfekt
funktioniert ... weil die modis haben schon probleme." Auf die
Rueckfrage: "einfach ALLES ABCHECKEN ALLES MOEGLICHE."
=== DER BEFUND, DER ALLES ERKLAERT ===
Es gibt seit dem 02.09. einen grossen Rundgang (pruef-grosscheck). Er
geht ueber jede Seite, zwei Bildschirmgroessen und VIER Rollen:
admin . manager . scout . creator
Vier von acht. Es fehlen modi, hand und gast -- also genau die drei
Rollen, die auf crew.dogfather-universe.com leben, und genau die, von
denen die Beschwerden kommen. Ihre Seiten waren nie im Ganzen auf einem
Handy durchgemessen worden.
Kein Vorwurf an den Rundgang: Er wurde fuers Agenturhaus gebaut, und
Team Dogi kam spaeter dazu. Aber es erklaert, warum Fehler dort
ueberleben konnten.
pruef-handy-teamdogi.mjs schliesst die Luecke: 4 Rollen x 2 Breiten x
bis zu 32 Seiten = 206 Seitenaufrufe, 91 052 Elemente, 3 880
Bedienelemente. Gemessen wird: kommt die Seite an, stuerzt etwas ab,
laeuft etwas ueber den Rand, ist Text abgeschnitten, kann man es
treffen, liegt etwas uebereinander, weiss man was es tut.
=== WAS ES GEFUNDEN HAT ===
DIE KOPFLEISTE WAR AUF JEDER SEITE ZU KLEIN. Bei Breiten bis 400 px
schrumpften alle Knoepfe auf 34x34, bis 560 px auf 36x36. Das sind zehn
Pixel unter dem, was ein Daumen sicher trifft -- und es betraf jede
Seite, jede Rolle, jeden Aufruf. Genau das erlebt man als "der Knopf
geht nicht".
Die Verkleinerung war nie noetig. Am echten Aufbau nachgemessen:
Breite belegt bei 44px noetig verfuegbar
360 px 237 284 328
390 px 237 284 358
412 px 245 284 380
Es passt ueberall, mit Luft. Jetzt 44x44 -- und dazu `flex-wrap: wrap`
als Regel statt einer dritten festen Zahl: Die Reihe bricht genau dann
um, wenn der Platz wirklich nicht reicht.
DER ZURUECK-KNOPF war 38x44 -- die Hoehe stimmte, die Breite nicht. Der
Rundgang hat ihn 192-mal gemeldet. Er ist der Knopf, den man auf jeder
Unterseite am haeufigsten trifft.
DIE KLEINEN UMSCHALTER (38 px) waren eine begruendete Ausnahme --
begruendet fuer die Maus. Auf Geraeten, die mit dem Finger bedient
werden, gilt jetzt 44. Gefragt wird `pointer: coarse` und nicht die
Breite: Ein schmales Browserfenster am Rechner braucht keine 44 px, ein
1200 px breites Tablet sehr wohl.
DIE KALENDERPILLEN waren 26 px hoch, das Rechtefeld 34 px breit, die
Kalenderpfeile 38 px. Alle auf 44.
EINE BESCHRIFTUNG HING NICHT AM FELD. In checkliste.js stand ein
<label> ohne `for` neben einem <select> ohne `id`. Optisch richtig --
fuer ein Vorleseprogramm ein namenloses Feld. Und weil wahl.js das
Systemmenue durch einen eigenen Knopf ersetzt und dessen Namen AUS DEM
LABEL holt, blieb auch der Knopf namenlos.
=== DREI FEHLER IN MEINER EIGENEN PRUEFUNG ===
Und sie sind der lehrreichere Teil.
(1) DER ERSTE LAUF MELDETE EIN 1647 px BREITES BILD auf einem 390 px
breiten Schirm. Das sah nach dem Fund des Tages aus. Es war einer
in MEINER Pruefung: `dogfather-universe.com` steht in der fest
eingebauten HSTS-Liste von Chromium, der Browser schaltet
unabaenderlich auf https um, und mein Testserver sprach http.
Ergebnis: JEDE Stilvorlage schlug fehl. Gemessen wurde eine Seite
ganz ohne CSS.
Haette ich den Befund gemeldet statt nachzusehen, waere ein halber
Tag in eine Reparatur geflossen, die nichts repariert. Die Pruefung
spricht jetzt selbst https, mit eigenem Zertifikat und einem
winzigen Vorbau.
(2) 350 FEHLALARME. `span.zurueck-knopf__text` wurde 192-mal als
abgeschnitten gemeldet, `span.teilen__text` 154-mal -- beide sind
ABSICHTLICH 1 px gross und weggeschnitten, damit ein
Vorleseprogramm sie liest und das Auge nicht. Dazu 24-mal
`-webkit-line-clamp` (gewolltes Kuerzen auf zwei Zeilen), 14-mal
Textfelder MIT Beschriftung (ich fragte `labels` nur bei input und
select, nicht bei textarea) und 26-mal Zierrat mit
`aria-hidden="true"`.
Eine Warnung, die immer kommt, ist keine Warnung mehr -- und diese
haetten jeden echten Fund zugedeckt.
(3) DIE UEBERLAUF-MESSUNG WAR BLIND. Sie rechnete
`scrollWidth - clientWidth`; `body { overflow-x: hidden }` macht
beide Werte immer gleich. Die Pruefung fand nichts und meldete
trotzdem gruen. Gefunden hat das die GEGENPROBE -- sie ist genau
dafuer da. Jetzt zaehlt, ob ein sichtbares Element ueber den
rechten Rand ragt.
=== UND EIN FEHLER BEIM AUFRAEUMEN ===
Beim Verschieben der Touch-Regeln von start.css nach module.css hat ein
NICHT-GIERIGES Suchmuster am ersten `}` am Zeilenanfang aufgehoert und
dabei mehr mitgenommen als gemeint: die Schriftgroessen-Regeln fuer
schmale Fenster. Die haetten danach nur noch auf Geraeten mit Finger
gegolten.
Gefunden hat es wieder der Rundgang, nicht das Lesen: `.k-pille` blieb
26 px hoch, obwohl die neue Regel 44 sagte -- die alte stand weiter
unten und gewann. Zurueckgeholt aus HEAD, an ihren Platz gesetzt.
Nebenbei kam dabei heraus, WARUM eine Regel nicht ankam: Jede Seite
laedt gate -> start -> seite -> module -> haus. `aufgaben.css` setzt
`.schnitt { min-height: 38px }` mit derselben Staerke, kommt aber
spaeter. Eine Regel, die man geschrieben hat und die nicht wirkt, sieht
im Editor genauso aus wie eine, die wirkt.
=== STAND ===
Befunde: 120 -> 64.
Weg sind: alle abgeschnittenen Texte (0), alle namenlosen
Bedienelemente (0), alle zu kleinen Knoepfe in Kopfleiste, Zurueck-Weg,
Filterreihen, Kalender.
Es bleiben 64, und sie sind alle von derselben Sorte: 48-mal der
Ersatzknopf eines Auswahlfeldes (34-42 px breit, aber 44 hoch), 8-mal
Kalenderpillen (36-39 breit, 44 hoch), 8 Ueberstaende. Alle sind in der
HOEHE gross genug und nur in der Breite knapp -- die komfortable
Empfehlung, nicht die Mindestanforderung. Sie stehen namentlich im
Prueflauf und sind der naechste Schritt.
GEMESSEN: pruef-css-klassen ALLES IN ORDNUNG, pruef-meldungen 8/0,
pruef-rechtetafel 19/0, pruef-turn-wege 15/0, und beide Gegenproben des
neuen Rundgangs schlagen an.
Co-Authored-By: Claude Opus 5 <[email protected]>
|