5d9c8cd37764f5e4f3e5ed36aed900cf34be1537
5
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
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]>
|
||
|
|
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]>
|
||
|
|
09375047a7 |
Entwicklung: die Karte geht auf dem Zugetragenen auf
Filipe, 01.10.2026: „mach alles los." Damit auch der offene Punkt von gestern: „Zugetragen" ist beim Aufmachen einer Karte die Vorgabe. DER ALTE EINWAND BLEIBT GUELTIG -- er steht jetzt in der Bedingung statt im Weg. Er lautete: „Ein Filter, der beim Öffnen schon etwas versteckt, lässt einen Punkte suchen, die gestern noch da waren." Richtig, und er trifft genau EINEN Fall: den, in dem gar nichts zugetragen ist. Dann zeigte „Zugetragen" eine LEERE Karte, und eine leere Karte sieht aus wie ein Fehler. Also: Hat dieser Mensch zugetragene Punkte, steht der Filter darauf. Hat er keine, steht er auf „Alle". Beides ist eine Auskunft, keines ist eine Suche. UND ER WIRD JE MENSCH NEU ENTSCHIEDEN. Bisher blieb der Filter ueber den Personenwechsel hinweg stehen -- richtig, solange er eine Erwartungsstufe meinte („wer Fortgeschritten gewaehlt hat, will das weiter sehen"). „Zugetragen" ist eine Aussage UEBER DIESE PERSON; sie mitzunehmen waere die falsche Frage. GEMESSEN, beide Faelle: Diene (2 zugetragen) -> Filter „Zugetragen", 2 Punkte VanVan (nichts) -> Filter „Alle", 68 Punkte ein Klick auf „Alle" -> wieder 68 Die Messung fragt jetzt, WAS DASTEHT, bevor jemand etwas anfasst. Vorher klickte sie auf den Filter und zaehlte nach -- seit er die Vorgabe ist, haette derselbe Klick ihn AUSgeschaltet. Sie haette das Gegenteil gemessen und trotzdem eine Zahl gemeldet. ZWEI NACHZUEGLER AUS DEM SICHT-WEG VON GESTERN `pruef-werdegang` wurde rot: „403 Forbidden" im Browser, ohne Adresse. Die Meldung sagte nicht, WORAN sie scheitert -- also sagt sie es jetzt (`403 /workspace/api/chat/sicht`). Die Ursache lag in der Messumgebung, nicht im Programm: Der HTTPS-Vorbau der Pruefung reicht den Host OHNE Port weiter, waehrend der Browser seine Herkunft MIT Port schickt. `gleicheHerkunft` vergleicht beides und antwortet folgerichtig 403. mess-reaktion macht es seit Langem richtig; zwei Dateien nicht. Aufgefallen ist es erst jetzt, weil der Sicht-Weg der erste zustandsaendernde POST ist, der auf JEDER Seite laeuft. Live stimmen Herkunft und Host ueberein (beide ohne Port, Caddy reicht den Host durch) -- nachgemessen. GEPRUEFT pruef-werdegang 103/0 (war 103/1), pruef-entwicklung 79/0, pruef-entwicklung-kacheln 34/0, mess-vanvan-karte ohne ein einziges ACHTUNG, pruef-zwischenspeicher 34/0. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
|
721ad262df |
Entwicklung: „Deine Karte" laesst sich einklappen
VanVan im Support: „Deine Karte im Bereich eure Aufgaben kann man
noch nicht einklappen, was die Seite unnötig lang zieht und
unübersichtlich macht."
GEMESSEN (mess-vanvan-karte, Abschnitt 5). Es ist IHRE eigene Karte,
nicht die eines Modi -- im Bildschirmfoto steht an jedem Punkt „1 ×
Läuft", also eine einzige Antwort. Ueber die rechte Hand urteilt nur
DogFather; bei ihr ist deshalb alles durch und die Karte entsprechend
lang, waehrend ein Modi zwei Stimmen braucht.
vorher nachher
Seite gesamt 7245 px 2945 px
davon „Deine Karte" 6186 px 1886 px (zugeklappt 636 px)
Schalter 0 6 + „Alle"-Knopf
6186 von 7245 px waren eine einzige Karte -- 85 Prozent der Seite,
68 Zeilen am Stueck, kein einziger Schalter.
DERSELBE MECHANISMUS WIE NEBENAN, NICHT EIN ZWEITER. Die Karte der
Leitung klappt seit Langem auf und zu. Die Klassen, der Pfeil, die
Zahl im Kopf und der Knopf „Alle auf-/zuklappen" sind dieselben --
ein zweiter Mechanismus daneben waere der, der beim naechsten Umbau
vergessen wird, und er saehe anders aus, obwohl er dasselbe tut.
Herausgeloest als `klappAbschnitt()`.
WELCHER STEHT OFFEN: Was ich TUN soll („Deine Aufgaben"), und von den
Beobachtungen die erste Kategorie. Alle zu hiesse „jedes Mal erst
suchen", alle auf waere der Zustand von vorher.
DIE ZAHL STEHT IM KOPF (14, 12, 12, 11, 10, 9). Eine zugeklappte
Kategorie, die nicht sagt, wie viel in ihr steckt, klappt man einmal
auf und danach nie wieder zu.
GEPRUEFT
Die Messung ist jetzt selbst die Wache: Sie schlaegt an, wenn es
keine Schalter gibt (so ist der Befund entstanden), wenn Zuklappen
weniger als die Haelfte spart, und wenn es Schalter ohne
„Alle"-Knopf gibt. Alle drei nachgestellt. Ein ANTEIL und keine feste
Pixelzahl -- 68 Punkte heute, vielleicht 90 naechstes Jahr.
pruef-entwicklung 79/0, pruef-werdegang 103/0,
pruef-entwicklung-kacheln 34/0, pruef-css-klassen,
pruef-zwischenspeicher 34/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
|
51c47e1c07 |
Entwicklung: der Mensch sieht, was seine Aufgabe ist
VanVan im Support: „wenn ich … Aufgaben an einen Modi zutrage und
auch bewerte, dann sieht der Modi zwar die Auswertung im Bereich
Entwicklung, aber bei ihm taucht nichts im Bereich eure Aufgaben
unten in der Karte auf."
IHR FALL NACHGESTELLT (server/mess-vanvan-karte.mjs): VanVan traegt
einem Modi zwei von 68 Punkten zu und bewertet sie, Filipe bewertet
nichts -- genau wie bei ihr.
vorher seine Karte: fertig=0 von 68, alles „offen",
Punktzeilen sichtbar: 0
Kennt sie das Wort „zugetragen"? NEIN
nachher Abschnitt „Deine Aufgaben (2)" mit beiden Titeln
ZWEI DINGE WAREN EINS, DIE GETRENNT GEHOEREN
Was er TUN soll die Zuteilung. Die gibt es, bevor jemand etwas
bewertet, und sie gehoert ihm.
Was man SIEHT die Bewertung. Die erscheint erst, wenn alle
hingesehen haben.
`meine-karte` kannte nur das Zweite. War die Bewertung noch nicht
vollstaendig, stieg die Anzeige mit `return` aus -- und damit sah er
gar nichts, obwohl ihm zwei Aufgaben zugetragen waren. Das ist die
falsche Reihenfolge: Wer seine Aufgabe erst sieht, wenn sich zwei
Leute ueber ihre Ausfuehrung einig sind, kann sie nicht angehen.
Die Regel fuer die Bewertung bleibt unveraendert. Eine einzelne
Meinung soll bei einem Menschen nicht als Urteil des Teams ankommen.
UND DIE ANDERE HAELFTE: NIEMAND SAGTE ES IHR
VanVan hatte gesetzt, es kam nicht an, und nichts auf ihrem
Bildschirm erklaerte das. Ein Mensch, der das zweimal erlebt, hoert
auf zu setzen. An einem Punkt, den sie bewertet hat, steht jetzt
leise: „Er sieht das noch nicht -- es fehlt noch eine Einschaetzung."
Ohne Namen: Wer fehlt, waere eine Aufforderung, jemanden
anzutreiben.
IHRE ZWEITE BEOBACHTUNG, EBENFALLS GEMESSEN
„bei jedem Punkt läuft obwohl auch wenn die Aufgaben darüber gar
nicht zugetragen wurde." Stimmt: Die vier Bewertungsknoepfe („✓
Läuft ↗ Wächst ! Da hakt es – Kann ich nicht sagen") stehen an allen
68 Punkten, auch an den nicht zugetragenen. Beim Durchscrollen liest
man deshalb ueberall „Läuft".
DIE 68 BLEIBEN. Filipe am 25.09.2026 ausdruecklich: „dogfather und
die rechte hand sollen immer noch die 68 sachen sehen wie vorher …
unsere sicht soll sich nicht aendern." Also kein Ausblenden und
keine neue Vorgabe, sondern ein Knopf mehr in der Leiste, die es
schon gibt: „Zugetragen · 2". „Alle" bleibt, was beim Aufmachen
gilt. Gemessen grenzt er auf 2 Punkte ein, Kopf „2 / 2".
NEBENBEI ZUSAMMENGEFUEHRT
* `beurteilerZahl()` an einer Stelle -- beide Enden stellen dieselbe
Frage, zwei Abschriften saegten irgendwann Verschiedenes ueber
denselben Punkt.
* `antwortReihe()` und `punkteGefiltert()` ebenso.
* Die Abfrage stand zuerst je Punkt in der Schleife: 68
Datenbankfragen fuer eine Zahl, die sich nicht aendert.
GEPRUEFT
pruef-entwicklung 79/0 (9 neue, mit Gegenproben in beide Richtungen:
ein nicht zugetragener Punkt traegt die Marke nicht, und sobald der
zweite Beurteiler setzt, geht es durch). mess-vanvan-karte ohne
ACHTUNG. pruef-werdegang 103/0, pruef-entwicklung-kacheln 34/0,
pruef-deutsche-texte, pruef-css-klassen, pruef-zwischenspeicher 34/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|