e8a5d7bc7e5dc5c5308727d78d52df016d706a2d
100
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
e8a5d7bc7e |
pruef-glocke: drei Viertel der Pruefung sind nie gelaufen
8 Pruefungen standen am Ende da. Jetzt sind es 36.
SCHRITT FUER SCHRITT NACHGEMESSEN, statt der Meldung zu glauben:
1. Drei von acht Rollen scheiterten mit „Zeitsperre nach 25 s"
beim Warten auf start.html -- hand, linke, modi. Danach brach
die Datei ab; alles dahinter lief nie.
2. Nicht an der Last: allein dasselbe Bild.
3. Was antwortet die Anmeldung im Browser? 401 ungueltig.
4. Dieselbe Anmeldung ueber die Schnittstelle, am SELBEN laufenden
Server: 200. Es lag also nie am Server.
5. Der Unterschied ist die KACHEL. Es gibt zwei Anmeldeseiten:
workspace/index.html spicy, admin, manager, scout, creator
workspace/crew-index.html admin, hand, linke, modi, gast
Auf 127.0.0.1 kommt die Agenturseite.
KEIN FEHLER AM PRODUKT. Der Server ist auf einer Pruefadresse
absichtlich grosszuegig, damit Pruefungen alles testen koennen (das
steht so im Quelltext); die zwei Seiten sind die Trennung der zwei
Haeuser.
DER FEHLER WAR EIN NOTNAGEL IN DER PRUEFUNG:
const kachel = await seite.$(`.rolle[data-rolle="${rolle}"]`)
|| await seite.$(".rolle");
Er sollte verhindern, dass ein Klick auf eine fehlende Kachel
abbricht. Seit die Kachel am 30.09. BINDEND ist (`718b267d`, auf
Filipes Wunsch), macht er aus „diese Kachel gibt es hier nicht"
etwas Schlimmeres: Er klickt irgendeine, der Server weist zu Recht
ab, und heraus kommt eine Zeitsperre nach 25 Sekunden, die wie ein
Fehler an der Glocke aussieht.
EIN NOTNAGEL, DER STILL DAS FALSCHE GREIFT, IST SCHLIMMER ALS EIN
LAUTER ABBRUCH. Jetzt wird die richtige Seite PROBIERT (nicht aus
einer Liste von Crew-Rollen gelesen -- die waere die naechste, die
beim sechsten Eintrag nicht mitwaechst), und findet sich die Kachel
auf keiner der beiden, bricht es mit Namen ab und zeigt, welche
Kacheln dastehen.
DAS IST HEUTE DER ZWEITE FALL DERSELBEN WURZEL. Bei
pruef-crew-wand-bild war es dieselbe Folgewirkung der bindenden
Kachel, nur sichtbarer. Nach jener Aenderung bin ich die Pruefungen
zum Zugang gelaufen und nicht die, die nebenbei eine Anmeldung
brauchen.
DENSELBEN NOTNAGEL GIBT ES NOCH EINMAL, in pruef-gifs. Dort zielt er
auf `creator`, und die Kachel steht auf der Agenturseite -- er
greift heute nie. Das ist Glueck und kein Entwurf, also ist er auch
dort weg.
GEPRUEFT: pruef-glocke 8 -> 36 Pruefungen, 0 Fehler, alle acht
Rollen. pruef-gifs 17 Pruefungen, 0 Fehler.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
775aabef38 |
Standwache: hat sich der Stand WAEHREND des Laufs geaendert?
Die zweite Sitzung hat die Luecke benannt: Das Arbeitsschloss
schuetzt den Commit und die Stempellaeufe, nicht die Pruefläufe. Wer
misst, waehrend ein anderer speichert, misst einen Stand, den es
nicht mehr gibt.
Am 06./07.09.2026 sind so fuenf Gesamtlaeufe wertlos geworden — rund
zwei Stunden Wartezeit ohne einen einzigen Befund. Am 01.10. dieselbe
Lage, nur anders: zwei Sitzungen im Verzeichnis, eine misst, die
andere speichert. Aufgefallen ist es nur, weil die andere es von
sich aus gesagt hat.
DIE FRAGE IST EINE MESSUNG, KEINE ZUSTAENDIGKEIT
„Haelt jemand das Schloss" waere die falsche Frage, und zwar in
beide Richtungen:
* Sie blockiert zu viel: Wer zwei Stunden am Schloss sitzt, haette
in der Zeit keinen Prueflauf mehr. Eine Sicherung, die das eigene
Arbeiten anhaelt, wird abgeschafft.
* Sie blockiert zu wenig: Filipe am Editor hat kein Schloss, mein
eigenes Werkzeug auch nicht.
Gefragt wird deshalb: Ist der Stand am Ende noch derselbe wie am
Anfang? Das trifft jede Quelle.
AN DER NOTBREMSE, NICHT IN 179 DATEIEN
Gemessen: 179 von 231 Pruef- und Messdateien rufen `notbremse`. Das
ist die eine Stelle, an der alle etwas bekommen — dieselbe
Ueberlegung wie bei der Notbremse selbst. Einzelne Dateien
nachzuruesten hilft nur bis zur naechsten ohne.
Fingerabdruck: Anzahl, Gesamtgroesse und juengste Aenderung von
workspace, assets, server, webdesign und den Seiten im
Wurzelverzeichnis — 670 Dateien in 27 ms. Kein Hash ueber den
Inhalt: Gesucht ist „hat jemand gespeichert", und das aendert immer
mindestens die Zeit.
BILDER ZAEHLEN NICHT. Die Messdateien legen selbst welche ab; eine
Wache, die bei jedem Bildschirmfoto anschlaegt, wird weggeklickt und
nimmt die echte Meldung mit.
SIE HAELT NICHTS AN. Ein Lauf, dessen Grundlage sich verschoben hat,
ist nicht „nicht in Ordnung" — er ist NICHT NACHSEHBAR. Deshalb
Rueckgabewert 3 (nicht 1, das waere eine Aussage ueber den Code; und
nicht 0, ein gruener Haken ueber einen Stand, den es nicht mehr
gibt, waere das Schlimmere) und ein ausdruecklicher Satz, dass das
kein Befund ist.
GEPRUEFT — pruef-arbeitsschloss 35 -> 48 Pruefungen, 0 Fehler:
zwei Aufnahmen hintereinander gleich (sonst waere jede Meldung
wertlos)
geaenderte Datei -> faellt auf
neue Datei -> faellt auf
neues Bild -> faellt NICHT auf
Lauf mit Aenderung -> Rueckgabe 3, sagt NICHT NACHSEHBAR
Lauf ohne Aenderung -> Rueckgabe 0 (Gegenprobe; sonst
waere „endet mit 3" auch wahr, wenn
sie IMMER 3 meldet)
Alles in einem Wegwerf-Verzeichnis mit gefaelschtem Baum — moeglich,
weil die Wache ihre Wurzel aus ihrem EIGENEN Pfad ableitet. Waere
sie festgeschrieben, liesse sich die Wache nicht pruefen, ohne am
echten Haus zu wackeln.
UND AM ECHTEN LAUF NACHGEWIESEN: Mitten in pruef-arten eine Datei
gespeichert -> Rueckgabe 3, mit Groesse und Uhrzeit. Ohne Eingriff
bei neun Laeufen (treff 85, kalender 141, material 159,
erwaehnung 129, arten, dabei-optik, tagesblick, aufgabenbrett,
kopfleiste, seiteninhalt) kein einziger Fehlalarm.
EINE ERWARTUNG VON MIR WAR FALSCH, und die Wache hatte recht: Ich
hatte im gefaelschten Baum eine zaehlende Datei erwartet, es sind
zwei — die Seite UND die Kopie der Wache selbst im server-Ordner.
Der zaehlt mit, und das ist richtig: Eine geaenderte Pruefdatei
verschiebt den Stand genauso wie eine geaenderte Seite.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
ec0ee61691 |
Arbeitsschloss: der Haken bleibt auf LF, und ein Messfehler von mir
ZWEI NACHTRAEGE ZUM SCHLOSS. 1. DER HAKEN HAT KEINE DATEIENDUNG Damit greift keine der Regeln in .gitattributes von sich aus — und git kuendigt beim Committen selbst an: „LF will be replaced by CRLF the next time Git touches it". Auf Linux ist `#!/bin/sh` mit einem CR dahinter ein Programmname mit einem unsichtbaren Zeichen am Ende („bad interpreter"), und die Datei hat schon einen Kommentar genau darueber. Eigene Zeile dazu: `tools/git-haken/* text eol=lf`. NACHGEMESSEN, DAMIT HIER KEINE BEHAUPTUNG STEHT: Auf Windows blockiert auch ein CRLF-Haken richtig — Rueckgabe 1, null Commits, richtige Meldung. Das ist also Vorsorge und keine Reparatur. Aber ein Haken, der still nicht laeuft, ist genau die Sicherung, die aussieht, als waere sie da. Zwei neue Pruefungen dazu: der Haken hat reine LF-Enden (byteweise gemessen), und die Regel steht in .gitattributes. 2. EIN MESSFEHLER VON MIR, UND ER GEHOERT AUFGESCHRIEBEN Ich habe gemeldet, im Verlauf lägen 73 CR-Bytes. Es war keines. Gemessen hatte ich mit einer Rohrkette aus `tr` und `od`, und `tr` nimmt in dieser Shell die Maskierung fuer das Wagenruecklauf-Zeichen nicht als Zeichen — gezaehlt wurden am Ende Zeilenenden, und die Datei hat 73. Mit Python byteweise nachgemessen: 0 im Arbeitsbaum, 0 im Index. Die Datei war immer LF; git hat nur VORHERGESAGT, was beim naechsten Auschecken passiert. Das ist heute der dritte Messfehler aus Shell-Maskierung — nach zwei `\b`, die als Steuerzeichen in regulaeren Ausdruecken landeten und dort je eine Pruefung lahmgelegt haben. Und beim Aufschreiben dieser Lehre ist sie mir ein viertes Mal passiert: Aus dem Kommentar `tr -d '\r'` wurde `tr -d ''`, die Aussage hat sich selbst bewiesen und dabei unlesbar gemacht. DIE REGEL STEHT JETZT, und zwar im Werkzeug selbst: Alles mit einem Rueckstrich gehoert in eine DATEI, nie in ein Hier-Dokument. Und wer Bytes zaehlen will, zaehlt Bytes — `readFileSync` ohne Zeichensatz, und 13 ist 13. GEPRUEFT: pruef-arbeitsschloss 33 -> 35 Pruefungen, 0 Fehler. Steuerzeichen im ganzen Haus: 834 Dateien, keines. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
603319a145 |
Arbeitsschloss: zwei Sitzungen sehen sich jetzt
HEUTE ZWEIMAL NUR GUTGEGANGEN. Zwei Claude-Sitzungen arbeiteten
gleichzeitig in diesem Verzeichnis, ohne voneinander zu wissen.
Keine hat etwas falsch gemacht — sie konnten es nicht wissen.
* Beide haben `git add -A` benutzt. Haette die eine
unfestgeschriebene Arbeit der anderen im Baum gehabt, waere sie
mitcommittet worden — unter fremdem Namen, in einer fremden
Begruendung, und niemandem waere es aufgefallen. Nachgesehen:
diesmal war nichts dabei.
* Beide haben den Stempellauf gestartet. Der schreibt 45 Dateien
um. Wer dort eine offen hatte, bekam sie unter den Haenden weg
geaendert.
Dasselbe hat in RunOne am 03.09.2026 sieben Minuten Ausfall
gekostet. Dort gibt es seitdem `arbeitsschloss.sh`; diese Fassung
uebernimmt seine Lehren.
WAS ES IST UND WAS NICHT. Es ist kein Riegel — wer wirklich muss,
kommt vorbei. Es beantwortet die eine Frage, die heute niemand
beantworten konnte: „arbeitet hier gerade sonst jemand?"
Die teuren Fehler liegen bei einem Schloss alle in derselben
Richtung: Es blockiert zu viel und wird deshalb abgeschafft. Also:
* Es blockiert NICHT, wenn das Schloss DEINES ist. RunOnes erste
Fassung fragte „ist abgeschlossen" statt „haelt es jemand
anders" — damit haette, wer ordentlich abschliesst, nie mehr
ausliefern koennen. Dafuer gibt es `fremd`.
* Es VERFAELLT nach zwei Stunden, und dass da jemand war, steht
beim Uebernehmen dabei.
* Es blockiert NICHT, wenn es selbst unlesbar ist — dritter
Ausgang, kein Stillstand.
* Notausgang: SCHLOSS_ZWANG=ja git commit …
DAS PROBLEM, AN DEM RUNONE HAENGT, IST HIER GELOEST. Dort faellt die
Kennung im Zweifel auf den Systembenutzer zurueck, und zwei
Claudian-Sitzungen laufen BEIDE als `claudian` — die Sicherung griff
ausgerechnet zwischen den zwei Faellen nicht, fuer die sie gebaut
wurde. Deshalb ist dort `export ARBEITER=…` Pflicht, und Pflicht
heisst: man vergisst es.
Hier steht `CLAUDE_CODE_SESSION_ID` in jeder Sitzung und ist je
Sitzung verschieden (nachgesehen, 36 Zeichen UUID). Zwei Sitzungen
auf demselben Windows-Benutzer unterscheiden sich damit von selbst,
ohne dass jemand etwas tun muss. Reihenfolge: ARBEITER, dann
Sitzungskennung, dann Benutzername MIT Warnung.
NIEMAND MUSS DARAN DENKEN:
* die beiden Stempelwerkzeuge nehmen es selbst und geben es selbst
frei — auch nach einem Absturz und bei Strg+C (wie `bauen.sh` im
Shop; eines, an das man denken muss, wird vergessen und ab da
umgangen)
* `tools/git-haken/pre-commit` bricht jeden Commit ab, solange
jemand ANDERS das Schloss haelt. Das ist die Stelle, die heute
gefehlt hat: `git add -A` ist der Griff, den man ohne Nachdenken
macht, und gegen einen Reflex hilft keine Regel auf Papier.
* `core.hooksPath` statt `.git/hooks` — letzteres ist nicht
versioniert und waere nach einem Klon genau dann leer, wenn es
gebraucht wird.
GEPRUEFT, server/pruef-arbeitsschloss.mjs: 33 Pruefungen, 0 Fehler —
in einem WEGWERF-Verzeichnis mit eigenem git, damit kein echtes
Schloss angefasst wird. Darunter am echten git:
ohne Schloss committen -> geht (0)
mit dem EIGENEN Schloss -> geht (0)
mit einem FREMDEN Schloss -> bricht ab (1), nennt wer und warum
und es stehen genau ZWEI Commits da, nicht drei
SCHLOSS_ZWANG=ja -> kommt vorbei
ohne das Schloss-Werkzeug -> laesst durch
Dazu: verfallenes Schloss laesst durch, mit laengerer Frist blockt
dasselbe Schloss wieder (Gegenprobe), unlesbarer Inhalt und
unlesbarer Zeitstempel blockieren nicht.
Portnummern nach der neuen Pruefdatei nachgemessen: Pruefbereich bis
5415, 462 Nummern, 0 Kollisionen. pruef-struktur 75/0,
pruef-fingermass 5/0, pruef-ports 10/0.
In DEPLOY.md steht es jetzt an erster Stelle — eine Sicherung, von
der nur der weiss, der sie gebaut hat, ist die erste, die umgangen
wird.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
1afb38258c |
Anfuehrungszeichen: drei Loecher in meiner eigenen Wache
Die zweite Sitzung hat in den Praesentationen des Vaults 83 Stellen
gefunden — und damit auf Loecher in MEINER Wache gezeigt. Ich habe
sie nachgemessen, alle drei waren echt.
LOCH 1 — SIE SAH NUR `server/workspace-*.js`
Also ausgerechnet nicht `workspace.js`, die groesste Datei des
Hauses. Der weitere Filter fand dort sofort drei Stellen:
workspace.js:3404 Kanal „Chat-Moderation" (Protokoll)
workspace.js:3422 „${titel}" -> ${haus} (Protokoll)
workspace.js:3304 „${… || "ohne Titel"}" (siehe Loch 3)
Das ist heute der DRITTE Fall von „die Wache kennt nur die halbe
Menge" — nach pruef-struktur (sah nur die Pruefdateien, nicht die
Anwendung) und pruef-fingermass (sah keine variable Breite).
LOCH 2 — IHR AUSDRUCK GILT JE ZEILE
Ein `„`, das erst in der naechsten Zeile mit einem geraden `"`
schliesst, fiel durch. Gemessen: drei echte Faelle, zwei davon
sichtbarer Seitentext.
workspace/leistung.html „nicht / zugeordnet"
workspace/leistung.html „Backstage-Tabelle / einfuegen"
workspace/assets/js/ampel.js „noch ' + 'verbessern"
Beim letzten laeuft das Zitat ueber eine Zeichenketten-Verkettung.
Neue Regel ohne Fehlalarme: erst alle RICHTIG geschlossenen Paare
entfernen (auch mehrzeilig), dann die einzeilig falschen (die meldet
die alte Regel). Was danach noch ein `„` hat und binnen drei Zeilen
ein gerades `"`, ist ein Fund. Ausgenommen bleibt das Zeichen ALS
WERT — in `content: "„";` und in den Sprachtabellen ist das `„` der
Inhalt und das `"` die Begrenzung.
LOCH 3 — EINE AUSNAHME, DIE EINEN FUND VERSCHLUCKT HAT
Gefunden durch die ZAHL, nicht durch den Blick: Der weitere Filter
liess die Ausnahmen von 12 auf 13 steigen. Die dreizehnte war
`… „${zeile[titelSpalte] || "ohne Titel"}"`
Der Ausdruck blieb am `"` von `"ohne Titel"` haengen; als Inhalt kam
`${zeile[titelSpalte] || ` heraus, das endet auf ein Leerzeichen,
und damit galt „der Satz geht in der naechsten Zeile weiter". Das
echte Schlusszeichen stand hinter dem `}` und war gerade.
Dass die Ausnahmen gezaehlt UND genannt werden, hat ihn gefunden.
Genau dafuer steht die Zeile dort.
Behoben an der Wurzel: Anfuehrungszeichen innerhalb einer Einsetzung
`${…}` werden vorher durch X ersetzt, bei gleicher Laenge und
gleichen Zeilenumbruechen. Das nimmt einer ganzen Sorte
Fehlklassifizierung die Grundlage — die Ausnahmen fielen danach von
13 auf 11.
UND EIN VIERTES, BEIM MESSEN AUFGEFALLEN
`„Van-Van”` in assets/js/data-modis.js schliesst mit U+201D, dem
ENGLISCHEN Zeichen. Zweimal, beide Male in einer DEUTSCHEN Zeile
(`de:` und `"de-CH":`) — nicht einmal eine Uebersetzung, in der es
richtig waere. Eigene Regel dafuer, die keine Ausnahme braucht: Wer
mit `„` oeffnet, schliesst deutsch; in fremdsprachigen Zeilen steht
gar kein `„` am Anfang.
DIE AUSNAHMEZAHL IST JETZT STRENG. Sie stand auf „hoechstens 12" —
damit waere der Anstieg auf 13 nicht aufgefallen. Jetzt genau 11,
wie bei den Grundlinien in pruef-fingermass.
GEPRUEFT: pruef-struktur 68 -> 75 Pruefungen, 0 Fehler. Dazu
leistung-optik 59/0, ampel 47/0, treff 85/0, modi-verborgen 87/0 —
die Seiten, deren Text ich angefasst habe. Steuerzeichen: 830
Dateien, keines. Beide Stempel gesetzt.
Sechs echte Stellen berichtigt, vier neue Gegenproben.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
2b3f140112 |
Wissen: ein gerades Schlusszeichen, von der Wache gefunden
workspace/assets/js/wissen.js:556
... legst du unter „Dateien" ab. (gerades ")
... legst du unter „Dateien“ ab.
Die Zeile ist nicht von mir: Sie kam heute um 14:33 aus einer
zweiten Sitzung im selben Verzeichnis (Commit
|
||
|
DogFatherGitandClaude Opus 5
|
159036efc9 |
helfer-port: die gemessene Zahl ist ein Stand, keine Wahrheit
Im Kommentar stand „die Pruefungen reichen bis 5409, Luft fuer 245 weitere Dateien". Noch am selben Tag kamen zwei Pruefdateien aus einer anderen Sitzung dazu, und daraus wurde 5413/243. Das ist kein Fehler, sondern der Beweis, dass die Umstellung von gestern richtig war: Zwei fremde Dateien haben alle Nummern dahinter verschoben, und es musste niemand etwas nachtragen. Nachgemessen danach: 460 Nummern, alle verschieden, 0 Kollisionen, pruef-ports 10/0 und pruef-portnummern 41/0. Aber eine Zahl im Kommentar, die sich am Tag ihrer Messung schon bewegt hat, ist genau die Sorte, der jemand spaeter glaubt. Sie steht jetzt als STAND da, mit dem Hinweis, wo die heutige zu holen ist: pruef-portnummern sagt sie bei jedem Lauf. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
b2b016f8dd |
Reaktion auf 320 px: das Bild ist ganz zu sehen
NACHGEMESSEN, wie es nach dem Einklappen der Reiterleiste wirklich
aussieht — und zwar im ANFANGSZUSTAND, mit zugeklappter Leiste:
Regie Raum Kino Schiene Pult Transport
412x915 45 620 232 388 128 181
390x844 45 549 219 330 128 181
360x640 45 345 203 143 128 181
320x568 45 75 75 1 198 181
Die Regieleiste ist von 101 bzw. 148 auf 45 Pixel geschrumpft — auf
320 px sind das 197 gewonnene Pixel.
EIN MESSFEHLER VON MIR, hier festgehalten: Mein erster Lauf zeigte
die Leiste GROESSER als vorher (148, 195, 242). Das Werkzeug klappt
sie weiter oben selbst auf, um die Register zu messen, und ich habe
danach die Hoehen gelesen. Gemessen war also der falsche Zustand —
eine Messung, die veraendert, was sie misst.
WAS AUF 320 BLEIBT: Der Raum hat 75 Pixel, das Bild wollte 180. Das
Pult liegt mit `z-index: 60` darueber, die Knoepfe sind also
erreichbar — und genau deshalb melden pruef-breiten und pruef-handy
nichts. Zu sehen war vom Bild trotzdem nur das obere Drittel.
`max-height: 100%` an der Leinwand. Gemessen wird der Kasten damit
320x75; die Breite bleibt, das Verhaeltnis gilt nicht mehr — aber
der Spieler darin setzt das Bild mittig mit Balken links und
rechts. Es ist klein und GANZ, statt gross und zu zwei Dritteln
hinter dem Pult.
(Im Kommentar stand zuerst, die Breite folge dem Verhaeltnis. Tut
sie nicht — 320x75, nicht 133x75. Berichtigt, bevor jemand sich
darauf verlaesst.)
AUF 360, 390 UND 412 AENDERT SICH NICHTS: Dort ist der Kasten
hoeher, als 16:9 verlangt, und `max-height` greift nicht ein.
Nachgemessen: 203, 219, 232 — wie vorher.
GEPRUEFT: pruef-handy 186/0, pruef-breiten 23/0, pruef-reaktion
421/0, mess-quer „NICHTS rollt seitlich".
EHRLICH BLEIBT: 320x568 zeigt weiterhin keinen Chat (Schiene 1 px),
und das Bild ist dort 320x75. Mit 198 Pixeln Pult und 181 Pixeln
Transport von 499 geht nicht mehr. Das waere ein eigener Schritt
und eine eigene Entscheidung — kein Nebenbei.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
63a56980c0 |
Wissen: Eine Absage ohne Alternative ist eine halbe Antwort
Wer eine Nicht-PDF in die Ablage zieht, bekam "Das ist keine PDF-Datei." -- richtig, aber eine Sackgasse. Filipe hat heute eine HTML-Praesentation dort abzulegen versucht, keinen Weg genannt bekommen und den Fehler bei sich gesucht. Jetzt steht dabei, wohin sie gehoert: unter "Dateien". Das ist die einzige Stelle, an der wir es ueberhaupt sagen koennen -- beim Auswaehlen ueber den Knopf greift schon `accept`, und die Datei ist im Fenster des Betriebssystems gar nicht erst anklickbar. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
5a9f1f467c |
Wissen und Dateien: Zwei Raster, die ihren Inhalt verloren haben
Filipe zum Bildschirmfoto der Wissen-Seite: "erstens sieht das richtig
scheisse aus". Zu sehen war die Kategorie-Auswahl quer ueber "STUFE",
"GERAET", "VEROEFFENTLICHT AM" und den Tag-Knoepfen. Text auf Text.
Zweimal dieselbe Ursache, zweimal ein Raster, das Kinder in eine Zelle
zwingt, die zu klein ist:
1. FORMULAR "NEUE ANLEITUNG" (aufgaben.css). Die Regel
`grid-template-rows: 1fr 44px` gibt jeder Zelle eine feste
Eingabezeile -- richtig und wichtig, damit alle Felder auf einer
Linie sitzen. Die Zelle "Hauptkategorie" enthaelt aber keine
Eingabe, sondern sechs Gruppen mit zwanzig Knoepfen. Gemessen: der
Kasten 40 px hoch, sein Inhalt 442 -- 402 px liefen ueber alles
darunter. Unter 560 px passierte das nicht, weil dort ohnehin
`auto auto` gilt; deshalb sah es am Handy richtig aus.
Es ist exakt die Falle, die eine Regel darueber schon einmal
zugeschnappt ist ("EINE ZELLE, DIE AUFKLAPPT ..."). Dieselbe
Antwort, diesmal fuer .katwahl.
2. DATEILISTE (dateien.css). .datei hat die Spalten `34px 1fr auto`.
Die ersten vier Kinder sitzen richtig; alles danach wird automatisch
platziert und landet in der ZEICHENSPALTE. Gemessen: "Fassung 2" in
34 px Breite, 22 px herausragend; auf 390 px zusaetzlich die
Metazeile ("1,9 MB" in zwei Zeilen) und "Sichtbar fuer" mit 49 px
Ueberstand.
ZWEI NEUE PRUEFUNGEN, und die erste war erst selbst falsch:
pruef-wissen-formular.mjs verglich zunaechst den KASTEN der Auswahl mit
dem der Zelle und meldete gruen, waehrend das Bildschirmfoto die
Ueberlappung deutlich zeigte. Der Kasten ist ja brav 44 px hoch --
herausgelaufen ist sein INHALT. Jetzt wird scrollHeight gegen
clientHeight gemessen, und die Pruefung wird rot, bevor der Fix
dazukommt. pruef-dateien-liste.mjs legt bewusst zweimal dieselbe Datei
ab, damit "Fassung 2" und "nicht mehr aktuell" ueberhaupt entstehen.
Versionsstempel neu gesetzt (202610011426, 670 Verweise in 45 Dateien).
Ohne ihn liegt die Korrektur auf dem Server und kommt bei niemandem an:
Cache-Control steht auf immutable.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
3a07c52499 |
Die drei dauerhaft roten Pruefungen sind gruen
Alle drei waren vorbestehend (Gegenprobe gegen den alten Stand
derselben Datei), und keine der drei war ein Fehler am Haus.
1. pruef-browser — WINDOWS BLOCKIERT WEBKIT
Schritt fuer Schritt nachgegangen:
- gemeldet: „WebKit: browserType.launch: Target page, context
or browser has been closed"
- nicht an paralleler Last; allein dasselbe Bild
- `npx playwright install --force webkit` nennt den Grund:
„Full list of missing libraries: icuuc77.dll"
- die Datei IST da, 1,8 MB, im Ordner webkit-2336
- Playwrights eigenes Werkzeug sagt, warum:
PrintDeps.exe icuuc77.dll
-> Eine Anwendungssteuerungsrichtlinie hat diese Datei
blockiert.
Smart App Control laesst die unsignierte Bibliothek nicht laden.
Das ist eine Einstellung des Rechners, kein Fehler im Haus — und
sie zu aendern waere Filipes Entscheidung, keine meine. (Smart
App Control laesst sich nur ABschalten; wieder einschalten geht
ohne Windows-Neuinstallation nicht. Fuer einen Testbrowser ist
das der falsche Preis.)
Der Kommentar im Code sagte es schon richtig — „eine Maschine,
die nicht startet, ist nicht ,in Ordnung', sie ist nicht
nachgesehen" —, umgesetzt war es als FEHLER. Jetzt drei
Ausgaenge wie in pruef-ports: „BESTANDEN — 0 Fehler, 2 nicht
nachsehbar". Damit daraus kein stiller Freispruch wird, haengen
zwei Dinge daran: mindestens ZWEI Maschinen muessen wirklich
gemessen haben, und die Zahl der Seitenaufrufe wird aus den
gelaufenen Maschinen abgeleitet statt gegen eine feste 3
geprueft.
2. pruef-crew-wand-bild — MEINE EIGENE FOLGEWIRKUNG VOM 30.09.
anlegen("Marina", "modi", "CODE-MODI-0001");
{ name: "Modi", rolle: "creator", code: "CODE-MODI-0001" }
Marina ist ein `modi`, angemeldet wurde sie mit der Kachel
`creator`. Bis zum 30.09. war das egal; seit `718b267d` („die
gewaehlte Kachel ist bindend", auf Filipes ausdruecklichen
Wunsch) wird es zu Recht abgelehnt. Drei Befunde aus einer
Wurzel, und mir ist es damals entgangen, weil ich nach der
Aenderung die Pruefungen zum Zugang gelaufen bin und nicht die
zum Wandbild.
Die Ursache war aber nicht die falsche Zeile, sondern dass es
ZWEI gab. `anlegen` gibt jetzt zurueck, was es angelegt hat, und
die Anmeldung nimmt genau das. Nebenbei beweist die Pruefung
damit zum ersten Mal, was sie beweisen sollte: Der Modi bekommt
„Aufgaben · Team Dogi" und seine eigenen Zeichen.
3. pruef-chat-anhaenge — EINE BLENDE, DIE UNTER LAST STILLSTEHT
Gemeldet: „0 Figuren" und „[]" statt der zwei Schriftzuege —
aber nur mit vier parallelen Pruefungen. Allein zweimal gruen.
Gemessen, was wirklich dasteht: lage „hoch", Figuren da, Bilder
geladen (447x450), Deckung exakt „0". Nicht 0,3 oder 0,7 — die
Ueberblendung hatte nicht ANGEFANGEN. Unter Last wird
`requestAnimationFrame` gedrosselt, und eine Blende, die auf
Bildern laeuft, steht still.
Mein erster Versuch — „warten, bis sich nichts mehr aendert" —
war genauso falsch wie die feste Wartezeit davor: Stillstand
heisst auch „noch nicht angefangen", und er kam sofort zurueck.
Auf eine Bewegung zu warten, die nicht laeuft, geht nicht.
Also wird sie abgeschaltet. Das Haus hat die Regel schon:
`@media (prefers-reduced-motion: reduce)` nimmt genau diesen
beiden Dingen die Blende. Der Endwert steht damit sofort da, die
Messung haengt nicht mehr am Rechner, und der Weg wird nebenbei
zum ersten Mal wirklich begangen.
Nicht tautologisch: Die Gegenprobe „und OHNE die zwei Figuren —
die gehoeren ins Hochformat (0)" steht weiter und bleibt gruen.
GEPRUEFT, und zwar unter DERSELBEN vierfachen Last, die sie vorher
rot gemacht hat:
pruef-chat-anhaenge 123 / 0 pruef-material 159 / 0
pruef-crew-wand-bild 45 / 0 pruef-kalender 141 / 0
pruef-browser 11+2 offen pruef-start-ansicht 160 / 0
pruef-dabei-optik 23 / 0 pruef-neue-seiten 109 / 0
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
|
dc5e6a0c24 |
Reaktion: das Chatfeld bekommt einen Namen
pruef-handy-teamdogi meldete auf beiden Geraeten und fuer Modi und
Community dasselbe:
reaktion.html: Bedienelement ohne Namen — input#chat-feld
Sein einziger Name war der PLATZHALTER. Der ist keiner: Er
verschwindet in dem Moment, in dem jemand anfaengt zu tippen, und
danach hat das Feld fuer ein Vorleseprogramm gar keinen Namen mehr.
Der Knopf daneben macht es seit jeher richtig
(`aria-label="Senden"`).
UND DER NAME WANDERT MIT. Das Feld sagt im Platzhalter, warum
gerade nicht geschrieben werden kann — „Der Chat ist gerade zu",
„Du bist gerade stumm geschaltet", „Gerade schreibt nur das Team".
Ein fester `aria-label` haette genau diese Auskunft fuer das Ohr
verschluckt. Er kommt deshalb aus derselben Zeile wie der
Platzhalter: eine Angabe, zwei Ausgaben. Zwei getrennte Texte
waeren die naechste Stelle, an der einer gepflegt wird und der
andere nicht.
GEPRUEFT
pruef-handy-teamdogi 8 Befunde -> 14 Pruefungen, 0 Fehler
pruef-reaktion 421 Pruefungen, 0 Fehler
pruef-handy 186 Pruefungen, 0 Fehler
Damit ist die Liste der alten offenen Punkte abgearbeitet:
- pruef-fingermass (Grundwert 1) unveraendert 1, dazu eine
zweite Zahl fuer die
Faelle, die sie bisher gar
nicht sehen konnte
- Regie/Transport auf 320x568 die Ueberlappung ist weg
- report.html 27x18 px gibt es nicht mehr; beide
Messungen melden die Seite
sauber (Notiz war veraltet)
- Ueberstand pruef-handy-teamdogi 0 Befunde
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]>
|
||
|
DogFatherGitandClaude Opus 5
|
d7f3e747b8 |
Reaktion: 26 Pixel zurueck fuer den Chat am Handy
Die rechte Gruppe der Transportreihe war auf 360x640 gemessen
122 Pixel hoch statt 44: In der dreispaltigen Reihe bekommt sie nur
89 Pixel Breite und bricht dreimal um. Das Wort „Weiter" davor ist
dabei eine Beschriftung fuer zwei Knoepfe, die ihre Aufgabe selbst
draufstehen haben — „Naechstes" und „Wechseln zu <Titel>".
Dieselbe Ueberlegung wie beim Wort „Tempo", das aus genau diesem
Grund schon weg ist. Am Rechner bleibt es: Dort ist Platz, und dort
ordnet es die Leiste.
GEMESSEN (mess-quer, mit Finger, Regie zugeklappt):
Transportleiste 207 -> 181 px auf 320, 360, 390 und 412
Chatschiene +26 px auf jedem Handy
Rechner/Tablet unveraendert (158 / 185)
WAS DAS NICHT LOEST, UND DAS SAGE ICH LIEBER GLEICH: Die verdeckten
Chatstufen auf 320 und 360 sind weiterhin da. pruef-breiten und
pruef-handy melden unveraendert 6 bzw. 3 Befunde. Der Grund steht
jetzt mit Zahlen im Quelltext — es ist eine Platzfrage, keine
Regelfrage, und sie braucht eine Entscheidung.
EIN VERSUCH, DER ZURUECKGENOMMEN WURDE: `minmax(0, auto)` statt
`auto` an der Kinozeile des Raums. Gemessen null Pixel Unterschied
(Kino vorher wie nachher 203 px). Der Raum ragt naemlich nicht aus
eigener Kraft ueber seine Zeile — die Zeile hat auf 360 px noch
161 Pixel, und ein 16:9-Video auf 360 px Breite will 203. Keine
Angabe an DIESEN Zeilen aendert daran etwas. Die Begruendung steht
jetzt dort, damit es niemand ein zweites Mal probiert.
Eine Regel, die nur aussieht, als taete sie etwas, ist schlimmer
als keine.
GEPRUEFT: pruef-handy 186 Pruefungen (3 Befunde, unveraendert),
pruef-breiten 23 (6 Befunde, unveraendert) — also keine neue
Beanstandung und keine verschwundene Pruefung. Stempel gesetzt.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
95c4599baa |
Anfuehrungszeichen: 199 falsche Schlusszeichen im sichtbaren Text
Deutsch oeffnet mit „ und schliesst mit “. An 199 Stellen, die ein
Mensch liest, stand als Schlusszeichen ein GERADES " -- „Nächstes"
statt „Nächstes“. Auf sechzehn oeffentlichen Seiten, in vierzig
Dateien des Workspace und in zwoelf Servermodulen, die Texte
verschicken.
Auf dem Bildschirm sieht man den Unterschied sofort. Beim Schreiben
nicht: Das gerade " liegt auf der Tastatur, die anderen nicht.
WARUM EIN ERSTER ANLAUF ZURUECKGENOMMEN WURDE
Ein gerades " ist an vielen Stellen SYNTAX und kein Schriftzeichen --
Grenze einer Zeichenkette, Grenze eines HTML-Attributs, Zeichen in
einem regulaeren Ausdruck. Wer stumpf ersetzt, macht aus
„<a href="https://… ein kaputtes Attribut
/^["'„»\s]+|["'“«.\s]+$/ einen kaputten Ausdruck
"… nichts „mal " + "eben …" eine kaputte Zeichenkette
DIE UNTERSCHEIDUNG LAEUFT AN MERKMALEN, NICHT AN EINER LISTE
< > = dazwischen -> HTML-Marke oder Attribut
endet auf Leerzeichen -> die Zeichenkette hoert hier auf, der
Satz geht in der naechsten Zeile weiter.
Ein deutsches Schlusszeichen steht NIE
hinter einem Leerzeichen.
Rueckstrich mittendrin -> regulaerer Ausdruck
${ ohne } -> mitten in einem Ausdruck
Eine Liste erlaubter Ausnahmen waere die naechste, die niemand
pflegt. Zwoelf Stellen bleiben dadurch stehen, alle zwoelf einzeln
angesehen und alle zwoelf zu Recht -- dort steht das richtige
Schlusszeichen ohnehin weiter unten im Satz.
Fuenf davon waren allerdings ECHTE Fehler HINTER dem Link
(`…>HasiDog</a>".`) -- die erste Regel hatte nur das Attribut
gesehen, nicht den Satz danach. Gezielt nachgezogen.
Ein maskiertes `\"` in workspace-vorlagen.js (28 Hooks) wird zu “ --
ohne Rueckstrich, denn “ begrenzt nichts.
KOMMENTARE BLEIBEN, WIE SIE SIND. Dort liest es niemand ausser mir;
eine Wache, die auch Kosmetik anmahnt, wird weggeklickt. Beim ersten
Messen fielen ausserdem acht Stellen aus buehne.html faelschlich an,
weil `/* */` in HTML (in <style> und <script>) nicht ausgeblendet
war -- jetzt schon.
DIE WACHE DAZU
pruef-struktur prueft es ab sofort mit derselben Regel: 322 Dateien
mit sichtbarem Text, 0 Funde, und die zwoelf bewussten Ausnahmen
werden GEZAEHLT und genannt (erlaubt: 12). Eine Ausnahme, die niemand
sieht, waechst -- und irgendwann steht der echte Fall darin.
GEPRUEFT
pruef-struktur 59 -> 68 Pruefungen, 0 Fehler
node --check auf allen geaenderten JS-Dateien
nachgemessen: 199 geaendert, 12 mit Grund stehen geblieben
gruen geblieben: bewerbung-aufgaben 163, nachwuchs 262,
reaktion 421, support 63, content 45, terminregel 35, treff 85
Und nachgesehen, ob eine Pruefung noch die alte Schreibweise
ERWARTET: 13 Fundstellen, alle dreizehn nur Text in ihrer eigenen
Ausgabe, keine einzige ein Vergleich mit dem Seitentext.
GEGENPROBE: In reaktion.html ein Schlusszeichen zurueckgedreht ->
„workspace/reaktion.html:546 „Nächstes"", mit Datei und Zeile. Und
die Erkennung einzeln gegen HTML-Attribut, fortgesetzte
Zeichenkette, regulaeren Ausdruck und eingesetzten Wert geprueft.
Stempel gesetzt: workspace 670 Verweise in 45 Dateien, oeffentlich
554 in 48 Seiten.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
7dc5356c80 |
Datum: der Tag kommt aus der Ortszeit, nicht aus UTC
GEFUNDEN UM 01:22, von pruef-kreislauf -- und nur, weil nachts
gearbeitet wurde.
Die Pruefung legt einen Wunsch mit dem HEUTIGEN Datum an und macht
daraus einen Termin. Gemessen:
geschickt: datum = 2026-10-01 (heuteLokal auf dem Server)
gespeichert: datum = 2026-09-30
Der Termin lag also in der Vergangenheit. Auf „Was ansteht" sortiert
er sich damit in den Abschnitt „Vorbei" ein -- und der ist mit
Absicht zugeklappt. Beim Wunsch stand „Daraus wurde ein Termin", auf
dem Brett war er nicht zu sehen. Zwei Stunden jede Nacht (im Winter
eine), genau in den Stunden, in denen hier gearbeitet wird.
URSACHE
const jetzt = () => new Date().toISOString(); // UTC
... jetzt().slice(0, 10) ... // UTC-Tag
ES WAR NICHT EINE STELLE. Nachgemessen: SECHZEHN in vierzehn Modulen,
davon ZEHN, die den falschen Tag in die Datenbank schreiben --
Termine, Wuensche, Highlights, Talente, Leads, Videos, Vorlagen --
und sechs, die „heute" vergleichen (ueberfaellige Aufgaben, Berichte,
die Frist einer Entwicklungsaufgabe).
NICHT ANGEFASST, WEIL RICHTIG: Rechnungen auf einem Datumstext mit
fester Uhrzeit (`Date.parse(tag + "T12:00:00Z") + n * 86400000`). Die
bleiben in jeder Zeitzone am selben Kalendertag -- kalender, teamlage
und serien machen es so, und das bleibt.
WARUM ES NIEMAND GEMERKT HAT
pruef-struktur sucht dieses Muster seit dem 06.09.2026. Aber:
- sie sah NUR in die `pruef-*.mjs`, nie in die Anwendung
- sie kannte die Schreibweise ueber eine FUNKTION nicht
(`const jetzt = () => ...` statt `const jetzt = ...`)
Die Wache stand vor den Pruefungen, nicht vor dem Haus -- derselbe
Fehler wie heute Nacht bei den Messports: eine Sicherung, die nur die
halbe Menge kennt, faellt in der anderen Haelfte aus, und zwar
lautlos, denn sie meldet ja „nichts gefunden".
Jetzt sieht sie in beides und kennt beide Schreibweisen. Beim ersten
scharfen Lauf fand sie sofort 23 weitere Stellen in den Pruefdateien
selbst -- dieselben Zeitbomben, gegen die sie gebaut worden war.
EINE ZWEITE WACHE, WEIL ICH SELBST HINEINGELAUFEN BIN
Mein Umbauwerkzeug hat in elf Modulen `heuteLokal()` eingesetzt und
die Einfuhr weggelassen: Es hat erst ersetzt und DANN gefragt, ob der
Name schon in der Datei steht -- da stand er, mein eigener Aufruf.
`node --check` sagt dazu nichts, „Laedt jedes Server-Modul?" auch
nicht: Die Datei ist syntaktisch tadellos. Erst der Aufruf faellt um
mit `ReferenceError: heuteLokal is not defined`. Gefunden hat es
pruef-video, zufaellig. Die anderen zehn waeren durchgerutscht.
Deshalb neu: „Ruft ein Modul etwas, das es nie eingefuehrt hat?" --
die Namen des Hauses aus den export-Zeilen gelesen, nicht
aufgezaehlt. 460 Aufrufe in 350 Dateien, alle mit Einfuhr.
pruef-kreislauf STELLT JETZT DIE RICHTIGE FRAGE
Sie war rot und hat den Fehler dabei nur gestreift: „`.kette` wird
nicht sichtbar", Zeitsperre nach 15 s. Das klingt nach der Anzeige
und schickt einen zur falschen Stelle. Neu:
- eine Zeile fragt das DATUM (ohne Browser, nennt den Fehler beim
Namen)
- der Browserteil klappt zu, was zu ist, und misst dann die Kette;
„gar nicht da" wird von „da und unsichtbar" unterschieden
NEBENBEFUND IN pruef-ics
Die Probe „fast richtig" war `echt.slice(0, -1) + "A"`. Der
Schluessel ist base64url; sein letztes Zeichen ist eines von
sechzehn. Endet er auf „A", IST die Probe der echte Schluessel, der
Server antwortet zu Recht mit 200, und die Pruefung meldet ein Loch,
das es nicht gibt -- einmal je sechzehn Laeufe. Heute Nacht zweimal
hintereinander, und die Suche ging eine halbe Stunde in eine
Aenderung, die damit nichts zu tun hatte.
GEPRUEFT
pruef-struktur 44 -> 59 Pruefungen, 0 Fehler
pruef-ics 37 -> 38, 0 Fehler
pruef-kreislauf Absturz bei Nr. 17 -> 25 Pruefungen, 0 Fehler
und gruen geblieben: treff 85, arten 28, video 74, uebernahme 39,
entwicklung 79, content 45, vorlagen 24, zuteilung 75,
scout-zuteilung 37, unterstuetzung 70, aufbewahrung 45,
bewerbung 91, treff-start 42, uebergang 65, nachwuchs 262,
auskunft 46, modi-ideen 30, neue-seiten 109, spicy 85,
wege-nach-draussen 67, aufgabenbrett 49, agentur 62,
bereiche-lesend 37 -- beide Haeuser
GEGENPROBEN, DIE WIRKLICH ROT WERDEN
- den UTC-Tag im `daraus`-Weg wieder eingebaut: pruef-kreislauf
meldet „er liegt HEUTE, nicht gestern (2026-09-30, heute ist
2026-10-01)", 25 Pruefungen, 1 Fehler -- und der Browserteil
bleibt gruen, weil er jetzt aufklappt. Jede Frage bei ihrer
eigenen Pruefung.
- eine Einfuhr aus workspace-video.js entfernt: die neue Wache
meldet „workspace-video.js: heuteLokal() (aus helfer-tag.mjs)"
- beide Erkennungen je gegen einen gebauten Rueckschritt geprueft
(Funktion, Variable, zwei Schritte, Date.now-Rechnung) und gegen
das, was NICHT anschlagen darf (UTC-Mittag, voller Zeitstempel,
fremdes Date, Name im Kommentar, Eigenschaft am Objekt)
EIN FEHLER BEIM UMBAU, HIER FESTGEHALTEN: Mein erster Lauf ueber die
Pruefdateien hat stumpf ersetzt und dabei KOMMENTARE umgeschrieben --
in sieben Dateien stand die alte Schreibweise als Beleg in der
Begruendung, und daraus wurde das Gegenteil. Bemerkt hat es der
Vergleich der Zahlen (34 Stellen statt der gemessenen 24), nicht die
Absicht. Zurueckgenommen und mit Schutz fuer Kommentare und
Zeichenketten wiederholt.
Datenbank vorher gesichert. Keine Schemaaenderung.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
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]>
|
||
|
DogFatherGitandClaude Opus 5
|
8e18c7bcf0 |
Aufgaben: eine Bewerbung auf eine erledigte Aufgabe ist keine mehr
Beim Durchsehen der echten Daten am 30.09. gefunden, Filipe am 01.10.: „mach alles los." GEMESSEN: Zwei Bewerbungen von Miss standen auf „beworben" -- an Aufgaben, die laengst `erledigt` bzw. `review` waren. Bei ihr stand weiter „wartet auf Antwort", und in der Liste der Leitung stand eine Entscheidung an, die es nicht mehr gibt. DAS MUSTER GIBT ES IM HAUS SCHON. `uebernahmeAbschliessen` raeumt genau so die offenen Bewerbungen weg, wenn jemand anderes eine Pool-Aufgabe bekommt -- samt dem Kommentar daneben: „Ohne diese Zeile blieb eine Bewerbung auf ,beworben' stehen, nachdem jemand anders die Aufgabe bekommen hat." Derselbe Fall, ein anderer Ausloeser, dieselbe Behandlung. ZWEI WEGE FUEHREN IN DEN ENDZUSTAND -- erledigen und abbrechen. Beide rufen jetzt dieselbe Funktion; nur einen zu bedienen waere die Haelfte, die man spaeter sucht. Der SATZ ist verschieden: „abgebrochen" ist nicht „erledigt", und wer gewartet hat, soll den Unterschied lesen koennen. KEIN `entschieden_von`. Niemand hat entschieden, die Frage hat sich erledigt. Dadurch faellt die Zeile auch aus der Absagen-Uebersicht von gestern heraus (die fragt `entschieden_von IS NOT NULL`) -- richtig, es ist keine Absage an diesen Menschen. KEINE BENACHRICHTIGUNG. „Deine Bewerbung: diesmal nicht" waere falsch -- es hat niemand nein gesagt. Der Satz steht an der Zeile. Wenn Filipe hier doch eine Meldung will, ist es eine eigene Art mit eigenem Wortlaut, kein Anhaengsel an die bestehende. GEPRUEFT -- pruef-bewerbung-aufgaben 163/0 (9 neue): bewirbt sich -> „beworben" Aufgabe erledigt -> faellt weg, mit Satz, ohne Entscheider Aufgabe abgebrochen -> ebenso, mit anderem Satz Aufgabe noch offen -> Bewerbung bleibt <- die Gegenprobe Ohne die letzte Zeile hiesse „faellt weg" womoeglich nur, dass jede Bewerbung wegfaellt. Ein eigener Messfehler unterwegs: Mein Lesehelfer fragte `/api/aufgaben/:id` und bekam `undefined` -- die Antwort dort hat eine andere Form. Vier Pruefungen waren rot, waehrend der Mechanismus im Protokoll nachweislich lief. Jetzt ueber die Liste, die in dieser Datei erprobt ist. Die eine vorhandene Zeile wird nachgetragen; auf einer Kopie der echten Datenbank durchgespielt (danach 0 offene Bewerbungen auf durchgelaufenen Aufgaben, integrity_check ok). pruef-zuteilung, pruef-aufgabenbrett, pruef-zwischenspeicher. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
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]> |
||
|
DogFatherGitandClaude Opus 5
|
718b267de0 |
Zugang: die gewaehlte Kachel ist bindend
Filipe, 01.10.2026: „mach das. es soll fest sein." VanVan hatte gemeldet: „Man kann sich mit seinem Zugangscode immer noch über jeden Button der Startseite anmelden, egal welche Rolle man hat." ICH HATTE ZUERST ABGERATEN -- und lag falsch, weil ich eine alte Lage beschrieben habe. Am 09.09.2026 hatte Filipe entschieden, dass die Modis KEINE eigene Eingangskachel bekommen: „damit die von der workspace auch nicht mal sehen dass die modis von mir einen eigenen zugang haben." Wer keine Kachel hat, muss irgendeine nehmen koennen -- daher der stille Zugang. SEIT DER HAUSTRENNUNG AM 24.09.2026 STIMMT DAS NICHT MEHR. Auf `crew.` steht laengst ein eigener Kachelsatz mit ALLEN fuenf Rollen: DogFather, rechte Hand, linke Hand, Modi, Community (CREW_KACHEL, und crew-index.html zeigt sie). Das Verbergen leistet seither die ADRESSE -- wer sie nicht kennt, findet die Wand nicht; wer sie kennt, liest die Rollennamen ohnehin offen darauf. Der stille Zugang war damit ein Rest. Er hat niemanden mehr geschuetzt und nur dafuer gesorgt, dass die Kachelwahl folgenlos blieb. Nachgesehen habe ich das erst, NACHDEM Filipe widersprochen hat; die Kachelsaetze standen die ganze Zeit im Quelltext. WAS SICH NICHT AENDERT: Auf der Agenturwand war der stille Zugang nie aktiv. Ein Team-Dogi-Code verhaelt sich dort weiterhin wie ein erfundener -- gleiche Antwort, gleicher Weg, gleiche Dauer. Das ist jetzt ausdruecklich gemessen. EINE PRUEFADRESSE IST KEINE WAND. `127.0.0.1` ist weder crew. noch Agentur. Ohne den stillen Zugang gaelte dort der Agentursatz -- und kein Modi kaeme mehr herein. Fuenfzig Pruefdateien melden Team-Rollen ueber diese Adresse an. Auf einer Adresse ohne Wand gibt es deshalb ALLE Kacheln; welche auf welcher ECHTEN Wand steht, misst pruef-modi-verborgen mit ausdruecklichem Host-Kopf. GEPRUEFT -- pruef-modi-verborgen 87/0 (war 85; die fuenf Zeilen „jede Kachel geht" sind durch sieben ersetzt, die die neue Regel und ihre Gegenproben messen). Die Anzahl ist Zeile fuer Zeile verglichen. Modi-Kachel + Modi-Code -> herein admin/hand/linke/gast -> abgewiesen rechte Hand auf ihrer Kachel -> herein Agenturwand + Modi-Code -> wie ein erfundener pruef-crew-adresse 169/0 (unveraenderte Anzahl, zwei Zeilen umgedreht). SECHZEHN PRUEFDATEIEN MELDETEN SICH UEBER FREMDE KACHELN AN -- ein Rest derselben Zeit. Systematisch gesucht statt einzeln entdeckt: Waere ich dem roten Lauf hinterhergelaufen, haette ich beim zwoelften aufgehoert. UND DABEI EIN EIGENER FEHLER: Mein erster Durchlauf las die Rolle am CODENAMEN ab (CODE-MODI- -> modi). Das ging gut, bis „Nane" kam: ein Modi mit dem Code CODE-NANE-0001. Zwei Pruefungen wurden rot, und zwar an einer Stelle („die Stimmen stimmen"), die mit Anmeldung nichts zu tun hat. Ein Codename ist eine Beschriftung, keine Tatsache -- die Rolle steht in `anlegen()`. Danach abgeleitet blieben genau zwei Abweichungen uebrig, und beide sind absichtliche Gegenproben. Drei Browserpruefungen tippten die Creator-Kachel mit einem Modi-Code. Die Modi-Kachel gibt es nur auf der Crew-Wand, und ein Browser auf 127.0.0.1 bekommt die Agenturwand; sie melden sich jetzt ueber die Schnittstelle an und bekommen den Keks. Gemessen werden soll dort, was ein Modi SIEHT -- nicht, wie er hereinkommt. Grün: pruef-modi-verborgen, pruef-crew-adresse, pruef-treff 85/0, pruef-galerie, pruef-kanaele, pruef-modi-katalog 150/0, pruef-modi-ideen, pruef-modi-kategorien, pruef-modi-checkliste 75/0, pruef-modi-livecheck, pruef-kachelraster, pruef-team-ampel 32/0, pruef-team-stufen 47/0, pruef-wunschliste, pruef-bremse, pruef-gespraech, pruef-personen-formular 43/0, pruef-start-ansicht, pruef-community-sicht, pruef-reaktion 421/0, pruef-abzeichen, pruef-chat, pruef-chat-kanaele 81/0, pruef-entwicklung 79/0, pruef-bewerbung-aufgaben 154/0, pruef-struktur, pruef-zwischenspeicher 34/0. `code_kennung` wird weiter geschrieben, aber nicht mehr gelesen -- sie war der Suchschluessel des stillen Weges. Stehen gelassen: Eine Spalte zu entfernen ist eine Schemaaenderung mit Sicherung, und sie kostet nichts. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
4503b1a475 |
Benachrichtigungen: nicht "Verbindung offen", sondern "sieht jemand hin"
Diene im Support (vor 5 Tagen): „Die Benachrichtigungen werden nicht
angezeigt, wenn neue Nachrichten reinkommen. Erst, wenn man die App
öffnet."
ERST GEMESSEN, WAS NICHT DAS PROBLEM IST. Am echten Bestand
nachgesehen: Diene HAT ein angemeldetes Geraet (Android, Chrome, seit
dem 29.09.), und alle zehn Geraete im Haus melden `fehler = 0`. An
der Zustellung liegt es nicht.
DANN NACHGESTELLT (pruef-abzeichen, Abschnitt 8):
Verbindung offen -> KEINE Benachrichtigung
Verbindung zu -> sie kommt
Genau sein Befund.
DER GEDANKE WAR RICHTIG, DIE FRAGE FALSCH. Im Quelltext stand:
if ((zuschauer.get(personId) || new Set()).size) continue;
und daneben die Begruendung -- „wer die Seite offen hat, sieht die
Nachricht ohnehin; ihm auch noch eine Meldung aufs Handy zu schicken
ist der schnellste Weg, dass er Benachrichtigungen abschaltet." Das
stimmt. Nur beantwortet `zuschauer` eine ANDERE Frage: ob eine
VERBINDUNG offen ist. Ein Handy mit der App im Hintergrund haelt sie
weiter -- und der Server hielt Diene fuer anwesend, waehrend sein
Bildschirm schwarz war.
DIE SEITE WEISS ES, DER SERVER NICHT. `document.visibilityState` ist
die einzige Stelle, die den Unterschied kennt. Also sagt sie es --
ueber einen winzigen Weg (`/api/chat/sicht`), beim Aufbau, bei jedem
Wechsel und mit `keepalive` beim Weggehen.
MIT VERFALL, und das ist der wichtige Teil: Ein Geraet, das
abstuerzt, im Funkloch steht oder eingefroren wird, sagt gar nichts
mehr. Ohne Verfall bliebe es fuer immer „sichtbar" und fuer immer
still. Wer nicht widerspricht, gilt nach zweieinhalb Minuten als weg
-- eine Meldung zu viel ist laestig, eine zu wenig ist genau der
Fehler, den Diene gemeldet hat. Dazu alle Minute ein Lebenszeichen,
solange die App vorn liegt.
EINE STELLE FUER DIE FRAGE. Sie wurde an zwei Orten gestellt:
`siehtZu()` und eine Abschrift mitten in `chatEreignis`. Die
Abschrift war die kaputte. Jetzt fragen beide dieselbe Funktion.
GEPRUEFT -- vier Lagen, und die zweite ist die wichtigere
Gegenprobe:
App liegt hinten -> Meldung kommt (war: nichts)
sieht wirklich hin -> KEINE Meldung (Absicht bleibt)
App weggelegt -> Meldung kommt wieder
gar keine Verbindung -> Meldung kommt
Ohne die zweite Zeile hiesse die Reparatur nur „jetzt kommt immer
eine", und das waere der schnellste Weg, dass jemand
Benachrichtigungen abschaltet.
UND EINE PRUEFUNG HAT DEN FEHLER MITGETRAGEN. pruef-anruf-klingelt
hielt den WORTLAUT der kaputten Zeile fest -- genau das, wovor ihr
eigener Kommentar drei Zeilen darueber warnt („Die Pruefung hat den
alten Wortlaut bestaetigt statt sein Verhalten"). Sie prueft jetzt
beides: dass gefragt wird, und dass die Frage die richtige ist.
pruef-abzeichen 26/0, pruef-chat, pruef-anruf 132/0,
pruef-chat-kanaele 81/0, pruef-anruf-klingelt 25/0, pruef-push-ziel
38/0, pruef-arten 28/0, pruef-reaktion 421/0, pruef-struktur,
pruef-zwischenspeicher 34/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
d4a3e54a72 |
Aufgaben: dauerhafte Aufgaben, die nicht abgehakt werden
VanVan im Support: „Man kann bei den Aufgaben, wenn man sie verteilt, ob selbst erstellt oder über die Vorlage noch nicht festlegen, dass die Aufgabe dauerhaft sein soll und somit nicht vom Modi in den Status erledigt gesetzt werden kann." Nachgesehen: Das Wort kam im Aufgabenmodul kein einziges Mal vor. Es war keine vergessene Zeile, es fehlte ganz. WAS EINE DAUERHAFTE AUFGABE IST: keine, die man abarbeitet, sondern eine, die man TUT. „Neue begruessen" ist nicht fertig, wenn man es einmal gemacht hat. ZWEI FOLGEN, und die zweite faellt leicht durchs Raster 1. Der Zugeteilte kann sie nicht auf „erledigt" setzen. Die Sperre steht im SERVER -- ein fehlender Knopf ist eine Bitte, abgelehnt wird an der Route. „Ich fange an" bleibt erlaubt: Auch eine stehende Aufgabe hat einen Anfang. 2. SIE HAT KEINE FRIST. Eine dauerhafte Aufgabe mit Frist waere ab dem naechsten Tag fuer immer ueberfaellig -- und eine Warnung, die immer kommt, ist keine mehr. Die Frist wird GELOESCHT, nicht ignoriert: Ein Datum, das dasteht und nicht gilt, ist schlimmer als keins. WER DARF DAS SETZEN: nur, wer verteilt. Koennte der Zugeteilte seine eigene Aufgabe dauerhaft machen, waere das eine Ausrede; koennte er es zuruecknehmen, waere die Sperre ein Knopf weiter offen. Beides nachgemessen. UND SIE LAESST SICH BEENDEN. Eine Pflicht, die niemand mehr beenden kann, waere eine Falle statt einer Regel. DREI STELLEN, KEINE VIERTE: das Anlegeformular auf „Aufgaben", das auf „Eure Aufgaben" (dort wird verteilt) und das Bearbeiten-Feld. Ueber das letzte laeuft VanVans „oder ueber die Vorlage" -- eine Vorlagen-Aufgabe entsteht ohne Formular, ein Schalter im Vorlagenbrett waere eine vierte Stelle fuer dieselbe Frage. An der Karte steht die Marke fuer ALLE, nicht nur fuer den Zugeteilten: Wer sie ansieht, soll wissen, warum dort kein „Fertig" steht. Ein fehlender Knopf ohne Erklaerung liest sich wie ein Fehler. GEPRUEFT pruef-bewerbung-aufgaben 154/0 (10 neue) mit vier Gegenproben: eine GEWOEHNLICHE Aufgabe laesst sich sehr wohl abhaken (sonst hiesse 409 nur, dass niemand je etwas abhaken kann), „Ich fange an" geht weiterhin, der Zugeteilte setzt und nimmt „dauerhaft" nicht, und nach dem Beenden durch die Leitung geht das Abhaken wieder. ZWEI EIGENE FEHLER, beide von Pruefungen gefunden * Ein BACKTICK in einem Kommentar -- mitten in einem Template-String (`SPALTEN`). Er hat ihn beendet, die Datei war syntaktisch kaputt. Dieselbe Familie wie die deutsche Anfuehrung in einem Anfuehrungsstring: ein Zeichen, das in der Umgebung etwas bedeutet. * `toISOString().slice(0,10)` fuer „morgen" -- pruef-struktur hat es noch am selben Abend gefunden. Zwischen 00:00 und 02:00 liegt der UTC-Tag noch auf gestern; die Pruefung haette nachts falsch angeschlagen. Jetzt ueber `tagLokal()`. Und einer, den nur die Messung zeigen konnte: `holen()` in workspace-zuteilung liest die Aufgabe mit einer eigenen, kurzen Spaltenliste. Ohne `dauerhaft` darin fragte die Sperre `a.dauerhaft` und bekam `undefined` -- sie war still wirkungslos, und im Quelltext daneben sah alles richtig aus. pruef-aufgabenbrett, pruef-zuteilung, pruef-aufgaben-vorlagen, pruef-entwicklung 79/0, pruef-css-klassen, pruef-deutsche-texte, pruef-struktur, pruef-zwischenspeicher 34/0. Schemaaenderung: ADD COLUMN dauerhaft. Datenbank vorher gesichert und geprueft (integrity_check ok, 12 Aufgaben). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
5e26df788b |
Bewerbungen: die Absage bleibt lesbar, und ihr seht, was ihr absagt
VanVan im Support: „Wenn sich ein Modi auf eine Aufgabe bewirbt und
man diese ablehnt, dann bekommt der Modi keine Benachrichtigung
darüber, dass die Aufgabe abgelehnt wurde und sieht somit auch eine
eventuelle Begründung nicht. Außerdem haben auch wir nirgendwo eine
Übersicht, bei wem wir welche Aufgaben schon abgelehnt haben."
GEMESSEN, BEVOR GEBAUT WURDE -- die Pruefungen standen zuerst da und
waren rot:
Frida sieht ihre beantwortete Bewerbung 0
Die Leitung sieht die Absagen 0
DIE URSACHE. `vorlagenBewerbungenFuer` fragt `WHERE zustand =
'beworben'`. Sobald jemand antwortet, faellt die Zeile aus JEDER
Ansicht heraus -- mitsamt der Begruendung, die Filipe am 23.09.
ausdruecklich verlangt hat („mit einem text als notiz"). Der Satz
wird also verlangt, geschrieben und weggesperrt.
Bei einer ZUSAGE fiel das nicht auf: Dort entsteht eine Aufgabe, und
an ihrer Karte steht die Antwort. Bei einer ABSAGE entsteht nichts.
Die Benachrichtigung selbst gab es (`bewerbung_antwort`, vorgabe an,
fuer ja und nein). Sie war nur das EINZIGE -- wer sie wegwischt oder
kein Geraet angemeldet hat, erfuhr nie, warum.
WAS JETZT DASTEHT
* BEIM BEWERBER: „Antwort auf deine Bewerbung" mit dem Ergebnis, dem
Satz und dem Namen dessen, der geantwortet hat. Beide Ausgaenge --
eine Liste, die nur Absagen sammelt, waere eine andere Sache. Nach
14 Tagen verschwindet sie von selbst.
SIE STEHT VOR DEM ZUKLAPPEN. Beim ersten Anlauf lag sie im Koerper
des Vorlagenbretts, und der wird nur gebaut, wenn das Brett
aufgeklappt ist -- zugeklappt ist die Vorgabe. Eine Antwort, die
man erst aufklappen muss, ist wieder keine.
* BEI DER LEITUNG: „Schon abgesagt", 90 Tage, mit der Zahl JE MENSCH
vorn. Das ist VanVans eigentliche Frage („falls sich jemand immer
wieder bewirbt und immer wieder abgelehnt wird"), und die
beantwortet eine Liste von zwanzig Zeilen nicht.
AUS BEIDEN WEGEN -- Vorlage und Aufgabe. Eine Uebersicht, die nur
die Haelfte zeigt, ist schlimmer als keine: „Frida wurde nie
abgelehnt" waere dann eine Auskunft, die stimmt und taeuscht.
ZUGEKLAPPT. Eine Liste von Absagen, die immer offen steht, ist eine
Sammlung von Nein-Sagen ueber Menschen, mit denen man morgen wieder
arbeitet.
KEIN ROT. Eine Absage ist kein Fehler; „diesmal nicht" ist keine
Aussage ueber den Menschen. Gedeckter Bernstein, und ab zwei Malen
faellt die ZAHL auf -- nicht nur die Farbe.
ZWEI EIGENE FELDER UND NICHT `bewerbungen` ERWEITERT. Dort heisst
eine Zeile im Browser „wartet auf Antwort", samt Zurueckziehen-Knopf.
Beantwortete Zeilen hineinzumischen haette bei einer Absage genau das
gezeigt. Ein Feld, dessen Bedeutung sich aendert, bricht seine Leser
lautlos.
`entschieden_von IS NOT NULL` TRENNT DREI DINGE, die alle `abgelehnt`
heissen: die Leitung hat eine Bewerbung abgelehnt (das hier), die
Person hat eine Zuteilung abgelehnt (ihre Entscheidung), und „von
jemand anderem uebernommen" (gar keine Absage).
Haustrennung gilt: `darfSchreibenMit` je Zeile.
GEPRUEFT
pruef-bewerbung-aufgaben 144/0 (weitere 10 Pruefungen plus zwei
Bilder). Die Gegenprobe steht in der Vorgeschichte: Dieselben
Pruefungen waren vor dem Bau rot.
Zwei eigene Messfehler, beide im Text festgehalten: Ich habe zuerst
auf dem AUFGABENbrett gemessen -- der Vorlagenkatalog steht aber auf
„Eure Aufgaben" (`zweig: 'team'`). Und `innerText` liefert den Text
so, wie er DASTEHT: Die Zeile suchte „Diesmal nicht" und fand
„DIESMAL NICHT", weil das Schild `text-transform: uppercase` traegt.
pruef-vorlagen 24/0, pruef-aufgaben-vorlagen, pruef-zuteilung,
pruef-aufgabenbrett, pruef-entwicklung 79/0, pruef-css-klassen,
pruef-zwischenspeicher 34/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
c933bcd2e0 |
Aufgaben: wer verantwortlich ist, hat auch eine Zuteilung
VanVan im Support: „Wenn ein Modi sich auf eine Aufgabe beworben hat
und die von uns angenommen wurde, dann steht beim Modi unter der
Aufgabe immer noch ich bewerbe mich."
GEMESSEN AN DEN ECHTEN DATEN (lesend, auf einer Kopie):
Aufgaben mit Verantwortlichem: 11
davon OHNE Zuteilungszeile: 8
Darunter Marinas zwei offene Vorlagen-Aufgaben -- genau die zwei
Karten aus ihrem Bildschirmfoto.
DIE URSACHE. `katalogAufgabeAnlegen()` schrieb eine Zeile in
`aufgaben` mit `verantwortlich_id` und KEINE in
`aufgaben_zuteilung`. Das Brett liest aber die Zuteilung, nicht den
Verantwortlichen: Es fand nichts, lieferte `meine_zuteilung: null`,
und die Bedingung im Browser beginnt mit `!mein` -- also bot sie an,
sich auf die eigene Aufgabe zu bewerben.
ES WAR NICHT NUR EIN FALSCHER KNOPF. „Ich fange an" und „Fertig"
haengen an derselben Zeile. Der Mensch bekam eine Karte, auf der er
das Falsche tun konnte und das Richtige nicht.
WARUM DIE VORHANDENE PRUEFUNG ES NICHT FAND: Sie geht den Weg ueber
das AUFGABENbrett -- dort war alles in Ordnung, nachgemessen steht
nach dem Annehmen richtig „Ich fange an | Fertig". VanVans Weg ist
der ueber das VORLAGENbrett, und der endet in einer neu angelegten
Aufgabe. Dieser Weg war nie geprueft.
DREI TEILE
1. `katalogAufgabeAnlegen` legt die Zuteilungszeile mit an. Mit
Zustand: `angenommen`, wenn die Person darum gebeten hat und die
Bitte angenommen wurde; `offen`, wenn die Leitung zutraegt -- dann
steht bei ihr Annehmen/Ablehnen, und das ist richtig, sie hat noch
nicht ja gesagt.
2. Eine Umstellung traegt nach, was schon dasteht. Wiederholbar
(`NOT EXISTS` + `INSERT OR IGNORE`), deshalb bei den Umstellungen
und nicht in einem Skript, das jemand vergisst. Auf einer KOPIE
der echten Datenbank durchgespielt: 8 Zeilen angelegt, danach 0
ohne Zuteilung, `integrity_check ok`. Marinas Karten stehen
danach auf `angenommen`.
3. Ein Riegel im Browser: Auf eine Aufgabe, die mir schon gehoert,
bewirbt man sich nicht. Er faengt jeden weiteren Weg ab, der eine
Aufgabe ohne Zuteilungszeile anlegt -- nicht alle acht kamen aus
der Vorlage.
GEPRUEFT
pruef-bewerbung-aufgaben 126/0 (15 neue: der ganze Vorlagenweg von
der Bewerbung bis zum Knopf auf ihrem Brett). NACHGESTELLT: Ohne die
Zuteilungszeile wird sie rot („und sie hat eine Zuteilungszeile
(undefined)"). pruef-zuteilung, pruef-aufgabenbrett, pruef-vorlagen
24/0, pruef-aufgaben-vorlagen, pruef-struktur, pruef-zwischenspeicher
34/0.
Ein Messfehler unterwegs, im Text festgehalten: Mein neuer Block
bewarb sich auf dieselbe Vorlage wie ein spaeterer Abschnitt und
nahm ihm damit seine -- zehn Pruefungen wurden rot, ohne dass am
Programm etwas falsch war.
Datenbank vor der Umstellung gesichert und geprueft
(integrity_check ok, 12 Aufgaben, 3 Zuteilungen).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
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]>
|
||
|
DogFatherGitandClaude Opus 5
|
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]>
|
||
|
DogFatherGitandClaude Opus 5
|
a3ec558127 |
Reaction: der Gleichlauf rechnet ohne Uhrenvergleich
Filipe: „die videos muessen perfekt laufen wenn ich die reaktions
mache."
GEMESSEN, NICHT VERMUTET. mess-reaktion hat einen neuen Abschnitt:
Er liest den Spielstand am ECHTEN <video>-Element in beiden Browsern,
rechnet beide auf denselben Augenblick um und sagt, wie weit Host und
Zuschauerin auseinanderliegen. Die vorhandene Pruefung fragte nur, ob
Start und Stopp ANKOMMEN -- zwei Videos koennen beide laufen und
trotzdem zwanzig Sekunden auseinander sein.
vorher nachher
Im Lauf 0,12 s -0,04 s
Wer dazukommt 6,91 s 0,26 s
Uhr des Geraets 30 s vor -29,97 s 0,26 s
DER SCHLIMMSTE FUND: DIE UHR DES TELEFONS
Der Zuschauer rechnete `Date.now() - stand.gesendet`. `gesendet` kam
vom SERVER, `Date.now()` vom Geraet -- zwei Uhren, die nie jemand
verglichen hat. Wessen Telefon dreissig Sekunden vorgeht, schaute
29,97 s weiter als alle anderen. Kein langsames Netz, kein schwaches
Handy. Oertlich faellt das nie auf: Auf einem Rechner sind beide
Uhren dieselbe.
Jetzt geht ein ALTER hinaus statt einer Uhrzeit -- die Differenz
zweier SERVERzeiten. Der Empfaenger braucht dafuer gar keine Uhr,
nur eine Stoppuhr (`performance.now()`), und die haelt Zeitumstellung
und Aufwachen aus dem Ruhezustand aus.
WEITER
* WER DAZUKOMMT, STEIGT RICHTIG EIN. Der gespeicherte Stand war so
alt wie der letzte Takt des Hosts; neue Spalte `sekunde_am` sagt,
wann er galt.
* DAS TEMPO GEHT IN DIE HOCHRECHNUNG EIN. Bei 2x laeuft die Videouhr
doppelt so schnell -- das fehlte ganz.
* JEDER RECHNET ALLE ZWEI SEKUNDEN SELBST NACH statt nur auf Zuruf.
Wer stockte, hing bis zu fuenf Sekunden hinterher.
* DER VORLAUF NACH EINEM SPRUNG WIRD GEREGELT, nicht geschaetzt --
gemessen wird der Rest, nicht die Ladezeit (siehe unten).
* PUFFERN IST AUCH IN DER TRANSPORTLEISTE KEINE PAUSE. Der
Start-Stopp-Knopf rief beim Puffern `playVideo()` -- wer Pause
drueckte, bekam „weiter". Lampe und Knopfbild flackerten bei jedem
Stocken. Die Lektion vom 29.09. war nur an einer Stelle eingeloest.
* DAS TEMPO MELDET UEBER `hostMelden()` statt ein zweites Mal von
Hand -- es hielt Puffern fuer Stillstand und hielt damit beim
Umschalten alle an.
* EIN VIDEO-RUNDRUF STATT DREI ABSCHRIFTEN. Beim Einbau hatte ich
zuerst nur eine nachgezogen; das Tauschen der beiden Videos haette
still die alte Rechnung weiterverschickt.
DREI EIGENE FEHLER UNTERWEGS, alle im Text festgehalten
1. ZWEI FUNKTIONEN HIESSEN `springen`. Meine „spring AUF die Stelle"
wurde von der vorhandenen „spring UM so viele Sekunden"
ueberschrieben -- lautlos, rueckwirkend fuer die ganze Datei. Ein
Zuschauer bei Sekunde 100, dem „geh auf 101" gesagt wird, waere
bei 201 gelandet. DREI BROWSERLAEUFE HABEN ES NICHT GEFUNDEN:
oertlich blieb der Abstand unter der Sprungschwelle, die Zeile
lief kein einziges Mal. Gefunden hat es erst eine Frage an die
ganze Datei -- die steht jetzt als Pruefung drin und wurde
nachgestellt (rot).
2. DER VORLAUF LERNTE NUR NACH OBEN. Gemessen wurde die Ladezeit
nach einem Sprung; ein Sprung in geladenes Material dauert aber
gar nicht, meldet nichts und lehrt nichts. Ergebnis: -0,95 s
stabil. Jetzt wird das ERGEBNIS geregelt statt der Ursache.
3. DER AUSREISSER VON 39,84 s WAR MEINE EIGENE MESSUNG -- der Block
davor schickt eine erfundene Position. Jetzt wird abgeklungen und
in Messreihenfolge ausgegeben.
GEPRUEFT
pruef-reaktion 421/0 (14 neue, darunter der Riegel gegen die
Rueckkehr der Uhrenrechnung und die Wache gegen doppelte
Funktionsnamen -- beide nachgestellt), mess-reaktion ohne ein
einziges ACHTUNG, pruef-buehne 38/0, pruef-struktur, pruef-
zwischenspeicher 34/0.
Schemaaenderung: ADD COLUMN sekunde_am. Datenbank vorher gesichert
und geprueft (integrity_check ok, 20 Personen).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
d5c84c7608 |
Abzeichen am App-Symbol - und die Zahl gehoert zu einem Haus
Die kleine Zahl auf dem Symbol des Startbildschirms. Sie fehlte ganz; setAppBadge kam im Haus kein einziges Mal vor. ZWEI ENTSCHEIDUNGEN Sie zaehlt ungelesene Nachrichten und nichts sonst. Ein Abzeichen muss weggehen koennen: Nachrichten verschwinden, sobald man sie liest; eine ueberfaellige Aufgabe verschwindet nicht dadurch, dass man die App oeffnet. Eine Zahl, die dauerhaft dasteht, ist nach drei Tagen kein Hinweis mehr, sondern ein Fleck. Und sie hat EINE Quelle. Im Browser haengt sie an chatZahlZeigen() - der einen Stelle, an der die Zahl ohnehin gesetzt wird (beim Laden, aus dem Ereignisstrom, beim Lesen). Fuer die geschlossene App - wo das Abzeichen ueberhaupt erst etwas wert ist - reist dieselbe Zahl in der Benachrichtigung mit. Der Service Worker setzt sie nur, wenn eine dabei ist: Eine Aufgabenerinnerung mit "0" haette dem Chat sein Abzeichen weggenommen. DER FUND NEBENBEI Beim Herausloesen der Abfrage fiel auf, dass sie nie nach dem Haus gefragt hat - die Raumliste zwanzig Zeilen darueber tut es laengst. Gemessen: Eine Managerin schreibt DogFather an der Agenturwand an, sein Zaehler auf crew. springt von 0 auf 1. Seit dem 24.09. soll das nicht mehr sein. Aufgefallen ist es erst jetzt, weil dieselbe Zahl ab heute auf dem Startbildschirm steht - und eine Zahl, die etwas Falsches zeigt, ist schlimmer als keine. Behoben ueber hausWo(); die Meldung nimmt das Haus des Raums, aus dem sie stammt. GEPRUEFT server/pruef-abzeichen.mjs, 19 Messungen am echten Weg: ein nachgebauter Browser macht die Benachrichtigung mit seinem privaten Schluessel auf und liest die Zahl heraus. Mit Gegenproben - ohne Zahl kommt keine mit, NaN rutscht nicht durch, eine echte Sieben schon. Und Abschnitt 7 wird rot, sobald man die Hausregel wieder herausnimmt (nachgestellt). Zwei eigene Messfehler unterwegs, beide im Text festgehalten: eine Suche, die im Kommentar landete statt im Code (jetzt ueber jsOhneKommentar), und Aufrufe ohne Host-Feld - ueber 127.0.0.1 gibt es kein Haus, die Pruefung mass also eine Regel an einer Verbindung, die sie gar nicht kennt. helfer-push-aufmachen.mjs: das Entschluesseln stand als lokale Funktion in pruef-push-weg; zwei Abschriften waeren die, die auseinanderlaufen. Nachbarlaeufe gruen: push, push-ziel, push-weg (17 unveraendert), arten, portnummern, struktur, chat, chat-kanaele, chatkachel, anruf, haus-trennung, zwischenspeicher. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
2c12b8706e |
Highlights des Teams sind sofort zu sehen -- ohne zweiten Klick
Filipe, 30.09.2026: „wenn wir bei highlights videos rein setzen will
ich nicht mehr dass wir sie freigeben muessen, sobald die reingesetzt
wurden sollen die sofort zu sehen sein."
=====================================================================
WAS ICH NICHT GETAN HABE, UND WARUM NICHT
=====================================================================
Die naheliegende Loesung waere gewesen, `highlight` aus
`TREFF_FREIGABE_BRETTER` zu streichen. Das waere falsch: Auf diesem
Brett laedt auch die COMMUNITY hoch -- Clips, Bilder, Fanart. Im
Quelltext steht woertlich daneben:
„Zwei Schloesser, weil hier fremde Inhalte hochgeladen werden --
Urheberrecht und Anstand sind nichts, was man nachtraeglich
klaert."
Filipe meint nicht das. Er meint: „wenn WIR videos rein setzen".
=====================================================================
DIE UNTERSCHEIDUNG STAND SCHON IM HAUS -- nur nicht im Code
=====================================================================
Derselbe Quelltext sagt ueber die zwei Freigabe-Bretter
Verschiedenes:
ansteht -> der SCHALTER „Im Treff zeigen". Das Team entscheidet
JE TERMIN, ob die Community ihn sieht.
highlight -> der Urheberrechts- und Anstandsfilter.
Ein Filter fragt „hat das jemand angesehen?". Wenn der, der ihn
bedienen darf, den Eintrag SELBST anlegt, ist die Antwort ja. Genau
diese Begruendung steht seit dem Uebernehmen aus dem Katalog im
Haus: „Eine zweite daneben waere keine Sicherheit, sondern ein
Klick."
Ein Schalter dagegen ist eine Entscheidung je Fall. Termine bleiben
deshalb unberuehrt -- sonst stuende jeder interne Termin sofort im
Treff, und danach hat niemand gefragt.
Neu: `FREIGABE_IST_FILTER` und `sofortFreigeben()` in
workspace-treff.js. DIE BEDINGUNG FRAGT DIE ROLLE, NICHT DEN WEG --
waere der Weg gefragt, waere aus dem Filter ein Loch geworden, sobald
jemand einen zweiten Weg baut. Ein Community-Mitglied ab „Stamm"
darf weiterhin einstellen; sein Eintrag wartet auf das Team.
Gerufen an ZWEI Stellen: beim Videoweg und beim Anlegen von Hand.
Beide hatten es bisher nicht.
=====================================================================
DIE VORHANDENE FREIGABEPRUEFUNG BEWEIST DAS NICHT
=====================================================================
Sie blieb nach der Aenderung gruen -- und das zu Recht: Sie legt ihre
Eintraege unmittelbar in der Datenbank an und prueft damit den
Mechanismus, nicht den Weg. Haette ich mich darauf verlassen, waere
eine Aenderung ausgeliefert worden, fuer die keine Zeile spricht.
pruef-treff (+5): DogFather legt ueber den echten Weg an -> die
Community sieht es SOFORT. Ein TERMIN bleibt verborgen. Die Regel
gibt fuer eine Rolle von aussen NICHT frei und fuer Termine
ueberhaupt nicht.
pruef-video (+3): Der Videoweg hat seinen eigenen Aufruf -- genau
dort wird einer vergessen. Geprueft wird die Freigabezeile selbst,
samt Gegenprobe „freigegeben ist nur, was auch angelegt wurde".
Meinen Abschnitt hatte ich erst HINTER das Abschalten des
nachgebauten TikTok-Dienstes gehaengt -- der Kopf der Datei warnt
woertlich davor („das Abschalten steht ganz hinten"). Gelesen habe
ich ihn, als es rot wurde.
UND `pruef-struktur` HAT MEINE EIGENE NEUE ZEILE GEFANGEN: Sie bildete
das Datum aus UTC statt Ortszeit -- zwischen Mitternacht und zwei Uhr
waere es der falsche Tag gewesen. Behoben mit `tagLokal()`, Minuten
nach dem Schreiben.
Gemessen: pruef-treff 85/0 (war 80), pruef-video 74/0 (war 71),
pruef-highlights 31/0, pruef-bereiche-lesend 37/0,
pruef-treff-werkzeuge 73/0, pruef-alle-sehen-es 43/0,
pruef-community-sicht 10/0, pruef-wege-nach-draussen 67/0,
pruef-struktur 44/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
f53791cefd |
Dritte Schicht: auch die Webdesign-Seiten trugen Stempel vom August
Nach den 35 oeffentlichen Seiten und den zwei Zahlen des Service
Workers lag dieselbe Faeulnis noch eine Ebene tiefer:
webdesign/*.html 49x ?v=20260823wd20 (23. August)
1x ?v=20260825wd51 (25. August)
Zwei VERSCHIEDENE Stempel in 13 Seiten, und beide aus dem August. Sie
verweisen auf dieselben Dateien wie die Startseite -- darunter
`main.css` --, und der Server schickt dazu ein Jahr `immutable`. Wer
den Bereich seit August besucht hatte, hatte sie eingefroren, ganz
unabhaengig vom Service Worker.
Dritte Schicht desselben Fehlers an einem Vormittag. Alle drei hatten
dieselbe Ursache: eine Zahl, die ein Mensch pflegen sollte.
Der Stempler nimmt die 13 Seiten jetzt mit -- 554 Verweise in 48
Seiten, EIN Stempel. `workspace/` bleibt ausgenommen: Dort arbeitet
`workspace-stempel.mjs`, und zwei Werkzeuge auf demselben Ordner
waeren zwei Antworten auf dieselbe Frage.
Und die Wache liest sie mit. Haette sie nur die Wurzel gelesen, waere
sie gruen gewesen und haette die Haelfte geprueft -- genau die Sorte
gruener Haken, die nichts bedeutet.
Viermal heute ist mir beim Schreiben ein Backslash durch die Shell
verlorengegangen (`\1` wurde zum Steuerzeichen, `\\` zu nichts).
Die Hausnotiz sagt das seit Langem; ich habe es viermal trotzdem
gemacht. Ab jetzt: alles mit Backslash geht durch das Werkzeug, nicht
durch die Befehlszeile.
Gemessen: pruef-zwischenspeicher 34/0, pruef-bewegung 9/0,
pruef-css-klassen 37/0, pruef-struktur 44/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
12fa0e45ba |
Der Webdesign-Bereich lieferte seit dem 27.08. ein veraltetes main.css aus
Der Stempel-Fund von eben hatte eine Fortsetzung: DEPLOY.md verlangte
seit dem 26.08. „ZWEI Zahlen hochzaehlen", mit Begruendung und
Messwerten daneben.
webdesign/sw.js const CACHE_NAME = "dogfather-webdesign-v64"
assets/js/wd-core.js .register("/webdesign/sw.js?v=64", …)
Gemessen am 30.09.2026 standen beide seit dem 27.08. auf v64 --
waehrend SIEBEN Commits die Dateien geaendert hatten, die der Service
Worker vorhaelt. Er haelt sechs vor, und `/assets/css/main.css` ist
eine davon.
Wer den Webdesign-Bereich einmal geoeffnet hatte, bekam sie seither
aus seinem Zwischenspeicher. Auch die Behebung von heute Vormittag
waere dort nicht angekommen.
EIN KOMMENTAR, DER VOR EINEM FEHLER WARNT, VERHINDERT IHN NICHT. Die
Anleitung war richtig, ausfuehrlich und begruendet. Getan hat es
trotzdem niemand -- fuenf Wochen lang. Das ist dieselbe Lehre wie am
11.09., als ein Warnhinweis neben einer abgeschriebenen Spaltenliste
stand und drei Spalten mit Inhalt trotzdem verlorengingen.
DESHALB MACHT ES JETZT DAS WERKZEUG. `tools/seiten-stempel.mjs`
setzt beide Zahlen auf denselben Stempel wie die Seiten. Passt eines
der zwei Muster nicht mehr, bricht es ab, statt stillschweigend
weiterzulaufen -- sonst waere die Zahl ab da wieder von Hand
gepflegt, und das merkt niemand.
Dass der Vorrat bei jedem Stempeln neu aufgebaut wird, ist Absicht:
sechs kleine Dateien kosten nichts, ein unbemerkt alter Stand fuenf
Wochen.
UND EINE WACHE DAZU. `pruef-zwischenspeicher` prueft jetzt:
· beide Zahlen stehen da
· sie sind GLEICH -- sonst wird der Vorrat geleert, aber der
Service Worker gar nicht erst neu geladen (Cloudflare ersetzt
sein `no-cache` durch vier Stunden)
· die Zahl ist nicht aelter als die vorgehaltenen Dateien
Die Liste der vorgehaltenen Dateien wird AUS DEM SERVICE WORKER
gelesen, nicht abgeschrieben -- eine zweite hier waere die, die beim
naechsten Eintrag auseinanderlaeuft.
Gegenprobe gemacht: die zwei Zahlen um eine Minute auseinander ->
rot, zurueck -> gruen.
DEPLOY.md sagt jetzt, dass es automatisch geht, und nennt den Befund
im Wortlaut daneben.
Gemessen: pruef-zwischenspeicher 34/0 (war 30/0), pruef-bewegung 9/0,
pruef-css-klassen 37/0, pruef-struktur 44/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
d087d02a63 |
Seit fuenf Wochen kam keine Aenderung der Website bei einem wiederkehrenden Besucher an
Gefunden beim Nachgehen des letzten roten Pruefstand-Eintrags. Eine
Kette aus drei Funden, und der dritte wiegt am schwersten.
=====================================================================
1. EINE ENDLOSE BEWEGUNG AUF ETWAS UNSICHTBAREM
=====================================================================
`pruef-browser` scheiterte in WebKit daran, dass der Anmeldeknopf nie
ruhig wurde. Eine der zwei laufenden Bewegungen war:
.knopf__laden { opacity: 0; animation: dreh .8s linear infinite; }
Dieselbe Suche, ueber ALLE 42 Stilvorlagen beider Haeuser und der
Website, fand einen zweiten: An jedem Navigationspunkt der
oeffentlichen Seite lief eine elf Sekunden lange Aurora -- unsichtbar
bis zum Ueberfahren, auf jeder Seite, fuer immer.
Beides faellt niemandem auf: Nichts stuerzt ab, nichts sieht falsch
aus. Es kostet nur Rechenzeit und Akku.
NEU: `server/pruef-bewegung.mjs` mit sechs Gegenproben -- darunter
die wichtigste, dass ein Beispiel IM KOMMENTAR nicht zaehlt (genau
diese Falle hat am 29.09. eine andere Pruefung dreimal getroffen).
Der Gesamtlauf findet sie von selbst, sie laeuft ab heute Nacht mit.
=====================================================================
2. DIE WEBSITE HATTE KEINEN STEMPLER
=====================================================================
Fuer den Workspace gibt es `workspace-stempel.mjs` seit Langem. Die
oeffentliche Website hatte nichts -- dort stand ein VON HAND
gepflegter Stempel, und der ist gealtert wie jede von Hand gepflegte
Liste.
NEU: `tools/seiten-stempel.mjs`, 447 Verweise in 35 Seiten. Er kennt
beide Schreibweisen (mit und ohne fuehrenden Schraegstrich) UND die,
die in einem `style="…url(…)"` stehen -- zwei Hintergrundbilder auf
streamplan.html waeren sonst ein Jahr lang die alten geblieben.
Dieselbe Luecke gab es im Workspace-Stempler schon einmal, dort bei
den App-Symbolen.
=====================================================================
3. UND DESHALB KAM SEIT DEM 27.08. NICHTS MEHR AN
=====================================================================
Stempel in allen 35 Seiten: ?v=20260828e (zuletzt 27.08.)
Aenderungen an assets/ seither: 6 Commits
Der Server dazu: Cache-Control: max-age=31536000, immutable
`immutable` heisst: Der Browser fragt nicht einmal nach. Wer die
Seite einmal geladen hatte, behielt Stilvorlagen und Skripte bis zu
EINEM JAHR.
Darunter der Partnercode DOGI10 auf der gepraegten Muenze und der
komplette Sprachumbau der Oberflaeche. Sie lagen auf dem Server, sie
waren ausgeliefert, und niemand sah sie.
Dieselbe Sorte Fehler wie am 09.09. im Workspace („eine Aenderung ist
nicht gemacht" -- sie war es, nur unsichtbar) und dieselbe wie bei
VanVans Shop: Eine Aenderung ist erst fertig, wenn sie auf der
Adresse ankommt, die der Nutzer benutzt.
`pruef-zwischenspeicher` fragt jetzt nicht mehr nur, OB ein Stempel
dasteht, sondern ob er NEUER ist als die Dateien, auf die er zeigt.
Gegenprobe gemacht: eine Datei zwei Stunden in die Zukunft gesetzt ->
rot, Zeit zurueck -> gruen. Eine Stunde Nachsicht, damit die Wache
nicht bei zwei Minuten anschlaegt und weggeklickt wird.
DEPLOY.md hat jetzt einen Schritt 0 mit beiden Stemplern und dem
Grund dafuer -- der Befund steht im Wortlaut daneben.
Gemessen: pruef-bewegung 9/0, pruef-zwischenspeicher 30/0,
pruef-browser 17/0, pruef-css-klassen 37/0, pruef-struktur 44/0,
pruef-workspace-umzug 3/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
8e4e525861 |
Auf der Zugangswand drehte sich ein unsichtbarer Kreisel -- fuer immer
`pruef-browser` stand seit dem 28.09. rot, und zwar NUR in WebKit
(Safari): „element is not stable" beim Klick auf den Anmeldeknopf, 53
Versuche ueber 30 Sekunden. Chromium und Firefox waren gruen.
Nachgemessen wanderte sein Kasten pro Bild um ein Fuenftel Pixel:
746.12,575.12 -> 745.10,575.60 (sechs Bilder)
Zwei Bewegungen liefen dabei -- `.buehne__bild` und `.knopf__laden`.
Beide sind echte Befunde.
=====================================================================
1. DER KREISEL DREHT SICH FUER IMMER, UNSICHTBAR
=====================================================================
.knopf__laden { opacity: 0; animation: dreh .8s linear infinite; }
.knopf[disabled] .knopf__laden { opacity: 1; }
Nur die Deckkraft schaltete um. Die Drehung lief ab dem Laden der
Seite, auf JEDEM Knopf, fuer immer -- nicht zu sehen und trotzdem
jedes Bild neu gerechnet. Auf einer Seite, auf der man einen Code
eintippt, ist das reine Verschwendung.
Und sie kannte die Hausregel nicht: Wer weniger Bewegung eingestellt
hat, bekam sie trotzdem. Jetzt dreht sie nur, wenn der Knopf
wirklich arbeitet -- und bei `prefers-reduced-motion` steht der Ring
still, statt zu verschwinden: Ein unsichtbarer Kreisel sagt gar
nichts, ein stehender sagt „ich arbeite noch".
=====================================================================
2. DIE KARTE BEWEGTE SICH, WENN MAN NACH IHR GRIFF
=====================================================================
Die Parallaxe folgte dem Zeiger AUCH ueber der Anmeldekarte. Wer die
Maus zum Codefeld fuehrt, bewegte damit das Feld. Bei zehn Pixeln
keine Katastrophe -- aber genau verkehrt herum: Was man bedienen
will, soll stillstehen.
Und es war der Grund fuer den Wettlauf: Der Zeiger bewegte das Ziel,
das er treffen wollte. Ein Wettlauf zwischen Maus und Karte ist auch
fuer einen Menschen keiner, den er gewinnen soll.
Ueber der Karte wird das Ziel nicht mehr nachgefuehrt. Die
Annaeherung laeuft aus und haelt an; verlaesst man die Karte, geht es
weiter. Das Bild lebt, die Bedienung steht.
=====================================================================
WARUM ES NUR WEBKIT GEZEIGT HAT
=====================================================================
Chromium liefert fuer eine zusammengesetzte Verwandlung oft den
Layout-Kasten OHNE die laufende Bewegung -- dort sah der Knopf ruhig
aus, obwohl er es nicht war. WebKit sagt die Wahrheit. Eine Maschine,
die frueher „gruen" meldet, hat nicht recht; sie sieht nur weniger.
Nachher: pruef-browser 17/0 (war 14/1), alle vier Maschinen.
Dazu gruen: crew-adresse 169/0, crew-wand-bild 45/0, kachelfarben
31/0, css-klassen 37/0, struktur 44/0, tippziele 13/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
69517e090b |
Wer im Chat hochscrollt, wird nicht mehr ans Ende gerissen
`pruef-chat-ausbau` stand seit dem 28.09. rot:
FEHL die Stelle bleibt stehen (0 -> 3574)
FEHL der Knopf sagt, wie viel wartet ("Zum neuesten")
FEHL er zaehlt mit ("Zum neuesten")
FEHL pruef-chat-ausbau: unbehandelter Fehler (der Knopf blieb verborgen)
WAS WIRKLICH PASSIERTE: Man liest weiter oben im Verlauf, jemand
schreibt -- und man wird ans Ende gerissen. Der Zaehler „1 neue
Nachricht" wurde dabei zurueckgesetzt, der Knopf blieb verborgen.
DIE URSACHE STAND AN DER FALSCHEN STELLE. Die Zuhoerer, die „der
Mensch hat selbst gescrollt" feststellen (Rad, Finger, Taste,
Zeiger), hingen INNERHALB des Sprung-Blocks zur Neu-Linie -- wurden
also erst angehaengt, NACHDEM einmal gesprungen worden war.
In einem ruhigen Gespraech passiert das nie: Wer alles gelesen hat,
bekommt keine Neu-Linie, der Block laeuft nicht, die Zuhoerer gibt es
nicht. Scrollt er hoch und es kommt eine Nachricht, entsteht die
Linie ZUM ERSTEN MAL -- der Block laeuft, haengt die Zuhoerer an und
springt im selben Atemzug. Das Hochscrollen von vorhin hat nie jemand
bemerkt.
Das ist der haeufigste Fall ueberhaupt: ein stiller Chat, man liest
etwas weiter oben nach, jemand schreibt.
Die Wache steht jetzt beim Aufbau, bei den uebrigen Zuhoerern des
Verlaufs. Ausdruecklich NICHT am `scroll`-Ereignis: Der Sprung
scrollt selbst, und `scroll` unterscheidet nicht, wer gescrollt hat.
Rad, Finger, Taste und Zeiger tut nur ein Mensch.
UND DIE PRUEFUNG HAT SELBST GEMOGELT. Sie schrieb `e.scrollTop = 0`
-- das setzt die Bildlaufposition zu, ohne dass ein Rad gedreht
wurde. Damit haette sie den Fehler auch nach der Behebung noch
gemeldet. Sie dreht jetzt das Rad (`mouse.wheel`) und prueft, dass
sie oben angekommen ist. Dieselbe Lehre wie bei den Fingergeraeten:
`setViewportSize` macht aus einer Maus keinen Finger, und
`scrollTop = 0` macht aus einem Programm keinen Leser.
Nachher: 70 Pruefungen, 0 Fehler (vorher 24/4).
die Stelle bleibt stehen (0 -> 0)
der Knopf sagt, wie viel wartet ("1 neue Nachricht")
er zaehlt mit ("2 neue Nachrichten")
wer unten steht, wird weiterhin mitgenommen -- ohne Knopf
Alle sieben Chatpruefungen gruen: anhaenge 123/0, aufloesen 126/0,
ausbau 70/0, kanaele 81/0, neu-stelle 63/0, neu 36/0, optik 62/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
75ede0a8e9 |
Die Rueckfragen sagten nicht, was passiert -- und eine lief gar nicht ueber den Hausdialog
`pruef-nachfrage` und `pruef-call-kategorien` standen seit dem 28.09. rot und waren als „nicht angesehen" vermerkt. Nachgemessen sind es drei echte Befunde und eine Zeitbombe. ===================================================================== 1. FALSCHE FELDNAMEN -- die Erklaerung erschien NIE ===================================================================== Der Hausdialog kennt `was:` und `ja:`. An vier Stellen in `reaktion.js` stand `text:` und `knopf:`. Beides wird stillschweigend ignoriert. Wer „Sendung beenden?" las, bekam den Titel und zwei Knoepfe -- genau die Frage, die `confirm()` stellt und derentwegen `nachfrage.js` ueberhaupt gebaut wurde. Es stuerzt nichts ab, es fehlt nur; so etwas findet keine Syntaxpruefung und kein Blick auf den Bildschirm, wenn man den Satz nicht vermisst. Alle vier tragen jetzt `was` UND `bleibt`. Beim Beenden steht dabei das, was seit heute frueh dazugekommen ist: dass Titel, Video, Vorschaubild, Beginn und das zweite Video geleert werden -- wer das nicht weiss, traegt danach alles noch einmal ein und haelt es fuer einen Fehler. ===================================================================== 2. `window.frageNachText` GIBT ES NICHT ===================================================================== Nur EINE Zeile im ganzen Haus nennt es; gesetzt hat es niemand. Die Abfrage „Wie viele Dogen waren es?" lief damit IMMER ueber den nackten `prompt()` -- ausgerechnet die, die am haeufigsten vorkommt. Der Hausdialog kann das laengst besser: `zahl:` ist ein Zahlenfeld mit Obergrenze und eigener Fehlerzeile. ===================================================================== 3. DER DOPPELTE NOTNAGEL WAR TOTER CODE ===================================================================== `window.frageNach ? await frageNach(...) : confirm(...)` -- der Notnagel fuer Browser ohne <dialog> steckt schon IN `nachfrage.js`, und zwar mit DEMSELBEN Text. Meiner daneben zeigte im Ernstfall WENIGER und im Normalfall nie etwas. Im Notizblock stand sogar der nackte `window.confirm()`, ganz ohne Hausdialog. Er fragt „bist du sicher"; der Hausdialog sagt, was passiert und was bleibt. Beim endgueltigen Loeschen ist das `bleibt` der halbe Grund fuer die Rueckfrage: Der Papierkorb ist der Ort, an dem man etwas wiederfindet. ===================================================================== 4. EINE ZEITBOMBE IN pruef-call-kategorien ===================================================================== Sie legte eine Wiederholung „in vier Tagen" an -- im Quelltext stand woertlich „also mit grosser Wahrscheinlichkeit dieser Monat". Heute ist der 30.; vier Tage spaeter ist Oktober. Der Server verlangt kuenftig UND im laufenden Monat, und am Monatsende gibt es beides zusammen nicht. DIE ANWENDUNG HATTE RECHT. Dieselbe Art wie bei `pruef-kalender` am 29.09. Die nahe Auspraegung wird jetzt GERECHNET (letzter Tag des Monats, 23:59) statt gehofft -- plus ein benannter dritter Ausgang fuer die eine Minute im Monat, in der es keinen kuenftigen Termin mehr in diesem Monat gibt. Die drei anderen Aussagen werden auch dann geprueft; ein Ausstieg, der gar nichts mehr misst, waere ein stiller Aussetzer. Gemessen: pruef-nachfrage 53/0 (war 51/2), pruef-call-kategorien 22/0 (war 21/1), pruef-notizen 79/0, pruef-reaktion 407/0, mess-reaktion 0/0, pruef-css-klassen 37/0, pruef-struktur 44/0. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
9125583120 |
Die geschlossene Reaction-Kachel sah aus wie die Aufgaben-Kachel
`pruef-kachelfarben` stand seit dem 28.09. rot und war als „nicht
angesehen" vermerkt. Nachgemessen ist sie ein echter Befund:
engstes Paar 0.0191 (Aufgaben <-> Reaction), Grenze 0,02
Beide sind entsaettigtes Blaugrau -- die Aufgaben tragen Silber, die
Reaction im Zustand „zu" ein blaues Grau. Genau darueber ging Filipes
Klage vom 22.09.: „ich seh immer wieder sehr viele die einfach
komplett die gleiche farbe haben."
GESUCHT, NICHT GERATEN. Was auf dem Schirm ankommt, ist der Ton UNTER
Sternenfeld, Vignette und Wolke -- aus den 32 gewoehnlichen Kacheln
laesst sich die Abbildung schaetzen. Sie traf auf einen Punkt genau:
#8b93a4 -> geschaetzt rgb(64,67,84), gemessen rgb(65,68,83)
Damit vorgesiebt, danach wirklich gerendert und nachgemessen -- eine
Schaetzung allein waere eine Rechnung, die plausibel aussieht.
UND NICHT „AM WEITESTEN WEG". Der groesste Abstand ist ein
Rechenergebnis, keine Gestaltung; er fuehrte zu dunklen Lilatoenen.
Gesucht wurde unter denen, die gleich hell bleiben wie bisher UND
warm sind: Die geschlossene Kachel ist die erste Stufe einer Folge
(zu -> gleich -> live, grau -> bernstein -> rot). Ein warmes Grau
fuehrt dorthin, ein blaues steht quer dazu.
#b8a8a0 Abstand 0,0481 statt 0,0191, Kontrast 8,7:1
Nachher am echten Bildschirm: 31 Pruefungen, 0 Fehler, engstes Paar
jetzt 0,0277 (Willkommen <-> Notizen). Die Rohfarbe kommt zu 56,5 %
an (vorher 38,9 %).
NEBENBEI: `pruef-zentrale-ring` war ebenfalls als rot vermerkt und ist
inzwischen gruen (14/0) -- der Eintrag im Pruefstand war veraltet.
Eine Bestandsliste altert, auch die eigene.
Gemessen: pruef-kachelfarben 31/0, pruef-zentrale-ring 14/0,
pruef-crew-wand-bild 45/0, pruef-css-klassen 37/0, pruef-struktur
44/0, pruef-haus-seiten 38/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
0031091bdd |
Die Eckenwahl zeigt, wo die Kameras stehen -- der letzte offene Punkt der Werbung
Offener Punkt vom 29.09.2026:
„Die Eckenbilder koennen auf den Kamerakacheln landen. 'Unten
rechts' liegt im Layout 'Kino' genau dort, wo die Kameras stehen.
... aber die Regie warnt dich (noch) nicht vorher."
GEZEIGT, NICHT VERBOTEN. Ein Platz, den die Regie ablehnt, waere
falsch: Vielleicht soll das Logo genau dorthin, weil die Kameras
gleich umziehen oder weil auf „nur Video" geschaltet wird. Wer
entscheidet, braucht die Auskunft -- nicht die Entmuendigung.
Dasselbe Verhaeltnis wie beim Tempo-Knopf, der grau wird statt zu
verschwinden.
NUR IM LAYOUT „KINO". `kamera_ecke` steuert den Stapel nur dort; bei
„gleich" und „Kamera gross" stehen die Kameras woanders, bei „nur
Video" gar nicht. Ein Hinweis, der auch dann erschiene, warnte vor
etwas, das nicht passieren kann -- und so etwas gewoehnt man sich ab.
AM KNOPF UND IM VORLESETEXT. Ein gestrichelter Rahmen in Bernstein
(40 %, gedaempft -- was gewaehlt ist, muss lauter sein als was zu
bedenken ist) UND der Satz „hier stehen gerade die Kameras" in
`title` und `aria-label`. Eine Markierung, die nur eine Farbe ist,
gibt es fuer den nicht, der Farben schlecht unterscheidet oder die
Seite vorlesen laesst.
Gemessen in mess-reaktion, mit Gegenprobe -- eine Markierung, die
immer da ist, ist keine:
Eckenwahl im Kino (Kameras unten rechts): ur:benannt
Gegenprobe bei „nur Video": 0 Hinweis(e)
„benannt" prueft ausdruecklich, dass der Satz dransteht und nicht nur
die Farbe.
Gemessen: mess-reaktion 0/0, pruef-reaktion 407/0, pruef-css-klassen
37/0, pruef-struktur 44/0, pruef-tippziele 13/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
6a42ce3432 |
Der Vorhang geht von selbst wieder auf -- ein offener Punkt weniger
Offener Punkt vom 29.09.2026, woertlich aus der Projektnotiz:
„Nimmst du jemanden aus der Sendung und machst es gleich wieder
rueckgaengig, steht bei ihm weiter 'Du bist aus dieser Sendung'.
... Das sauber zu loesen hiesse, ihm waehrend der Sperre eine
langsame Nachfrage zu lassen -- das ist ein eigener Umbau."
Der Umbau ist seit gestern da: Der geschlossene Saal fragt alle 15
Sekunden nach. Dasselbe Muster passt hier -- nur die FRAGE muss eine
andere sein.
NUR DIE EINE FRAGE, NICHT DER GANZE STAND. `rausgenommen()` schliesst
den Ereignisstrom mit Absicht: Wer draussen ist, soll die Sendung
nicht weiterverfolgen. `/api/reaktion` braechte Video, Titel und
Stand mit -- genau das, was ihr genommen werden soll. `POST /dabei`
beantwortet dagegen nur „bin ich wieder dabei?" und verraet nichts:
403 aus_der_sendung / treff_massnahme -> weiter warten
409 saal_zu -> weiter warten
200 -> neu laden
NEU GELADEN WIRD NUR BEI 200, und das ist der Unterschied zwischen
einer Loesung und einer Schleife. Schliesst der Saal, waehrend jemand
draussen ist, kaeme 409; wuerde darauf neu geladen, stuende die
Massnahme danach immer noch, der Vorhang kaeme wieder, und die Seite
laedt sich im Kreis.
ZWANZIG SEKUNDEN. Eine Massnahme ist kein Anruf -- wer
zurueckgeholt wird, ist eine halbe Minute spaeter wieder da.
UND WARUM NEU LADEN STATT WEITERZEICHNEN: `rausgenommen()` hat die
Verbindungen abgebaut, den Strom geschlossen und den Vorhang
angehaengt. Das im Betrieb wieder aufzubauen waere viel Zustand --
und genau das tut ein Neuladen in einem Schritt. Bisher haben wir
den Menschen darum GEBETEN.
DIE PRUEFUNG FEHLTE, und das ist der eigentliche Punkt: Der Mangel
stand seit dem 29.09. in der Notiz und hatte keine. So bleibt ein
bekannter Mangel fuer immer bekannt -- niemand merkt, wenn er behoben
ist, und niemand merkt, wenn er zurueckkommt. Jetzt wartet
mess-reaktion nach der zurueckgenommenen Massnahme darauf, dass der
Vorhang von selbst verschwindet. Gegenprobe gemacht: Nachfrage
abgeschaltet -> „Der Vorhang hebt sich von selbst: NEIN", Rueckgabe 1.
Gemessen: mess-reaktion 0/0, pruef-reaktion 407/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
0fbd3f45b3 |
Die Chatkiste steht immer, Beenden raeumt auf -- und eine verspaetete Antwort ueberschreibt nichts Neueres mehr
Filipe, 30.09.2026: „wenn eine sendung beendet wurde soll alles
automatisch verschwinden. also von daten die da stehen von dem video."
Und: „mach dass ich die chat kiste immer sehe bitte und nicht erst
wenn das video läuft."
=====================================================================
1. BEENDET HEISST LEER
=====================================================================
Beim Beenden verschwinden Titel, YouTube-Adresse, Videotitel,
Vorschaubild, Beginn und das zweite Video samt seiner Stelle. Vorher
blieb alles stehen; beim naechsten Aufmachen stand dort der Titel der
letzten Sendung und ein Beginn, der in der Vergangenheit liegt.
ERST DER VERLAUF, DANN DAS LEEREN -- weg vom Schreibtisch heisst
nicht weg aus der Welt. Geprueft: Nach dem Beenden steht die Sendung
weiter in `reaktion_verlauf`, samt Video.
EINE FELDLISTE, NICHT ZWEI. Die Aufzaehlung stand in der
Zuruecksetzen-Route; jetzt brauchen sie zwei Wege. `SENDUNGS_FELDER`
und `PULT_EINSTELLUNGEN` stehen einmal oben. Zwei Abschriften waeren
die, die beim naechsten Spaltenzuwachs auseinanderlaufen -- genau so
sind am 11.09. drei Spalten mit Inhalt verlorengegangen.
Einstellungen (Bildaufteilung, Kameragroesse, Chatmodus) und die
Warteschlange bleiben -- die raeumt weiter nur „Alles zuruecksetzen"
ab. Wer nur vorbereitet und dann zumacht, behaelt seine Eingaben; das
ist eine Entscheidung und steht als Pruefung fest.
DAS FELD „BEGINN" WURDE NIE GELEERT, nur gefuellt:
`if (lage.beginnt_am && document.activeElement !== …)` -- zwei Fragen
in einer Bedingung, und die zweite beantwortete die erste
stillschweigend mit nein. Das betraf auch den vorhandenen
Zuruecksetzen-Knopf.
=====================================================================
2. DIE CHATKISTE STEHT IMMER
=====================================================================
Sie lag in `#teil-live` und ging mit ihm weg. Im Wartebereich stand
dabei woertlich „Der Chat ist schon offen" -- der Satz stimmte sogar,
der Server laesst dort schreiben (201, geprueft); zu sehen war der
Chat trotzdem nicht.
Die drei Haeute und die Schiene liegen jetzt in einem gemeinsamen
`.raum`: links wechseln die Haeute, rechts steht der Chat. Das Raster
wandert mit nach oben statt sich zu verdoppeln -- zwei
`grid-template-columns` fuer dieselbe Frage waren am 28.09. der
Grund, warum die Regieleiste null Pixel bekam.
Wer nicht schreiben darf, liest den Grund im Feld („Der Saal ist zu").
DER UMBAU HAT DREI DINGE VERSCHOBEN, und die Messung hat sie sofort
gefunden: Kino 0 px hoch, Spendenkarte bei x=1458 ausserhalb des
Bildes, „Kamera aus"-Schild kam nicht an. Eine Ursache: Zwei Regeln
(`grid-row: 2` und `grid-area: kino`) zielten auf die drei Haeute,
weil die frueher unmittelbar im Saal lagen. Gefunden hat das nicht
das Nachdenken, sondern eine Messung der ganzen Kette --
`teil-live 0x0 @1440,742` lag NEBEN dem Raum.
=====================================================================
3. „DER SAAL IST ZU" ERREICHTE NIEMANDEN, DER DARIN SASS
=====================================================================
`stand: "zu"` loescht `reaktion_dabei`, und `melden()` suchte seine
Empfaenger erst danach -- in genau dieser geleerten Liste. Die Seiten
der Zuschauer blieben auf „live" stehen.
`melden(art, daten, wer)` nimmt jetzt eine Empfaengerliste; die
Stand-Route bestimmt sie VOR jeder Aenderung.
UND EINE ZUGESPERRTE SEITE VERSTUMMTE FUER IMMER. War der Saal zu,
hielt `anschliessen()` jeden Takt an -- und Rundrufe bekam sie auch
keine, weil sie in keiner Liste mehr stand. Machte der Host wieder
auf, passierte bei allen mit offenem Reiter NICHTS. Nicht in dreissig
Sekunden: nie, bis jemand von Hand neu lud. Gemessen: Server sagt
„vorbereitung", die Seite zeigt „zu", auch nach 40 Sekunden.
Jetzt fragt eine geschlossene Seite alle 15 Sekunden nach -- der
ruhigste Zustand des Hauses, dort kostet das nichts.
=====================================================================
4. WER ZULETZT ANTWORTET, HAT NICHT RECHT
=====================================================================
Eine Abfrage ist Sekundenbruchteile unterwegs. Kommt in dieser Zeit
ein Rundruf an, ist SEIN Stand der neuere -- und trotzdem hat die
verspaetete Antwort ihn ueberschrieben.
Gemessen: Die Regie schaltet die Werbung auf Wechsel, der Rundruf
zeichnet ihn, und einen Augenblick spaeter steht wieder Laufband.
Eine feste Wartezeit in der Messung hatte das zugedeckt; es fiel
erst auf, als ich sie durch eine echte Bedingung ersetzte.
Drei Runden Raten lagen daneben. Gefunden hat es eine Mitschrift der
Aufrufkette:
wechsel:2 @ EventSource
laufband:2 @ zeichnen < standHolen < signalEmpfangen
Eine Folgenummer zaehlt jeden angekommenen Rundruf. Jede Abfrage, die
die Seite VON SICH AUS macht -- nach dem Verbindungsaufbau, im
geschlossenen Saal, bei jedem Verbindungssignal, nach einer
abgelehnten Anwesenheitsmeldung, und der Anwesenheitstakt selbst --
verwirft ihr Ergebnis, wenn inzwischen etwas Neueres da war.
Abfragen nach einer EIGENEN Handlung bleiben hart: Sie bringen Dinge
mit, die kein Rundruf traegt (die Verwaltungslisten der Regie). Die
Unterscheidung steht am Aufruf, nicht in einer Bedingung im Inneren.
=====================================================================
5. UND DIE MESSUNGEN WARTEN NICHT MEHR AUF DIE UHR
=====================================================================
Feste Wartezeiten sind dieselbe Falle wie feste Schwellen: Sie
stimmen, bis daneben etwas langsamer wird, und melden dann einen
Fehler, den es nicht gibt. Zweimal ist mir das in einer Stunde
passiert -- einmal beim Band, einmal bei den Ecken. Der Werbeblock
wartet jetzt fuenfmal auf das Ergebnis, der Gleichlauf viermal; laeuft
eine Frist ab, ist es ein echter Befund.
Die erste Fassung der Gleichlauf-Gegenprobe war selbst falsch -- sie
hielt das Selbstheilen des Systems fuer einen Fehler.
Neu in mess-reaktion: „Die Chatkiste in jedem Zustand" (alle drei,
mit Breite und Sperrgrund) und „Beendet heisst leer (im Pult)" -- dort
gemessen, wo Filipe hinsieht, nicht in der Datenbank.
Neu in pruef-reaktion (+14): das Leeren, die Gegenprobe „vorher war
etwas drin", der Verlauf bleibt, und die Entscheidung „wer nur
vorbereitet hat, behaelt seine Eingaben".
Gemessen: mess-reaktion dreimal hintereinander 0/0, pruef-reaktion
407/0, pruef-css-klassen 37/0, pruef-struktur 44/0, pruef-tippziele
13/0, pruef-haus-seiten 38/0, pruef-haus-trennung 100/0, pruef-buehne
38/0, pruef-push-ziel 38/0, mess-buehne 0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
2c3b90d75c |
Benachrichtigungen: die Reaction laedt ein, jedes Haus bekommt sein Gesicht -- und die Videos haengen nicht mehr
Filipe, 29.09.2026: „ich will dass du die benarichtigungen
perfektionierst. dogfather und alle anderen sollen die
benachrichtigungen perfekt von dieser seite hier bekommen."
Und dazu, mit einer Bildschirmaufnahme: „wieso haengen die videos
immer."
=====================================================================
1. WARUM DIE VIDEOS HAENGEN -- zwei Zeilen, eine Rueckkopplung
=====================================================================
Die Aufnahme zeigt den YouTube-Zaehler bei 0:13 von 31:34, vier
Bilder lang unbewegt, in der Mitte der Ladering.
a) `hostMelden()` rechnete `laeuft = getPlayerState() === 1`.
Zustand 3 heisst PUFFERN -- „ich will spielen, mir fehlen
gerade Daten". Der Host meldete in diesem Moment „laeuft
nicht", und zwar sofort, weil `onStateChange` bei jedem
Zustandswechsel meldet.
b) `empfaenger()` fuegt den Host ausdruecklich hinzu, und
`folgen(d)` lief im Ereignisstrom fuer alle -- auch fuer ihn.
Seine eigene Meldung kam zurueck und traf dort auf
if (!stand.laeuft && getPlayerState() === 1) pauseVideo();
Der Host puffert eine halbe Sekunde, laeuft weiter -- und wird vom
Echo seines eigenen Pufferers angehalten. Bei einem 31-Minuten-Video
passiert das in den ersten Sekunden zuverlaessig.
Und alle Zuschauer bekamen bei JEDEM Pufferer des Hosts ein
Pause-Play-Paar. Das ist das Ruckeln, das man fuer die eigene
Leitung haelt.
GEMESSEN, NICHT HERGELEITET (mess-reaktion):
vorher Host=laeuft -> Pufferer gemeldet -> Host=pause
nachher Host=laeuft -> Pufferer gemeldet -> Host=laeuft
Drei neue Messungen, jede mit Gegenprobe:
· ein gemeldeter Pufferer haelt den Host nicht an
· ein ECHTES Anhalten (Knopf gedrueckt) haelt alle an -- sonst
waere das Erste mit kaputtem Gleichlauf bezahlt
· beim Puffern meldet der Server `laeuft=true`; ist der Pufferer
nicht herzustellen, sagt die Messung das (dritter Ausgang)
Beide Behebungen einzeln zurueckgenommen: beide Male rot.
Die erste Fassung der Gegenprobe war selbst falsch -- sie hielt das
Selbstheilen des Systems (der Host meldet alle fuenf Sekunden die
Wahrheit) fuer einen Fehler. Deshalb drueckt sie jetzt den Knopf,
statt eine Meldung zu faelschen.
=====================================================================
2. DIE REACTION LAEDT EIN
=====================================================================
Nachgemessen war `workspace-reaktion.js` STUMM: kein einziges
`benachrichtige`. Beim Einschalten lief `melden("reaktion", ...)`
ueber den Ereignisstrom -- also nur an Leute, die die Seite ohnehin
offen haben. Das Kino machte auf, und die Einladung verliess das Haus
nie. Dasselbe Muster wie bei den Bewerbungen am 23.09.
Neue Art `reaktion_live`, eigene neben `dogfather_live`: Das eine ist
sein Stream auf TikTok, das andere das Kino hier im Haus.
Eingeladen wird, wer ein Geraet hat und NICHT der Agentur gehoert
(`AGENTUR_ROLLEN` -- keine neue Liste). Nicht der, der eingeschaltet
hat. Und nicht zweimal: Eine Bremse von zwei Stunden faengt den
Neustart ab, denn das Merkmal haengt an `gestartet_am` und das wird
bei jedem Wechsel nach live neu gesetzt.
Geprueft Ende zu Ende in pruef-reaktion (+10): Sendung geht auf
Sendung, danach stehen genau fuenf Einladungen in `push_verschickt` --
rechte Hand, linke Hand, Modi, zweimal Community. Nicht der Host,
nicht die Creatorin. Einladung abgeschaltet: sechs Fehlschlaege.
=====================================================================
3. DARF DAS NACHTS KOMMEN? -- drei Antworten statt zwei
=====================================================================
Hier stand `art === "test" || art === "anruf"`, 230 Zeilen von der
Artenliste entfernt. Am 18.09. hat das eine Nacht lang alle Anrufe
verschluckt; behoben wurde damals dieser eine Fall.
GEMESSEN AM LIVE-BESTAND: `dogfather_live` ging an allen sieben
Abenden vom 22. bis 28.09. zwischen 20:28 und 21:06 raus -- jedes Mal
knapp vor der Sperre um 22 Uhr. Geht Filipe einmal um 22:05 live,
bekommt niemand etwas, und niemand erfaehrt warum.
`ruhe` steht jetzt an der ART:
"immer" (Vorgabe) 22-7 gesperrt -- Erinnerungen
"spaet" nur 1-7 -- etwas laeuft GERADE
"nie" nie -- ein Mensch wartet am Hoerer
=====================================================================
4. JEDES HAUS BEKOMMT SEIN GESICHT
=====================================================================
Im Service Worker stand fest `workspace-192.png`. Von acht Menschen
mit angemeldetem Geraet gehoeren fuenf ins Crew-Haus -- die sahen auf
jeder Benachrichtigung das Symbol des Hauses, in dem sie nicht
arbeiten.
Entschieden wird es auf dem SERVER: Im Browser stuende sonst die
verborgene Crew-Adresse in einer Datei ohne Anmeldung (der Befund vom
21.09. bei crew-haus.css) -- und es waere eine zweite Fassung der
Hausteilung. Zweistufig, beide Stufen gibt es schon: die Zielseite,
wenn sie in genau ein Haus gehoert (GEHOERT_ZU_ADRESSE), sonst
`AGENTUR_ROLLEN`.
=====================================================================
5. DAS ABZEICHEN WAR EIN KLOTZ
=====================================================================
`badge` ist das winzige Zeichen in der Statusleiste; Android benutzt
davon NUR den Alphakanal. Dort stand dasselbe `workspace-192.png` --
ein vollflaechiges Quadrat ohne Transparenz, also ein ausgefuellter
Klotz. Es stuerzt nichts ab, deshalb faellt es niemandem auf.
`assets/img/abzeichen-96.png`: der gefuellte Umriss des Huskys, weiss
auf durchsichtig, 3,5 KB. Drei Fassungen gebaut und bei ECHTER Groesse
(24 px) verglichen -- Strichbild zerfaellt, Flaeche traegt.
`server/helfer-png-alpha.mjs` liest den Alphakanal wirklich (PNG
auspacken, Zeilenfilter zuruecknehmen). Eine Pruefung auf „die Datei
gibt es" haette den Klotz nie gefunden -- die Datei gab es ja. Die
Gegenprobe ist der alte Zustand selbst: dieselbe Rechnung meldet auf
`workspace-192.png` „kein Alphakanal, Deckung 100 %".
Das Abzeichen liegt NICHT bei den App-Symbolen -- `pruef-struktur`
verlangt dort zu jedem Namen den vollen Satz und hielt es fuer eine
neue App. Der Waechter hat recht: Ein Abzeichen ist kein App-Symbol.
=====================================================================
Gemessen: mess-reaktion 0, pruef-reaktion 393/0 (+10),
pruef-push-ziel 38/0 (+27), pruef-push 24/0, pruef-push-weg 20/0,
pruef-glocke 36/0, pruef-struktur 44/0, pruef-haus-trennung 100/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
a43bc565ec |
Werbeeinblendung fuer die Reaction: Laufband, Wechsel und zwei Bilder in sechs Ecken
Filipe: „ich will dass du auch perfektionierst dass ich einen banner durchlaufen kann, oder erscheinen lassen kann mit werbung drauf ... und ich will auch das dogfather logo oben rechts links unten rechts links genau wie oben unten mittig, so dass ich es wegmachen und hinzufuegen kann." DAS BAND Zwei Arten: „Laufband" zieht die Botschaften von rechts nach links, „Wechsel" blendet sie nacheinander ein. Ein Rabattcode gehoert in den Wechsel -- wer „DOGI10" lesen will, waehrend es wandert, hat es gesehen und nicht behalten. Die Dauer ist einstellbar (8-40 s). Das Band ist Glas, kein Balken: ein Verlauf, unten dicht genug, dass jede Schrift traegt, oben offen. Man sieht das Video weiter. Das Laufband traegt die Folge ZWEIMAL. Wandert es um 50 % seiner Breite, steht die zweite dort, wo die erste war, und der Sprung zurueck ist unsichtbar. Ohne sie entstuende am Ende jedes Durchlaufs eine leere Flaeche -- das sieht aus, als sei die Einblendung abgestuerzt. Wer weniger Bewegung eingestellt hat, bekommt den Wechsel statt des Laufbands -- nicht „aus". Die Werbung soll auch dann wirken. DER RABATTCODE Ein Wort in Grossbuchstaben mit einer Ziffer darin bekommt eine eigene Flaeche in Bernstein: „DOGI10" ja, „VANVAN" nicht. Er ist der einzige Teil der Botschaft, den jemand ABSCHREIBEN soll. Der Text wird NIE als HTML eingesetzt -- die Kennzeichnung baut echte Elemente. Sonst waere ein Eingabefeld im Regiepult ein Weg, fremdes Markup in den Stream zu bringen. DIE ZWEI BILDER Der Husky und der Haekelhase aus der Zusammenarbeit mit VanVan, jeweils an einem von sechs Plaetzen: oben und unten, je links, mittig, rechts -- oder aus. Links und rechts mittig gibt es mit Absicht nicht: dort liegen bei jedem Videodienst die Bedienelemente. Zwei Bilder auf denselben Platz werden abgelehnt (400 ecke_belegt) -- sie laegen uebereinander, und man saehe von beiden nichts. Wer unten steht, weicht dem Band aus, und die Spendentafel rueckt hoch. Beides im Stilblatt ueber `:has`, nicht im Programm: Das Band kennt die Tafel nicht und die Tafel kennt das Band nicht. Der Husky ist schwarz und laege auf dunklem Videobild als Silhouette in der Nacht. Zwei weiche helle Schatten legen eine Kontur darum -- dieselbe Loesung, die jeder Sender fuer sein Wasserzeichen nimmt. IM STREAM, NICHT NUR IM SAAL Beides laeuft in der Buehnenquelle mit, die OBS abfilmt, mit groesserer Schrift (24 statt 18 px) -- ein Stream wird auf einem Handy gesehen, oft in einem Viertel des Bildes. Gemessen: die OFFENE Quelle zieht eine Umschaltung nach, ohne dass die Szene neu geladen werden muss. EINE QUELLE, NICHT DREI `werbungStand()` steht in `reaktion-tabellen.js` und wird von Saal, Regie und Buehne aufgerufen. Erst standen dort drei Abschriften derselben Abfrage; beim Entfernen der Datenbank-Kennung habe ich eine davon geaendert, und die anderen lieferten sie weiter. WAS DIE PRUEFUNGEN DABEI GEFUNDEN HABEN - pruef-buehne: Die Botschaften trugen ihre Datenbank-Kennung in die OBS-Auskunft, die nur mit einem Schluessel geschuetzt ist. Die Feldliste geht jetzt zwei Ebenen tief -- eine abschliessende Liste, die nur die oberste kennt, laesst sich umgehen, indem man ein Feld in ein vorhandenes Objekt legt. - pruef-reaktion: Acht Fehlerwoerter ohne deutschen Satz. Nachgetragen im Hausstil: was nicht geht UND was stattdessen. - pruef-struktur: Die Suche nach totem CSS las `buehne.html` und `tafel.html` nicht -- eine Ausnahme, die fuer eine ganz andere Frage gemacht war (Startbildschirm-Symbol). Sie haette verlangt, `.obs-buehne` zu loeschen, also die Regel, die den Stream traegt. - pruef-tippziele: Erkannte als Anhebung nur `min-height`/`min-width`. Ein `height: 44px` im Fingerblock hebt genauso -- Fehlalarm, und ein Fehlalarm an einer Pruefung, die nach jeder Aenderung laeuft, wird weggeklickt. Zwei Gegenproben dazu. - mess-reaktion: Die Regieleiste am Handy wurde gegen die feste Zahl SIEBEN geprueft und meldete „zeigt nur 8 von 7". Sie zaehlt jetzt selbst. - mess-buehne: Die Konsolenmeldung zeigte dauerhaft vier Fehlschlaege, alle von den Pruefungen selbst bestellt. Jetzt eng gefiltert, benannt, mit Gegenprobe -- und ein UNERWARTETER Fehlschlag in der Quelle, die in den Stream geht, faellt ab sofort durch. Gemessen: mess-reaktion 0, mess-buehne 0, pruef-reaktion 383/0, pruef-buehne 38/0, pruef-tippziele 13/0, pruef-struktur 44/0, pruef-css-klassen 0, pruef-haus-trennung 100/0, pruef-haus-seiten 38/0. 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
|
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
|
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
|
||
|
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
|
||
|
DogFatherGit
|
3dd4cef42d |
Die Handgriffe unter jeder Nachricht: drei Zeilen werden zwei
EINE RECHNUNG, DIE NIE GEMESSEN WURDE
In chat.css stand seit dem 25.09.2026 neben den 44-Pixel-Knoepfen
der Fusszeile:
"Fuenf mal 44 plus vier Abstaende sind 236 px -- eine Blase hat
auf 412 px innen 251 px. Die Reihe bleibt damit einzeilig."
Sie vergisst die Uhrzeit. Die ist 57 Pixel breit und steht in
derselben Reihe; 236 + 57 sind 293.
Auffallen konnte das nicht, weil die Regel nie lief: Alle
Handy-Messungen des Hauses liefen bis gestern mit einem MAUSZEIGER.
`setViewportSize` macht aus einem Browser kein Telefon -- `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. Die Rechnung wurde also gedacht und nie
gesehen.
Mit Finger gemessen, 412 px: 234 Pixel Platz fuer 277 Pixel Inhalt.
DREI Zeilen, 96 Pixel hoch -- unter jeder einzelnen Nachricht.
DIE UHRZEIT BEKOMMT IHRE EIGENE ZEILE
Sie ist das einzige Stueck der Reihe, das kein Beruehrziel ist.
Damit behalten die fuenf Knoepfe ihre 44 Pixel nebeneinander:
5 x 44 + 4 x 2 = 228 und passen in 234.
Gemessen jetzt: zwei Zeilen, 74 Pixel. Die Knopfzeile braucht 224
von 234.
EIN VERSUCH, DER ES NICHT WURDE
Zuerst hatte ich die Blase am Fingergeraet von `min(66%, 62ch)` auf
82 Prozent verbreitert -- daneben steht ja die Absicht, sie solle
"auf dem Handy trotzdem die Breite ausnutzen". Die Messung kam
SCHLECHTER zurueck (188 statt 234 Pixel Platz), und das lag an der
Messung selbst: Sie las "die erste Fusszeile". Wie breit die ist,
haengt vom Text darueber ab. Dieselbe Aenderung sah dadurch mal
besser und mal schlechter aus, ohne dass sich etwas geaendert hatte.
Der eigentliche Grund, warum 82 Prozent nicht helfen: `max-width`
ist eine Obergrenze, keine Breite. Eine kurze Nachricht hat eine
schmale Blase, und die Fusszeile bricht darin genauso um. Bei
allen vier gemessenen Nachrichten brach sie.
MESSUNG GESCHAERFT
- Sie fragt jetzt, WIE VIELE Fusszeilen umbrechen, nicht wie die
erste aussieht.
- "Inhalt" ist die breiteste ZEILE, nicht die Summe aller Kinder.
Seit die Uhrzeit absichtlich umbricht, waere die Summe die
Breite zweier Zeilen uebereinander -- sie meldete 444 Pixel in
einer 234 Pixel breiten Fusszeile und sah wie ein Ueberlauf aus.
- `mess-notizblock` misst am Handy jetzt ebenfalls mit Finger
(eigener Kontext, `hasTouch`). Vorher zeigten seine
Handy-Bilder eine Seite, die auf keinem Handy so aussieht.
DIE KLAMMERWACHE HAT WIEDER EINEN ECHTEN FUND GEMACHT
Beim Zuruecknehmen des 82-Prozent-Versuchs blieb das schliessende
`}` der Medienabfrage stehen. Zweiter echter Fund in zwei Tagen,
beide Male an meinem eigenen Werkzeug.
GEPRUEFT
pruef-chatkachel, -css-klassen, -tippziele, -handy: alle EXIT 0
mess-chat-optik EXIT 0 -- 2 Zeilen, 74 px (vorher 3 / 96)
mess-notizblock EXIT 0
|
||
|
DogFatherGit
|
7351820c55 |
Der Waechter gegen Namensstreit gilt jetzt fuer das ganze Haus
Er wurde gestern fuer `reaktion.css` gebaut, nachdem `.stufen` dort
zweimal stand und die Stufenleiter der Spenden dadurch das Aussehen
der Chat-Leiste bekam -- drei Stufen nebeneinander, 572 Pixel in
einer 327 Pixel schmalen Spalte, mit der waagerechten Rollleiste auf
Filipes Bildschirmfoto.
Eine Wache, die nur eine Datei ansieht, findet genau die Fehler
dieser einen Datei. Auf alle 36 Stilvorlagen angewandt fand sie
GENAU EINE weitere Stelle.
DER FUND: `.wahl2__eintrag` in gate.css
Zeile 1584 display: block (mit text-overflow: ellipsis)
Zeile 2634 display: flex (fuer Personenbilder, 08.09.2026)
Kein Streit zweier Bauteile, sondern eine spaetere Erweiterung --
und trotzdem ein echter Fehler: `text-overflow: ellipsis` wirkt bei
`display: flex` NICHT auf ein anonymes Flex-Kind. Der Knopf
„… eintragen" in jeder Auswahl des Hauses hat langen Text seither
HART abgeschnitten statt mit „…" gekuerzt.
GEMESSEN -- und nur im Bild zu sehen: `scrollWidth` ist in beiden
Faellen gleich (364 px bei 200 px Breite). Die Zahlen sagten
„kein Unterschied", das Bildschirmfoto zeigte einen. Ein Beleg mehr
dafuer, dass zwei gleiche Zahlen nicht dasselbe Ergebnis bedeuten.
REPARIERT
- Der eigene Eintrag bekommt einen `.wahl2__name`-Span, wie jeder
andere Eintrag auch. Damit kuerzt er wieder mit „…".
- Die zwei Grundregeln sind eine. Wer die erste las, glaubte an
`display: block` -- 1050 Zeilen weiter stand das Gegenteil.
DIE WACHE
923 Grundregeln in 36 Stilvorlagen, keine Klasse zweimal
verschieden gebaut. Gezaehlt wird nur, was sich widersprechen
kann: nicht dieselbe Klasse in einem Zusammenhang (`.saal .pult`),
nicht eine Variante in einer Medienabfrage, nicht
„erst versteckt, dann gezeigt". Sechs Gegenproben, darunter der
echte Fall vom 28.09. und eine Klasse im Kommentar.
GEPRUEFT: css-klassen, freie-namen, suchfeld, tippziele alle EXIT 0.
|
||
|
DogFatherGit
|
0c696f286d |
Der Kopf der Regie bleibt stehen, waehrend ihr Inhalt rollt
Drei kleine Dinge an der Schublade von vorhin, und eine ehrliche
Notiz zu dem, was nicht ging.
- `overflow-y: auto` statt `overflow: hidden`. Reicht der Platz
nicht, rollt die Schublade senkrecht -- statt ihren Inhalt
unter der Transportleiste verschwinden zu lassen. Senkrechtes
Rollen war nie das Problem; Filipes Ansage vom 28.09. galt dem
Wischen nach links und rechts.
- `flex: none` am Kopf. Ohne das ist er ein Flex-Kind mit
`shrink: 1` -- was nichts hilft, weil sein `min-height: auto`
ihn nicht unter die Hoehe seines Inhalts laesst. Er ragte dann
einfach hinaus.
- Der Kopf klebt beim Rollen (`position: sticky`). Sonst scrollt
man „Auf Sendung" weg -- den Knopf, um den es geht.
AUF 320 PIXELN BLEIBT ES BEIM BEKANNTEN MANGEL
Dort bleiben zwischen Registern und Transportleiste rund 190 Pixel,
und der Kopf der Regie allein braucht 210. Sechs Versuche haben nur
bestimmt, WER verdeckt wird: „Vorbereiten" unter der Leiste, die
Schublade ueber „Gaeste" und „Bild", oder beim rollenden Container
22 Pixel Ueberlappung. Keiner hat es geloest.
Das steht jetzt mit Zahlen und Versuchen im Stilblatt -- samt dem
Hinweis, dass es ein eigenes Nachdenken braucht (die Regie wird dort
ein eigener Bildschirm statt einer Schublade) und nicht den siebten
Versuch mit derselben Werkzeugkiste.
NEBENBEI: Die Klammerwache hat ihren zweiten Fund in zwei Tagen
gemacht -- beim Umbauen blieb erneut eine schliessende Klammer ohne
ihren Anfang stehen. `pruef-handy` und `mess-reaktion` waren dabei
gruen; ohne die Wache waere es unbemerkt mitgegangen.
GEPRUEFT: css-klassen, handy, tippziele, reaktion alle EXIT 0;
mess-reaktion EXIT 0 (133 px sichtbares Bild, kein Knopf ueber
einem anderen), mess-quer EXIT 0.
|
||
|
DogFatherGit
|
a6b37909ca |
Die Transportleiste steht am Handy in einer Reihe
Auf dem Bildschirmfoto nach dem Umbau lagen der runde Play-Knopf und
seine Nachbarn uebereinander. `pruef-handy` meldete das nicht: Sie
fragt, ob die MITTE eines Knopfes frei ist -- zwei Knoepfe koennen
sich an den Raendern ueberlagern und beide „erreichbar" sein. Wer
danebentippt, trifft trotzdem den falschen.
GEMESSEN (neue Stelle in mess-reaktion, die jedes Knopfpaar der
Leiste auf Ueberschneidung prueft):
tempo-auf / v-spiel 21 x 44 px
v-spiel / v-tauschen 21 x 38 px
URSACHE: `grid-template-columns: auto 1fr auto`. Tempo links und
„Wechseln zu <Videotitel>" rechts nahmen so viel, dass die mittlere
Spalte schmaler wurde als der 58 Pixel breite Play-Knopf -- und ein
zentrierter Inhalt, der breiter ist als seine Spalte, ragt ueber
BEIDE Raender.
Jetzt `minmax(0, auto) max-content minmax(0, auto)`: Die Mitte ist
so breit wie ihre drei Knoepfe zusammen und schrumpft nie, die
Seiten geben nach. `min-content` war dabei die falsche Zwischenstufe
-- damit war die Spalte so breit wie ihr BREITESTER Knopf, und
„−10" und „+10" brachen darunter um.
GEPRUEFT: pruef-handy, -tippziele, -css-klassen, -reaktion und
mess-quer alle EXIT 0; mess-reaktion meldet „Kein Knopf der
Transportleiste liegt ueber einem anderen" und 133 Pixel sichtbares
Bild.
|
||
|
DogFatherGit
|
e272dd4673 |
Am Handy ist die Transportleiste wieder erreichbar
Der offene Punkt von gestern Nacht, jetzt geloest -- und dabei stellte
sich heraus, dass er schlimmer war als gemeldet.
WAS WIRKLICH LOS WAR
Gemeldet war: "Am Handy bleibt bei offener Regie vom Bild nichts."
Gemessen auf 390x844 ergab sich mehr:
Saal 69..844 (775 px)
Zeilen 101 + 0 + 511 + 325 = 937
transport 681..1006 -- 162 Pixel UNTER dem Fensterrand
Der Koerper hat `overflow: hidden`; die Leiste war also nicht
abgeschnitten, sondern weg. Play, "Naechstes" und die Sprungknoepfe:
bei offener Regie nicht erreichbar. Das Bild hatte dabei null Pixel.
DIE RECHNUNG, DIE ES ERKLAERT
Regieleiste 101 (zwei Zeilen Register)
Regie-Kopf 207 (fuenf Zeilen zu je rund 44 px -- der
Klapp-Knopf stand allein in einer)
Regie-Inhalt 305
Transport 325 (Schiene 48 + drei Gruppen untereinander)
----
938 von 775.
Video, Regie und Transport passen auf einem Handy nicht nebeneinander.
Das ist keine Frage der Gestaltung, sondern des Platzes.
VIER SCHNITTE UND EINE ENTSCHEIDUNG
1. Die Tempo-Gruppe klappt hinter ihren eigenen Wert -- dasselbe
Muster wie "Aa" im Chat, das dort 73 Pixel gespart hat. Der
Knopf zeigt "1x" oder "1,5x", man muss zum Nachsehen also nicht
aufklappen. Am Rechner gibt es ihn nicht.
2. Der Klapp-Knopf rutscht neben die Lampe statt in eine eigene
Zeile.
3. Die drei Gruppen der Transportreihe stehen nebeneinander (158
statt 240 Pixel) -- moeglich, seit die Tempo-Gruppe klappt.
4. Die Messwerte stehen in einer Zeile, die grossen Knoepfe
bekommen weniger Polsterung.
Das reichte nicht. Also die Entscheidung: AM HANDY LEGT SICH DIE
REGIE UEBER DAS BILD, statt ihm Platz wegzunehmen -- als Rasterfeld
ueber die Zeilen 2 und 3, unten angedockt, hoechstens 72 Prozent
hoch. Oben bleibt ein Streifen Bild stehen (gemessen 135 px): Wer
mitten in der Sendung etwas einstellt, muss sehen, worueber er redet.
Gemessen jetzt: Saal 775 = Leiste 101 + Bild 481 + Regie 346, und
der Transport steht bei 601..844 -- erreichbar.
DREI VERSUCHE, DIE ES NICHT WURDEN (und warum)
- `position: absolute` mit gemessener Transporthoehe: lief, lag
aber 17 Pixel ueber den Registern. Der Bezugsrahmen eines
absolut gesetzten RASTERFELDES ist sein Rasterbereich, nicht der
Container -- mit `grid-row: 3` (0 Pixel hoch) wurde aus
`max-height: 100%` eine Hoehe von einem Pixel.
- `top` UND `bottom` UND `height: fit-content`: Der Browser
verwirft dann das `bottom`; die Regie ragte 101 Pixel in die
Leiste.
- `grid-row: 2 / 4` mit `align-self: end` statt absolut: ragte 146
Pixel nach oben und schob die Seite 198 Pixel breiter.
AUF 320 PIXELN BLEIBT ES BEIM ALTEN
Dort passen Register (104), Regie-Kopf (210) und Transportleiste
(158) zusammen nicht in die 499 Pixel Saal -- es fehlten 17. Fuenf
Verteilungen haben nur bestimmt, WER verdeckt wird: erst
"Vorbereiten" und "Beenden" unter der Leiste, dann die Schublade
ueber "Gaeste" und "Bild". Die Schublade greift deshalb erst ab 360
Pixeln; darunter bleibt der Stand von vorher -- ein bekannter Mangel,
aber kein neuer. Der Grund steht im Stilblatt.
NEBENBEI GEFUNDEN
- `.muenzsatz` brach nicht um und ragte auf 320 px 8 Pixel hinaus
-- die Tafel rollte dort wieder waagerecht.
WACHEN GESCHAERFT
- Die Klammerwache von gestern hat heute ihren ersten echten Fund
gemacht: Beim Herausschneiden einer Regel blieb eine `}` stehen.
Ohne sie waere das als drei Befunde in `mess-reaktion`
aufgetaucht, die wie Programmfehler ausgesehen haetten.
- Der Namensstreit-Waechter meldete `pult (grid vs. flex)` und
`messwerte__paar (grid vs. flex)` -- beides Fehlalarm: Eine
Regel in einem Zusammenhang (`.saal .pult`) und eine in einer
Medienabfrage sind Varianten, kein Streit. Er nimmt beides jetzt
aus. Dabei fiel auf, dass sein Muster die schliessende Klammer
verbrauchte, die der naechste Treffer als Anfang braucht -- der
echte Fall vom 28.09. (`.stufen` zweimal) wurde dadurch gar
nicht gefunden. Die Gegenprobe deckt jetzt fuenf Faelle ab.
- `mess-reaktion` mass die HOEHE der Kinozeile und haette 431
Pixel gemeldet, waehrend das Bild vollstaendig verdeckt war.
Sie misst jetzt, wieviel oberhalb der Schublade uebrig bleibt.
GEPRUEFT
pruef-reaktion, -css-klassen, -tippziele, -handy, -struktur,
-buehne: alle EXIT 0
mess-reaktion EXIT 0, kein ACHTUNG, kein offener Punkt
mess-quer EXIT 0 -- fuenf Groessen, nichts rollt seitlich
mess-buehne EXIT 0
|
||
|
DogFatherGit
|
a9e0834cfb |
Nichts wird mehr nach links oder rechts geschoben
Filipe, 28.09.2026: "ich will auch nicht dass man sachen nach links
und rechts schieben muss. perfektion das untereinander. ich will
niemals irgendwas nach links oder rechts swippen muessen." Dazu ein
Bildschirmfoto der Tafel "Gestaltung" mit waagerechter Rollleiste.
GEMESSEN, NICHT GERATEN
Ein grep nach `overflow-x` findet nur die absichtlichen Roller. Er
findet nicht die Stelle, an der ein Inhalt breiter ist als sein
Kasten und der Browser von sich aus eine Rollleiste anhaengt -- und
genau das war auf dem Bild zu sehen. `server/mess-quer.mjs` geht
deshalb im echten Browser jedes Element durch, auf fuenf
Bildschirmgroessen, in allen sieben Registern, bei offener und
zugeklappter Regie und in allen fuenf Anordnungen.
Erster Lauf: 78 Stellen. Davon waren 54 KEINE -- `overflow-x: hidden`
ist abgeschnittener Text, dort laesst sich nichts schieben. Die
Messung trennt das jetzt; wer es mitzaehlt, findet die echten nicht
mehr. Uebrig blieben vier Ursachen:
1. DIE REGISTER rollten absichtlich waagerecht. Auf 412 px standen
von 605 px Registern 193 rechts ausserhalb -- dass es
"Gestaltung" und "Spenden" gibt, erfuhr man nur beim Wischen auf
Verdacht. Sie brechen jetzt um. Das kostet oben rund 45 Pixel
und bringt Gewissheit dafuer.
2. `.stufen` STAND ZWEIMAL IN reaktion.css -- einmal fuer die
Stufenleiter der Spenden (`display: grid`), 600 Zeilen spaeter
fuer die Chat-Leiste Offen/Team/Zu (`display: flex`). Die
spaetere gewinnt: Die Stufenleiter stellte ihre drei Stufen
NEBENEINANDER, 572 Pixel in einer 327 Pixel schmalen Spalte.
Das ist die Rollleiste auf Filipes Bild. Die Chat-Leiste heisst
jetzt `.chatstufen` / `.chatstufe`.
Dritter Fall dieser Art nach `.tafel` und `.stufe-knopf`.
3. DIE TAFELN KONNTEN NICHT SCHRUMPFEN. Ein Gitterfeld hat von
sich aus `min-width: auto` und besteht auf seinem unteilbarsten
Inhalt. Mit `minmax(0, 1fr)` und `min-width: 0` bricht jetzt
alles um, statt hinauszulaufen.
4. DIE TRANSPORTLEISTE ragte am Handy 76 Pixel ueber beide Kanten
("Naechstes" war nur halb zu sehen). Zwei Gruende: `.transport__teil`
hatte kein `flex-wrap` (die mittlere Gruppe schon -- zwei Regeln
fuer dieselbe Sache, eine vergessen), und im Umschalter steht
ein ganzer Videotitel, der als Flex-Kind auf seiner vollen
Breite bestand.
NEBENBEFUND: EINE FESTE ZAHL VON GESTERN
Der Saal stand auf `height: calc(100dvh - 69px)` -- 69 war einmal
die gemessene Hoehe der Kopfleiste. Sie ist 73 geworden, und der
Saal endete damit 4 Pixel unter dem Fensterrand: Der Play-Knopf war
nur mit Scrollen zu erreichen. Die Antwort ist keine neue Zahl,
sondern eine Regel, die misst -- der Koerper ist jetzt eine Spalte,
die Kopfleiste nimmt, was sie braucht, der Saal bekommt den Rest.
(Dabei noch ein Spezifitaetsunfall: `.reaktion-seite` (0,1,0)
verliert gegen `body.start` (0,1,1) aus start.css.)
NEUE WACHEN
- `mess-quer.mjs` mit Gegenprobe (ohne die Reparaturen findet sie
47 px, mit ihnen nichts).
- pruef-reaktion: kein absichtliches `overflow-x: auto` mehr; und
zwei Grundregeln derselben Klasse mit verschiedenem `display`
sind ein Namensstreit. Der bisherige Waechter verglich nur
ZWISCHEN Stilvorlagen -- `.stufen` stand zweimal in DERSELBEN.
- pruef-css-klassen: jede Klammer hat ihr Gegenstueck. Beim
Umschreiben blieb heute das Ende einer Regel ohne ihren Anfang
stehen; der Browser wirft die Zeile weg und schliesst dafuer den
naechsten @media-Block zu frueh. Drei Befunde sahen daraufhin wie
Programmfehler aus.
MESSUNG NACHGEZOGEN
`mess-reaktion` stammte noch aus der Zeit vor "Regie links" und
"drei Kacheln" und meldete drei Dinge, die keine Fehler waren --
gemessen gegen den Stand von HEAD: identisch rot. Sie misst ausserdem
seit heute mit FINGER statt Mauszeiger; ohne `hasTouch` greift keine
einzige Regel aus `@media (pointer: coarse)`, und dort stehen alle
44-Pixel-Beruehrziele des Hauses.
OFFEN UND AUFGESCHRIEBEN
Am Handy bleibt bei offener Regie vom Bild nichts (0 px). Der Mangel
besteht seit dem Umbau "Regie links"; drei Versuche, ihn heute zu
loesen, haben Knoepfe verdeckt -- und ein verdeckter Knopf ist
schlimmer als ein kleines Bild. Die Versuche und der richtige Weg
(Tempo-Gruppe hinter einen Knopf, wie "Aa" im Chat) stehen in
reaktion.css. `mess-reaktion` meldet ihn als dritten Ausgang: nicht
als Fehler und nicht als bestanden.
GEPRUEFT
pruef-reaktion 384 / 0 (vorher 379)
pruef-spenden 172 / 0
pruef-buehne 36 / 0
pruef-css-klassen, -tippziele, -struktur, -handy: ohne Befund
mess-quer EXIT 0 -- 28 Stellen, fuenf Groessen, nichts rollt
mess-reaktion EXIT 0, 1 benannter offener Punkt
mess-buehne EXIT 0
|
||
|
DogFatherGitandClaude Opus 5
|
813d2e85a1 |
Die Kuerzel stehen jetzt an dem, was sie bedienen
Filipe, 28.09.2026: "das soll nicht ueberall sein sondern da perfekt
integriert werden."
Er hat recht: Die Legende war ein eigener Absatz am Ende der Regie --
hinter ALLEN Registern. Damit stand sie unter "Ton", unter "Spenden",
unter "Gestaltung", also an sechs Stellen, an denen keines ihrer
Kuerzel etwas tut. Eine Legende, die ueberall steht, gehoert nirgends
hin.
Und eine Legende ist ohnehin der Umweg: Sie zwingt dazu, vom Knopf zu
einer Liste zu schauen und zurueck. Steht die Taste AM Knopf, liest
man sie beim Bedienen -- und lernt sie dabei.
Leertaste unter dem runden Play-Knopf (ein Wort passt nicht
hinein, und der Knopf soll das Zeichen bleiben, das man
blind trifft)
Pfeile an -10 und +10
+ und - am Wort "Tempo"
N an "Naechstes"
T an "Wechseln"
M am Mikro-Knopf in der Senderleiste
1 bis 5 bei der Anordnung im Register "Bild"
Nichts geht verloren, jedes steht dort, wo es wirkt.
UND DIE PRUEFUNG STELLT EINE ANDERE FRAGE ALS VORHER. Sie pruefte, ob
ein Kuerzel IRGENDWO in der Legende steht. Jetzt prueft sie, ob es am
RICHTIGEN Knopf steht -- ein Kuerzel an der falschen Stelle ist
schlimmer als keins. Dazu eine Gegenprobe, dass die alte Legende
wirklich weg ist: Stuende beides da, pflegte beim naechsten Kuerzel
jemand nur eine der beiden Stellen.
Der Chat bleibt unveraendert: Er liegt in `#teil-live` und erscheint
damit nur, wenn die Sendung laeuft -- so, wie Filipe es erwartet hat.
pruef-reaktion 379/0 - pruef-css-klassen ok - pruef-tippziele 11/0
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
a6d55d939a |
Die Regie steht links neben dem Video, nicht nur unten
Filipe, 28.09.2026: "anstatt alles nur unten zu haben wieso nicht
rechts und links noch ausnutzen um mehr ueberblick zu haben."
ICH HATTE IHN ZWEIMAL FALSCH VERSTANDEN. Beim ersten Mal baute ich
zwei Spalten INNERHALB der unteren Leiste, beim zweiten Mal Kacheln
darin. Gemeint war der BILDSCHIRM: Die Regie klebte als 272 Pixel
hoher Streifen unten, waehrend darueber das ganze Bild frei war. Man
sah entweder das Video oder die Bedienung.
AUFGEKLAPPT steht sie jetzt LINKS neben dem Video, ueber die volle
Hoehe. Rechts der Chat, unten die Senderleiste und der Transport --
die Anordnung jedes Sendepults: Was man bedient, liegt neben dem, was
man dabei ansieht.
ZUGEKLAPPT bleibt alles wie vorher, eine schmale Leiste unten. Wer
die Regie zumacht, will das Bild gross; eine leere Spalte daneben
waere das Gegenteil.
WAS DAS NEBENBEI LOEST: Die Kacheln hatten unten 272 Pixel fuer sich
-- drei Felder untereinander passten nicht hinein, und die
Transportleiste verdeckte den Rest. In einer Spalte stehen rund 700
Pixel zur Verfuegung. Die Enge war nie eine Frage der Gestaltung,
sondern des Platzes.
DER TRANSPORT VERLAESST DAS REGISTER. Er lag in "Sendung" und war
damit weg, sobald jemand auf "Ton" oder "Spenden" ging. Jetzt ist er
eine eigene Zeile unter dem Saal -- und damit auch bei zugeklappter
Regie da. Der Play-Knopf ist der eine, den man mitten in einer
Sendung blind treffen muss.
`:has(.pult[data-auf="ja"])` UND KEINE KLASSE AM KOERPER: Der Zustand
steht schon am Pult; ein zweiter Merker waere die zweite Antwort auf
dieselbe Frage. Erst ab 1100 px -- darunter bleibt fuer das Video
keine Breite: 26rem Regie plus 23rem Chat sind 784 Pixel. Gerechnet,
nicht geraten.
=======================================================================
DREI BEFUNDE GEGEN DIE EIGENEN PRUEFUNGEN -- UND EINER IST ERNST
1. "GENAU EINE REGEL DARF DIE ZEILEN DES SAALS SETZEN" war die
Faustregel zum Befund vom Nachmittag, aber nicht die Frage, um
die es geht. Eine zweite FASSUNG (Handy, aufgeklappte Regie) ist
richtig und noetig -- sie setzt die Zeilen neu UND verteilt die
Kinder neu. Der Fehler war eine zweite ANGABE, die die Zeilenzahl
VERKLEINERT und die Kinder stehen laesst. Geprueft wird jetzt
genau das: Jede Fassung, deren Gegenstand der Saal IST, muss
gleich viele Zeilen haben.
2. DER ERNSTE: Dieselbe Pruefung hatte einen BLINDFLECK. Ihr Muster
liess den Regelrumpf ueber eine oeffnende Klammer hinweg laufen
(`[^}]*` statt `[^{}]*`) -- damit fiel jede Regel INNERHALB eines
`@media` heraus. Gemessen: Sie meldete "alle 1 Fassungen",
obwohl zwei dastanden. Ein Fehler im Medienblock -- und genau
dort steht die ganze Handyansicht -- waere unbemerkt
durchgegangen. Die Gegenprobe beweist jetzt, dass eine Fassung
mit weniger Zeilen wirklich auffaellt.
3. Auch beim Regieplatz zaehlte sie Fassungen statt Wirkung und
schlug an, sobald eine dritte dazukam. Jetzt prueft sie, ob eine
Fassung eine KACHEL VERGISST -- dann verschwindet die in genau
dieser Ansicht, und gemerkt haette es niemand.
pruef-reaktion 374/0 - pruef-css-klassen ok - pruef-tippziele 11/0
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
6033d1b6f2 |
Der Regieplatz sind jetzt Kacheln
Filipe, 28.09.2026, zum ersten Versuch: "ich wollte was hoch
professionelles wo rechts links und unten kacheln sind wo alles drin
ist, schoen verteilt. wieso so einen kleinen scheiss."
Er hat recht, und es steht auf seinem Bildschirmfoto:
DIE LINKE SPALTE WAR LEER. "Was laeuft" zeigte nur einen Titel --
und wenn nichts laeuft, steht dort nichts. Ein grosses schwarzes
Loch neben einer vollen Spalte sieht nicht nach Aufteilung aus,
sondern nach Fehler.
ES WAREN KEINE KACHELN. Zwei Spalten mit einer Trennlinie sind eine
Teilung, keine Gliederung. Ohne Rahmen, ohne Kopf, ohne eigenen
Grund fehlt genau das, was eine Flaeche aufgeraeumt aussehen
laesst.
DIE LEISTE WAR EIN KASTEN MIT LUFT. `1fr auto 1fr` schiebt drei
kleine Knopfgruppen an die Raender eines 1400 Pixel breiten
Kastens. Leere zwischen Knoepfen liest sich als "hier fehlt noch
etwas".
WAS JETZT DASTEHT
LINKS Eine Kachel "Was laeuft" mit VORSCHAUBILD -- damit ist sie
immer gefuellt. Ohne Video steht der Satz darin, der sagt,
was zu tun ist; ein leerer Kasten sagt nur, dass etwas
fehlt. Sie geht ueber beide Zeilen der rechten Seite,
sonst franste eine Seite unten aus.
RECHTS Zwei Kacheln: "Die Sendung" (Titel, YouTube, Beginn) und
"Bereitlegen" (zweites Video, Vorschaubild, Zuruecksetzen).
UNTEN Die Transportleiste, dichter: jede Gruppe beschriftet
("Tempo", "Weiter"), und der Umschalter ist aus der linken
Kachel hierher gewandert. Er ist ein Handgriff IM Live wie
"Naechstes" -- und fuellt die rechte Seite, die vorher leer
war.
Das Vorschaubild nimmt ein eigenes, wenn eines eingetragen ist, sonst
YouTubes. Laedt keines, tritt der Platzhaltersatz ein: Ein Bild, das
404 antwortet, steht genauso im Dokument wie eines, das laedt -- auf
dem Bildschirm ist an seiner Stelle nichts.
UND EIN FUND DER HAUSPRUEFUNG: `kachel` gibt es bereits in start.css
und module.css. Ein Namensstreit ueber Stilblaetter hinweg ist genau
die Sorte Fehler, die spaeter irgendwo ganz anders etwas verschiebt
-- und den niemand dort suchen wuerde. Heisst jetzt `regiekachel`.
pruef-reaktion 369/0 - pruef-css-klassen ok - pruef-tippziele 11/0
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
99e62eebbe |
Regieplatz, Bildschirm teilen, Zuruecksetzen und der Preis
Vier Sachen aus Filipes Ansagen vom 28.09.2026.
=======================================================================
1. DER REGIEPLATZ
"kann das nicht bissl aufgeteilt sein auf links und rechts und eine
barre unten in der mitte. kannst du das nicht hoch professionell
machen und hochwertig vom aussehen?"
Die Teilung folgt dem, was WANN gebraucht wird:
LINKS Was laeuft. Das liest man.
RECHTS Was eingetragen wird. Das tippt man VOR der Sendung.
UNTEN Der Transport. Den fasst man WAEHREND der Sendung an.
Vorher stand alles in einem Stapel, und wer im Live an den Play-Knopf
wollte, musste an den Eingabefeldern vorbeiscrollen. Der Play-Knopf
ist jetzt rund und 58 px -- der einzige, den man blind treffen muss,
und die Form unterscheidet ihn schon vor dem Hinsehen.
UND EIN FUND, DEN NUR DIE MESSUNG FAND: Nach dem Umbau lag die Leiste
bei y=986 in einem 900 Pixel hohen Fenster. Die Rechnung ging auf
(links, rechts, Leiste darunter) und das Ergebnis war trotzdem
falsch. Jetzt klebt sie (`position: sticky`) -- unten, wie gewollt,
und immer sichtbar. Ihr Grund musste dafuer dicht werden: eine
halbdurchsichtige Leiste, durch die Text scrollt, ist die Flaeche,
auf der man sich im Live verliest.
=======================================================================
2. DEN BILDSCHIRM TEILEN
"waere es nicht einfach eine bildschirm uebertragung zu installieren
und es zu perfektionieren?"
Ja -- der Weg war schon da: Die Kamerabilder laufen als
Direktverbindung von Mensch zu Mensch. Geteilt wird deshalb AN STELLE
der Kamera; `replaceTrack` tauscht die Bildspur in jeder bestehenden
Leitung aus, ohne dass eine einzige neu ausgehandelt werden muss.
Eine zweite Spur daneben waere eine zweite Verhandlung je Zuschauer,
und jede davon kann scheitern.
Vier Dinge, die sonst schiefgegangen waeren:
- Wer waehrenddessen dazukommt, bekommt den Bildschirm und nicht
das Gesicht.
- Das eigene Fenster zeigt, was die anderen sehen -- sonst waere es
die eine Anzeige, der man nicht trauen kann.
- Der Stopp-Knopf des Browsers wird gehoert; sonst bliebe die Seite
auf "teilt" stehen und sendete ein totes Bild.
- Der Kameraknopf wird grau, solange geteilt wird. Er haette keine
Wirkung mehr -- und ein Knopf, der still nichts tut, ist
schlimmer als keiner.
Ein Bildschirm wird ausserdem NICHT zugeschnitten: `cover` ist fuer
ein Gesicht richtig, bei einem Schreibtisch faellt links und rechts
genau das weg, worum es geht.
UND DIE WAHRHEIT STEHT AN DER BEDIENUNG: Netflix, Disney+ und Prime
bleiben beim Teilen schwarz (Widevine schaltet den Videobereich ab --
auf Discord und Zoom ist es genauso), und einen Film weiterzusenden
waere eine oeffentliche Wiedergabe. Wer das erst erfaehrt, nachdem im
Stream zehn Minuten ein schwarzes Rechteck stand, erfaehrt es zu
spaet.
=======================================================================
3. ALLES ZURUECKSETZEN
"brauch ich auch noch einen button wo ich alles easy zuruecksetzen
kann."
"Alles" heisst: der Schreibtisch, nicht das Gedaechtnis. Geleert
werden Titel, Video, zweites Video, Vorschaubild, Beginn,
Warteschlange, Gaesteliste; Anordnung, Kameragroesse, Ecke, Tempo und
Chatmodus gehen auf Vorgabe.
NICHT ANGETASTET werden Spenden, die Dogen der Leute, der Chatverlauf
und die Massnahmen der Moderation. Eine bezahlte Spende aus den
Buechern zu nehmen waere eine Faelschung; eine stillschweigend
aufgehobene Sperre waere eine Entscheidung, die niemand getroffen
hat. Beides steht nebeneinander im Dialog, BEVOR etwas passiert -- ein
"Bist du sicher?" ohne diese Liste ist keine Frage, sondern eine
Huerde.
Im Live ist der Knopf grau und sagt warum. Und die Spalten stehen
einzeln da statt als "alles ausser": Eine Ausnahmeliste waechst still
mit jeder neuen Spalte mit, und dann loescht das Zuruecksetzen
irgendwann etwas, das es nie loeschen sollte.
=======================================================================
4. DER PREIS BEI DEN DOGEN
"da muss ich auch sehen so viel dogen sind so viel euro. damit ich
auch immer weiss was es ist. aber nur ich. die leute sollen nur sehen
was dogen kosten."
Das ist keine Ruecknahme von "nie Geld", sondern ihre Grenze. Die
Regel war richtig fuer alles, was ANZEIGE ist -- Karte, Stream, Chat,
Punktestand -- und falsch fuer die eine Stelle, an der jemand KAUFT.
GENAU ZWEI AUSNAHMEN, und die Pruefung nennt sie beim Namen statt die
Regel aufzuweichen:
knoepfe[].cent fuer alle -- der Preis am Kaufknopf
kurs_cent_je_doge nur fuer die Leitung
DIE ERLAUBNIS STECKT IN DEN DATEN UND NICHT IN EINEM `if`. Ein
Zuschauer hat den Kurs nicht und kann deshalb GAR KEINEN Preis
ausrechnen -- auch nicht, wenn eine spaetere Zeile es versuchte. Eine
Abfrage "darf der das sehen?" in der Oberflaeche waere eine Regel, die
man vergessen kann; eine fehlende Zahl ist eine, die man nicht
vergessen kann.
Eine Zahl statt dreissig Einzelumrechnungen: Wer je Zeile einen Cent
mitschickt, hat dreissig Gelegenheiten, eine zu vergessen.
=======================================================================
FUENF BEFUNDE GEGEN DIE EIGENEN PRUEFUNGEN
1. Eine Pruefung fragte "liegt die Leiste unter beiden Spalten?" --
das tut eine klebende Leiste beim Hochscrollen absichtlich nicht.
Sie stellte die Frage von vorher. Jetzt zaehlt die Reihenfolge im
Dokument, die beim Scrollen wie beim Stillstand gilt.
2. Eine Messung klickte auf einen Namen und wartete 400 ms auf die
UHR -- und verschluckte den Klickfehler still. Derselbe Lauf war
dreimal gruen und beim vierten rot, ohne Codeaenderung. Jetzt wird
auf das Merkmal gewartet, bis zu dreimal, und die Zahl der
Anlaeufe steht im Protokoll.
3. Eine Pruefung loeschte erst selbst den Chat (eine Sendung zu
beenden tut das mit Absicht) und fragte dann, ob er noch da ist.
4. "Die Dogen sind unberuehrt (0 Staende)" -- null bleibt auch dann
null, wenn das Zuruecksetzen sie mitnaehme. Jetzt steht vorher
eine echte Spende da, und die Zahl gehoert in die BEDINGUNG.
5. `knopf-still--haupt` stand seit Wochen im HTML und war in KEINEM
Stilblatt definiert -- eine Klasse, die aussieht, als sei etwas
hervorgehoben, und auf dem Bildschirm ist es das nicht. Gefunden
beim Nachsehen, ob es sie gibt, bevor ich sie ein zweites Mal
benutze.
Und eine neue Pruefung, die es vorher nicht gab: ALLE 118 Kennungen,
die das Programm mit `$('...')` anspricht, werden gegen das HTML
gehalten. Nach einem Umbau, der die halbe Tafel neu sortiert, waere
eine verlorene Kennung KEIN Fehler beim Laden -- `$()` gibt still
`null` zurueck, und der Fehler erscheint erst, wenn jemand mitten in
der Sendung den Knopf drueckt.
pruef-reaktion 365/0 (vorher 321) - pruef-spenden 172/0 (vorher 167) -
pruef-buehne 36/0 - pruef-css-klassen ok - pruef-tippziele 11/0 -
mess-reaktion und mess-buehne ohne Beanstandung
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
96bdd79a91 |
Die Dogen-Muenzen: drei Saetze zu je drei Stufen
Filipe, 28.09.2026: "ich werde die drei varianten schicken fuer niedrige spenden. mittlere und hohe spenden. alle drei varianten will ich drauf so dass ich sie aussuchen kann wie ich will. aber pass sie sofort diesen 3 kategorien an." DIE ZUORDNUNG IST GELESEN, NICHT GERATEN In allen drei Saetzen geht es nacktes Metall -> Steinkranz -> Vollbesatz; Filipes Dateinummern (01/02/03) und die Uhrzeiten seiner Entwuerfe laufen genau mit. Klassik: Palladium, Gold mit Saphir, Diamant. Amethyst: Stahl, Rosegold, Vollbesatz. Neon: Chrom auf Schwarz, Steinkranz, Vollbesatz. AUS 25 MB WURDEN 443 KB Je Bild 320 px WebP statt 1254 px PNG, Faktor 58. Die Zahl ist gemessen: Groesster Fall in der Seite 110 px (Karte, hoechste Stufe), auf der OBS-Tafel 189 px, bei doppelter Bildschirmdichte rund 220. Drei Megabyte fuer ein 24-Pixel-Zeichen waeren ein Ladebalken mitten in der Sendung -- wer auf dem Handy zusieht, bekaeme die Karte, wenn sie schon wieder weg ist. Die Originale liegen neben den Datenbanksicherungen, nicht im Repo: 26 MB, die bei jedem Klon mitkaemen und die niemand ausliefert. WELCHE MUENZE WANN -- ABGELEITET STATT GEPFLEGT "Niedrig, mittel, hoch" gibt es im Haus schon: die Stufenleiter. Zwei eigene Grenzen daneben waeren eine zweite Antwort auf dieselbe Frage, und spaetestens beim Verschieben einer Stufe zeigte die Muenze etwas anderes an als der Name auf der Karte. Die Leiter wird deshalb in DRITTEL geteilt -- bei den drei Werksstufen genau eine je Muenze, bei sechs zwei je Muenze, bei einer einzigen ueberall die mittlere. DIE MUENZE STEHT AUCH GROSS AUF DER KARTE Sonst haette Filipe neun Bilder fuer ein 24-Pixel-Zeichen gezeichnet. "dogen" ist dafuer eine neue Vorlage neben Herz, Welle und Krone -- und die drei Werksstufen bekommen sie EINMAL zugeteilt, nur wo noch die Werksvorlage steht und kein eigenes Bild hochgeladen ist. Wer danach ein Herz zurueckstellt, findet es morgen nicht wieder als Muenze vor: Eine Einstellung, die sich gegen den Benutzer durchsetzt, wird abgeschafft. Und steht sie gross da, nimmt das Stilblatt die kleine neben der Zahl weg -- dieselbe Muenze in zwei Groessen auf einer Karte sieht aus wie ein Versehen. AM BILDSCHIRMFOTO NACHGEBESSERT Bei 0,92em blieb an den Spendenknoepfen ein 13,5-Pixel-Fleck uebrig; bei einem flachen Symbol reicht das, bei einer Muenze mit Pfote, Schriftzug und Steinen nicht. Jetzt 1,05em ueberall und 1,6em auf den Knoepfen. In der Auswahl sahen "Amethyst" und "Neon" bei 40 px praktisch gleich aus -- und genau sie auseinanderzuhalten ist der Zweck dieser Liste. Jetzt 56/64/72 px. Und was gewaehlt ist, steht als WORT da: Neben neun glaenzenden Muenzen geht ein ruhiger Rahmen unter, und wer Farben schlecht unterscheidet, sieht ihn gar nicht. EIN SATZWECHSEL ERREICHT ALLE Die Karten trugen ihren Satz immer selbst mit und waren richtig. Die Muenzen an den Spendenknoepfen und beim eigenen Stand aber nicht -- die holt eine Seite nur bei einer Spende neu. Eine Einstellung, die nur dort ankommt, wo sie gemacht wurde, ist keine Einstellung des Hauses. ZWEI BEFUNDE GEGEN DIE PRUEFUNG SELBST 1. Sie verlangte "erste Grenze ECHT kleiner als zweite". Bei genau zwei Stufen fallen beide absichtlich zusammen -- sie meldete einen Fehler, wo das Verhalten richtig ist. 2. Sie prueft die Muenzverteilung jetzt auf einer FRISCHEN Datenbank. Vorher lief sie auf der, die ein frueherer Abschnitt umgebaut hatte: Eine Pruefung, die den eigenen Kollateralschaden misst, misst sich selbst. Dazu eine Gegenprobe, dass eine selbst gewaehlte Vorlage NICHT ueberschrieben wird. UND DREI AN DER MESSUNG Sie suchte noch die gezeichnete Muenze (svg), wo jetzt ein Bild liegt. Umgestellt nicht auf "ist ein img da", sondern auf `naturalWidth > 0` -- ob es etwas ZEIGT. Ein img, das 404 antwortet, steht genauso im Dokument wie eines, das laedt; auf dem Bildschirm ist an seiner Stelle nichts. Und beim Satzwechsel las sie die vorige Karte, die noch acht Sekunden stand: Die Karten laufen in einer Schlange, also wird auf das Merkmal gewartet, das nur die neue hat. pruef-spenden 167/0 (vorher 136) - pruef-reaktion 321/0 - pruef-css-klassen ok - pruef-tippziele 11/0 - mess-reaktion und mess-buehne ohne Beanstandung Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
c00c209ac9 |
Dogen statt Geld -- und die Texte schreiben die Leute selbst
Filipe, 28.09.2026:
"der text der dazu erscheint sollen die leute selber schreiben
koennen. soll auf nicht zu viel aber auch nicht zu wenig
schreiben koennen. aber es sollen personalisierte texte sein von
den leuten selbst."
"mann soll nie die summe sehen sondern die dogen auch mit dem
symbol ... es soll auch nie geld da stehen sondern Dogen."
"ich will dass die den leuten auch als punkte hinzugefuegt werden."
DER TEXT KOMMT VON DEM, DER GIBT
Bisher konnte ihn nur die Leitung tippen; beim Melden schickte der
Zuschauer gar nichts mit. Jetzt stehen nach dem Tippen auf einen
Betrag zwei Felder da: Name auf der Karte (mit dem eigenen Namen
vorausgefuellt) und der eigene Text, bis 140 Zeichen.
140 ist gemessen, nicht geraten: Die Karte steht je nach Stufe sechs
bis elf Sekunden. Bei 140 Zeichen sind das zwei bis drei Zeilen -- die
fasst man im Vorbeischauen. Bei 200 wird die Schrift auf einer kleinen
Karte so eng, dass niemand mehr hinsieht, und ein Gruss, den keiner
liest, ist schlechter als ein kurzer. Der Zaehler erscheint erst ab
30 uebrigen Zeichen; einer, der von Anfang an mitlaeuft, macht aus
einem Gruss eine Aufgabe.
UND EINE SCHRANKE DAVOR. Der Text kommt von einem Fremden und steht
gleich im Livestream. Er laeuft ohnehin durch die Bestaetigung -- neu
ist, dass die Leitung ihn dort AENDERN kann. Ohne das bliebe nur "ganz
ablehnen", und dann faellt wegen eines Wortes eine echte Spende unter
den Tisch.
NIE WIEDER GELD AUF DEM BILDSCHIRM
Ein Doge sind zehn Euro (Filipes Angabe "1 euro sind 0,10 dogen",
rueckgefragt und bestaetigt -- zwischen den beiden Lesarten liegt der
Faktor 100). Gerechnet wird in Tausendsteln, nie in Kommazahlen.
Das Entscheidende ist nicht die Beschriftung: DER BROWSER BEKOMMT
KEINEN EURO-BETRAG MEHR, auch nicht verborgen im JSON. Der Kurs steht
einmal auf dem Server. Was nicht gesendet wird, kann an keiner Stelle
versehentlich erscheinen, und niemand muss daran denken. Gemessen:
38 Felder im Stand, kein Geldfeld, kein Eurozeichen, auch nicht auf
der Buehnentafel. Der einzige Ort, an dem noch ein Euro entsteht, ist
die PayPal-Adresse -- weil PayPal ihn braucht.
DIE PUNKTE: EIN BUCH, KEIN ZAEHLER
Ein Feld `dogen` an der Person waere kuerzer gewesen -- und die zweite
Antwort auf dieselbe Frage. Der Stand IST die Summe der Buchungen, und
eine Summe kann sich nicht von ihren Posten entfernen. Weil Filipe
spaeter etwas daran haengen will ("spezielle sachen ... wo mit diesen
dogpunkten zu tun hat"), steht neben jeder Zeile ein Grund und ein
Datum: Ein Zaehler, der kleiner wird, laesst keine Frage mehr
beantworten.
Dass nie doppelt gutgeschrieben wird, entscheidet ein eindeutiger
Index in der Datenbank und keine Bedingung im Programm -- "nochmal
zeigen" und ein wiederholter Strom koennen es damit gar nicht
ausloesen.
Ohne Person keine Punkte: Eine von Hand eingetragene Spende hat oft
nur einen Vornamen auf dem Handy. Daraus eine Person zu RATEN waere
schlimmer als keine Gutschrift -- deshalb waehlt die Leitung sie aus,
und tut sie es nicht, laeuft die Karte trotzdem.
DAS SYMBOL IST VORBEREITET
Filipe: "die symbole schick ich dir spaeter." Es wird im Regiepult
hochgeladen, ohne Deploy -- bis dahin steht eine gezeichnete Muenze
da. Es liegt bei den Stufenbildern, weil das der einzige Weg ist, der
Bilder OHNE Anmeldung ausliefert; sonst fehlte es ausgerechnet im
Stream.
=======================================================================
UND EINE REPARATUR AN DEM, WAS HEUTE MITTAG LIVE GING
Seit
|
||
|
DogFatherGitandClaude Opus 5
|
3fedeea716 |
Kamerafenster: Groesse und Ecke lassen sich stellen
Filipe: "und danach perfektionierst du auch die verschiedenen groessen von kamera und so, perfektionier das alles bitte." Sechs Groessen (0,6x bis 2x) und vier Ecken, beide an der SENDUNG und nicht am Browser: Was Filipe einstellt, sehen alle. Waere es eine Einstellung je Geraet, redete er ueber ein Bild, das bei den Zusehenden anders aussieht -- und im Stream stuende ein drittes. Anordnung, Groesse und Ecke gehen jetzt EINEN Weg (/layout), weil sie zusammen eine einzige Frage beantworten: Wie sieht das Bild aus? Drei getrennte Aufrufe waeren drei Rundrufe, und dazwischen saehen die Zusehenden eine Mischung -- neue Anordnung, alte Ecke. Eine falsche Angabe laesst auch das Gute stehen, statt halb umzustellen. Die Ecke gibt es, weil unten rechts bei TikTok die Knopfreihe liegt, bei YouTube die Fortschrittsleiste, und Untertitel fast immer unten stehen. Eine feste Ecke ist eine, die bei jeder zweiten Plattform im Weg ist. Die OBS-Videoquelle kennt jetzt die Anordnung und blendet sich bei "Nur Kamera" aus -- sonst laege im Stream ein stehengebliebenes YouTube-Bild unter den Kameras, und Filipe saehe es nicht, weil er auf seine Szene schaut und nicht auf die Quelle. VIER BEFUNDE, ALLE VON DEN PRUEFUNGEN UND KEINER VOM AUGE: 1. Die Knoepfe fuer Groesse und Ecke gab es gar nicht. HTML und Stilblatt waren da, das Programm nicht. Gemessen: "0 von 0 Eckknoepfen gesperrt", und der Hinweistext stand noch wortgleich wie im HTML -- zwei leere Kaesten, die aussahen, als sei alles in Ordnung. 2. Bei "Nur Kamera" war der Stapel 493 px breit statt 1072. Der neue Deckel max-width: 46% -- richtig gegen ein zu grosses Fenster bei "Video gross" -- galt still auch dort, wo die Kameras die ganze Flaeche fuellen sollen. 3. Am Handy haette die Groesseneinstellung ueberhaupt nichts bewirkt: Dort stand weiterhin width: clamp(88px, 26vw, 140px) am Fenster selbst. Das ist die dritte Wiederholung derselben Sache an einem Tag (die Saalzeilen, die Tafeln, jetzt die Kamerabreite): Zwei Regeln fuer dieselbe Frage sind die Garantie, dass eine davon irgendwo falsch gewinnt. Breite und Rand gehen jetzt ueber --kam-grund/--kam-rand, --kam wird an genau EINER Stelle gerechnet, und eine Pruefung zaehlt das nach. 4. Die Pruefung schlug auf ihren EIGENEN Kommentar an, der die entfernte Zeile zitiert. Ein Werkzeug, das bei jedem Lauf meckert, wird nach dem zweiten Mal weggeklickt -- samt dem echten Befund darin. Gezaehlt werden jetzt Regeln, nicht Prosa. Gemessen beim Zuschauer und nicht in der Datenbank: 1x -> 208 px, 2x -> 416 px, alle Fenster innerhalb der Leinwand, und jede der vier Ecken am Abstand zu den Kanten nachgewiesen statt an ihrem eigenen Namen. Ein Knopf, der gerade nichts bewirken kann, ist grau, und der Satz darunter sagt warum. pruef-reaktion 320/0 - pruef-buehne 36/0 - pruef-css-klassen ok - pruef-tippziele 11/0 - mess-reaktion ohne Beanstandung Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
2b02d88767 |
Die Regieleiste steht jetzt über dem Saal
Filipe: „ich hätte das gerne oben also nicht in dieser kachel sondern über der kachel wo die videos laufen werden und das soll extrem perfektioniert werden." WARUM DAS MEHR IST ALS EIN UMHÄNGEN Die Register standen INNERHALB des einklappbaren Teils. Wer die Regie zuklappte, um mehr Bild zu haben, hatte sie nicht mehr — und genau dann braucht man sie. Oben ändert sich ihre Aufgabe: aus dem Inhaltsverzeichnis einer Schublade wird eine Steuerleiste über der Sendung. Daraus folgen vier Dinge, die vorher nicht nötig waren: 1. EIN REGISTER MACHT DIE ZUGEKLAPPTE REGIE AUF. Vorher wechselte nur der Reiter, die Tafel lag im zugeklappten Teil — sichtbar passierte nichts. Nur auf, nie zu: Zugemacht wird mit dem Griff. Ein Knopf, der beim zweiten Druck das Gegenteil tut, versteckt irgendwann etwas, das jemand gerade liest. 2. SIE BRICHT NICHT UM, SIE ROLLT. Sieben Register in zwei Zeilen kosten am oberen Rand rund 90 px — und zwar dem Video. Gemessen: eine Zeile auf 1440 px wie auf 390 px, dort mit Einrasten und weichen Rändern als Auskunft, dass es weitergeht. 3. SIE LÖST EIN, WAS `role="tablist"` VERSPRICHT. Pfeiltasten wandern, Pos1/Ende springen, genau ein Register liegt in der Tabulatorfolge. Steht die Rolle im Markup und tut das Programm es nicht, sagt ein Vorleser etwas an, was nicht stimmt — schlimmer als keine Rolle. Gemessen wird das gedrückt, nicht gelesen: fünf Tastendrücke, und Fokus, Auswahl und offene Tafel müssen jedes Mal dasselbe sagen. 4. EINE GLEITENDE MARKE zeigt, wo man steht — Glas mit Lichtkante, darunter ein roter Streifen zur offenen Tafel. Ist die Regie zugeklappt, wird er leise: Der Streifen führt dann nirgendwohin. Dazu ein Schild „Regie" links (am Handy weg), damit die sieben Wörter am oberen Rand nicht wie eine zweite Navigation aussehen. DER FEHLER, DER MICH ZWEI ANLÄUFE GEKOSTET HAT Die Leiste war im Browser 1 px hoch, ihre Register standen 55 px hoch daneben und ragten über das Video. Ursache: 900 Zeilen weiter unten stand eine ZWEITE `grid-template-rows` für `.saal` (aus der Zeit, als der Saal zwei Zeilen hatte). Sie stand später und gewann — die Leiste landete in der `1fr`-Zeile und bekam null Pixel. Und fast hätte ich das Falsche repariert: Beim Durchprobieren habe ich `style.gridTemplateRows` gesetzt — ein Stilattribut schlägt jede Regel im Stilblatt. Damit „funktionierten" `auto` und `min-content` gleich gut, weil beide die zweite Regel aushebelten, und es sah nach einem Unterschied zwischen den beiden aus. Erst nach dem Entfernen der Doppelung hat die Gegenprobe gezeigt: `auto` tut es genauso. Eine Probe, die mehr ändert als das, wonach man sucht, beantwortet eine andere Frage. Es gibt jetzt eine Prüfung, dass genau EINE Regel die Zeilen des Saals bestimmt. ZWEI WEITERE FUNDE AUS DER MESSUNG Am Handy blieben bei offener Regie 131 px für das Bild — ein Streifen. Mein erster Versuch (62dvh → 52dvh) machte es auf 75 px SCHLECHTER: Die Ursache lag woanders, die Leiste des Pults bricht dort in vier Zeilen um und ist rund 200 px hoch, wovon ein Anteil der Fensterhöhe nichts wissen kann. Mit `min(52dvh, 19rem)` sind es 210 px. Und die Spendenkarte wurde als „steht aus dem Bild heraus" gemeldet: 413 statt 430 px, links −1. 413 ist genau das 0,96-fache — die Messung hatte die Karte im Ausblenden erwischt. Sie wartet jetzt auf `data-da="ja"` und misst nur, was ganz da ist. GEPRUEFT pruef-reaktion 280 (vorher 260), 0 Fehler — Abschnitt 18 neu. mess-reaktion: Rückgabewert 0, kein ACHTUNG; misst die Leiste jetzt auf 1440 und auf 390 px, samt Tastatur und Aufklappen. Dazu grün: handy, buehne, struktur, css-klassen, tippziele. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
d2f02ba84e |
Spenden: Stufen gestaltbar, Bild hochladen, Größe je Stufe
Filipes Wunsch: „mach paar fertige und so dass ich auch hochladen
kann. auch so dass ich das anders gestalten kann oder die größe
verändern kann. ... auch spezielle sachen bei speziellen spenden."
WAS ES SCHON GAB, WAS FEHLTE
Drei Stufen ab Werk, fünf gezeichnete Zeichen, Farbe und Dauer je
Stufe — und sogar schon ein Feld für ein eigenes Bild. Es fehlte der
Weg, das alles zu ÄNDERN: Um eine Stufe umzubenennen, hätte jemand in
die Datenbank greifen müssen.
DIE GRÖSSE IST DAS „SPEZIELLE BEI SPEZIELLEN SPENDEN"
Je Stufe, nicht einmal für alle: Eine Rudel-Legende darf größer
dastehen als ein Danke. Eine einzige Größe für alle wäre wieder eine
Preisliste. Umgesetzt als EINE Schriftgröße, alles darin in `em` —
nicht `transform: scale()`, denn die Karte kommt schon mit
`translateX()` herein, und zwei `transform` an derselben Stelle
schließen einander aus; außerdem wird Text beim Skalieren matschig.
Nur nach oben (1 bis 2,5), und das ist eine ehrliche Grenze: Das
kleinste Wort auf der Karte steht bei 11,52 px, die Hausgrenze ist
11,5. Ein Faktor von 0,8 machte daraus 9,2 px. Kleiner geht an der
richtigen Stelle — die OBS-Tafel hat ihren eigenen Regler in der
Adresse, dort ist es eine Videoeinblendung und kein Text zum Lesen.
AUSPROBIEREN, OHNE EINE SPENDE ANZULEGEN
Der naheliegende Weg wäre gewesen: eine Spende eintragen und danach
löschen. Das ist verboten — in ein laufendes System kommen keine
Testdaten, und „gelöscht" heißt bei Geld nicht „war nie da". Die
Probe schreibt deshalb NICHTS und geht nur an den, der drückt; eine
Probe im ganzen Saal wäre eine Spende, die es nicht gab.
DREI FEHLER, DIE DIE PRÜFUNG GEFUNDEN HAT
1. `protokolliere()` wurde an 17 Stellen falsch herum gerufen —
`(personId, aktion, detail, ip)` statt `(aktion, {…})`. JavaScript
beschwert sich nicht: Das zweite Argument war ein Text, und einen
Text zu zerlegen ergibt lauter `undefined`. Auf dem echten Server
nachgemessen: 39 Protokollzeilen mit Aktionen wie „16.0", alle
ohne Person, ohne Detail, ohne IP. Betroffen waren Material,
Hilfe, Bühne, Reaction und Spenden — also jede Änderung an
Dogi-Media und jede Maßnahme im Live-Chat, ausgerechnet das,
wofür es ein Protokoll gibt. Alle 17 berichtigt, und
pruef-struktur wacht jetzt darüber (mit Gegenprobe).
2. Beim Speichern der Leiter bekam jede Stufe eine NEUE Kennung
(DELETE + INSERT). Ein Bild-Hochladen gegen die eben noch gültige
Kennung antwortete mit 404 — im Alltag trifft das jeden, der einen
zweiten Bildschirm offen hat. Jetzt werden vorhandene Zeilen
geändert statt ersetzt; das Bild bleibt von selbst daran hängen.
3. `ab_cent` ist eindeutig. Zwei Stufen ihre Beträge tauschen zu
lassen scheiterte mit „UNIQUE constraint failed", obwohl das
Ergebnis in Ordnung gewesen wäre: Beim Umschreiben stößt die
Leiter auf sich selbst. Jetzt in drei Schritten — löschen,
geparkte Zwischenwerte, endgültige Werte —, und das ist nach
außen nie sichtbar.
UND DREI, DIE IN MEINER MESSUNG STECKTEN
Die Messung hat eine noch laufende Karte aus dem vorigen Abschnitt
erwischt und daraus drei Fehler gemeldet, die keine waren —
darunter „die Probe läuft im ganzen Saal". Sie zählte außerdem die
versteckten Dateifelder als zu kleine Tippziele. Jetzt räumt sie
vorher auf, wartet auf die Karte MIT DER ERWARTETEN GRÖSSE (die
Karten laufen in einer Schlange — einen Knoten zu entfernen beendet
sie nicht) und lässt die Einblendung zur Ruhe kommen, bevor sie misst.
Ein Bildschirmfoto aus der Einblendphase sah aus, als stünde die
Karte links heraus; nachgemessen: links 18 px, ganz im Bild.
GEMESSEN, NICHT ANGENOMMEN
Karte bei Größe 1: Schrift 16 px, Betrag 25,92 px. Bei Größe 2:
32 px und 51,84 px — Faktor exakt 2,00. Hätte eine einzige Regel noch
in `rem` gestanden, wäre die Karte ungleichmäßig gewachsen, und auf
einem Bild sieht beides nur „größer" aus.
AUCH DAS BILD IST GEPRÜFT
Es liegt am Bühnen-Router und nicht am Spenden-Router: Die
Spendentafel in OBS hat keine Anmeldung, und ein 401 als JSON in
einem `<img>` ergibt ein kaputtes Bild ohne jeden Hinweis. Ohne
Schlüssel, aber mit 128 Bit zufälligem Dateinamen — dieselbe
Größenordnung wie der Bühnenschlüssel, und es ist ein Zierbild, das
ohnehin im Stream steht. Kein Ausbruch aus dem Ordner (vier Wege
geprüft, gemessen wird die Wirkung und nicht der Statuscode).
NACHGETRAGEN AUS BLOCK 4
`reaktion_meldungen` fehlte im Löschkonzept — eine bestehende Prüfung
hat es gefunden. 30 Tage nach dem Erledigen; meistens sind sie
ohnehin früher weg, weil der Live-Chat beim Beenden gelöscht wird und
die Meldungen daran hängen. Wer meldet, muss sich darauf verlassen
können, dass daraus keine dauerhafte Liste wird.
GEPRUEFT
pruef-spenden: 95 Prüfungen (vorher 46), 0 Fehler.
pruef-reaktion 260, pruef-buehne 36, pruef-aufbewahrung 45,
pruef-struktur, pruef-meldungen, pruef-css-klassen, pruef-tippziele,
pruef-deutsche-texte, pruef-auskunft alle grün.
mess-reaktion und mess-buehne: Rückgabewert 0, kein ACHTUNG.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
74c74a08ab |
Reaction: Geschwindigkeit, zwei neue Anordnungen, zweites Video
Filipes Wunsch: „auch bei den videos sachen wie pause geschwindigkeit. meine kamera größer machen video kleiner. nur mein bild, nur das video, möglichkeit zwischen allem zu wechseln so wie ich will, auch gerne so dass ich vielleicht noch ein zweites nebenbei vorbereiten kann so dass ich hin und her switchen kann." GESCHWINDIGKEIT Sechs Stufen von 0,5× bis 2× (0,25× fehlt mit Absicht — bei einem Viertel klingt Sprache wie ein defektes Band). Sie gilt für ALLE: Wer sie nur bei sich umstellte, redete über eine Stelle, die die anderen noch nicht gesehen haben. Die OBS-Bühne zieht sie mit nach — ohne das liefe der Stream nach fünf Minuten auf 1,5× zweieinhalb Minuten hinter dem Saal her. Und der Zuschauer SIEHT sie: ein kleines Schild „1,5× Geschwindigkeit" auf der Leinwand, nur wenn es nicht 1× ist. Ohne das hält jeder Zweite seine Leitung für kaputt. Zwei Fallen, die dabei zugemacht wurden: Der Fünf-Sekunden-Takt des Hosts schreibt das Tempo NICHT mit (sonst drehte ein Takt mit altem Wert die Einstellung zurück), und nach jedem Videowechsel wird es neu gesetzt (YouTube stellt beim Laden auf 1 zurück). Gesetzt wird nur, was `getAvailablePlaybackRates()` hergibt — einen unmöglichen Wert ignoriert der Player schweigend, und dann stünde der Knopf auf 1,5 und es liefe 1,0. ZWEI ANORDNUNGEN MEHR „Nur Video" und „Nur Kamera" sind kein weiteres Größenverhältnis, sondern ein Weglassen — und genau das braucht OBS: Dort liegt die Kamera ohnehin als eigene Quelle, die Bühnenseite soll sie nicht doppelt zeigen. `display: none` und nicht `opacity: 0`: ein unsichtbarer YouTube-Rahmen spielt weiter und hält den Ton. Tasten 1–5, wie vorher 1–3. DAS ZWEITE VIDEO — und warum es nicht die Warteschlange ist Die Schlange ist eine Reihenfolge: eins nach dem anderen, das Gespielte ist weg. Filipe will etwas anderes — zwei Videos NEBENEINANDER, hin und her, und jedes merkt sich seine Stelle. Mit der Schlange nachgebaut wäre es eine Schlange, aus der man nie wieder herauskommt. Der Umschalter steht nur da, wenn es etwas zum Umschalten GIBT; ein Knopf, der „kein zweites Video" antwortet, ist im Live eine Falle. Getauscht wird in EINEM Schreibvorgang (BEGIN IMMEDIATE) — ein Abbruch dazwischen hätte dasselbe Video auf beiden Seiten und die gemerkte Stelle des anderen verloren. Und die Stelle kommt vom Host und nicht aus der Datenbank: dort steht der Stand vom letzten Takt, bis zu fünf Sekunden alt. Was daneben bereitliegt, sieht nur, wer sendet — es ist die Rückhand, und die verrät man nicht vorher (`zweit` ist aus `oeffentlich()` ausgenommen). DER FEHLER, DEN DIE MESSUNG GEFUNDEN HAT Bei „Nur Kamera" war der Kamerabehälter 2175 px breit in einer 1072 px breiten Leinwand — von zwei Gästen stand nur einer im Bild, der zweite lag hinter `overflow: hidden`. Auf dem Bildschirmfoto sah das aus wie eine Anordnung für einen, und niemand hätte gefragt, wo der zweite geblieben ist. Zwei Ursachen: Die Leinwand ist ein Raster mit einer Spalte nach Inhaltsbreite — ein zu breites Kind im Fluss zieht die Spalte mit, und `width: 100%` bezog sich danach auf die gewachsene Spalte. Die Begrenzung wuchs also mit dem, was sie begrenzen sollte; `max-width: calc(50% - 8px)` rechnete gegen denselben Wert und war wirkungslos. Jetzt `position: absolute; inset: 0` (kann das Raster nicht mehr aufziehen) und `flex: 1 1 0; min-width: 0` an den Fenstern — eine Regel, die nicht rechnet, kann sich nicht verrechnen. Die Messung prüft seitdem bei JEDER Anordnung, ob alle Kamerafenster innerhalb der Leinwand liegen. GEMESSEN, NICHT ANGENOMMEN Dass in der Datenbank 1.5 steht, sagt nichts darüber, ob das Video schneller läuft. Die Messung liest deshalb die Uhr der Regie zweimal ab und rechnet nach: 1× → 1,00 Sekunden je Sekunde, 2× → 2,00. Der Umschalter ebenso: hin, zurück, und die Uhr steht wieder bei 79 s statt bei 0. GEPRUEFT pruef-reaktion: 260 Prüfungen (vorher 216), 0 Fehler. pruef-buehne 36, pruef-struktur, pruef-meldungen, pruef-tippziele, pruef-css-klassen alle grün. mess-reaktion: Rückgabewert 0, kein einziges ACHTUNG. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
a02cf5c026 |
Reaction: Rollen sichtbar, Moderation im Live-Chat
Filipes Wunsch: „die modis, linke hand und rechte hand soll im chat extra aussehen und auch sachen wie stummschaltungen, sperrungen, meldunge und alles mögliche im chat machen können falls sich jemand nicht benimmt." WER SPRICHT Jeder Beitrag aus dem Team trägt jetzt ein Abzeichen: „Dogi", „Team" (beide Hände) und „Modi". Ein WORT und nicht nur eine Farbe — rund acht Prozent der Männer unterscheiden Rot und Grün schlecht, und hier hängt an der Unterscheidung etwas. Gedeckte Töne auf schwacher Fläche, 11,52 px (die Hausgrenze ist 11,5), weil daneben ein Video läuft. Die Wörter sagen den RANG nicht: Filipe steht nie über seinem Team. Eine Prüfung schlägt an, wenn dort „Chef", „Boss" oder „Leitung" stünde. WAS DIE MODERATION KANN Am Namen öffnet sich ein Menü mit vier Wegen: Beitrag wegnehmen, 10 Minuten stumm, aus der Sendung — und der Verweis in den Treff, wo längere Maßnahmen hingehören (mit Begründungspflicht und Frist in Tagen). Die Reaction baut kein zweites Sperrsystem daneben: Wer im Treff eine Pause hat, schreibt hier auch nicht. Neu ist nur, was der Treff nicht hat — MINUTEN. Höchstens eine Stunde; wer länger etwas braucht, nimmt den Treff. Nicht gegen das Team: Wer einen Modi stummschalten könnte, hätte einen Weg, die Moderation selbst auszuschalten, mitten in der Sendung. MELDEN DARF JEDER Die Moderation sieht nicht alles, wer mitliest schon. Zweimal melden zählt einmal (sonst füllt einer allein die Liste). Bei der Moderation erscheint im Kopf der Schiene „1 Meldung" — nur wenn etwas offen ist; eine Zahl, die immer dasteht und meistens null ist, wird nach drei Tagen nicht mehr gelesen. VIER FEHLER, DIE DABEI AUFGEFALLEN SIND 1. `oeffentlich()` nahm `meldungen` und `massnahmen` NICHT aus dem Rundruf. Der Rundruf wird aus dem Stand dessen gebaut, der gerade etwas getan hat — bei einer Moderationshandlung wären der gemeldete Text, der Name des Gemeldeten und der Name des MELDERS an jeden im Saal gegangen. Wer meldet, muss sich darauf verlassen können, dass das niemand sieht. 2. `meldung.js` hatte zwei Schlüssel doppelt: `geschlossen` und `nur_leitung`. Der spätere gewinnt stillschweigend — in der Hilfe stand dadurch „Der Saal ist zu". Ein Wort, ein Satz; eine Prüfung hält das jetzt fest. 3. Wer stummgeschaltet war, bekam bei OFFENEM Chat „Der Chat ist gerade zu" — der Aufrufer reimte sich den Grund aus der Chat-Stufe zusammen. Jetzt gibt `schreibGrund()` den echten Grund zurück. 4. Wer rausgenommen wurde, merkte nichts: Das Video lief weiter, nur die Anwesenheitsmeldung schlug still fehl. Jetzt hält alles an und es steht ein Satz da, der sagt, dass es nur für heute gilt. UND EINER, DEN NUR DAS BILDSCHIRMFOTO GEFUNDEN HAT Das Menü lag messbar komplett im Fenster (x=1099..1315 von 1440, y=652..840 von 900) und war trotzdem abgeschnitten: Die Chatliste rollt, und ein rollender Vorfahre beschneidet sein Kind. „Im Fenster" und „sichtbar" sind zwei verschiedene Fragen, und ich hatte die falsche gemessen. Das Menü hängt jetzt fest am Fenster und klappt nach oben oder links, wo kein Platz ist. Die Messung fasst seitdem mit `elementFromPoint` an jeden Knopf an, statt Rechtecke zu vergleichen. GEPRUEFT pruef-reaktion: 216 Prüfungen (vorher 156), 0 Fehler — zwei neue Abschnitte. mess-reaktion misst die Moderation jetzt im echten Browser: Abzeichen, Überlauf der Schiene, Menü, Stummschaltung beim Betroffenen, Meldung bis zur Moderation, Rauswurf. Dazu grün: pruef-meldungen, pruef-struktur, pruef-css-klassen, pruef-tippziele, pruef-deutsche-texte, pruef-hilfe. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGit
|
cb8e59bb08 |
Eine Arbeitsdatei war mitgewandert
tools/.messkopf.txt ist ein Zwischenstand beim Bauen der Messung -- sie gehoert nicht in die Geschichte. Die uebrigen Zwischenstaende stehen schon in .gitignore; dieser Name fehlte. |
||
|
DogFatherGit
|
079cf8c74f |
Drei Quellen fuer OBS und TikTok Studio -- ohne Anmeldung, mit Schluessel
Filipe: "ich will das alles auch so perfekt dass ich es ganz einfach
und easy mit obs oder mit tiktok studio verbinden kann. also so dass
man dan nur die kamera und das video sieht."
WARUM OHNE ANMELDUNG -- nachgesehen, nicht angenommen
OBS speichert die Anmeldung einer Browser-Quelle NICHT zuverlaessig;
im OBS-Forum stehen dazu Meldungen bis in die aktuelle Fassung 31.
Eine Quelle, bei der man sich nach jedem Programmstart neu anmelden
muss, ist mitten in einer Sendung unbrauchbar.
Deshalb ein SCHLUESSEL in der Adresse -- derselbe Weg, den jedes
Alert-Werkzeug im Netz geht. 32 Byte aus dem Zufall des Systems,
verglichen wird zeitgleich (`timingSafeEqual`): Ein gewoehnlicher
Vergleich bricht beim ersten falschen Zeichen ab, und aus den
Bruchteilen einer Millisekunde laesst sich ein Schluessel Zeichen
fuer Zeichen erraten.
DREI QUELLEN, WEIL DREI DINGE VERSCHIEDEN SIND
buehne.html Das laufende YouTube-Video, auf die Sekunde genau wie
bei allen anderen. Stumm (der Ton kommt aus dem
Mischpult) und ohne jede Bedienung -- was hier zu
sehen ist, geht in den Stream.
DIE EIGENE KAMERA IST ABSICHTLICH NICHT DRIN. Sie ist
in OBS direkt als Geraet verfuegbar, in besserer
Qualitaet und frei in Groesse und Lage -- genau das,
was Filipe will ("meine kamera groesser machen video
kleiner"). Den Umweg ueber den Browser zu nehmen
hiesse, Qualitaet gegen nichts einzutauschen und die
Groesse festzulegen statt sie freizugeben.
tafel.html Nur die Spendenkarten, auf DURCHSICHTIGEM Grund.
Groesse und Lage stehen in der Adresse (`&g=1.6`,
`&pos=or`): Wer in OBS eine Quelle einrichtet, hat die
Adresse ohnehin vor sich -- ein Wert, den man
stattdessen im Regiepult suchen muesste, waere ein
Fensterwechsel mitten im Einrichten. Alles rechnet in
`rem`, ein Wert nimmt Schrift, Bild und Polsterung
gleichmaessig mit.
Buehnenmodus `reaktion.html?nur=buehne` -- dieselbe Seite, nur ohne
alles Bedienbare. Fuer den Fall, dass GAESTE im Bild
sind: Deren Kameras kommen ueber eine
Direktverbindung an, und die braucht eine angemeldete
Seite. Diese eine wird als Fenster aufgenommen.
ES IST DIESELBE SEITE UND NICHT EINE ZWEITE. Eine
eigene muesste Video, Kameras, Verbindungsaufbau und
Nachfuehrung noch einmal enthalten -- und beim
naechsten Umbau saehe eine von beiden anders aus.
WAS HERAUSKOMMT, IST DIE EIGENTLICHE FRAGE
Wer den Schluessel hat, sieht genau das, was ohnehin im Stream
steht: Video, Stand, Sekunde, Titel -- und die Spendenkarten. Kein
Chat, keine Namen von Zusehenden, keine Zahlen ueber das Haus. Die
Pruefung zaehlt die Felder der Auskunft EINZELN auf und weist jedes
verbotene namentlich nach; eine Auskunft, die "ungefaehr das
Richtige" enthaelt, ist bei einem Weg ohne Anmeldung keine.
Ein neuer Schluessel macht die alten Adressen sofort tot -- und
schliesst die laufenden Quellen. Sonst liefe eine mit dem alten
weiter, obwohl er zurueckgezogen ist, und man haelt sich fuer
sicher, ohne es zu sein.
SIE MUESSEN TAGE LAUFEN, OHNE DASS JEMAND HINSIEHT
Das ist der Unterschied zu einer Seite im Browser: Wer eine Seite
offen hat, merkt, wenn sie haengt. Eine Quelle in OBS laeuft im
Hintergrund, und ein Stillstand faellt erst auf, wenn die erste
Spende nicht erscheint -- mitten in der Sendung. Deshalb ein
Lebenszeichen alle 25 Sekunden, eine eigene Wache (70 Sekunden ohne
alles = neu verbinden) und ein sofortiger Neuaufbau, wenn der
Rechner aus dem Ruhezustand kommt.
Und: Ein Fehler wird angezeigt, aber nur der, der etwas bedeutet --
ein falscher Schluessel. Alles andere bleibt still, weil jede
Flaeche hier im Stream zu sehen waere.
ZWEI EIGENE FEHLER, BEIDE VON DER MESSUNG GEFUNDEN
1. Die Quellen kamen mit 401 zurueck, obwohl die Seiten laengst
geladen waren: `aufgabenRouter` haengt eine Schranke ueber ALLE
Pfade unter /workspace/api. Genau dafuer stehen `sicherungRouter`
und der Weg fuers Profilbild schon davor -- die Buehne ist der
dritte Fall derselben Art und steht jetzt dort.
2. `waitUntil: "networkidle"` auf einer Seite mit Ereignisstrom. Der
Strom endet absichtlich nie; die Messung wartete auf einen
Zustand, der nicht eintreten kann, und brach nach 30 Sekunden ab.
Dieselbe Falle wie am 06.09. beim Regressionslauf.
ZWEI PRUEFUNGEN WURDEN DABEI GENAUER
`pruef-struktur` verlangte von den zwei OBS-Quellen ein Symbol fuer
den Startbildschirm, ein Manifest und eine Leistenfarbe. Sie
laufen in einem Programmfenster und werden nie installiert -- sie
fallen aus dieser Frage heraus, benannt und mit Grund.
Die Namensstreit-Regel zaehlte jede Klasse, die irgendwo in einem
Selektor vorkommt. Damit galt auch
`body[data-nur="buehne"] .kopfleiste { display: none }` als eigene
Klasse -- dabei ist das das Gegenteil: eine absichtliche
Bezugnahme, um sie im Buehnenmodus wegzunehmen. Gezaehlt wird
jetzt nur, was am ANFANG einer Regel steht, also als eigenes
Bauteil gemeint ist. Mit Gegenprobe in beide Richtungen -- sonst
haette ich eine Regel nur so lange geschaerft, bis sie schweigt.
GEMESSEN
mess-buehne (neu) Ein Browserfenster OHNE jeden Keks: beide
Quellen arbeiten, 0 Kekse, Grund durchsichtig
(rgba(0,0,0,0)), Karte laeuft an (25 EUR,
Rudel-Legende, 348x178). Falscher Schluessel: kein
Inhalt, Grund im Bild. Neuer Schluessel: alter 404,
neuer 200. Buehnenmodus: Kopf, Chat, Pult und
Schild weg, Leinwand da, Saal 720 von 720.
pruef-buehne (neu) 36 Punkte, 0 Fehler
pruef-reaktion 156 (war 154), spenden 46, haus-trennung 100,
haus-seiten 38, struktur 35, css-klassen 33,
verborgen 25, rechtetafel 19, portnummern 15,
ports 8 -- alle 0 Fehler.
|
||
|
DogFatherGit
|
dcd0298700 |
Spenden: vier Knoepfe, eine Karte im Bild -- und die Wahrheit ueber PayPal
Filipe: "ich will dass das richtig perfekt gemacht wird so dass die
leute so einfach wie moeglich eine spende aufs paypal machen koennen.
und wenn jemand spendet soll auch der betrag erscheinen mit einem
bild."
WAS GEHT UND WAS NICHT -- NACHGESEHEN, NICHT ANGENOMMEN
Hinterlegt ist ein PayPal.me-Link auf ein PRIVATES Konto. Daraus
folgt zweierlei, und beides bestimmt den ganzen Aufbau:
ES GEHT: `paypal.me/<name>/5EUR` oeffnet PayPal mit schon
eingetragenem Betrag. Ein Tipp, fertig. Belegt an PayPals eigener
Hilfeseite zu PayPal.Me.
ES GEHT NICHT VON SELBST: PayPal meldet eine Zahlung nur, wenn ein
Webhook oder IPN eingerichtet ist -- beides braucht Zugangsdaten,
die nur Filipe selbst anlegen kann. Ob ein PRIVATES Konto das
ueberhaupt kann, sagt PayPals eigene Doku nicht eindeutig; ich habe
es gesucht und nicht gefunden, und etwas zu behaupten, das ich
nicht belegen kann, waere hier das Gefaehrlichste.
DESHALB DREI HERKUENFTE UND NICHT EINE
"hand" Filipe sieht die PayPal-Meldung auf dem Handy und tippt
den Betrag ins Pult. Geht immer, braucht nichts, ist in
drei Sekunden getan, und die Karte laeuft sofort.
"gemeldet" Der Zuschauer sagt nach dem Spenden selbst Bescheid.
Landet als OFFEN und wird erst gezeigt, wenn die
Leitung es bestaetigt.
"paypal" Kommt automatisch, sobald ein Webhook eingerichtet ist.
Bis dahin steht dieser Weg leer da -- die Tabelle und
die Sperre gegen doppelte Zahlungsnummern sind schon
fertig.
WARUM EINE MELDUNG NICHT SOFORT ERSCHEINT: Sonst tippt irgendwer
"500 Euro" und steht damit gross im Bild. Eine Spende ist eine
Aussage ueber Geld; die gehoert bestaetigt, bevor sie oeffentlich
wird. Der Weg dahin ist EIN Tipp -- billig genug, dass niemand in
Versuchung kommt, ihn abzukuerzen. Beim Bestaetigen darf der Betrag
berichtigt werden: Die Leitung hat die PayPal-Meldung vor sich und
weiss es besser als die Behauptung.
FUER DIE ZUSCHAUER
Vier Betraege im Chat (2, 5, 10, 25 EUR) statt eines Links. Wer eine
Liste sieht, rechnet; wer vier Knoepfe sieht, tippt. Die Adresse wird
NICHT zweimal gepflegt -- sie steht auf der Unterstuetzen-Seite, und
von dort wird sie gelesen. Steht dort nichts oder ist der Weg auf
unsichtbar, gibt es hier auch keine Knoepfe. An einer Adresse, die
kein paypal.me ist, wird kein Betrag angehaengt: Er fuehrte sonst zu
einer Seite, auf der etwas anderes steht als auf dem Knopf.
DIE KARTE
Betrag gross, Name, Gruss, ein Bild dazu -- und eine Farbe, die von
der Stufe kommt. Drei Stufen ab Werk: Danke (ab 1), Starke Runde (ab
5), Rudel-Legende (ab 20), je mit eigener Vorlage, Farbe und Dauer.
Gilt immer die HOECHSTE, die noch passt; mit Ober- UND Untergrenze je
Stufe waere die doppelte Gelegenheit, eine Luecke zu lassen -- durch
die faellt dann ausgerechnet der grosse Betrag.
EINE NACH DER ANDEREN. Drei Spenden in zehn Sekunden sind keine
Seltenheit; uebereinander gelegt waere keine mehr lesbar, und
ausgerechnet die groesste ginge unter. Bei voller Schlange werden die
Zeiten gekuerzt, nicht die Karten weggeworfen -- wer gegeben hat,
soll es sehen.
DIE KARTE IST EIN EIGENES STUECK (spendenkarte.js/.css) und haengt an
nichts aus der Reaction. Dieselbe Karte laeuft spaeter als eigene
Seite fuer OBS und TikTok Studio; zweimal gebaut hiesse, sie sieht
nach der naechsten Aenderung an einem der beiden Orte anders aus --
und man merkt es erst im Livestream.
DER BETRAG STEHT IN CENT
Nie als Kommazahl. 0.1 + 0.2 ist in keiner Programmiersprache 0.3,
und bei Geld faellt das irgendwann jemandem auf -- meistens dem, der
zahlt. Formatiert wird erst auf dem Bildschirm.
DREI EIGENE FEHLER, VON DEN PRUEFUNGEN GEFUNDEN
1. Ein Weg aus einer Verzweigung: `/spenden/${id}/${ja ?
"bestaetigen" : "ablehnen"}`. `pruef-struktur` hat das zu Recht
beanstandet -- ein Tippfehler im selteneren Zweig faellt erst auf,
wenn er mitten in einer Sendung gebraucht wird. Beide Wege stehen
jetzt ausgeschrieben da.
2. "Genau 5 Register" -- zweimal am selben Tag dieselbe feste Zahl,
in der Messung UND in der Pruefung. Beim sechsten Register wurden
beide rot, obwohl nichts kaputt war. Jetzt wird gezaehlt: zu jedem
Reiter gehoert eine Tafel, und keine steht ohne Reiter da.
3. Die Messung war zu ungeduldig: Die erste Karte laeuft elf
Sekunden (die hoechste Stufe steht am laengsten), die zweite
wartet in der Schlange -- richtig so. Die Messung wartete 1,6
Sekunden und meldete "laeuft nicht". Jetzt wird auf das Merkmal
gewartet, nicht auf die Uhr.
GEMESSEN
mess-reaktion 4 Betragsknoepfe mit richtiger Adresse.
25 EUR von Hand -> Karte "Rudel-Legende" bei der
Zuschauerin. 500 EUR gemeldet -> steht NICHT im
Bild, wartet im Pult. Bestaetigt mit berichtigten
10 EUR -> Karte "Starke Runde". Stufe passt zum
Betrag, beide Male.
pruef-spenden 46 Punkte, 0 Fehler (neu) -- darunter die
Gegenprobe, dass ohne Zahlungsnummer beliebig viele
Zeilen nebeneinander stehen duerfen (sonst liesse
sich nur EINE Spende von Hand eintragen).
pruef-reaktion 154, unterstuetzung 70, aufbewahrung 45,
struktur 35, css-klassen 33, portnummern 15,
tippziele 11, ports 8, meldungen 8 -- alle 0 Fehler.
SCHEMA: zwei Tabellen (spenden, spenden_stufen) mit einem
Einmalig-Index auf die Zahlungsnummer. Auf einer Kopie der echten
Datenbank durchgespielt: 20 Personen, 227 Chatnachrichten, keine
Tabelle verliert eine Spalte.
|
||
|
DogFatherGit
|
28b492527e |
Kamera und Chat -- die zwei fehlenden Host-Steuerungen
Filipes Notiz nennt acht: "Host-Steuerung fuer Kamera, Mikrofon,
Video, Gaeste, Lautstaerke, Chat, Layout und Start/Ende."
Nachgezaehlt war sechsmal etwas da und zweimal nichts.
KAMERA
Es gab keinen Weg, das eigene Bild abzuschalten. Wer kurz aufstehen,
trinken oder etwas holen wollte, musste die Sendung verlassen oder
sich dabei filmen lassen.
Jetzt liegt eine SENDERLEISTE ueber dem Bild -- Kamera, Mikro und ein
Pegel. Sie gehoert jedem, der sendet, Host wie Gast: Ein Gast, der
sein eigenes Bild nicht abschalten kann, muesste den Host darum
bitten, und das ist keine Bedienung, sondern eine Bitte.
DAS BILD WIRD AM GERAET ABGESCHALTET (`track.enabled = false`), nicht
am Server: Die Verbindung bleibt stehen, der Ton laeuft weiter, und
beim Wiedereinschalten ist das Bild sofort da. Der Server erfaehrt es
nur, damit bei den ANDEREN "Kamera aus" im Fenster steht. Ohne diese
Beschriftung sind ein abgeschaltetes und ein kaputtes Bild dasselbe
schwarze Rechteck -- und dann fragt jemand im Chat, ob die Technik
hakt.
Erst das Geraet, dann die Ansage. Andersherum stuende bei allen
"Kamera aus", waehrend noch ein Bild fliesst; man glaubte sich
unsichtbar. Geht die Ansage nicht durch, wird das Geraet
zurueckgesetzt -- ein Knopf, der halb wirkt, ist schlimmer als einer,
der gar nicht wirkt.
Das Mikro laeuft denselben Weg. Erst wollte ich es rein oertlich
lassen; das waere dieselbe stille Falle gewesen: Wer sich selbst
stummschaltet und trotzdem redet, saehe bei allen anderen ein ganz
normales Fenster.
CHAT
Es gab Moderation -- Beitraege wegnehmen -- aber keine Steuerung des
Chats selbst. Einen Beitrag zu loeschen, nachdem er stand, ist etwas
anderes, als ihn gar nicht erst zuzulassen.
Drei Stufen: OFFEN, TEAM (wer moderiert, darf -- wer aufraeumen soll,
muss dabei reden koennen) und ZU (nur die zwei, die fuehren). Zwei
Stufen waeren zu wenig: "zu" ist in einer Sendung fast immer zu viel,
dann sitzen alle vor einem stummen Fenster. Die mittlere ist die, die
man wirklich braucht.
Die Schalter stehen im Kopf der Chatschiene, nicht im Regiepult: Man
moderiert, wo man liest. Ein Umweg ueber ein Register waere in dem
Moment, in dem es laut wird, genau ein Umweg zu viel.
EIN GESPERRTES FELD SAGT, WARUM. "Gerade schreibt nur das Team" statt
eines Feldes, das sich nicht beschreiben laesst und schweigt --
sonst schreibt jemand in den Hauschat, dass die Reaction hakt. Und
die Stufe gilt AM SERVER: Ein ausgegrautes Feld haelt niemanden auf,
der die Schnittstelle kennt. Beide Antworten kommen aus derselben
Funktion; zwei Rechnungen waeren zwei Gelegenheiten, dass ein Feld da
ist und mit 403 antwortet.
EIN FUND NEBENBEI: "MEIN MIKRO" WAR EIN PLACEBO
Gemessen: `staende.mikro` wird nirgends gelesen. Der Schieber liess
sich bewegen, die Zahl daneben aenderte sich -- und es passierte
nichts. Das ist schlimmer als ein fehlender Regler: Man glaubt, man
haette leiser gestellt.
Technisch ist das auch richtig. Die eigene Lautstaerke laesst sich
nicht am Regler aendern; man muesste den Ton umrechnen und die Spur
in jeder Verbindung austauschen. Was man beim eigenen Mikro braucht,
ist AN oder AUS -- und ein Pegel, der zeigt, dass es ankommt. Genau
das steht jetzt dort, als vierte Spalte im Pult, mit demselben
Zustand wie die Senderleiste. Die drei anderen Regler bleiben Regler:
Sie steuern, was ICH hoere, und das geht am Empfaenger.
UND EINER IN MEINER EIGENEN ARBEIT
`kasten.append(el("div","pegel")).append(el("i"))` -- `Node.append()`
gibt `undefined` zurueck, nicht das angehaengte Element. Ein
TypeError beim Aufbau des Pults, den `node --check` nicht sieht.
Beim Verkuerzen nicht nachgesehen, was die Methode zurueckgibt.
Dazu: Die Pegel-Takte liefen in `pultAufbauen()`. Das Pult hat nur,
wer die Sendung fuehrt -- ein Gast haette seinen Pegel nie gesehen,
und genau er braucht ihn am dringendsten.
GEMESSEN
mess-reaktion Der Host schaltet ab, und bei der Zuschauerin steht
"Kamera aus" bei DogFather, Bild verdeckt.
Stufe "Team": Feld gesperrt mit Grund, und der
Server lehnt denselben Versuch mit 403 ab.
pruef-reaktion 154 Punkte, 0 Fehler (vorher 132), neuer Abschnitt
13 mit 22 Punkten und Gegenprobe (es geht auch
wieder auf -- eine Sperre, die man nicht loesen
kann, ist keine Stufe, sondern ein Ende)
dazu gruen handy 180, css-klassen 33, struktur 35,
tippziele 11, aufbewahrung 45, meldungen 8
Der neue Abschnitt baut sich seine Buehne selbst. Abschnitt 9 beendet
die Sendung; sich auf den Stand eines frueheren Abschnitts zu
verlassen ist die Kopplung, die spaeter jemand aus Versehen
zerreisst.
SCHEMA: drei Spalten (reaktion_dabei.kamera_aus, .mikro_aus,
reaktion.chat_modus), alle per ALTER TABLE. Auf einer Kopie der
echten Datenbank durchgespielt: 20 Personen, keine Tabelle verliert
eine Spalte.
|
||
|
DogFatherGit
|
d79f6faa23 |
Die Reaction-Kachel steht hinter Dogi-Media
Filipe: "die kachel von der kategorie, reaktion, soll nach der kachel, dogi-move, erscheinen bitte und danke." EINE KACHEL "DOGI-MOVE" GIBT ES NICHT -- das Wort kommt im ganzen Haus nicht vor. Die einzige, die passt, ist "Dogi-Media" (Bilder und Videos zum Posten). Dorthin ist sie gesetzt; sollte etwas anderes gemeint gewesen sein, ist es eine Zeile zurueck. Die Reihenfolge der Community-Kacheln ist damit: Willkommen - Rudel-Chat - Highlights - Anschlagbrett - Was ansteht - Wunschliste - Dogi-Media - REACTION - Draussen Geprueft: reaktion 132, kachelraster 24, kachel-universum 13 -- alle 0 Fehler. Die angefangene Arbeit an der Host-Steuerung (Kamera- und Chat-Spalten) bleibt bewusst im Arbeitsstand: Sie ist unfertig und hat in dieser Lieferung nichts zu suchen. |
||
|
DogFatherGit
|
711a5470ab |
Die Regie wird eine Regie -- und das Video lief bei niemandem
Filipe: "perfektionier das auch mit den videoos. pefektionier auch das
aussehen und das layout von der regie. ich will dass du das viel
hochwertiger und profissioneller machst."
DAS VIDEO LIEF BEI NIEMANDEM -- AUCH NICHT BEIM HOST
Gemessen ueber ein neues Merkmal am Rahmen: `onStateChange` ist nie
ausgeloest worden, bei keinem der drei Browser. Zwei Ursachen, die
sich gegenseitig verdeckt haben:
Ein Player mit Ton darf ohne Handlung des Menschen nicht losgehen.
Ohne `mute: 1` greift `playVideo()` nicht -- und ein Zuschauer hat
keine Bedienung (mit Absicht), haette also NIE eine Moeglichkeit
gehabt, es zu starten. Eine Stunde Standbild.
`onReady` tat `if (host) takt(); else folgen();`. Der Host hat damit
nur GEMELDET, wo er steht, und nie selbst begonnen. Er meldete
"laeuft nicht", und alle anderen folgten ihm brav ins Stehen.
Die Messung bricht ab jetzt ab, wenn der Player nicht bei beiden
laeuft. Ein gruener Haken ueber einem Standbild ist wertlos.
DIE WARTESCHLANGE
Vorher gab es genau EIN Videofeld. Wer zwei Sachen hintereinander
schauen wollte, tippte mitten in der Sendung eine YouTube-Adresse ein
-- vor Publikum, mit laufender Kamera, ein Tippfehler von einem
schwarzen Rechteck entfernt. Jetzt wird vorher eingeraeumt und im Live
nur weitergeschaltet: anhaengen, schieben, "Jetzt", "Naechstes".
Die Titel kommen von YouTube selbst (oEmbed, kein Schluessel, kein
Kontingent) und werden EINMAL geholt und hingelegt. Klappt der Abruf
nicht, steht dort die Kennung -- kein erfundener Name. Die Grenze ist
ueber die Umgebung veraenderbar, damit die Pruefung den vollen Fall in
Sekunden erreicht statt dreissig Videos anzuhaengen.
DIE REGIE
Vorher fuenf Kaesten untereinander in einem Bereich, der hoechstens
die halbe Bildschirmhoehe hat -- man sah fuenf halbe Dinge. Die drei
grossen Knoepfe lagen ganz unten, hinter acht Feldern und vier
Reglern. Wer mitten in der Sendung "Beenden" drueckt, drueckt es, weil
etwas passiert ist; das darf nicht hinter einer Bewegung liegen.
Eine Leiste, die IMMER steht: Lampe, Laufzeit, Zuschauer, wie viele
davon Bild bekommen, Gaeste, gemessener Upload -- und rechts die
drei Knoepfe.
Register statt Stapel: Sendung, Warteschlange, Ton, Gaeste, Bild.
Eine Videospur mit echter Bedienung: Pause, +/-10 s, Positionsband,
Restzeit, "Naechstes". Vorher musste man ins YouTube-Bild fassen --
und was dort passiert, passiert nur bei einem selbst.
PEGEL an den Reglern, aus einer echten Messung (AnalyserNode). Sie
beantworten die Frage, die man sich sonst erst nach der Sendung
stellt: "War mein Mikro ueberhaupt an?" Ein Regler auf 100 sagt
darueber nichts. Beim YouTube-Regler steht dabei, dass dort nichts
zu messen ist -- Ton aus einem fremden Rahmen laesst sich nicht
abgreifen, und ein erfundener Ausschlag waere schlimmer als keiner.
Der Upload wird an der Verbindung gemessen (`getStats`), nicht aus
"zwoelf mal 350 kbit/s" gerechnet.
Tastaturkuerzel -- und die Legende steht darunter. Ein Kuerzel, das
niemand kennt, ist keins.
VIER FEHLER, DIE NUR DIE MESSUNG GEZEIGT HAT
1. `.tafel` WAR SCHON VERGEBEN. Die Anmeldeseite hat diese Klasse und
setzt sie `position: absolute`; reaktion.html laedt beide
Stilvorlagen. Die Register-Tafel trug damit NICHTS zur Hoehe bei
(114 px Raster, 294 px Inhalt) und malte quer ueber Register und
Kuerzel -- 197 Pixel, um die die Seite ueberlief. Auf dem Bild sah
es aus wie ein Anzeigefehler; es war ein Namensstreit. Dritter
Fall dieser Art nach .knopf-still und .schalter, deshalb steht er
ab jetzt in einer Pruefung: keine Klasse aus reaktion.css darf in
gate/start/module/haus.css vorkommen.
2. `node:sqlite` kennt kein `.transaction()`. Von Hand geklammert.
3. Das Schild war auf dem Handy 10,24 px gross -- unter der
Hausgrenze von 11,5 px. Gefunden von `pruef-handy`, das die
GEZEICHNETE Groesse misst; die Stilvorlagen-Pruefung haette die
Zeile in der Medienabfrage durchgelassen.
4. Die Messung klickte blind auf den Griff des Pults ("umschalten")
und machte es damit ZU, seit es aufgeklappt startet. Sie stellt
den Zustand jetzt her, statt ihn umzuschalten.
UND DIE HARTNAECKIGSTE: DAS BILD DES GASTES KAM BEIM HOST NICHT AN
Erst in einem von drei Laeufen, dann in drei von drei -- und zwar
SCHLIMMER, nachdem ich einen Wachhund dagegen gebaut hatte. Vier
Ursachen, hintereinander gemessen statt geraten:
a) `kameraHolen()` wurde beim Host FUENFMAL betreten. Die Wache
`if (meinStrom) return` wirkt erst, wenn die Kamera DA ist --
solange die erste Anfrage laeuft, geht jede weitere als zweite
Anfrage an dasselbe Geraet. Eine blieb liegen, und mit ihr der
Anruf, der darauf wartete. Der Platz in `ruftGerade` blieb
belegt, und damit kam nie wieder eine Leitung zustande. Jetzt
bekommen alle dasselbe Versprechen zurueck.
b) Der Wachhund riss Leitungen ab, die gerade verhandelt wurden --
zwischen "Leitung angelegt" und "Angebot abgeschickt" liegen
drei await.
c) "Ruf mich an" brach dasselbe ab: Der Bittende weiss nicht, dass
es schon laeuft, und fragt alle drei Sekunden weiter.
d) Meine Reparatur von (b) und (c) war "signalingState !== stable
heisst: in Arbeit" -- ohne Uhr. Damit war eine Leitung, deren
Antwort nie ankommt, vor BEIDEN Aufraeumwegen sicher, dauerhaft.
Der Zuschauer bekam daraufhin gar nichts mehr; ich hatte den
Fehler nur von einer Seite auf die andere geschoben. "Wird
verhandelt" ist ein Zustand MIT DAUER und steht jetzt an genau
einer Stelle.
Dazu ein eigener Fehler beim Aufraeumen: Mit der Messspur ist
`ruftGerade` mit herausgefallen. Vier Laeufe ohne jedes Bild -- und
`node --check` sieht das nicht, eine fehlende Variable ist
syntaktisch tadellos.
GEMESSEN
mess-reaktion fuenf Laeufe hintereinander ohne Beanstandung;
beide Kameras 640 px bei Host UND Zuschauerin,
Video laeuft bei beiden, Upload 0,9 Mbit/s,
Warteschlange 2 Zeilen mit Vorschaubildern,
kein Ueberlauf (4 px statt 197)
pruef-reaktion 132 Punkte, 0 Fehler (vorher 88)
pruef-handy 180 Punkte, 0 Fehler
dazu gruen css-klassen 33, struktur 35, tippziele 11,
meldungen 8, kamera-richtlinie 10
SCHEMA: neue Tabelle `reaktion_liste`, neue Spalte
`reaktion.video_titel` (ALTER TABLE, keine Abschrift der Spalten).
|
||
|
DogFatherGit
|
85101176d2 |
Zwei fuehren die Sendung: DogFather und die rechte Hand
Filipe, 28.09.2026: „die rolle dogfather und vanvan sollen alles sehen und bereit machen auch vorher. nur die zwei sollen alles sehen, vorbereiten und einschakten koennen." DREI DINGE AENDERN SICH, UND ZWAR GENAU DIESE DREI 1. VORBEREITEN UND EINSCHALTEN duerfen jetzt beide -- einstellen, Vorbereitung, auf Sendung, beenden, Gaeste holen und entfernen, stummschalten, Anordnung, Video steuern. Beide dasselbe; es gibt hier keinen Ersten und keinen Zweiten. Das ist eine AUFGABE und kein Rang: Wer die Sendung fuehrt, bedient die Technik. 2. „ALLES SEHEN" heisst die Namensliste derer, die zusehen. Die bekamen bisher auch die linke Hand und die Modis, weil sie moderieren duerfen. Das war eine Vermischung zweier Dinge, die nichts miteinander zu tun haben: Wer einen Beitrag wegnehmen darf, muss deshalb nicht wissen, wer im Saal sitzt. Ab jetzt bekommt die Liste nur, wer auf der Buehne steht. Die Moderation bleibt unveraendert bei DogFather, beiden Haenden und den Modis -- einen Beitrag wegzunehmen ist weder „alles sehen" noch „vorbereiten" noch „einschalten", sondern dasselbe, was sie im Treff ohnehin tun. 3. WER AUF SENDUNG DRUECKT, IST IM BILD. Vorher stand als Host, wer zuletzt etwas eingestellt hatte. Mit zwei Leuten, die vorbereiten duerfen, waere das eine Falle: VanVan richtet am Nachmittag alles ein, Filipe drueckt abends auf Sendung -- und im Bild stuende VanVans Name, waehrend Filipe redet. Beim Einstellen wird `host_id` deshalb nur noch gefuellt, wenn dort noch niemand steht (damit die Ankuendigung „Als Naechstes" jemanden nennen kann). Wer die Sendung FUEHRT, entscheidet sich beim Einschalten. GEPRUEFT IN BEIDE RICHTUNGEN Nur zu messen, wer darf, hiesse: Die Tuer laesst sich spaeter weit aufmachen, ohne dass etwas rot wird. pruef-reaktion misst deshalb auch, wer ausdruecklich NICHT darf -- und dass es genau zwei sind: genau zwei fuehren die Sendung: admin, hand die rechte Hand darf einstellen / vorbereiten / Anordnung linke, modi, gast: duerfen nicht einstellen (403) ein Modi holt niemanden dazu (403) wer eingeschaltet hat, fuehrt die Sendung (Filipe) drueckt die rechte Hand, fuehrt sie (VanVan) die rechte Hand sieht, WER dabei ist -- sie fuehrt mit linke, modi: moderieren, bekommen die Namensliste aber nicht admin/hand: sehen Regiepult -- linke/modi/gast: nicht Das Regiepult haengt an `ich.host` und an nichts sonst. Ein zweiter Ort, an dem der Browser dieselbe Frage noch einmal beantwortet, waere der, der spaeter abweicht -- und dann stuenden Knoepfe da, die mit 403 antworten. pruef-reaktion 74 -> 88 Punkte, 0 Fehler. Dazu gruen: meldungen 8, rechtetafel 19, verborgen 25, modi-verborgen 85. |
||
|
DogFatherGit
|
5d89d108f9 |
Die Reaction: zusammen schauen, live, mit Kamera und Chat
Filipes Kurznotiz vom 28.09.2026, von links nach rechts:
Kachel sichtbar -> geschlossen -> Vorbereitung -> Wartebereich/
Chat -> Countdown -> LIVE -> Reaction + Gaeste + Chat + PayPal
-> Ende
DREI STAENDE, NICHT SIEBEN
„Wartebereich" und „Countdown" sind keine eigenen Zustaende, sondern
das, was „Vorbereitung" auf dem Bildschirm TUT. Drei Staende, die
sich gegenseitig ausschliessen, sind pruefbar; sieben, von denen sich
vier ueberlappen, sind es nicht.
DAS VIDEO LAEUFT NICHT UEBER DIESEN SERVER
Naheliegend waere: Der Host spielt ab, alle sehen seinen Bildschirm.
Das waere aus zwei Gruenden falsch. Rechtlich ist ein
weitergesendetes YouTube-Video eine oeffentliche Wiedergabe -- genau
die Sache, fuer die Kanaele gesperrt werden. Und technisch kostet es
Bandbreite und Qualitaet.
Jeder Zuschauer laedt das Video deshalb SELBST. Uebertragen wird nur
der Spielstand: Kennung, laeuft/pausiert, Sekunde. Das sind ein paar
Byte, jeder sieht es in voller Qualitaet, und alle sind auf derselben
Sekunde. Nachgefuehrt wird erst ab anderthalb Sekunden Abweichung --
ein Player, dem man jede Sekunde eine neue Position gibt, ruckelt
sichtbar.
DIE KAMERAS LAUFEN DIREKT VON MENSCH ZU MENSCH
Ueber denselben Weg wie die Anrufe im Haus (seit 18.09.), nur mit
mehr Empfaengern. Das hat eine Grenze, und sie ist gerechnet, nicht
geraten: Bei 360p und rund 350 kbit/s sind zwoelf Zuschauer etwa
4 Mbit/s Upload beim Host. Darueber schaltet die Sendung von selbst
auf Ton um -- wer keine Kamera mehr bekommt, hoert alles, sieht das
Video und kann schreiben. Ehrlicher als eine Verbindung, die stockt,
und sichtbar im Regiepult.
Heute sind es elf Menschen im ganzen Haus (gemessen: 1 admin, 1 hand,
1 linke, 4 modi, 4 gast). Die Grenze ist weit weg -- sie steht
trotzdem drin, weil sie sonst erst auffaellt, wenn es zu spaet ist.
DIE SEITE IST ANDERS GEBAUT ALS JEDE ANDERE IM HAUS
Ueberall sonst: Kacheln, Karten, Listen -- man liest, entscheidet,
geht wieder. Hier sitzt man. Eine Stunde, mit anderen, auf EINE
Sache schauend. Deshalb kein Raster, sondern ein SAAL: grosse Flaeche
fuer das Video, Kamerabilder als schwebende Fenster darueber, der
Chat als Schiene daneben. Die Seite scrollt nicht -- ein Video, das
beim Tippen im Chat nach oben rutscht, ist der schnellste Weg, dass
jemand aufhoert zu schreiben.
Fuer den Host ein REGIEPULT: vier senkrechte Regler nebeneinander wie
an einem Mischpult, darueber die Sendung, daneben Gaeste und
Anordnung, unten drei grosse Knoepfe. Es SCHIEBT den Saal, es deckt
ihn nicht zu.
Die Kachel traegt ihren Zustand als Farbe: grau geschlossen,
bernstein in Vorbereitung, rot auf Sendung. Keine Ton-Nummer -- der
Farbraum ist bei 46 voll, und sie braucht auch keine.
PAYPAL: EINE QUELLE
Der Knopf nimmt den Weg, der auf der Unterstuetzen-Seite hinterlegt
ist -- derselbe Eintrag, dieselbe Pflege. Ist dort nichts eingetragen
oder steht er auf unsichtbar, erscheint hier kein Knopf. Eine
geratene Adresse ist an dieser Stelle die gefaehrlichste aller
Abkuerzungen.
=======================================================================
ACHT FEHLER, DIE OHNE MESSUNG LIVE GEGANGEN WAEREN
=======================================================================
1. `data-live` WAR SCHON VERGEBEN. Die Draussen-Kachel bekommt es,
sobald Filipe auf Twitch sendet. Meine Regel haette ihr waehrend
jedes Streams die Farbe genommen -- genau dann, wenn sie wichtig
ist. Heisst jetzt `data-sendung`, und pruef-reaktion haelt beides
auseinander.
2. DIE INHALTSRICHTLINIE HAETTE YOUTUBE LAUTLOS GESPERRT. Die Datei
warnt an genau dieser Stelle selbst davor: Am 27.08.2026 hat
`frame-src 'none'` den Musik-Knopf stillgelegt -- der Knopf
reagierte, das Feld ging auf, und wo die Player sein sollten,
blieb es leer. Hier waere das Ergebnis eine schwarze Leinwand vor
Publikum gewesen. youtube-nocookie.com fuer den Rahmen (setzt keine
Werbekennungen), www.youtube.com fuer die Einbett-API,
i.ytimg.com fuer die Vorschaubilder.
3. KAMERA UND MIKROFON WAREN GESPERRT. Dieselbe Falle, vor der
index.js selbst warnt -- und die am 18.09. schon einmal zugeschlagen
hat. Die Ausnahme ist jetzt eine benannte MENGE statt eines zweiten
Sonderfalls, und pruef-kamera-richtlinie.mjs haelt sie GEGEN DEN
QUELLTEXT: Welche Seite laedt ein Skript, das getUserMedia
aufruft? Genau die muss drinstehen -- und keine andere. Eine
Liste, die abgeleitet wird, kann nicht veralten.
4. ZWEI ANRUFE AN DIESELBE PERSON. Zwischen `await kameraHolen()` und
dem Anlegen der Verbindung laeuft alles andere weiter; jeder Takt
sagte wieder „den kenne ich noch nicht". Der Empfaenger antwortete
auf beide Angebote, und die zweite Antwort traf eine Verbindung,
die laengst stand.
5. DAS ANGEBOT GING HINAUS, BEVOR DER EMPFAENGER ZUHOEREN KONNTE.
Gemessen:
[spur] an [3] reaktion_signal | offen: [2,1]
...
[spur] Strom auf fuer 3 Lenny
Die Anmeldung ist ein gewoehnlicher Abruf und sofort durch, der
Ereignisstrom eine stehende Verbindung. Der Host erfaehrt vom
Neuankoemmling also zuverlaessig, BEVOR der zuhoeren kann.
Die Richtung ist jetzt umgedreht: Wer bereit ist, BITTET um den
Anruf -- er ist der Einzige, der das sicher weiss. Dazu ein
eigener, schneller Takt (2,5 s) und eine Ruecknahme, wenn ein
Angebot bei niemandem ankommt.
6. EIN VIDEO MIT TON STARTET NICHT VON ALLEIN. `videoWidth` war 640,
das Bild kam also an -- und das Fenster blieb schwarz. Kein
Fehler, keine Meldung, es passiert einfach nichts. Die Kameras
starten jetzt stumm (stumm darf losgehen), ein Knopf schaltet den
Ton frei, und die erste Beruehrung der Seite tut es ohnehin.
7. DIE LADE AM HANDY GING NICHT AUF. Gemessen: ein 390x775 grosser
Saal mit 219 px Video und 556 px Leere darunter. Statt den Knopf
zu reparieren, ist die Lade weg -- unter Kopfleiste und Video
bleiben auf einem Telefon rund 550 px, das ist mehr Chat, als eine
Lade je zeigen wuerde. Ein Zustand weniger ist besser als ein
Zustand, der funktioniert.
8. `sendBeacon` KANN NUR POST. Beim Schliessen des Fensters wird ein
gewoehnlicher Abruf abgebrochen; mein DELETE waere nie angekommen,
und jeder haette zwei Minuten lang als anwesend gegolten.
Dazu drei Funde der Hauspruefungen, alle von mir verursacht:
17 Schriftgroessen unter der Lesbarkeitsgrenze von 11,5 px, elf
Maschinenworte ohne deutschen Satz, und ein Aufbewahrungseintrag ohne
Rechtsgrundlage.
=======================================================================
GEMESSEN
pruef-reaktion 74 Punkte, 0 Fehler (11 Abschnitte)
pruef-kamera-richtlinie 10 Punkte, 0 Fehler (neu, abgeleitet)
mess-reaktion beide Kameras kommen an, 640 px, laufen --
beim Zuschauer UND beim Host. Diese Messung
hat einen Rueckgabewert: Alles andere kann
gruen sein, und trotzdem sitzt jeder vor
einem schwarzen Rechteck.
pruef-handy 180 (vorher 177), pruef-notizen 79,
pruef-aufbewahrung 45, pruef-meldungen 8, pruef-css-klassen 33,
pruef-struktur 35, pruef-crew-adresse 161,
pruef-haus-trennung 100, pruef-start-ansicht 160 -- alle 0 Fehler.
|
||
|
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
|
de4a9d0771 |
Der Commit-Text gehoert nicht ins Verzeichnis
Beim Committen mit -F landet die Textdatei ueber 'git add -A' selbst im Stand. Sie ist Arbeitsmaterial wie die Drehprotokolle und die Sammellaeufe -- alle drei stehen jetzt in .gitignore. |
||
|
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. |
||
|
DogFatherGitandClaude Opus 5
|
150555bc33 |
Der Notizblock -- und eine Pruefung, die zwoelf Kacheln nie angesehen hat
Filipe: „fuer die modis, rechte und linke hand und dogfather eine
kachel hinzufuegst, sie soll: Notizen, heissen. ich will dass du das
auch wie ein notizblock erstellst. ich will dass es uebelst geil und
einzigartig ist."
=================================================================
TEIL 1: DIE FARBE -- UND WAS DABEI AUFFIEL
=================================================================
Fuer die neue Kachel braucht es einen Ton. Beim Suchen fiel auf, dass
tools/kachelton-entzerren.mjs zwoelf der 45 Farben fuer FREI hielt.
Sie sind es nicht. bereicheFuer() gibt fuer die fuenf Rollen des
Agenturhauses null zurueck -- das heisst „nimm die Liste aus dem
Browser", und die steht in workspace/assets/js/bereiche.js. Dort
stehen die Toene 1 bis 22 und 44: Dashboard, Zahlen, Team-Lage,
Scout-Pipeline. Kacheln, die jeden Tag jemand ansieht.
pruef-kachelfarben hatte denselben blinden Fleck. Sie meldete seit
Wochen „33 benutzte Toene" und war gruen. Was sie dadurch NICHT sah:
* Der Farblauf von gestern Nacht hat zwoelf dieser Kacheln
verschoben und drei davon unter die Buntheitsgrenze gedrueckt.
Gruen geblieben.
* Ton 7, 16 und 22 lagen SEIT JEHER unter der Grenze (0,112 / 0,116
/ 0,068). Nie gemeldet.
Das ist die Sorte gruener Haken, vor der die Hausregel warnt: Er sagt
nur, dass die Bedingung erfuellt war -- nicht, dass sie das Richtige
angesehen hat.
BEHOBEN, und zwar an der Wurzel: Die REGELN (Kontrast, Buntheit)
gelten jetzt fuer jeden Ton, der irgendwo an einer Kachel steht --
gelesen aus denselben fuenf Dateien, die auch pruef-kachel-universum
liest. Dazu die Namen der Kacheln, damit „Ton 1 traegt Dashboard"
ueberhaupt pruefbar ist.
DIE PALETTE WURDE NEU GERECHNET, mit dem dritten Verfahren an einem
Tag -- die ersten zwei stehen als Fehler im Kopf des Werkzeugs:
1. Alle 45 neu verteilt. Lief ueber zwei ausdrueckliche Wuensche
hinweg (#ff1a1a, #a8d8ff).
2. Nur die Kollisionen, aber immer nur EINEN der beiden bewegt.
Ergebnis: Ton 1 sprang vom Tuerkis ins Altrosa, 0,197 weit.
3. BEIDE duerfen sich bewegen, und zwar beide nur ein bisschen.
Zwei Toene, die 0,02 auseinanderstehen und 0,09 brauchen, teilen
sich das -- jeder rueckt 0,045, und beide bleiben, was sie waren.
kleinster Abstand 0,0154 -> 0,0905
zu blass 4 -> 0
sichtbar veraendert 7 Kacheln (ueber 0,05)
kaum zu sehen 28 (13 zwischen 0,02 und 0,05, 15 darunter)
EINE AUSNAHME MIT ZAHL, keine mit Achselzucken: Ton 1 (Dashboard)
bleibt acht Tausendstel unter der Buntheitsgrenze. Gemessen ueber ALLE
16,7 Millionen sRGB-Farben ist die naechste, die alle Regeln haelt,
#7a75c8 -- ein Blauviolett, 0,113 entfernt. Tuerkis erreicht in sRGB
schlicht keine hoehere Buntheit, und das schmale Band teilen sich
schon sieben Toene. Eine Kachel, die ihre Farbfamilie behaelt, ist die
bessere Antwort auf „richtig geil und speziell" als eine, die acht
Tausendstel bunter ist und niemand wiedererkennt. blassBis sagt jetzt
bei jeder Ausnahme, WIE WEIT sie reicht -- vorher hiess blassErlaubt
schlicht „hier wird weggesehen".
DIE NEUE FARBE IST GRUEN UND WOLLTE BERNSTEIN SEIN. Gesucht war die
Farbe von Papier. Gemessen gibt es sie nicht mehr: Der beste Bernstein
im ganzen Farbraum haelt 0,0799 Abstand -- unter der Hausgrenze. Und
Platz schaffen hilft nicht: Setzt man ihn fest, muss ein warmer Ton
das Band verlassen (Ton 45 waere 0,212 weit ins Magenta gewandert).
Die groesste wirklich freie Luecke liegt im Gruen, bei 0,0917. Ein
linierter Block in Gruen ist Papier, seit es Papier gibt.
=================================================================
TEIL 2: DER BLOCK
=================================================================
DREI ENTSCHEIDUNGEN, AUS DENEN DER REST FOLGT:
1. ES GIBT KEINEN SPEICHERN-KNOPF. Nirgends. Wer einen Block
aufschlaegt und lostippt, drueckt hinterher nicht auf „sichern";
er klappt ihn zu. Gesichert wird 800 ms nach dem letzten
Tastendruck. Geht das nicht, bleibt der Text im Browser liegen und
wird nachgereicht -- und der Fuss sagt ehrlich „noch nicht
gesichert", statt einen Verlust zu melden, den man gerade nicht
verhindern kann.
2. DAS BLATT IST EIN SCHREIBFELD MIT EINER DECKSCHICHT. Das Feld
traegt Text und Cursor und ist unsichtbar; darueber zeichnet eine
zweite Schicht denselben Text noch einmal -- mit Kaestchen,
Ueberschriften, Strichen und Links.
DARAUS FOLGT EINE EISERNE REGEL, und sie steht dreimal im Code:
KEINE Auszeichnung darf die BREITE eines Zeichens aendern. Kein
Fettdruck, keine andere Groesse, keine Sperrung. Erlaubt sind nur
Farbe, Flaeche, Rahmen und Durchstreichen. Ein einziges
font-weight: 700 verschoebe den Umbruch, und ab der zweiten Zeile
stuende der sichtbare Text neben dem Cursor.
pruef-notizen misst das am echten Umbruch: eine Probe mit allen
Auszeichnungen und einer Zeile, die umbrechen MUSS. Sind beide
Schichten verschieden hoch, sitzt der Umbruch woanders. Mit
Gegenprobe -- Fettdruck auf der Deckschicht bricht die Deckung um
genau eine Zeile (30 px), und die Zeile wird rot.
3. DIE TASTATUR FUEHRT DIE LISTE FORT, NICHT EINE LEISTE. Ein
Spiegelstrich und Enter macht den naechsten Punkt, ein leeres
Kaestchen und Enter das naechste Kaestchen -- und ein GESETZTER
Haken wird dabei nicht mitgenommen, die naechste Aufgabe ist ja
noch nicht erledigt. Zweimal Enter beendet die Liste. Ein Klick
aufs Kaestchen hakt ab. Es gibt keine Werkzeugleiste, weil man beim
Schreiben nie den Stift wechselt.
UND: NIEMAND SIEHT DIE NOTIZEN EINES ANDEREN. Auch DogFather nicht.
Es gibt in workspace-notizen.js keinen siehtAlles()-Zweig, keinen
Umschalter, keine fremde Liste -- jede Abfrage hat person_id = ? fest
eingebaut. Die Kachel steht deshalb in „Fuer dich" und nicht in
„Taeglich": Die Gruppe sagt die wichtigste Eigenschaft, bevor man sie
anfasst.
NUR AUF DER TEAM-ADRESSE. Auf der Agenturadresse ist die Seite ein
404 -- auch fuer DogFather. Das ist dieselbe Trennung wie bei Chat,
Kalender und Aufgaben, und sie steht an zwei Stellen: in
GEHOERT_ZU_ADRESSE (die Datei) und in der Schnittstelle (die Daten).
Die Seite ist nur HTML; die Daten sind die Sache.
Dazu: sechs Papierfarben, Anheften, Suche mit Hervorhebung im Text,
Papierkorb mit dreissig Tagen und einem Eintrag in der
Aufbewahrungsliste (ohne den waere die Frist ein Satz in einem
Kommentar -- genau das ist dem Support am 24.09. passiert).
=================================================================
EIN FUND BEIM BAUEN, DER ALLEN GEHOERT
=================================================================
DELETE /workspace/api/notizen/:id gab es schon -- in
workspace-aufgaben.js, fuer die Notizen AN einer Aufgabe. Weil jener
Router frueher eingehaengt ist, hat er jeden Loeschversuch des Blocks
abgefangen und mit 404 beantwortet.
Von aussen sah das aus wie ein Fehler im neuen Modul: Anlegen ging,
Aendern ging, Loeschen nicht. Man sucht dann im eigenen Code, und dort
ist nichts. Express meldet so etwas nicht -- es nimmt die erste Route,
die passt, und schweigt ueber die zweite.
Der Block liegt jetzt unter /workspace/api/notizblock. Und
pruef-notizen geht seitdem den Routenbaum von express durch und meldet
jedes Paar aus Methode und Pfad, das zweimal vergeben ist. Gemessen:
307 Wege, keine Dublette. Die Pruefung gilt fuers ganze Haus, auch
wenn sie in dieser Datei steht -- hier ist sie gefunden worden.
Nebenbei berichtigt: pruef-crew-adresse verlangte von jedem Eintrag
der Haustafel HTTP 200 mit Inhalt. Das stimmte, solange dort nur
oeffentliche Dateien standen. notizen.html ist die erste Seite hinter
der Anmeldung -- sie antwortet mit 302, und das ist richtig. Gefragt
wird jetzt, was die Tafel wirklich meint: GIBT es das hier.
GEMESSEN, alles nach den Aenderungen:
pruef-notizen 76 Punkte, 0 Fehler (neu)
pruef-kachelfarben 31 Punkte, 0 Fehler (vorher 26)
pruef-kachel-universum 13 Punkte, 0 Fehler
pruef-crew-adresse 157 Punkte, 0 Fehler
pruef-buehne 230 Punkte, 0 Fehler -- notizen.html neu in
der Liste, schlechtester Kontrast 6,73:1,
also 50 % ueber der Grenze
pruef-rechtetafel, -haus-seiten, -struktur, -css-klassen,
-jeder-hat-eine-seite, -workspace-seiten, -kachelraster,
-rueckmeldung alle 0 Fehler
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
69ba533cee |
Wer mit der Tastatur bedient, sieht wieder, wo er steht
pruef-barrierefrei-workspace, wissen.html, Scout und Creator: Beim
Durchtabben veraendert sich an den Wissenskacheln NICHTS. Kein Rahmen,
kein Ring, keine Kante. Wer nicht mit der Maus arbeitet, tippt blind.
=== EIN SPEZIFITAETS-UNFALL, UND ER BETRIFFT NICHT NUR DIESE SEITE ===
Die Regel war da und richtig geschrieben:
wissen.css .kachel:focus-visible { box-shadow: 0 0 0 3px ... }
Sie kam nur nicht an. Gemessen mit einem neuen Werkzeug
(server/mess-fokus.mjs, echte Tastendruecke, kein focus()):
:focus true :focus-visible true
boxShadow gleich rgba(0,0,0,0.95) 7px 7px 14px -10px inset
outline gleich none
`:focus-visible` griff also, und trotzdem blieb alles, wie es war.
Der Grund steht in module.css, in einer Liste von 45 Klassennamen:
:is(.eintrag-karte, ..., .kachel, ..., .gruppe[data-gruppe], ...)
`:is()` uebernimmt die Spezifitaet seines STAERKSTEN Arguments.
`.gruppe[data-gruppe]` ist eine Klasse PLUS ein Attribut. Damit ist die
ganze Liste (0,2,0) statt (0,1,0) -- genau so stark wie
`.kachel:focus-visible`. Bei Gleichstand gewinnt, was spaeter geladen
wird, und module.css wird zuletzt geladen. Ein einziges Attribut in
einer Aufzaehlung, sechs Zeilen weiter rechts, hat den Fokusring von
jedem Bauteil im Haus verschluckt, dessen Fokusregel aus einer Klasse
besteht.
=== GELOEST WIRD DAS NICHT, INDEM MAN DIE LISTE SCHWAECHER MACHT ===
Das war schon einmal so (`:where()`, Spezifitaet null) und ergab einen
Zwitter aus neuer Form und alter Kante -- der Kommentar in module.css
beschreibt es. Wer die Zahl senkt, verschiebt das Problem auf die
naechste Regel.
Geloest wird es, indem die ANTWORT dort steht: ein Fokusring fuer die
ganze Modulliste, in derselben Datei wie die Form, mit
`:focus-visible` also eine Klasse staerker als die Grundregel. Er gilt
damit fuer jedes Modul im Haus -- auch fuer die, die es noch nicht
gibt, und auch dort, wo nie jemand an eine Fokusregel gedacht hat.
`outline-offset` ist NEGATIV, und das ist kein Geschmack: `clip-path`
(die Fase an der Ecke) schneidet alles ab, was ausserhalb der Form
liegt. Ein Ring mit positivem Abstand waere unsichtbar gewesen -- der
alte war es ja auch. Nach innen gezeichnet bleibt er stehen. Gemessen,
nicht geschlossen.
=== WAS NICHT MITREPARIERT WURDE, UND WARUM ES DASTEHT ===
Derselbe Gleichstand trifft auch Hover-Regeln in frueher geladenen
Dateien: `.ablage:hover` (dateien.css), `.call:hover` (calls.css),
`.kk:hover` (scouting.css), `.fortschritt:hover` (uebersicht.css)
setzen alle `border-color`, und die Grundregel setzt `border: 0`.
Diese vier tun vermutlich nichts.
Angefasst habe ich sie nicht -- es gibt kein Messgeraet dafuer. Fokus
laesst sich pruefen (die Pruefung tabbt und vergleicht), Hover nicht.
Und die naheliegende Loesung wuerde die Form von 45 Bauteilen auf 38
Seiten neu entscheiden; das ohne Messgeraet zu tun waere Raten mit viel
Einsatz. Der Befund steht deshalb als Absatz in module.css, damit der
Naechste nicht wieder bei null anfaengt.
=== UND EINE BEHAUPTUNG VON MIR WIRD ZURUECKGENOMMEN ===
Im Commit
|
||
|
DogFatherGitandClaude Opus 5
|
80988f2d23 |
Berichtigt: Die Rechnung hat zwei ausdrueckliche Wuensche ueberfahren
Der Commit davor hat alle 45 Kachelfarben neu verteilt, um acht fast gleiche Paare zu trennen. Das Ergebnis war rechnerisch besser und praktisch falsch. pruef-kachelfarben hat sechs Fehler gemeldet: Ton 38 #ff1a1a -> #ff241e „nur die soll knall rot sein!!!" Ton 44 #a8d8ff -> #90c3ff „soll auch babyblau sein mit bissl lila" Ton 40, 10, 33 unter die Buntheitsgrenze von 0,12 gedrueckt und die Regenbogenkachel zeigte noch die 32 alten Farben Beide Farben standen mit Datum, Zitat und Begruendung in der Pruefung. Ich habe sie nicht gelesen, weil ich ein GLOBALES Ziel optimiert habe -- „alle 45 moeglichst weit auseinander" -- und eine globale Rechnung kennt keine Einzelfaelle. === DIE LEHRE IST NICHT „DIE RECHNUNG WAR FALSCH" === Sondern: Eine Gesamtloesung fuer ein LOKALES Problem bezahlt man mit allem, was an den nicht betroffenen Stellen schon richtig war. Acht Paare standen zu eng. Verschoben wurden 45. Der zweite Anlauf (tools/_toene-reparieren.mjs) macht es umgekehrt: Solange ein Paar zu eng steht, wird das engste genommen und EINER der beiden auf die naechste erlaubte Farbe geschoben. Sonst nichts. Und dabei kam das Beste des Tages heraus -- gemessen, nicht geahnt: Von den 45 Toenen tragen nur 33 eine Kachel, zwoelf stehen bereit. In JEDEM der acht zu engen Paare ist mindestens einer dieser zwoelf dabei. Wer den Unbenutzten verschiebt, loest dasselbe Problem, ohne dass sich fuer irgendjemanden auch nur eine Kachel veraendert. kleinster Abstand 0,0154 -> 0,0940 Paare unter 0,09 14 -> 0 veraendert 14 von 45 davon in Gebrauch 4 -- und zwar um 0,003 bis 0,012 Vier Zehntausendstel OKLab sind nicht zu sehen. Es gibt also KEINE Kachel, die ihre Farbe wechselt. Das ist mehr als Bequemlichkeit: Wer zwei Jahre lang „das Tuerkise" angesteuert hat, sucht danach, wenn es plötzlich rosa ist. === UND DIE WUENSCHE STEHEN JETZT DORT, WO GERECHNET WIRD === Die Liste FESTGELEGT ist von server/pruef-kachelfarben.mjs nach tools/kachelton-regeln.mjs gewandert -- neben die Schwellen, aus genau demselben Grund, aus dem die Schwellen dort stehen. In der Pruefung konnte sie nur EINES: eine Abweichung melden, nachdem sie passiert ist. Das hat sie getan, und das ist ihr Verdienst. Aber eine Bedingung, die erst NACH dem Schaden spricht, ist die schwaechere Form. Wer die Farben rechnet, soll gar nicht erst die Moeglichkeit haben, sie zu verschieben -- das Werkzeug liest die Liste jetzt selbst und setzt festgelegte Toene sogar zurueck, wenn es sie verschoben vorfindet. Dasselbe gilt fuer die Buntheitsgrenze: Sie kommt aus der Regeldatei, und sie gilt nur fuer benutzte Toene -- so, wie die Pruefung sie anwendet. Das ist nicht Nachgiebigkeit, sondern Rechnung: Mit Buntheit >= 0,12 fuer ALLE 45 ist ein Mindestabstand von 0,09 nachweislich unmoeglich (Decke 0,0853). Die zwoelf unbenutzten duerfen blasser sein und nehmen genau den Druck aus dem engen Blau-Tuerkis-Bereich, an dem der erste Anlauf gescheitert ist. GEMESSEN: pruef-kachelfarben 26 Pruefungen, 0 Fehler (vorher 26 mit 6 Fehlern). pruef-kachel-universum 13 Pruefungen, 0 Fehler. Regenbogenkachel mit tools/kachel-regenbogen.mjs neu geschrieben -- 99 Punkte in drei Groessen, je 33 Farben. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
954426615f |
Der Pruefstand bekommt selbst eine Pruefung -- und der Mensch ein Stueck
der Notiz
Jede Nacht laeuft tools/nachtlauf.mjs ueber 193 Pruefdateien und
schreibt das Ergebnis als Notiz in Filipes Vault. Diese Notiz ist das
Einzige, was er von dem ganzen Aufwand zu sehen bekommt.
Und sie war die einzige Datei im Haus, die niemand geprueft hat.
=== WARUM DAS VORHER GAR NICHT GING ===
nachtlauf.mjs startet BEIM IMPORT sofort einen Lauf. Wer die Notiz
messen wollte, haette damit eine halbe Stunde Rechenzeit ausgeloest --
und nebenbei das echte Ergebnis auf Filipes Startseite ueberschrieben.
Am 04.09.2026 hat genau so ein Griff bei RunOne einen roten Alarm ueber
einer fehlerfreien Buchhaltung erzeugt, am Morgen einer Vorstellung.
„Ein Prueflauf ist kein harmloser Lesevorgang."
Der Textbau steht deshalb jetzt in tools/nachtlauf-notiz.mjs: nur
Textbau, kein Nebeneffekt, Importieren ist folgenlos.
=== UND EIN STUECK DER NOTIZ GEHOERT AB JETZT DEM MENSCHEN ===
Oben in der Notiz stand: „von Hand aendern bringt nichts, beim
naechsten Lauf ist es wieder ueberschrieben." Das war ehrlich und
trotzdem falsch herum gedacht.
Das Wertvollste an diesem Pruefstand ist naemlich nicht die Zahl,
sondern der Satz daneben: „die hier ist rot, weil sie den Umbau vom
24.09. nicht mitbekommen hat" oder „die ist echt, Finger weg". Genau
dieser Satz wurde jede Nacht geloescht. Heute Nacht standen 37
Dateien in der Liste, und bei 25 davon waere so ein Satz die halbe
Arbeit gewesen.
Jetzt gibt es einen Bereich zwischen zwei Marken, den der Lauf wieder
einsetzt statt ihn zu ueberschreiben. Fehlt er, wird er leer neu
angelegt -- mit der Erklaerung darin, wozu er da ist.
=== 30 PRUEFUNGEN, JEDE MIT GEGENPROBE ===
1. Der Block „von Hand" ueberlebt einen Lauf -- UND das alte
Ergebnis daneben verschwindet wirklich. Ohne die zweite Haelfte
wuerde die erste nur beweisen, dass die Datei nicht angefasst
wurde.
2. Ein leerer Block zaehlt als nicht vorhanden; sonst waere die
Erklaerung fuer immer weg, sobald jemand sie einmal loescht.
3. Weniger Pruefungen als gestern werden gemeldet, auch wenn alles
gruen ist (die Lehre vom 28.08.: 789 statt 804, gruen, und acht
Pruefungen je Geraet waren still weggefallen). Gegenprobe: Bei
MEHR Pruefungen darf der Satz NICHT kommen -- eine Warnung, die
immer kommt, ist keine Warnung mehr.
4. Der dritte Ausgang sagt „konnte nicht nachsehen", nennt den Grund
und wie alt der letzte echte Stand ist -- und behauptet nirgends,
alles sei in Ordnung.
5. „Keine Pruefung gezaehlt" wird als das benannt, was es ist: kein
Befund, sondern ein Zaehlproblem. Acht Dateien standen heute Nacht
aus diesem Grund als rot da.
Punkt 5 der Pruefung hat sich beim ersten Lauf gleich bezahlt gemacht:
Sie zaehlt nach, ob JEDER der vier Aufrufe in nachtlauf.mjs den
Notizpfad mitreicht. Drei davon sind die seltenen Ausgaenge, die man
beim Ausprobieren nie erwischt -- und an jedem einzelnen waere der
Block „von Hand" spurlos verschwunden. Beim Umbau hatte ich genau
diese drei zuerst vergessen.
GEMESSEN: 30 Pruefungen, 0 Fehler. Die echte Notiz im Vault wird dabei
nicht angefasst -- gearbeitet wird in einem mktemp-Ordner.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
d7bb0f7e60 |
45 Kachelfarben: acht Paare waren dieselbe Farbe -- und die Pruefung
konnte es nicht sagen
Filipe am 17.09.: „ich will das jede kachel eine andere farbe hat, es
soll keine die gleiche farben haben bitte und auch keine die sich
irgendwie aehnlich sind ... die farben sollen auch richtig geil und
speziell sein."
Gemessen am 25.09.: #ff8fb4 gegen #fe8ebe, Abstand 0,0154 in OKLab.
Das ist mit blossem Auge DIESELBE Farbe. Acht solche Paare gab es.
=== WARUM ES NIEMAND GEMERKT HAT ===
pruef-kachel-universum hat es gesagt. Jede Nacht. Die Zeile stand da:
„kleinster Abstand 0,0154". Gelesen hat sie niemand -- weil direkt
daneben eine zweite Zeile stand, die NIEMALS gruen werden konnte:
„kein Paar unter 0,10".
Nachgerechnet (tools/_toene-packen.mjs, eine echte Kugelpackung ueber
alle sRGB-Farben, die 4,8:1 gegen den Grund halten, nicht blenden und
bunt genug sind):
30 Farben -> 0,115 48 Farben -> 0,0925
40 Farben -> 0,103 52 Farben -> 0,0840
45 Farben -> 0,0974 60 Farben -> 0,0805
Die Forderung war fuer 21 Farben geschrieben. Bei den heutigen 45
liegt die DECKE bei 0,0974 -- „kein Paar unter 0,10" konnte niemand
erfuellen, mit keiner Palette der Welt.
DAS IST DER EIGENTLICHE BEFUND. Eine Bedingung, die niemand erfuellen
kann, macht nicht nur sich selbst wertlos. Sie faerbt die ganze Datei
rot, und ab da liest man die Zeile darueber nicht mehr. Der echte
Mangel lag acht Tage offen da, versteckt hinter einem Fehlalarm.
=== DIE NEUE PALETTE WURDE GERECHNET, NICHT NACHGEBESSERT ===
Von Hand nachbessern hat sie erst dahin gebracht: Am 08.09. waren es
21 Farben, danach kamen sechzehn dazu, jede einzeln gewaehlt, keine
gegen die anderen geprueft. In drei Schritten:
1. Aus allen erlaubten sRGB-Farben 45 so waehlen, dass der kleinste
Abstand so gross wie moeglich wird.
2. Sie den 45 Kachelnummern so zuordnen, dass jede moeglichst nah an
ihrer bisherigen Farbe bleibt -- eine Kachel soll wiedererkennbar
sein, sie rueckt, sie wechselt nicht.
3. Nachziehen: Jeder Ton darf zurueck in Richtung seiner alten Farbe
wandern, solange der Mindestabstand haelt.
Ergebnis: kleinster Abstand 0,0154 -> 0,0931, kein Paar mehr unter
0,09. Dreissig der 45 Kacheln haben sich um weniger als 0,02 bewegt --
das sieht man nicht. Nur sieben sind sichtbar gewandert, und alle
sieben lagen in dem Gedraenge aus neun fast gleichen Rot- und
Rosatoenen, das den Ausschlag gegeben hat.
„Richtig geil und speziell" bleibt messbar erhalten: Die Buntheit hat
eine Untergrenze von 0,10 in der Rechnung, damit keine Farbe ins Graue
rutscht. Gemessen kostet das nichts -- mit dieser Grenze ist die Decke
sogar minimal hoeher als ohne (0,0974 gegen 0,0973).
=== UND DIE PRUEFUNG SAGT JETZT ETWAS ERFUELLBARES ===
kleinster Abstand >= 0,09 (Decke fuer 45 Farben: 0,097)
hoechstens 48 Farben (darueber ist 0,09 nicht mehr
erreichbar -- gemessen, nicht
gesetzt)
Gegenprobe: #ff8fb4 gegen #fe8ebe muss durchfallen
Die zweite Zeile ist die wichtige: Sie bewacht den GRUND. Wer die
46., 47., 48. Kachel anlegt, kommt noch durch; wer die 52. anlegt,
bekommt gesagt, dass jetzt ueber die Palette geredet werden muss,
statt still wieder in zwei gleiche Farben zu rutschen. Genau das ist
zwischen dem 08.09. und dem 17.09. passiert.
GEMESSEN: pruef-kachel-universum 13 Pruefungen, 0 Fehler (vorher 12
mit 2 Fehlern). Schlechtester Textkontrast auf der fertigen Kachel
7,02:1, am Bildschirmfoto gemessen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
ce1a1f758c |
Zum dritten Mal dieselbe Schrift zu dunkel -- diesmal mit Luft
entwicklung.html, „Noch niemand im Team": 4,42:1 gemessen, noetig sind
4,5:1. Der Befund ist klein. Die Geschichte dahinter ist es nicht.
=== DREIMAL IN VIER WOCHEN, IMMER DERSELBE GRIFF ===
01.09. #6d7d92 -> #75859a gemessen 4,43 -> 4,95
07.09. #75859a -> #7f8fa6 gemessen 4,50 -> rund 4,9
25.09. #7f8fa6 -> #95a4ba gemessen 4,42 -> 5,75
Neben jedem dieser Schritte steht ein sorgfaeltiger Kommentar, der
erklaert, warum genau dieser Wert richtig ist. Alle drei waren richtig
-- fuer den Untergrund, den man GERADE KANNTE.
Der Hintergrund ist aber ein BILD. Bilder haben helle Stellen, und die
liegen bei jedem neuen Layout woanders. Wer eine Schrift auf zwei
Kommastellen genau gegen die hellste Stelle einstellt, die er heute
gefunden hat, stellt sie auf den naechsten Umbau ein.
=== WAS DIESMAL ANDERS GEMACHT WURDE ===
1. NICHT NUR DIE ROTE SEITE ANGESEHEN. Die schlechtesten Werte ALLER
vierzehn Seiten nebeneinandergelegt:
hilfe.html 4,90 auf rgb(51,53,56) <- die hellste im Haus
teamlage.html 4,98 auf rgb(45,52,64)
entwicklung 4,42 auf rgb(40,41,44) <- die, die rot war
befinden.html 5,38 auf rgb(29,39,46)
... zehn weitere ueber 6,3
Die rote Seite war also NICHT die gefaehrlichste. Zwei andere lagen
knapper an der Grenze, als der letzte Rutscher gross war -- sie
waeren als naechste drangewesen. Haette ich nur entwicklung.html
repariert, haette ich in zwei Wochen dasselbe noch einmal getan.
2. DER BEZUG IST JETZT DIE HELLSTE FLAECHE IM HAUS, nicht die der
Seite, die gerade rot ist. Beide Toene beider Haeuser gegen
rgb(51,53,56) gerechnet:
Gate still #7f8fa6 -> #95a4ba 4,35 -> 4,86
leise #94a5bb -> #9fb0c6 4,90 -> 5,56
Crew still #8f88b2 -> #a7a0cb 4,10 -> 5,00
leise #a9a2ca -> #b4aed6 5,10 -> 5,84
Der stille Ton im Crew-Haus stand bei 4,10 -- UNTER der Grenze, seit
Wochen, ohne dass eine Pruefung je etwas gesagt haette. Nicht weil
sie nachsichtig war, sondern weil noch keine Crew-Seite mit dieser
Flaeche angesehen wurde. Ein gruener Haken heisst nicht, dass
nachgesehen wurde.
3. PRUEF-BUEHNE PRUEFT JETZT AUCH DIE LUFT. Nicht nur „ueber 4,5",
sondern: „hat die schlechteste Stelle dieser Seite noch elf Prozent
Reserve?" Die Zahl ist gemessen und nicht gewaehlt -- beide
Rutscher oben waren rund elf Prozent gross, und 4,5 mal 1,11 ist
5,0. Eine Seite unter diesem Wert ist noch in Ordnung und schon in
Gefahr, und genau das soll sie sagen, solange man es noch in Ruhe
beheben kann.
Sie haengt an der jeweiligen Grenze, nicht an einer festen 5,0: Bei
grossem Text sind 3:1 erlaubt, dieselbe Luft sind dort 3,33. Eine
hineingeschriebene 5,0 wuerde grossen Text ohne Not anmahnen.
GEMESSEN: pruef-buehne 230 Pruefungen (vorher 192), 0 Fehler.
Schlechteste Seite jetzt hilfe.html mit 5,15:1 -- 15 % ueber der
Grenze. Die Schrift bleibt deutlich leiser als der Haupttext: der
steht bei 11,8:1, also mehr als doppelt so hoch.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
1ba9d07af2 |
Zwoelf rote Pruefungen -- und kein einziger Fehler im Programm
Der Rundumcheck geht weiter. Diese zwoelf standen im Nachtlauf als rot
und waren es nicht: Jede hat den Umbau vom 24.09. (die Haustrennung),
den vom 25.09. (die zugetragenen Punkte) oder eine Umbenennung
mitbekommen -- nur ihre Erwartung nicht.
DAS IST KEIN TROST. Ein Fehlalarm zeigt auf eine echte Stelle und nennt
eine plausible Zahl; man sucht danach an richtigem Code. Und zwoelf rote
Zeilen, die immer rot sind, nehmen dem ganzen Satz die Stimme.
=== DIESELBE WURZEL, SECHSMAL: DAS FALSCHE HAUS ===
Seit dem 24.09. antwortet der Server auf der Agenturadresse nicht mehr
ueber Team-Dogi-Leute -- und genau das taten diese Pruefungen:
pruef-nachwuchs legte einen Modi ueber die Agenturadresse an
(400). Einundzwanzig Meldungen hingen an diesem
einen Aufruf. 82 Zeilen auf crew. umgestellt,
aus „Mara, Managerin" wurde die linke Hand --
im Teamhaus ist sie das, was gemeint war.
230 -> 262 Pruefungen, 0 Fehler.
pruef-schritt dasselbe beim Aufgabenbrett (404/400).
pruef-treff-werkzeuge fragte die Einladungsliste eines Modis auf der
Agenturadresse ab -- dort ist er nicht.
pruef-rechte-umstellen benutzte `wissen.html` als zweite Probeseite.
Die ist laut Rechtetafel fuer alle offen und auf
crew. trotzdem zu: Dort kommt man nur auf Seiten,
fuer die es eine Kachel gibt. Jetzt material.html.
pruef-personen-formular verglich eine Erwartung FUER die Agentur mit
einer Messung OHNE Adresse (127.0.0.1) -- vier
gegen acht Rollen. Beides war richtig, nur nicht
dasselbe.
pruef-treff suchte „Support" zwischen den Brettern. Er steht
in „Fuer dich", wo er hingehoert -- eine kaputte
Seite zu melden ist kein Aushang. Die Liste stand
ZWEIMAL in der Datei; nachgezogen wurde eine.
Jetzt eine, von beiden benutzt.
=== ZWEIMAL: EINE FESTE ZAHL, DIE DIE SEITE UEBERHOLT HAT ===
pruef-community-sicht erlaubte „3 bis 8 Seiten". Es sind zwoelf, und
jede gehoert dorthin. Statt einer Spanne steht
jetzt die LISTE da: Kommt eine dazu, wird die
Zeile rot und nennt sie beim Namen. Eine Spanne
haette elf statt zwoelf stillschweigend
durchgelassen -- in beide Richtungen.
pruef-nachwuchs schaltete EINE Person ab und erwartete, dass die
Ampel danach schweigt. Der Kommentar darueber
sagt selbst: „Die Schwelle wird nicht
abgeschrieben, sondern aus dem Verhalten
abgeleitet" -- eine feste Anzahl abzuschalten ist
aber eine Abschrift in anderer Waehrung. Jetzt
wird abgeschaltet, BIS es kippt.
=== UND VIERMAL EIN WERKZEUG, DAS STUMPF WAR ===
pruef-scout-zuteilung suchte `.person__zeile` -- eine Klasse, die es
nicht mehr gibt. `querySelectorAll` liefert dafuer
ein leeres Feld, `.some()` darauf ist immer
false: Die Pruefung war nicht rot, weil etwas
fehlte, sondern weil sie nichts ansehen konnte.
Jetzt `.person`, und die ANZAHL der gefundenen
Karten steht in einer eigenen Bedingung.
pruef-loeschen suchte `::before` in einem Fenster von 600
Zeichen ab dem Selektor. Das misst die Laenge des
KOMMENTARS: Am 25.09. kam eine Begruendung von
zwanzig Zeilen dazu, und die Regel rutschte
hinaus. Jetzt wird nach dem Selektor gesucht.
pruef-portnummern hielt jedes `listen(` fuer einen Serverstart --
auch das blosse Nachsehen, ob eine Nummer frei
ist. Damit mahnte sie ausgerechnet die Datei an,
die das Vergeben der Nummern prueft. Jetzt zaehlt
der Import von `index.js`; dazu vier Gegenproben,
damit die engere Fassung nicht zum blinden Fleck
wird.
pruef-spicy stellte eine Person auf „manager" und dann
weiter. An Managern aendert seit dem 22.09. nur
DogFather etwas -- die Pruefung hatte sich selbst
die Tuer zugezogen. Jetzt kommt „manager" zuletzt,
und dass danach nichts mehr geht, ist eine eigene
Zeile. Aus dem Stolperstein wird eine Aussage.
=== EINER WAR FAST EIN BEFUND ===
pruef-alle-sehen-es meldete „highlight: DogFather 0, Community 0".
Das Brett hat als einziges keinen Katalog (dort
stehen echte Hoehepunkte, keine Vorlagen), und an
einem leeren Brett ist „sehen beide dasselbe?"
nicht zu messen: null gleich null waere auch dann
wahr, wenn die Community gar nichts duerfte.
Die Pruefung legt dort jetzt selbst einen Eintrag
an -- und musste dabei zweimal lernen: Der Eintrag
gehoert VOR den Katalog (danach ist die
Schreibbremse ausgeloest, 429), und er muss
FREIGEGEBEN werden, sonst sieht die Community ihn
zu Recht nicht. Beides steht jetzt als Aussage in
der Pruefung.
GEMESSEN: alle zwoelf gruen -- 43, 10, 31, 262, 43, 15, 56, 69, 37, 85,
73 und 80 Pruefungen, zusammen 804, kein Fehler.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
3b73e1f42e |
Versionsnummer von anruf.js hochgezaehlt -- sonst bliebe die Reparatur im Zwischenspeicher
Die Datei wird mit fester Nummer eingebunden (anruf.js?v=...). Wer sie aendert und die Nummer stehen laesst, hat ausgeliefert und trotzdem nichts bewirkt: Jeder Browser, der die Seite schon einmal offen hatte, nimmt weiter die alte Datei. Genau die Sorte Auslieferung, die gruen meldet und nichts tut. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
29d339b262 |
Ein turn: ohne Zugangsdaten haette JEDEN Anruf verhindert, nicht nur die vermittelten
Gefunden am 25.09.2026 beim Bau des Podcast-Studios, das dieselbe
Rechnung benutzt, und dort im echten Browser gemessen:
Failed to construct 'RTCPeerConnection': Both username and credential
are required when the URL scheme is "turn" or "turns".
`new RTCPeerConnection(...)` WIRFT. Die Folge ist nicht "kein
Vermittlungsserver", sondern KEIN ANRUF -- auch nicht der, der direkt
zustande gekommen waere. Aus einem Randproblem (etwa jeder Fuenfte
braucht Vermittlung) waere ein Totalausfall fuer alle geworden,
ausgeloest davon, dass /etc/coturn-workspace.geheimnis einmal nicht
lesbar ist: Rechte verstellt, beim Neuaufbau vergessen, Datei leer.
server/workspace-turn.js laesst solche Eintraege bewusst stehen, damit
der Grund nicht verschwindet ("KEIN STILLES WEGLASSEN"). Das ist dort
richtig -- es heisst aber, dass im Browser aussortiert werden muss,
bevor die Verbindung gebaut wird. Genau das fehlte. Der Kommentar
daneben behauptete "ein turn: ohne Passwort schadet nicht"; das war
nie gemessen und ist falsch.
Zwei Aenderungen in workspace/assets/js/anruf.js:
1. Beim Uebernehmen der Adressen werden turn:/turns:-Eintraege ohne
Benutzer UND Passwort aussortiert. STUN bleibt -- es kennt gar keine
Anmeldung und ist der Weg, der in den meisten Faellen reicht. Der
Grund geht nicht verloren, er steht weiter in der Konsole (jetzt mit
dem Dateinamen, in dem man nachsehen muss).
2. `adressenFrisch()` sagt bei gesetztem Grund immer "nicht frisch".
Sonst waere die Liste fuer immer frisch: Ohne Zugangsdaten bleibt nur
STUN uebrig, und ein STUN-Eintrag hat keinen Ablaufzeitpunkt --
`every()` sagt dann "alles gueltig" und es wird nie wieder gefragt.
Waere die Datei auf dem Server repariert, telefonierte trotzdem
niemand mehr mit Vermittlung, bis er die Seite neu laedt. (Nebenbei
die zweite Falle derselben Zeile: `every()` auf einer LEEREN Liste
ist `true`.)
Geprueft in server/pruef-anruf.mjs: Die Pruefung liest den Filter aus
der ausgelieferten Datei und FUEHRT IHN AUS -- vier Adressen hinein,
zwei brauchbare heraus, mit Gegenprobe, dass er ueberhaupt etwas
wegnimmt. Eine Pruefung, die nur nachsieht, ob irgendwo "filter" steht,
waere auch dann gruen, wenn der Filter das Falsche tut.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
cdb6c46f8b |
Der Chat oeffnet dort, wo das Neue anfaengt -- bei allen sechs Rollen
Filipe: "wenn ich in den chat rein gehe und es neue kommentare gibt, will ich dass mein chat sich da öffnet wo die neuen nachrichten anfangen die ich noch nicht gesehen hab bitte und nicht immer ganz unten. sonst muss man immer hoch scrollen um die neuen zu lesen und das ist scheisse. perfektionier das bei allen rollen." DIE FUNKTION GAB ES SEIT DEM 09.09.2026 -- eine Linie „Ab hier neu" und einen Sprung darauf. Sie hat trotzdem nicht funktioniert, und zwar aus DREI Gruenden, die sich gegenseitig verdeckt haben. Gefunden hat sie keine Ueberlegung, sondern eine Messung in Pixeln: Wie weit ist die Linie vom oberen Rand entfernt? Ein negativer Wert heisst „darueber", also unsichtbar. 1. DER SPRUNG RECHNETE GEGEN DEN FALSCHEN PUNKT. `linie.offsetTop` ist der Abstand zum `offsetParent` -- und das ist nur dann der Verlauf, wenn dieser `position: relative` traegt. Tut er nicht. Gemessen auf 390 px landete die Linie 23 px OBERHALB des sichtbaren Bereichs: Man musste genau das tun, was Filipe nicht mehr tun wollte. Am Rechner stimmte es zufaellig, weil dort weniger dazwischenliegt -- deshalb ist es nie aufgefallen. Jetzt: Oberkante der Linie minus Oberkante des Verlaufs plus dessen Bildlaufposition. Das gilt immer, egal wer wessen offsetParent ist. 2. JEDES NACHLADEN LOESCHTE DIE LINIE. `gelesenBeimOeffnen` wurde bei JEDEM Aufruf gesetzt, auch beim sanften Nachladen. Sanft laedt der Verlauf staendig nach -- vor allem, wenn der Ereignisstrom sich verbindet. Die Seite laedt, zeichnet, meldet „gelesen bis hier", der Strom verbindet sich, laedt sanft nach -- und jetzt steht in `gelesen_bis` schon die letzte Nachricht. Keine Linie mehr, Sprung ans Ende. DAS IST DER FEHLER, DEN FILIPE GESEHEN HAT. Und er wuerfelte: Kommt die Verbindung vor dem ersten Zeichnen, passiert nichts; danach ist die Linie weg. Ueber sechs Rollen gemessen waren mal drei rot, mal zwei, mal andere -- bei unveraendertem Code. 3. UND EIN EINZIGER SPRUNG REICHT NICHT. Zwischen Sprung und fertigem Bild waechst die Hoehe noch: Schriften kommen an und setzen den Text um, Bilder melden ihre Groesse. Jetzt wird nachgezogen -- nach den Schriften, nach jedem Bild, nach zwei Bildwiederholungen -- und die Stelle haelt, bis der Mensch selbst scrollt. „Ich habe dich an die neue Stelle gesetzt" ist eine Zusage; sie beim naechsten Nachladen zu brechen waere schlimmer, als sie nie gegeben zu haben. GEMESSEN -- server/pruef-chat-neu-stelle.mjs (neu), 63 Pruefungen, 0 Fehler, zweimal hintereinander mit demselben Ergebnis: Sechs Rollen in beiden Haeusern (DogFather, rechte Hand, linke Hand, Modi auf crew.; Manager und Creator auf workspace.), je auf Handy (390 px) und Rechner (1280 px). Je Blick: Steht die Linie im Verlauf? Ist sie zu SEHEN? Steht Zusammenhang darueber? Und ist der Verlauf NICHT am Ende? Ergebnis: 115-118 px unter dem oberen Rand am Handy, 150-153 px am Rechner -- darueber jeweils die letzte alte Nachricht. Dazu drei Gegenproben: Ohne Ungelesenes gibt es keine Linie und der Verlauf steht am Ende (sonst laendete man grundlos mitten im Verlauf); und die Messung erkennt „nicht sichtbar" auch wirklich (-1403 px an einem absichtlich nach unten gescrollten Verlauf) -- sonst waere jede gruene Zeile darueber wertlos. DIE PRUEFUNG SELBST HAT ZWEIMAL DAS FALSCHE GEMESSEN, bevor sie das Richtige maass, und beides steht als Begruendung darin: Sie schickte `/gelesen` ohne `bis` (die Route verlangt eine Nummer und lehnt sonst ab -- der Lesestand blieb null, die Linie entstand nie), und sie benutzte einen Raum je Rolle fuer zwei Blicke, was einen Wettlauf mit der „gelesen"-Meldung erzeugte. Jetzt bekommt jeder Blick seinen eigenen Raum: mehr Aufbau, dafuer immer dasselbe Ergebnis. pruef-chat 63/0, pruef-chat-optik 62/0, pruef-chat-kanaele 81/0, pruef-treffchat 110/0, pruef-chat-neu 36/0, pruef-pin-fuer-mich 37/0, pruef-erwaehnung 129/0, pruef-gifs 17/0. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
9d219e17ce |
Ein Bild vom Aushang: zwei Knoepfe, und man sieht welcher mehr bewirkt
server/mess-aushang.mjs zeigt, was pruef-pin-fuer-mich nicht messen kann -- wie die zwei Knoepfe nebeneinander aussehen. Drei Blicke: DogFather auf dem Handy (beide Knoepfe), ein Modi auf dem Handy (nur einer), DogFather am Rechner. Gemessen: „lösen" 52x50 in Grau, „bei allen" 68x50 in der Warnfarbe des Hauses. Beide ueber 44 px hoch, beide im Bild, und auf den ersten Blick unterscheidbar -- genau darum ging es: Zwei gleich aussehende Knoepfe nebeneinander waeren die schlechteste Loesung. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
bf3c7bd718 |
Einen Aushang loest jeder fuer sich -- fuer alle nur DogFather und die rechte Hand
Filipe: "jeder soll das fixierte individuel für sich lösen können aber
niemals so dass es sich für alle löst. außer dogfather macht es oder die
rechte hand dan ist es bei jedem weg ansonsten sollen alle anderen
rollen es individuell für sich lösen können. dogfather und die rechte
hand sollen die option haben für sich selbst oder für alle zu lösen."
BIS HEUTE GAB ES NUR EIN LOESEN, UND DAS GALT FUER ALLE. Wer den Knopf
sah, nahm damit jedem im Raum den Aushang weg; wer ihn nicht sah, musste
die Ansage vom Montag bis Freitag ueber jedem Gespraech stehen lassen.
JETZT ZWEI KNOEPFE AM AUSHANG:
"lösen" nimmt ihn nur bei MIR weg -- jeder darf das, ohne
Rueckfrage. Umkehrbar: Das Menue an der Nachricht holt
ihn mit "wieder oben" zurueck. Eine Rueckfrage vor etwas
Umkehrbarem lernt man wegzuklicken, und danach klickt man
auch die weg, die zaehlt.
"bei allen" nimmt ihn jedem weg -- nur fuer DogFather und die rechte
Hand, und MIT Rueckfrage. Er traegt die Warnfarbe des
Hauses: Zwei gleich aussehende Knoepfe nebeneinander
waeren die schlechteste Loesung, man traefe den falschen
und merkte es erst, wenn jemand fragt, wo die Ansage
hin ist.
EIN EINZIGER KNOPF MIT AUSWAHLFENSTER waere kuerzer und schlechter: Der
haeufige Fall ("weg damit, kenne ich") braeuchte dann zwei Klicks, und
der seltene, folgenreiche waere genauso weit entfernt wie der harmlose.
WAS NICHT IN FILIPES SATZ STEHT UND TROTZDEM NOETIG IST: Wer einen
Aushang SELBST angeheftet hat, darf ihn auch selbst wieder fuer alle
loesen. Sonst entsteht eine Sackgasse -- es haengen hoechstens drei,
und eine Gruppenleitung, die drei angeheftet hat und keinen abnehmen
darf, koennte nie wieder etwas anheften. Sie nimmt damit nur zurueck,
was sie selbst getan hat; das ist die Kehrseite derselben Erlaubnis,
keine neue.
TECHNISCH: eine Tabelle `chat_pin_aus` (Nachricht, Person). Kein
Eintrag heisst sichtbar -- nicht umgekehrt, sonst muesste beim Anheften
fuer jeden Teilnehmer eine Zeile entstehen und wer spaeter dazukommt,
saehe den Aushang nie. Der Verbund steht in der Abfrage und nicht im
Browser: Eine Liste, die alles schickt und im Browser gefiltert wird,
ist eine Liste, die alles schickt.
GEMESSEN -- server/pruef-pin-fuer-mich.mjs (neu), 37 Pruefungen, 0 Fehler:
- Der Modi nimmt sie bei sich weg. BEI DOGFATHER UND BEIM ZWEITEN
MODI HAENGT SIE WEITER -- das ist der Kern des Auftrags, und er
laesst sich nur mit mehreren Anmeldungen messen.
- Er holt sie zurueck; zweimal wegnehmen ist kein Fehler.
- Er kann NICHT fuer alle loesen (403), und die Absage sagt, was
stattdessen geht.
- Die rechte Hand loest fuer alle -- danach ist sie bei jedem weg.
- Wer selbst angeheftet hat, loest seinen eigenen (200) und den von
DogFather nicht (403).
- Das Nachruecken stimmt: Wer einen von dreien weggenommen hat, sieht
zwei, waehrend DogFather drei sieht.
- Drei Gegenproben: fremder Raum 404, ohne Anmeldung 401, erfundene
Nummer 404.
DIE PRUEFUNG MUSSTE AUF node:http UMGEBAUT WERDEN. Sie braucht
Team-Dogi-Rollen, die es nur auf der Crew-Adresse gibt -- und den
`Host`-Kopf laesst `fetch` nicht setzen (verbotener Kopf, undici
verwirft ihn stumm). Die Anfrage kam auf 127.0.0.1 an, waehrend
`Origin` die Crew-Adresse nannte; jede schreibende Anfrage bekam 403
"fremde_herkunft". Im ersten Lauf sah das aus, als sei die neue Route
kaputt.
AUSSERDEM IN DIESER RUNDE: Die drei Faecher im Chat (Personen, Gruppen,
Kanaele) waren 38 px hoch statt 44. Gefunden vom Handy-Rundgang bei
jeder Rolle -- aber erst, seit der Sammellauf auch die Zeile UNTER dem
Befund mitschreibt. Vorher stand dort nur "1 Befund".
Die Schemaaenderung auf einer Kopie der echten Datenbank durchgespielt:
72 Tabellen, keine Zeile und keine Spalte verloren, chat_pin_aus da.
pruef-chat 63/0, pruef-chat-optik 62/0, pruef-chat-kanaele 81/0,
pruef-treffchat 110/0, pruef-chat-neu 36/0, pruef-handy-teamdogi
0 Befunde, pruef-css-klassen gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
a06184f24f |
Der Name auf der Teamseite hatte null Pixel -- und drei Messungen waren stumpf
Weiter am Rundumcheck, diesmal der Handy-Rundgang. Von sechs Befunden war einer ein echter Layoutfehler, zwei waren zu kleine Schrift, und drei kamen daher, dass die Messung etwas nicht unterscheiden konnte. === AUF DEM HANDY KAPUTT === 1. DER NAME IN DER PERSONENKARTE WAR NULL PIXEL BREIT. Gemessen auf 412 px: `h3.tperson__name` mit `w=0` bzw. `w=15`. Der Name stand als Buchstabensaeule da oder gar nicht -- auf der Seite, die von Menschen handelt. `.tperson__text` trug `flex: 1; min-width: 0`. Das erlaubt dem Textblock, auf null zu schrumpfen, und Flexbox schrumpft lieber, als umzubrechen -- die Pille „zuletzt gesehen" daneben blieb stehen und nahm allen Platz. `min-width: 0` war trotzdem richtig gemeint (ohne sie blaeht ein langes Wort den Kasten auf); es fehlte nur die Untergrenze. Jetzt `min(14ch, 100%)`: vierzehn Zeichen, wenn so viel Platz ist, sonst der ganze Platz, der da ist. Die Pille bricht um -- `flex-wrap: wrap` stand am Kopf ohnehin schon, es fehlte nur der Grund, es zu benutzen. 2. ZWEI BESCHRIFTUNGEN UNTER DER LESBARKEITSGRENZE. `.u-weg__marke` 10,88 px, `.u-weg__aus` 11,2 px -- die Hausgrenze sind 11,5. Der Reflex dahinter: Eine Marke soll leise sein, also macht man sie klein. Leise wird sie aber durch Farbe und Gewicht; eine Schrift, die man nicht lesen kann, ist nicht leise, sondern weg. Derselbe Griff ist mir gestern dreimal an einem Tag passiert. === DREI MESSUNGEN, DIE ETWAS NICHT UNTERSCHEIDEN KONNTEN === 3. `pointer-events: none` IST KEIN BERUEHRZIEL. Die Terminpunkte im Monatsraster des Kalenders sind 8 x 8 px und nehmen ausdruecklich keine Beruehrung an -- angetippt wird die ZELLE. Sie als „zu klein" zu melden ist, als beanstande man die Groesse eines gemalten Knopfs. `pruef-breiten` kennt die Ausnahme seit jeher; im Handy-Rundgang hat sie gefehlt. 4. `font-size: 0` IST KEINE KLEINE SCHRIFT, SONDERN KEINE. Dieselben Punkte: Die Schrift wird auf null gesetzt, die Farbe bleibt. Gemeldet wurde „0px, zu klein". Die Grenze nach unten bleibt scharf -- alles zwischen 0,1 und 11,5 px ist weiterhin ein Befund, nur die glatte Null faellt heraus. Sie ist eine Aussage, keine Nachlaessigkeit. 5. `scrollWidth > clientWidth` SAGT BEI INLINE-ELEMENTEN NICHTS. Chromium liefert dort fuer `clientWidth` glatt null, und damit ist jeder Text breiter als sein Kasten. Der richtige Umgang mit einer unmoeglichen Messung ist, sie nicht zu machen -- nicht, ihr Ergebnis zu glauben. Dazu: Was per `clip-path: inset(50%)` fuer das Auge weggenommen ist (echte <select> unter selbst gebauten Umschaltern, Beschriftungen zu Symbolknoepfen), kann nicht abgeschnitten sein. === UND EINE MELDUNG, DIE JETZT SAGT, WO MAN SUCHEN MUSS === „abgeschnitten: Mara (18>0)" hat mich zwanzig Minuten gekostet -- drei Vermutungen, drei Messungen. Die Meldung nennt jetzt Element, Klasse, Darstellungsart und Breite: „Mara (18>0, h3.tperson__name, block, w=0)". Damit war der Fall in einem Blick klar. Eine Pruefung, die nur sagt DASS etwas ist, ist eine halbe. GEMESSEN: pruef-breiten 0 Fehler (9 Breiten, 38 Seiten), pruef-team 51/0, pruef-tippziele 11/0, pruef-css-klassen 33/0. Im Handy-Rundgang bleiben die Kopfleisten-Befunde bei 360/390/412 px -- die nehme ich mir als Naechstes vor, sie brauchen einen Umbau und keine Korrektur. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
f7276172d0 |
Drei Fehlalarme, die auf echte Stellen zeigten -- und keiner war ein Fehler
Weiter am Rundumcheck. Diese Runde hat KEINE Zeile am Programm
geaendert: Alle drei Befunde kamen aus den Pruefungen selbst. Das ist
kein Trost, sondern die unangenehmere Sorte -- ein Fehlalarm nennt eine
echte Stelle und eine plausible Zahl, und man sucht danach am richtigen
Code.
1. EIN FARBFORMAT, DAS DIE MESSUNG NICHT KANNTE.
`pruef-neue-seiten` meldete auf treff-regeln.html einen Kontrast von
1,07 -- praktisch unsichtbarer Text. Nachgemessen an Ort und Stelle:
dunkler Text auf HELLBLAUER Flaeche, rund 10:1.
Chromium gibt eine Farbe, die aus `color-mix()` entstanden ist, als
`color(srgb 0.37 0.78 0.97)` zurueck -- Werte von 0 bis 1, keine
Kommas. Die Messung las nur `rgba?(...)`, fand die Flaeche des
Sprunglinks nicht, ging zum fast schwarzen Elternteil weiter und
rechnete dunkel gegen dunkel. Im Haus ist `color-mix` ueberall.
Der Farbleser kennt jetzt beide Formate und faehrt vier Proben mit
(rgb, rgba, color(srgb), color(srgb / alpha)) -- dazu eine fuenfte,
die beweist, dass er bei Unbekanntem NICHTS liefert. Ein Leser, der
im Zweifel Schwarz zurueckgibt, waere schlimmer als der alte: Er
wuerde nie wieder auffallen.
2. EINE SEITE, DIE ZU KURZ WAR, UM "GEFUELLT" ZU HEISSEN.
Dieselbe Pruefung verlangte von jeder Seite mehr als 400 Zeichen
Text. entwicklung.html hat 350 -- seit dem Umbau, bei dem aus
achtzehn Zahlenkaesten zwei Personenkacheln mit einem Ring wurden.
Die Seite sagt seither mehr und braucht weniger Worte; die Pruefung
bestrafte damit genau die Verbesserung.
Jede Seite darf jetzt sagen, woran man sieht, dass sie da ist: eine
Zeichenzahl, wo Text die Sache ist -- ein MERKMAL (".e-person",
mindestens zwei), wo Struktur die Sache ist. Eine Zahl kann beides
nicht unterscheiden.
3. EIN ABSCHNITT, DER SPAETER KAM ALS DIE MESSUNG.
"Die rechte Hand sieht ihre eigene Karte" war rot -- versteckt,
obwohl der Server `hat_karte: true` sagte. Von Hand nachgesehen
stand sie da. Die Entwicklungsseite laedt nacheinander (Aufgaben,
Vorlagenbrett, eigene Karte), und zwischen zwei Schritten kann es
laenger als 600 ms still sein -- die Ruheregel der Pruefung hielt
das fuer "fertig". Jetzt wartet sie zusaetzlich auf den einen
Abschnitt, der sich selbst aufdeckt, hoechstens zwei Sekunden.
Nebenwirkung: Der Vergleich "zwei verschiedene Bildschirme" misst
jetzt 632 gegen 1191 Zeichen statt 350 gegen 350.
109 Pruefungen, 0 Fehler (vorher 8).
4. UND EINE FESTE ZAHL, DIE MIT DER SEITE GEWACHSEN IST.
`pruef-buehne` erlaubte hoechstens ZWEI Texte, um die herum kein
freier Untergrund zu finden ist. treff-regeln.html hat inzwischen
40 Textstuecke, drei davon stehen dicht -- 7,5 %. Die Sorge dahinter
bleibt richtig (eine Pruefung, die kaum hingesehen hat, darf nicht
"bestanden" sagen), aber das ist eine Frage des ANTEILS: zwei von
vier waere schlimm, drei von vierzig ist es nicht. Jetzt: zwei
immer erlaubt, darueber ein Zehntel -- und die Meldung nennt die
Textanfaenge, damit man in einer Sekunde sieht, worum es geht.
ZWEI NEUE WERKZEUGE, beide aus der Not dieser Runde entstanden:
mess-farbe-am-text.mjs -- liest die Farben an Ort und Stelle aus und
geht die Elternkette hoch bis zur ersten
deckenden Flaeche
mess-seiteninhalt.mjs -- zeigt, was auf einer Seite wirklich steht,
mit ROLLE=hand auch mit fremden Augen
GEMESSEN: pruef-neue-seiten 109/0, pruef-buehne alles in Ordnung.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
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]>
|
||
|
DogFatherGitandClaude Opus 5
|
39ca642a52 |
Acht Pruefungen standen Nacht fuer Nacht als rot da -- sie waren gruen
Der naechtliche Lauf meldete heute frueh "37 Pruefungen sind rot".
Acht davon waren gar nicht rot: fehlerfrei durchgelaufen, Exitcode 0,
keine einzige FEHL-Zeile. Der Laeufer zaehlte bei ihnen aber NULL
Einzelpruefungen, und "null Pruefungen ist ein Fehler" -- eine Regel,
die richtig ist und hier das Falsche traf.
DER GRUND WAR EIN GROSSBUCHSTABE. Der Zaehler suchte `(ok|FEHL)`;
pruef-kachelfarben, -livepunkt, -tippziele, -turn-wege, -leerzustand,
-nachfrage, -tagesruf und -anruf-klingelt schreiben ` OK `.
Zwei Schaeden auf einmal:
1. Ihre Punkte fehlten in der Gesamtzahl -- allein in fuenf der acht
sind das 114 Stueck. Ausgerechnet die Zahl, die vor stillen
Aussetzern schuetzen soll, war selbst eine Luecke.
2. Acht dauerhaft rote Eintraege in einer Notiz, die morgens gelesen
wird. Eine Warnung, die immer kommt, ist keine mehr.
Der Zaehler liest jetzt beide Schreibweisen. Die Dateien werden NICHT
vereinheitlicht: Acht umzuschreiben waeren acht Gelegenheiten, etwas
kaputtzumachen -- und die neunte, die morgen jemand anlegt, schreibt
ohnehin wieder, was sie will.
DAZU EINE PRUEFUNG, DIE DAS FESTHAELT (server/pruef-pruefzaehler.mjs).
Ein Kommentar haette den naechsten Fall nicht verhindert. Sie holt
sich den Ausdruck AUS alles-pruefen.mjs (zwei Fassungen desselben
Musters laufen auseinander), startet vier der schnellsten Pruefungen
wirklich -- je zwei in beiden Schreibweisen -- und hat drei
Gegenproben: Sie darf nicht wahllos zaehlen, sie muss zwei als zwei
zaehlen, und sie muss null als null sehen koennen, sonst waere "null
ist ein Fehler" blind.
UND DIE NOTIZ SAGT JETZT, WAS SIE MEINT. Statt "(keine Fehlerzeile
gefunden)" steht bei diesen Faellen: "Kein Befund -- es wurde keine
einzige Pruefung GEZAEHLT", mit der Erklaerung dazu. Fuer alles andere
ohne Fehlerzeile gibt es den dritten Ausgang ("Konnte nicht sagen,
woran es lag") samt den letzten Ausgabezeilen.
NEBENBEFUND, GEFUNDEN VON pruef-rueckmeldung: Die Tuer ins andere Haus
trug Ton 40 -- dieselbe Nummer wie "Entwicklung". Auf DogFathers Wand
standen zwei Kacheln in derselben Farbe, und er ist der Einzige, der
beide sieht; deshalb ist es nie jemandem aufgefallen.
Die naheliegende Antwort waere eine 46. Farbe gewesen. Gerechnet kam
ein Abstand von 0,0862 heraus -- unter der Hausgrenze von 0,09. Der
Farbraum ist bei 45 Toenen voll, und eine zweite benannte Ausnahme
am selben Tag waere der Anfang vom Ende der Regel.
Richtig ist die andere Antwort: Die Tuer ist gar keine
Bereichskachel. Sie fuehrt hinaus und gehoert keinem Bereich an --
also bekommt sie keine Bereichsfarbe, sondern faellt auf --akzent
zurueck. Damit unterscheidet sie sich von allen 45 anderen.
Gefunden hat das die Pruefung erst, nachdem sie SAGEN konnte, welche
Nummer doppelt ist. Vorher stand dort nur "kein Farbton doppelt (34
Kacheln vom Server)" -- damit sucht man in vier Listen ueber zwei
Dateien.
Dazu: start.js schreibt kein data-ton="undefined" mehr (String()
macht aus einem fehlenden Wert sonst ein Wort, und jede Pruefung,
die Toene zaehlt, liest dann Text statt Zahl).
WAS MICH VOR DER FALSCHEN REPARATUR BEWAHRT HAT: Meine erste Vermutung
war, die FEHL-Zeilen staenden zu weit hinten im Ausgabefenster. Die
Gegenprobe dazu wurde rot -- null Dateien. Genau dafuer ist sie da.
GEMESSEN:
- pruef-pruefzaehler (neu): 7 Pruefungen, 0 Fehler.
- pruef-rueckmeldung: 30 geprueft, 0 Fehler (war rot).
- pruef-kachelfarben 26/0, pruef-haus-trennung 100/0,
pruef-crew-adresse 153/0.
- tools/.nachtlauf-* ist jetzt ignoriert: Laufzeitzustand, der sich
jede Nacht aendert. Das Ergebnis steht in der Vault-Notiz.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
257c01b8f0 |
Support: Babyblau mit Lila, und der Melder bekommt seine Knoepfe wirklich
Nachtrag zu
|
||
|
DogFatherGitandClaude Opus 5
|
cebdd88e8d |
Support: der Melder hat das letzte Wort -- und die Kachel bekommt ihren eigenen Stil
Filipe: "ich will dass die leute die mir was geschickt haben im support, auch meine notiz bekommen wenn ich fertig bin. damit die bescheid wissen und dan anklicken koennen, es funktioniert, oder noch nicht. und erst wenn es funktioniert gedrueckt wird, will ich dass alles richtig fertig ist. perfektionier den ganzen weg und mit dem gedanken das manchmal sachen mehrmal nicht sofort perfekt sein werden." DER GANZE WEG, nicht nur der Schlusspunkt: 1. Die Leitung drueckt "Behoben - nachfragen ...". Der Knopf hiess vorher "Erledigt ..." und tat auch das; jetzt stellt er eine Frage, also heisst er auch so. Eine Beschriftung, die etwas anderes sagt als der Knopf tut, glaubt man genau einmal. 2. Die Meldung steht auf "wartet" -- ein vierter Stand zwischen "wird bearbeitet" und "erledigt". Beim Melder heisst er "geht es wieder?", weil er aus SEINER Sicht keine Wartezeit ist, sondern eine Frage. 3. Er sieht die Notiz und zwei Knoepfe. "Geht wieder" ohne Rueckfrage (der haeufige, harmlose Fall). "Noch nicht" verlangt ein Wort -- sonst faengt die Suche von vorn an und die naechste Runde waere dieselbe wie die letzte. 4. "Noch nicht" ist keine Beschwerde, sondern Runde 2: zurueck in Arbeit, Rundenzahl plus eins, Leitung bekommt eine Nachricht, und der Verlauf behaelt, was beim letzten Mal versucht wurde. Niemand faengt von vorn an -- genau der Fall, den Filipe genannt hat. 5. Erst sein "Geht wieder" schliesst die Meldung. Danach kann weder er noch die Leitung sie wieder aufmachen (409). NUR DER MELDER darf bestaetigen, ausdruecklich nicht die Leitung (`person_id !== req.person.id`, nicht "ist Leitung") -- sonst nickt sie ihre eigene Arbeit ab und der ganze Umweg waere Zierde. Eine fremde Meldung gibt 404, nicht 403: Wer sie nicht sehen darf, soll auch nicht erfahren, dass es sie gibt. DER VERLAUF STEHT UNTEREINANDER statt nur der letzten Antwort. Bei Runde drei war sonst nicht mehr zu sehen, was beim ersten Mal versucht wurde, und genau das loest einen wiederkehrenden Fehler. Meldungen von vor diesem Umbau haben keinen Verlauf -- die zeigen wie bisher ihre blosse Antwort, ein leerer Kasten waere schlechter als der alte Satz. DIE KACHEL SIEHT ANDERS AUS (zweiter Wunsch: "viel geiler viel profissioneller ... die hauptfarbe soll babyblau sein mit bissl lila"). `support-seite` traegt den Stil; alle Regeln haengen daran und gelten damit nur hier. Zwei weiche Lichter, Pillen statt Kaesten als Filter, eine leuchtende Naht ueber dem Meldefeld. Augenschonend: gedeckt, kein Neon, Kontrast geprueft. GEMESSEN: - pruef-support: 45 -> 58 Pruefungen, 0 Fehler. Der ganze Weg einmal durch, MIT einer Runde, die schiefgeht. Dazu drei Gegenproben: die Leitung kann nicht fuer den Melder bestaetigen (404), "noch nicht" ohne Wort wird abgelehnt (400), eine geschlossene Meldung bleibt zu (409, aus beiden Richtungen). - Die Schemaaenderung auf einer KOPIE der echten Datenbank durchgespielt: 72 Tabellen, keine Zeile und keine Spalte verloren, support_runden und `runde` da, 'wartet' in der CHECK-Regel. - pruef-css-klassen, pruef-deutsche-texte, pruef-code, pruef-glocke: alle gruen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
939aa6371b |
Zutragen geht jetzt direkt am Punkt -- ein Griff statt eines Fensters
Filipe: "ich will sofort über diese aufgaben da spezifisch zuteilen kann bitte. bei allen personnen." DAS AUSWAHLFENSTER BLEIBT -- es ist der Weg, wenn man jemanden neu einrichtet und zwoelf Punkte auf einmal vergibt. Der Knopf am Punkt ist der andere Fall, und der haeufigere: Man liest eine Beobachtung, denkt "das soll er machen", und will es in dem Moment erledigen -- nicht ein Fenster aufmachen, in einer Liste von 68 denselben Punkt suchen und wieder zumachen. AUS DER MARKE WIRD DER SCHALTER. An derselben Stelle, an der bis eben nur "Aufgabe" stand, sitzt jetzt der Knopf, mit dem man es tut. Er steht IMMER da, auch wenn nichts zugetragen ist: Auf einem Handy gibt es kein Ueberfahren, und einen Knopf, der erst beim Zeigen erscheint, gibt es dort nicht. Im Ruhezustand ist er ein Umriss -- 68 gefuellte Kaestchen untereinander waeren ein Balken. EIN PUNKT, EIN AUFRUF -- und das ist nicht nur Bequemlichkeit: Wuerde dieser Knopf die ganze Liste schicken (wie das Fenster), loeschte er die Zutragung, die jemand anderes eine Sekunde vorher gemacht hat. Genau das misst die Pruefung: erst zutragen, dann nachsehen, ob die vorherigen unberuehrt sind. ZWEIMAL DASSELBE IST KEIN FEHLER. Wer zweimal tippt oder zwei Fenster offen hat, bekommt denselben Zustand -- nicht eine Absage und nicht einen doppelten Eintrag (`ON CONFLICT DO NOTHING`). DIE ZAHL KOMMT VOM SERVER ZURUECK und wird nicht im Browser weitergerechnet: Bei zwei offenen Fenstern waere die eigene falsch, und niemand saehe, warum. Kopf, Ring und Kachel ziehen damit sofort nach -- ohne Neuladen und ohne Sprung. EIN FUND AM WERKZEUG, eine Ebene tiefer: tools/_um.py stellt Anker auf die Zeilenenden der Datei um -- und entwicklung.css hat GEMISCHTE (Bestand CRLF, ein angehaengter Block LF). Der Anker wurde auf CRLF gestellt und traf den LF-Teil nicht; die Meldung lautete "Anker 0x", und man sucht den Fehler im Anker, obwohl er Zeichen fuer Zeichen stimmt. Genau die Sorte Fehlalarm, gegen die dieses Werkzeug gebaut wurde. Es probiert jetzt beide Arten und ersetzt mit der, die an der Fundstelle gilt. Geprueft: pruef-entwicklung 63 -> 70 Punkte, darunter zwei Gegenproben (ein erfundener Punkt wird abgewiesen, ein Modi traegt nichts zu). pruef-tippziele (11) und pruef-css-klassen unveraendert gruen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
177c3c012a |
Die Bildschau und 2520 Farben statt 360
=== 1. BILDER OEFFNEN SICH MITTIG, MIT HUSKY UND HASE ===
Filipe: "wenn man bilder aufmacht, will ich dass die in der mitte sind.
beim hochformat soll links der husky sein und rechts der hase und beim
querformat soll oben dogfather und unten team dogi stehen da wo platz
ist ... ich will nicht dahin geschmissen sondern was richtig geiles mit
einem geilen hintergrund."
WAS VORHER PASSIERTE, und es war kein Fehler im Code: Der Klick fuehrte
auf die DATEI. Was man dann sah, war die eingebaute Bildanzeige des
Browsers -- schwarzer Grund, Bild oben links in der Ecke, auf seinem
Bildschirmfoto 1200 px Schwarz daneben. Eine Datei hat keine
Gestaltung. Wer Gestaltung will, muss eine SEITE zeigen.
Die Schau liegt jetzt UEBER dem Chat. Escape bringt einen dorthin
zurueck, wo man war, und das Gespraech laeuft im Hintergrund weiter --
ein zweiter Tab braeuchte eine eigene Seite, eine eigene Anmeldung und
einen eigenen Weg zurueck.
DER WEG IN DEN TAB BLEIBT TROTZDEM. Der Verweis hat unveraendert
`href`, `target` und `rel`; mittlere Maustaste, "In neuem Tab oeffnen"
und Herunterladen gehen wie seit jeher. Abgefangen wird nur der
gewoehnliche Klick -- und auch der nur, wenn die Schau geladen ist.
Wer Strg, Umschalt oder Befehl haelt, bekommt den alten Weg; das sind
die Griffe, die Leute seit zwanzig Jahren benutzen.
DIE BEGLEITER STEHEN DA, WO PLATZ IST -- und die Antwort darauf wird
GEMESSEN, nicht geschaetzt: nicht die Fensterbreite, sondern der Rest
neben dem Bild, nachdem es eingepasst ist. Eine Schwelle wie "ab
1100 px" waere fuer ein 3:4-Foto richtig und fuer ein 9:16-Foto auf
demselben Schirm falsch. Unter 170 px bleibt der Husky weg: Eine Figur,
die ein Streifen ist, steht besser nicht da.
Husky und Hase sind eigens verkleinert (2,1 MB und 1,0 MB werden 40 kB
und 32 kB) und bekommen weiche Raender -- ihr Hintergrund ist dunkel,
aber nicht durchsichtig; als Rechteck saehe man zwei Kaesten.
Der erste Anlauf spiegelte den Hasen, damit beide "nach innen" schauen
-- ein alter Reflex aus dem Plakatsatz. Auf dem Probebild stand danach
"Hasi Dog" seitenverkehrt auf seinem Hoodie. Schrift im Bild spiegelt
man nie.
pruef-chat-anhaenge bekommt 14 neue Punkte, darunter beide Formate und
zwei Gegenproben: Strg+Klick oeffnet die Schau NICHT (sonst hiesse "sie
geht auf" nur, dass der alte Weg verloren ist), und im Hochformat liegt
KEINE der Figuren ueber dem Foto.
NEBENBEFUND, den die Pruefung gefunden hat: Die Sprachnachricht war auf
165 px geschrumpft -- zu schmal fuer den Schieber. Ursache war keine
Aenderung an ihr, sondern eine Folge: Die Blase ist so breit wie ihr
breitester Inhalt, und seit die Handgriffe darunter Zeichen statt
Woerter sind (123 statt ueber 400 px), bestimmt das Abspielgeraet die
Breite selbst. Eine Reihe kuerzer zu machen hat einen Schieber schmaler
gemacht, drei Bildschirme weiter.
=== 2. DER FARBKREIS: HELLER UND DUNKLER ===
Filipe: "dieser kreis muss viel perfekter sein. ich will dass die leute
auch heller und dunkler aussuchen koennen ... so dass die leute viel
krassere moeglichkeiten haben."
WARUM DAS BIS HEUTE NICHT GING: Die 360 Toene liegen alle auf DERSELBEN
Leuchtdichte. Das war kein Zufall -- solange die Blase in der gewaehlten
Farbe stand, musste jede dieser Flaechen dieselbe Schrift tragen. Eine
hellere Farbe zuzulassen hiesse damals: irgendwo wird eine Nachricht
unlesbar.
SEIT DEM 25.09.2026 IST DIE BEDINGUNG EINE ANDERE. Die Blase ist fuer
alle dunkles Glas; der Ton ist Kante und NAME. Damit faellt die alte
Regel weg, und an ihre Stelle tritt: der Ton muss als Name auf dem
Blasengrund lesbar bleiben.
DIE ZAHLEN SIND GEMESSEN, NICHT GEWAEHLT. Ueber alle 360 Winkel, jeweils
der schlechteste Fall:
40 % schwarz 4,468 -- unter der Schwelle, faellt raus
34 % schwarz 4,555 -- ginge, aber ohne Reserve
30 % schwarz 4,619 <- die dunkelste Stufe
0 % 5,12 <- die Mitte, der alte Kreis
55 % weiss 9,6 <- die hellste Stufe
Sieben Stufen, 2520 Farben statt 360. pruef-chat-neu rechnet jede
einzelne nach -- die knappste hat 2,6 Prozent Reserve.
DIE ALTEN SCHLUESSEL BLEIBEN GUELTIG. "ton-214" heisst weiterhin genau
dieselbe Farbe; die Stufe steht als Zusatz dahinter ("ton-214-s6"). Wer
seit dem 23.09. eine Farbe traegt, traegt nach diesem Umbau dieselbe.
DIE PROBE IN DER MITTE ZEIGT ENDLICH, WAS MAN BEKOMMT. Dort stand eine
gefuellte Flaeche mit heller Schrift -- so sah die Blase bis heute frueh
aus. Jetzt steht dort derselbe Blasengrund und darauf der Ton als Name,
mit genau der Rechnung aus chat.css. Das ist nicht nur ehrlicher, es
macht die sieben Stufen erst moeglich: Eine gefuellte Flaeche muesste
Schrift tragen, und bei sehr hellen Toenen schafft das keine der beiden
Schriftfarben mehr (4,1 statt noetiger 7). Als Name auf dunklem Grund
ist derselbe helle Ton besonders gut lesbar (8,0).
Der Erklaersatz im Fenster war damit falsch geworden ("Alle Toene
leuchten gleich stark") und sagt jetzt, was stimmt.
ZWEI PRUEFUNGEN WURDEN GENAUER:
pruef-chat-neu mass den HINTERGRUND der Mitte -- eine Darstellung,
die es nicht mehr gibt. Sie misst jetzt die Schriftfarbe und rechnet
die Mischung nach. Dabei stolperte sie ueber eine dritte
Farbschreibweise: Chromium gibt `color-mix`-Ergebnisse als
`color(srgb 0.676 0.645 0.504)` zurueck. Die Zeile war rot, obwohl
die Farbe auf den Bildpunkt genau stimmte -- ein Fehlalarm, der
teurer ist als ein echter Befund, weil man am Aussehen sucht und der
Fehler im Lesegeraet liegt.
Und sie prueft nicht mehr 360, sondern 360 x 7 -- nur den Grundton zu
messen hiesse, sechs Siebtel ungeprueft auszuliefern.
Geprueft: pruef-chat-anhaenge (123), pruef-chat-neu (36),
pruef-chatkachel (40), pruef-chat, pruef-chat-ausbau (69),
pruef-chat-optik, pruef-tippziele (11), pruef-css-klassen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
4b48aa46f6 |
Berichtigt: Die Leitung sieht wieder alle 68 -- gezaehlt wird das Zugetragene
Filipe: "falsch, dogfather und die rechte hand sollen immer noch die 68
sachen sehen wie vorher und der button soll einfach perfektioniert
werden damit wir beide sie den jeweiligen als aufgabe geben koennen.
und die modis sollen nicht sehen. aber unsere sicht von dogfather und
rechte hand soll sich nicht aendern."
MEIN FEHLER WAR EINE VERWECHSLUNG von zwei Dingen, die gleich aussehen
und verschieden sind:
EINGRENZEN -- die Liste wird je Person kuerzer. Das habe ich gebaut.
ZUTRAGEN -- aus der vollen Liste bekommt jemand etwas als AUFGABE.
Das war gemeint.
Der Unterschied zaehlt: Die 68 sind das, woran ihr euch entlanghangelt,
wenn ihr jemanden anseht. Eine Liste, die sich je Person verkuerzt,
waere bei jedem Menschen eine andere -- und dann faellt kein Vergleich
mehr auf.
DIE KARTE ZEIGT WIEDER ALLES, und an jedem Punkt steht, ob er diesem
Menschen als Aufgabe zugetragen ist: eine Kante links und das WORT
"Aufgabe". Nicht nur die Farbe -- wer Farben schlecht unterscheidet,
saehe sonst nur einen etwas anderen Kasten.
GEZAEHLT WIRD TROTZDEM DAS ZUGETRAGENE. Filipe: "es sollen nur die
menge angezeigt werden die wir zutragen und erledigte dan auch nur die
die erledigt wurden von den zugetragenen." Aus "0 von 68 angesehen"
wird "3 von 12 erledigt".
BEIDE HAELFTEN MUSSTEN MITZIEHEN, und das ist die Stelle, an der es
leicht schiefgeht: Die Kachel nahm links die Zahl ALLER
Einschaetzungen. Waere nur das Ganze nachgezogen worden, stuende dort
"13 von 3" -- eine Zahl, die groesser ist als ihr Ganzes, und die
niemand mehr erklaeren kann. Der Verbund mit der Zuteilung steht
deshalb schon in der Abfrage, an drei Stellen: Karte, Uebersicht und
Ring.
NULL ZUGETRAGEN IST KEINE NULL, SONDERN EIN SATZ. "0 von 0 erledigt"
liest sich wie ein Versaeumnis; "noch nichts zugetragen" sagt, was zu
tun ist. Der Knopf heisst jetzt auch, was er tut: "Aufgaben zutragen".
Der leere Kasten, der im ersten Anlauf die ganze Karte ersetzte, ist
weg -- genau der hatte die Sicht der Leitung veraendert.
Geprueft: pruef-entwicklung 61 -> 63 Punkte. Die neuen halten
ausdruecklich fest, was ich falsch gemacht hatte: Die Leitung sieht den
GANZEN Katalog (68), und die Liste bleibt auch nach dem Zutragen
vollstaendig -- nur die Marke wandert. Ohne diese zwei Zeilen waere
dieselbe Eingrenzung beim naechsten Umbau wieder eine Zeile Arbeit und
niemandem aufgefallen. Dazu pruef-css-klassen und pruef-tippziele.
Co-Authored-By: Claude Opus 5 <[email protected]>
|