1082 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
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]>	2026-09-30 16:48:24 +02:00
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]>	2026-09-30 15:45:48 +02:00
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]>	2026-09-30 13:39:55 +02:00
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]>	2026-09-30 12:55:12 +02:00
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]>	2026-09-30 12:14:23 +02:00
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]>	2026-09-30 12:12:32 +02:00
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]>	2026-09-30 11:38:38 +02:00
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]>	2026-09-30 11:27:57 +02:00
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]>	2026-09-30 11:22:14 +02:00
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]>	2026-09-30 11:10:49 +02:00
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]>	2026-09-30 10:52:46 +02:00
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]>	2026-09-30 10:43:42 +02:00
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]>	2026-09-30 10:37:05 +02:00
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]>	2026-09-30 02:36:13 +02:00
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]>	2026-09-29 23:48:46 +02:00
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]>	2026-09-29 17:16:26 +02:00
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	2026-09-29 16:14:13 +02:00
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	2026-09-29 16:00:57 +02:00
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	2026-09-29 14:51:52 +02:00
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.	2026-09-29 14:35:29 +02:00
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	2026-09-29 14:23:57 +02:00
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	2026-09-29 14:04:06 +02:00
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	2026-09-29 13:59:20 +02:00
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.	2026-09-29 13:45:02 +02:00
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.	2026-09-29 13:41:04 +02:00
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.	2026-09-29 13:18:42 +02:00
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	2026-09-29 12:56:03 +02:00
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	2026-09-29 02:34:09 +02:00
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]>	2026-09-28 20:51:30 +02:00
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]>	2026-09-28 20:45:34 +02:00
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]>	2026-09-28 20:12:21 +02:00
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]>	2026-09-28 20:03:38 +02:00
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]>	2026-09-28 19:36:05 +02:00
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 3fedeea7 war der Buehnenmodus (reaktion.html?nur=buehne) kaputt: Leinwand null Pixel hoch, im Stream ein schwarzes Bild. Das ist die Fensterquelle fuer den Fall, dass Gaeste im Bild sind. Ursache: Teil A hat die Zeilen des Saals festgenagelt (#teil-live auf Zeile 2). Im Buehnenmodus stand aber seit jeher eine eigene Regel, die dem Saal nur EINE Zeile gibt -- das Video landete in einer impliziten Zeile, die sich nach ihrem Inhalt bemisst, waehrend die Leinwand ihre Hoehe aus der Zeile nimmt. Beide warten aufeinander, heraus kommt null. Das ist heute der VIERTE Fall von "zwei Regeln fuer dieselbe Frage" (Tafeln, Saalzeilen, Kamerabreite, Buehnenmodus). Die Loesung ist jedes Mal dieselbe: nicht die zweite Regel richtig stellen, sondern sie abschaffen. DREI DINGE, DIE DARAN LEHRREICH SIND: 1. MEINE EIGENE PRUEFUNG WAR GRUEN UND WERTLOS. Ich hatte nach Teil A extra geprueft: "genau eine Regel bestimmt die Zeilen des Saals". Sie verlangte, dass die Zeile mit `.saal` BEGINNT -- und hat `body[data-nur="buehne"] .saal { … }` deshalb nie gesehen. Jetzt zaehlt sie jede Regel, in deren Auswahl `.saal` vorkommt, mit einer Gegenprobe, die eine eingeschobene zweite wirklich findet. 2. EINE SEITE MIT ZWEI ANSICHTEN BRAUCHT BEIDE MESSUNGEN. Nach Teil A liefen `pruef-buehne` (Schnittstelle) und `mess-reaktion` (normale Ansicht). `mess-buehne` -- die einzige, die diese Ansicht ueberhaupt oeffnet -- lief nicht. 3. EIN PYTHON-SKRIPT, DAS ERST AM ENDE SCHREIBT, MELDET "ok" FUER AENDERUNGEN, DIE NIE ANKOMMEN. Eine fehlgeschlagene Zusicherung hat einen ganzen Stapel verworfen, obwohl die erste Aenderung schon bestaetigt war. Die Messung meldete daraufhin "Auf der Karte steht: undefined" -- kein Fehler im Code, sondern eine Zeile, die nie geschrieben wurde. Gefunden hat es die Messung, nicht das Lesen. pruef-spenden 136/0 (vorher 95) - pruef-reaktion 321/0 - 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]>	2026-09-28 18:54:02 +02:00
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]>	2026-09-28 14:35:02 +02:00
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]>	2026-09-28 14:13:07 +02:00
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]>	2026-09-28 10:14:26 +02:00
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]>	2026-09-28 09:48:26 +02:00
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]>	2026-09-28 09:32:10 +02:00
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.	2026-09-28 09:08:59 +02:00
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.	2026-09-28 09:08:42 +02:00
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.	2026-09-28 08:34:42 +02:00
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.	2026-09-28 08:16:49 +02:00
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.	2026-09-28 08:04:07 +02:00
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).	2026-09-28 03:45:15 +02:00
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.	2026-09-28 02:01:32 +02:00
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.	2026-09-28 01:52:22 +02:00
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.	2026-09-27 19:37:06 +02:00
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.	2026-09-27 19:05:48 +02:00
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.	2026-09-27 18:46:53 +02:00