884 Commits

This Branch

This Branch

All Branches

Author	SHA1	Message	Date
DogFatherGitandClaude Opus 5	200728c8e7	Der leere Ring zeigte "100 %" -- das las sich wie "alles geschafft" ... Die Pruefung verlangte prozent === 100, wenn gar nichts zu tun war. Der Gedanke war richtig (ein leerer Ring darf nicht wie Versagen aussehen), die Umsetzung nicht: Gelesen wird zuerst die Zahl in der Mitte, und "100 %" heisst fuer jeden Menschen "fertig". Am ersten Tag, ohne eine einzige Aufgabe, stand das als groesstes Element der Startseite. Seit dem 19.09. steht dort ein Strich. Ein Anteil von nichts ist keine Null und keine Hundert, sondern nicht definiert. Die Pruefung fragt jetzt danach -- und damit gleichzeitig schaerfer: Solange gar keine Zahl dasteht, kann dort auch nicht versehentlich der Uhrzeitwert stehen. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-21 11:44:55 +02:00
DogFatherGitandClaude Opus 5	782a9116f2	Zwei Pruefungen rechneten in UTC und schlugen abends falschen Alarm ... pruef-zeitraum und pruef-highlights bildeten ihren Tagesstempel mit toISOString(). Das ist UTC. Zwischen 22:00 und Mitternacht deutscher Zeit ist das schon der naechste Tag -- die Pruefungen verglichen dann einen Eintrag von heute mit dem Datum von morgen und meldeten einen Fehler, wo keiner war. Der Zeitraum-Filter im Haus rechnet richtig; er benutzt tagLokal() aus helfer-zeit.mjs. Nur die Pruefungen darueber hatten ihre eigene, falsche Rechnung. Jetzt benutzen sie denselben Helfer wie der Code, den sie pruefen -- damit koennen die beiden gar nicht mehr auseinanderlaufen. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-21 11:44:55 +02:00
DogFatherGitandClaude Opus 5	acd3e1f385	Zwei Tabellenumbauten haetten 15 Spalten still geloescht ... `personen` und `aufgaben` wurden beim Freischalten eines neuen CHECK-Werts von Hand neu gebaut -- die Spaltenliste stand zweimal im Code abgeschrieben (CREATE und INSERT). Gemessen: aufgaben: 23 Spalten, 18 aufgezaehlt -> vorlage, kategorie, aus_eintrag_id, aufwand, aus_punkt weg personen: 19 Spalten, 9 aufgezaehlt -> bild, ueber_mich, tiktok, instagram, youtube, twitch, chat_kachel, code_kennung, stufe, alter_bestaetigt_am weg Bei `personen` haengen daran die Profilfotos und die Altersbestaetigung: Alle waeren nach einem Rueckspielen still wieder unbestaetigt gewesen, ohne Fehlermeldung, bei unveraenderter Zeilenzahl. Die Zeilenzaehlung, die als Sicherung gedacht war, kann einen Spaltenverlust gar nicht sehen. Es ist derselbe Fehler wie am 11.09. an der Eintragstabelle (24 hinein, 21 heraus). Damals wurde `checkListeErweitern` gebaut, das die Spalten aus PRAGMA table_info ABLEITET -- eine Liste, die niemand pflegt, kann nicht veralten. Diese beiden Bloecke waren aelter und wurden bei der Umstellung uebersehen. Jetzt gehen alle 16 Umstellungen denselben Weg, kein Neubau zaehlt mehr von Hand. Auf dem laufenden Server ist nichts verloren (24 Spalten, CHECK vollstaendig) -- die Falle stand fuer den Tag, an dem jemand eine Sicherung zurueckspielt. Gefunden hat es nicht das Lesen, sondern pruef-abbrechen: Sie baut absichtlich eine ALTE Datenbank und liess die Umstellung darauf laufen -- danach meldete der Server "no such column: a.aufwand". Neu: pruef-umstellung.mjs (18 Pruefungen) haelt die Fehlerklasse dauerhaft zu. Sie baut eine echte alte Datenbank mit gefuellten Spalten, laesst die Umstellung laufen und zaehlt danach Spalten UND Inhalte. Mit Gegenprobe: ein absichtlich fehlerhafter Umbau zeigt, dass die Zeilenzahl dabei stimmt und trotzdem Daten fehlen. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-21 11:44:45 +02:00
DogFatherGitandClaude Opus 5	0082c74bd7	Versionsstempel nachgezogen ... pruef-zwischenspeicher hat es gemeldet: Der Commit davor hat Stilvorlagen und Skripte geaendert, aber keine HTML -- damit bleibt der Verweis `?v=...` stehen, der Browser haelt seine alte Kopie fuer aktuell (ein Jahr, unveraenderlich), und die Reparatur kaeme bei niemandem an. Genau der Fall, fuer den die Pruefung gebaut wurde: Ein Deploy, der fehlerfrei durchlaeuft und trotzdem nichts ausliefert. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-20 23:14:14 +02:00
DogFatherGitandClaude Opus 5	67a0eb8717	DogFather konnte einen zweiten DogFather nicht mehr herabstufen ... Gefunden beim Durchsehen der schnellen Pruefungen: pruef-haus-trennung stand auf 60 ok / 6 Fehler. Drei Ursachen, eine davon ein echter Rueckschritt von gestern. --- 1. DER RUECKSCHRITT --------------------------------------------- In darfRolleAendern stand seit gestern: if (person.rolle === "admin") return ziel.rolle !== "admin"; Das macht aus "DogFather ist nicht mehr VERGEBBAR" ein "an einem DogFather ist nichts mehr zu aendern". Ein zweiter Zugang liess sich damit nie wieder zuruecksetzen -- er waere fuer immer DogFather geblieben. Die Pruefung sagte es woertlich: "solange es zwei gibt, darf einer wechseln (403)". Die beiden echten Gefahren haengen woanders und bleiben unberuehrt: Niemand KANN 'admin' vergeben, und der LETZTE DogFather laesst sich nicht herabstufen. --- 2. ZWEI SCHLOESSER FUER DIESELBE TUER --------------------------- Ich hatte gestern `rollenZumAendern` mit 403 VOR die vorhandene Pruefung gesetzt, die mit 400 "Unbekannte Rolle." antwortet. Damit war die Luecke wieder offen, vor der der Kommentar vom 17.09. direkt daneben warnt: Zwei verschiedene Antworten -- "gibt es nicht" gegen "darfst du nicht" -- verraten beim Durchprobieren, WELCHE Rollen existieren. Jetzt eine Regel an einer Stelle. `darfAnlegen` ist dort raus, weil Vergeben und Anlegen seit gestern verschiedene Dinge sind. Gemessen: admin anlegen = aendern (sieben Rollen) spicy anlegen = aendern (vier) hand anlegen = — aendern = modi, gast manager anlegen = creator aendern = — Und die eigene Zeile bekommt jetzt 400 mit einem Satz statt 403: Es ist keine Rechtefrage, sondern eine unsinnige Bitte. --- 3. DREI ERWARTUNGEN, DIE AELTER WAREN ALS DIE REGEL -------------- Die Pruefung verlangte 403, wo seit dem 17.09. 400 richtig ist -- ihre Zeile stammt vom 10.09., sieben Tage aelter als die Regel. Und sie verlangte 404 fuer "die rechte Hand vergibt keine Rolle", was bis vorgestern stimmte. Dabei fiel auf, dass NICHTS geprueft hat, ob die rechte Hand ihre neue Faehigkeit ueberhaupt ausueben kann -- nur, dass sie es nicht darf. Eine Pruefung, die nur das Verbotene misst, laesst offen, ob das Erlaubte geht. Jetzt beide Richtungen: an einer anderen rechten Hand aendert sie nichts (403) und an DogFather erst recht nicht (403) einen Modi macht sie sehr wohl zur Community (200) und es steht so in der Datenbank (gast) eine zweite rechte Hand ernennt sie nicht (400) Nebenbei: `unbekannte_kachel` (gestern eingefuehrt) hatte keinen Satz in meldung.js -- die Kennung waere woertlich auf dem Bildschirm gelandet. pruef-meldungen hatte es gemeldet. Und ein Absturz beim Bauen: `const anlegen = await hole(...)` weiter unten im selben Block verdeckt die gleichnamige Funktion im GANZEN Block, auch oberhalb seiner eigenen Zeile. pruef-haus-trennung: 70 ok, 0 Fehler (vorher 60/6). Dazu gruen: rollen-anlegen 11/0, personen-loeschen 40/0, rechte-umstellen 46/0, verteilen 11/0, meldungen 8/0. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-20 23:13:27 +02:00
DogFatherGitandClaude Opus 5	445ea88f2b	fetch verweigert Port 5060 -- und sagt dasselbe wie ein toter Server ... Nach der Umstellung auf abgeleitete Nummern bekam pruef-chat-kanaele die 5060 und stuerzte ab: TypeError: fetch failed Der Server lief nachweislich ("Server laeuft auf http://127.0.0.1:5060"), die Anmeldung ueber `http.request` hatte sogar geklappt, und BASIS war sauber ("http://127.0.0.1:5060", 21 Zeichen, PORT eine Zahl). Nur die `fetch`-Aufrufe scheiterten. 5060 ist SIP und steht auf der "bad ports"-Liste der Fetch-Spezifikation. Node hat sie uebernommen: `fetch` baut dorthin keine Verbindung auf, noch bevor ein Paket fliegt. Die Ursache steht nur in `.cause` -- "bad port" statt "ECONNREFUSED". Die Meldung obendrueber ist beide Male dieselbe, und wer sie liest, sucht am Server. Gegengeprueft mit einem echten Zuhoerer auf beiden Nummern: 5060 -> fetch failed (bad port) 5062 -> fetch failed (ECONNREFUSED) <- also normal erreichbar `eigenerPort` ueberspringt die gesperrten Nummern jetzt (portNummer). Uebersprungen wird nach der REGEL, nicht nach einer Tabelle von Sonderfaellen: die n-te brauchbare Nummer ab 5000. Eindeutig bleibt es, weil die Reihenfolge feststeht. pruef-portnummern (11 statt 8) prueft es doppelt: gegen die Liste UND am echten Verhalten -- ein Zuhoerer auf 5060 muss fuer `fetch` tot sein, einer auf einer abgeleiteten Nummer erreichbar. Ohne die zweite Haelfte waere die Liste nur eine Behauptung ueber Node, und Behauptungen altern. Nebenbefund: Auch im alten, von Hand vergebenen Bereich lag eine gesperrte Nummer -- die 4190. Sie war nie vergeben, rein zufaellig. pruef-chat-kanaele: 79 Pruefungen, 0 Fehler -- wieder auf der Grundlinie, die vor der Umstellung gemessen wurde. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-20 23:06:52 +02:00
DogFatherGitandClaude Opus 5	aa8842e72e	Zwei Pruefungen waren rot, weil Namen sich geaendert hatten ... Beide meldeten seit Tagen einen Fehler, den es nicht gab. Eine rote Pruefung, die rot BLEIBT, gewoehnt einem das Hinsehen ab -- ab da uebersieht man auch die echte. --- pruef-teilen: 14 ok / 3 Fehler -> 27 ok / 0 -------------------- Sie suchte `.teilen__brett`. Die Seite baut `.tl-brett`; die Klassen wurden irgendwann umbenannt, und die Pruefung suchte seitdem nach Elementen, die es nicht gibt. Gemeldet hat sie das sogar richtig -- "drei Ziele zur Auswahl (0)" --, nur hat niemand die Klammer gelesen. Danach lief sie in einen Klick-Zeitablauf und brach ab, weswegen DREIZEHN weitere Pruefungen nie stattfanden. --- pruef-crew-wand-bild: 41 ok / 4 Fehler -> 45 ok / 0 ------------ Zwei feste Erwartungen aus einer Zeit, die vorbei ist: 1. `/Team Dogi/` im Reiter. Die App heisst seit dem Treff-Umzug "DogFather Universe". Statt den neuen Namen einzutragen -- und damit dieselbe Zeitbombe mit neuem Datum zu stellen -- kommt er jetzt aus `crew.webmanifest`. Benennt jemand die App um, folgt der Reiter, und beides bleibt gruen. Weichen sie auseinander, sieht der Mensch im Reiter einen anderen Namen als auf seinem Startbildschirm, und genau das soll die Pruefung finden. 2. `kacheln === 3`, seit Filipe am 10.09. sagte "3 rollen. dogfather. rechte hand und modis". Am 19.09. zog der Treff in Team Dogi ein und die Community kam als vierte dazu -- die Zahl war ab da falsch, die Wand richtig. Verglichen wird jetzt die MENGE der Rollen, nicht ihre Anzahl: Eine Zahl sagt beim Scheitern "3 erwartet, 4 gefunden" und verschweigt, WELCHE. Beide Male war die Seite richtig und die Pruefung veraltet -- das ist dieselbe Krankheit wie bei den Portnummern und bei pruef-entwicklung: ein Name oder eine Zahl, abgeschrieben an einer zweiten Stelle, die niemand mitpflegt. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-20 22:55:41 +02:00
DogFatherGitandClaude Opus 5	6e46a08543	Portnummern werden abgeleitet, nicht mehr vergeben ... Gemessen: 165 Pruefdateien, 129 verschiedene Nummern -- NEUNZEHN doppelt, vier davon dreifach. Niemand hatte das gewollt; jede neue Pruefung wurde von einer vorhandenen abgeschrieben, und die Nummer kam mit. Meine eigene Notiz sagte "sieben" -- auch eine Bestandsliste altert. Der Waechter faengt den Schaden ab, aber er kann nur melden, was schon passiert ist: Zwei Pruefungen mit derselben Nummer koennen nie gleichzeitig laufen, und ein liegengebliebener Prozess der einen laesst die andere abbrechen mit einer Meldung, die wie ein Befund aussieht. Genau das ist mir am 20.09. zweimal passiert. Jetzt leitet jede Datei ihre Nummer aus ihrer STELLE IM ALPHABET ab (eigenerPort in helfer-port.mjs), zwei je Datei. Nicht ueber eine Pruefsumme: Bei 165 Namen in 4900 Nummern waeren nach dem Geburtstagsproblem rund DREI Zusammenstoesse zu erwarten -- ein Hash tauscht eine sichtbare Doppelung gegen eine unsichtbare. Die Stelle im Alphabet ist eindeutig von der Bauart her. --- ZWEI FEHLER AUF DEM WEG, BEIDE LEHRREICH ------------------------- 1. DER ERSTE VERSUCH WAR GRUEN UND KAPUTT. Ersetzt wurde mit einem Muster: "([^"]*4231[^"]*)". Das hielt { host: "127.0.0.1", port: 4231, path: "/404.html" } fuer eine Zeichenkette -- ein Muster kann eine oeffnende nicht von einer schliessenden Anfuehrung unterscheiden. Heraus kam { host: "127.0.0.1`, port: ${PORT}, path: `/404.html" } also GUELTIGER Code ohne port-Feld. `node --check` sagte gruen fuer alle 164 Dateien. Aufgefallen ist es erst, weil ich vier Vertreter gegen eine vorher gemessene Grundlinie laufen liess: pruef-schranke 39/0 vorher, 38/1 nachher. Alles zurueckgenommen und mit einem Zerleger neu gemacht, der weiss, ob eine Stelle Code, Zeichenkette, Vorlage, Kommentar oder regulaerer Ausdruck ist. In pruef-ics stand die Nummer in einem regulaeren Ausdruck -- der wird jetzt gebaut statt hingeschrieben. 2. EIN MODUL, DAS BEIM IMPORTIEREN ARBEITET, IST EINE FALLE. Der zweite Durchgang importierte den ersten, um seine Mechanik zu benutzen -- und fuehrte dessen Hauptlauf gleich mit aus. Die zweiten Nummern wurden dadurch als erste behandelt, zwei Aufrufe bekamen dieselbe Nummer, und in pruef-content stand `const PORT` zweimal. --- WAS DAS DAUERHAFT HAELT ----------------------------------------- pruef-portnummern.mjs (neu, 8 Pruefungen) fragt nicht "welche Nummern sind doppelt", sondern "wer traegt ueberhaupt noch eine von Hand ein" und "wer startet einen Server, ohne seine Nummer abzuleiten". Die zweite Frage hat sofort etwas gefunden, das in KEINER Doppelungsliste stand: pruef-push-weg belegte 4341 und 4342, rief den Waechter aber gar nicht auf -- dieselbe Nummer wie pruef-agentur. Eine Liste zeigt nur, was auf ihr steht. Mit Gegenprobe: Eine unbekannte Datei bekommt keine geratene Nummer, sondern einen Abbruch, und eine dritte Nummer je Datei gibt es nicht. --- NACHGEMESSEN ---------------------------------------------------- Sechzehn Pruefungen gegen ihre vorher gemessene Grundlinie, je eine Vertreterin jeder umgestellten Bauweise (eine Nummer, zwei Nummern, Nummer in einer Zeichenkette, in einer Vorlage, in einem regulaeren Ausdruck, dynamische Einfuhr, Nachtlauf mit zwei Laeufen): crew-adresse 132/0 · schranke 39/0 · content 45/0 · entwicklung 46/0 anruf 127/0 · ics 37/0 · push-weg 20/0 · arten 28/0 · video 67/0 kanalzeile 14/0 · agentur 62/0 · spicy 83/0 · creator-anlegen 50/0 push-ziel 10/0 · portnummern 8/0 Alle exakt wie vorher. Zwei waren schon vorher rot und sind es unveraendert geblieben (crew-wand-bild 41/4, teilen 14/3) -- per `git stash` belegt, nicht angenommen. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-20 22:51:21 +02:00
DogFatherGitandClaude Opus 5	d79cb9196b	Die Entwicklungs-Pruefung war rot, ohne dass etwas kaputt war ... Sie hielt seit dem 19.09. eine Namensliste fest: !["Eure Aufgaben", "Talente"].includes(k.name) Als ein Modi eine eigene Kachel bekam -- "Deine Aufgaben", weil "Eure" aus seiner Sicht falsch ist -- wurde sie rot. Nichts war kaputt, der Name hatte sich geaendert. Das ist die abgeschriebene Liste zum dritten Mal in diesem Haus, und diesmal traf sie eine Pruefung: Eine rote Pruefung, die rot BLEIBT, gewoehnt einem das Hinsehen ab und ist damit schaedlicher als gar keine. Erst nachgemessen, ob die Kachel ueberhaupt falsch ist: In workspace-entwicklung.js steht const personen = leitung ? db().prepare(...) : []; Ein Modi bekommt dort eine LEERE Liste -- er sieht auf der Seite nur sich selbst. Die Kachel war also richtig, die Pruefung nicht. An ihre Stelle treten zwei Messungen: 1. DAS VERSPRECHEN STATT DES NAMENS. Filipe hatte gemeldet, dass auf der Kachel "die Antworten sieht nur du" stand und sie trotzdem auf eine Seite mit fremden Namen fuehrte. Das ist eine Eigenschaft des Untertitels, nicht des Namens. Wer morgen eine Kachel "Dein Kopf" nennt und dasselbe verspricht, ist mitgeprueft -- die Namensliste haette ihn durchgelassen. 2. DIE ECHTE GRENZE, die bisher NIEMAND gemessen hat. Ob eine Kachel richtig zeigt, ist Beschriftung; ob die Seite dahinter fremde Namen herausgibt, sind Daten -- und nur das schuetzt jemanden wirklich. Gemessen wird jetzt beides: Ein Modi bekommt auf /entwicklung/lage NIEMANDEN (0), DogFather und die rechte Hand bekommen sehr wohl welche (2). Die zweite Zeile ist die Gegenprobe zur ersten -- waere der Filter einfach zu, saehe auch die Leitung nichts, und die Modi-Zeile waere trotzdem gruen. Nebenbei: Beim ersten Lauf stand `lage.code === 200` statt `lage.status` -- der Helfer heisst anders. Beide Zeilen wurden dadurch ROT, obwohl die Zahlen (2 und 0) von Anfang an stimmten. Der richtige Ausgang: lieber laut scheitern als still bestaetigen. pruef-entwicklung: 46 Pruefungen, 0 Fehler (vorher 43 mit 1 Fehler). Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-20 22:32:44 +02:00
DogFatherGitandClaude Opus 5	b0e7542507	Der Anrufkasten zeigt, WER dran ist -- nicht dreimal "Verbunden" ... Filipe, zu Screen 1: "wenn ich anrufe soll das auch viel besser geiler und spezieller aussehen aber es soll nicht raushaengen." Erst gemessen: Es haengt nichts raus. Der Kasten ist 374 px am Handy, 340 am Rechner, 72 Teile geprueft, kein einziges ueber dem Rand. Die Optik war also gar nicht der Mangel -- zwei andere Dinge waren es. 1. DER NAME DES ANRUFERS GING IMMER VERLOREN. `wer(raumName || "Anruf")` lief VOR `kastenBauen()`. Das Element #anruf-wer gab es zu dem Zeitpunkt noch nicht, die Zuweisung lief ins Leere, und oben stand bei jedem Anruf das Wort "Anruf". Die Reihenfolge ist umgedreht: erst bauen, dann beschriften. 2. IN EINEM ANRUF OHNE VIDEO STAND JE PERSON DAS WORT "Verbunden". Bei dreien dreimal dasselbe Wort -- und man sah nicht, WER dabei war. In einer Gruppe ist genau das die Frage: Ist Kessi schon drin? Jetzt steht dort ein Kreis mit den Anfangsbuchstaben und der echte Name; waehrend es klingelt ein wartendes Gesicht mit dem Namen dessen, den man anruft. Vorher war die Flaeche in dieser Sekunde leer, und ein leerer Kasten mit "Es klingelt ..." sieht aus wie einer, der haengt -- ausgerechnet im unsichersten Moment. Der Name kommt NICHT aus einer Abfrage. Wer anruft, bekannt beim Start nur sich selbst; alle weiteren kommen ausschliesslich ueber das Ereignis "dabei", und genau dort fehlte das Einsammeln. Deshalb sah der ANRUFER unter jedem Kreis "Jemand" -- die Angerufenen nicht. UND DIE PRUEFUNG WAR ZU NACHSICHTIG. Sie verlangte einen Namen "laenger als ein Zeichen"; der Rueckfalltext "Jemand" ist sechs Zeichen lang und kam damit durch. Gruen, waehrend der Hauptfall kaputt war. Die zweite Fassung verglich gegen eine abgeschriebene Namensliste -- die nannte "Jonas, Luna, Mara, Pat", angelegt werden aber "Filipe, Rieke, Kessi, Tili", und der Kommentar daneben behauptete schon da, sie sei abgeleitet. Jetzt ist sie es wirklich: Die Namen werden beim Anlegen eingesammelt, und geprueft wird, dass jeder GENAU DIE BEIDEN ANDEREN sieht -- nicht "irgendeinen echten Namen", denn der eigene Name im eigenen Kasten waere auch einer. pruef-anruf: 127 Pruefungen, 0 Fehler. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-20 22:25:45 +02:00
DogFatherGitandClaude Opus 5	9d086eccaf	Chat: das Buehnenbild scheint durch, jeder Account bekommt seine Kachel ... Hinter jeder Seite steht ohnehin eine Buehne (neun Szenen, fuer den Chat die Lounge). Sie lag bisher hinter einer deckenden Flaeche -- vorhanden, geladen, unsichtbar. Sie durchscheinen zu lassen kostet keine einzige Datei mehr, und auf der Adresse von Team Dogi kommt damit von selbst deren eigene Fassung. Das geht aber NUR, wenn der Text auf einer deckenden Kachel steht. Sonst liegt Schrift auf einem Foto: an der dunklen Stelle lesbar, an der hellen nicht, und beim Scrollen wechselt es. Filipes zweiter Satz ("die texte sollen immer in einer kachel sein") ist deshalb kein Zusatzwunsch, sondern die Bedingung fuer den ersten. Und jeder Account waehlt seinen Ton. Zwoelf Stueck, alle gleich dunkel und gleich gesaettigt -- sie unterscheiden sich im Farbton und in sonst nichts. Ein freier Farbwaehler klingt grosszuegiger und ist die schlechtere Loesung: Mit ihm laesst sich Schwarz auf Schwarz einstellen oder Neongelb, das allen anderen in die Augen sticht. Die Kachel gehoert einem selbst, GESEHEN wird sie von allen anderen. Gemessen: der schlechteste Kontrast liegt bei 13,9:1 (noetig 7). Drei eigene Fehler beim Bauen, alle von der Pruefung gefunden: 1. Es gibt ZWEI Regeln fuer dieselbe Kachel (Grundform und Feinschliff). Ich hatte nur die erste umgestellt, die zweite gewann -- die eigene Kachel waere durchsichtig geblieben. 2. Die Pruefung las backgroundColor und pruefte den Alphawert. Eine Kachel mit einem VERLAUF hat dort rgba(0,0,0,0); sie meldete "durchsichtig" bei einer Kachel, die voellig deckt. Jetzt werden zwei Bildpunkte verglichen, einmal mit und einmal ohne Buehnenbild -- das misst die Sache selbst, nicht ihren Stellvertreter. 3. Dieselbe Pruefung suchte nur die rgba-Schreibweise. Chrome gibt das Ergebnis von color-mix als color(srgb r g b / a) zurueck; der Rueckfall war "Alpha 1", und sie meldete "deckt" bei einer Flaeche, die durchscheint. Genau das Gegenteil. pruef-chatkachel.mjs: 27 Pruefungen, mit eingebauter Gegenprobe (auf der freien Flaeche MUSS sich etwas aendern, sonst misst der Vergleich nichts). pruef-chat-optik und pruef-erwaehnung unveraendert gruen. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-20 19:58:50 +02:00
DogFatherGitandClaude Opus 5	9c96612321	Am Handy lag Text auf Text -- im Satz ueber Vertraulichkeit ... Auf der Befindens-Seite ueberlagerten sich bei 430 px zwei Absaetze um 18 Pixel. Betroffen war ausgerechnet "Deine Antworten liest niemand ausser dir" -- also der Satz, in dem das Vertrauen entsteht, das die ganze Seite braucht. Ursache war eine feste Zahl: -18px Abstand, gerechnet gegen die 26 px, die das Element darueber mitbringt. In einer Kopfzeile setzt start.css dieses margin-bottom aber auf 0. Aus 26 minus 18 wurde 0 minus 18. Zwei fuer sich richtige Regeln, und dazwischen ein Schaden, den keine von beiden verursacht. Die Lehre ist nicht "-18 auf -8 aendern" -- das waere dieselbe Zahl mit anderem Wert und beim naechsten Zusammentreffen wieder falsch. Jetzt bestimmt der Absatz davor seinen Abstand selbst, und nur dann, wenn der Zusatz wirklich folgt (:has). Acht Pixel, in jeder Umgebung. Gefunden hat es ein Bildschirmfoto, nicht das Lesen: Beide Regeln sehen einzeln vernuenftig aus. Die Messung steht jetzt fest in pruef-befinden.mjs (113/0), mit Gegenprobe: Mit dem alten Wert wird sie rot, ohne ihn gruen. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-20 19:48:46 +02:00
DogFatherGitandClaude Opus 5	2719bd9b88	Wie geht es dir: achtzehn Fragen in sechs Feldern, eine Zusammenfassung ... Sechs Fragen mehr (jetzt 18), und alle in sechs Feldern gegliedert: Last & Erholung, Miteinander, Sinn & Anerkennung, Klarheit & Rueckhalt, Grenzen & Sicherheit, Weiterkommen & Ausblick. Die Felder sind nicht ausgedacht -- es sind die Gebiete, die die Forschung zu belasteten Rollen durchgehend abfragt. Die drei neuen Luecken, die sie schliessen: Schlaf (zeigt Erschoepfung frueher als jede andere Frage), Widersprechen (der Kern dessen, was psychologische Sicherheit heisst) und Mitreden (viel Anforderung bei wenig Einfluss ist die Kombination, aus der Erschoepfung entsteht). Jede neue Frage hat ihre belegte Einordnung -- eine Frage ohne Grundlage ist eine Frage, die jemand gut fand. DIE ROTATION MUSSTE NEU. Der Katalog ist nach Themen sortiert; wer daraus drei aufeinanderfolgende nimmt, bekommt drei aus demselben Feld. Jetzt wird der Ring vorher verzahnt -- erst je eine Frage aus jedem Feld, dann je eine zweite. Ein Fenster trifft damit von selbst verschiedene Felder. Ein erster Anlauf reservierte feste Plaetze fuer die kernlosen Felder. Begruendet mit einer Auswertung je Feld, die es gar nicht gibt -- und er kostete: zwoelf Runden, bis jede Frage einmal gestellt war, fast ein halbes Jahr. Gefunden hat das pruef-befinden.mjs, nicht das Nachdenken. Mit dem verzahnten Ring und vier Plaetzen je Runde sind es vier Runden. DIE EINE ZUSAMMENFASSUNG AM ENDE, nicht eine je Kategorie. Sie sagt in dieser Reihenfolge: die Lage in einem Satz, was traegt (benannt, nicht als Zahl), hoechstens EINE Sache zum Hinschauen, ein Schluss, der zur Lage passt. Umgekehrt waere es eine Maengelliste mit Trostpflaster, und so etwas beantwortet man beim naechsten Mal nicht mehr ehrlich. ZUR FRAGE NACH DER BESTEN KOSTENLOSEN MOEGLICHKEIT: bewusst KEINE KI. Das sind Gesundheitsdaten (wer nachts wach liegt, wer angefeindet wird, wer ans Aufhoeren denkt) -- deshalb sind sie im ganzen Haus als nurSelbst markiert. Kostenlose KI-Angebote bezahlt man mit den Daten. Ein Sprachmodell erfindet ausserdem, und zwar ueberzeugend. Und ein fremder Dienst faellt aus. Jeder Grund reicht einzeln. Die Begruendung steht ausfuehrlich in workspace-befinden-resuemee.js. Nebenbefund behoben: Die Zusammenfassung blieb direkt NACH einer abgeschlossenen Runde leer -- da ist keine Antwort mehr "frisch". Genau der Moment, in dem man sie sehen will. Auch eine Pruefung korrigiert: Sie verbot den Text "entwicklung.js" irgendwo in der Datei und schlug an einem Kommentar an, der die Serverdatei benennt. Sie misst jetzt die Skript-Quellen. pruef-befinden.mjs 112/0, pruef-resuemee.mjs 35/0 (neu). Offener Befund, aelter als diese Aenderung: pruef-entwicklung.mjs meldet "ein Modi: keine Kachel fuehrt mehr ersatzweise auf die Entwicklungsseite" -- auch ohne diese Commits. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-20 19:45:14 +02:00
DogFatherGitandClaude Opus 5	1bdeccc054	Highlights: drei Accounts nebeneinander, nach Zeit geteilt ... DogFather, HasiDog und DogFather Clips haben eigene Zuschauer und einen eigenen Ton -- das steht so schon an KANAELE im Server. Eine gemeinsame Galerie behauptete, sie waeren ein Topf; wer fuer Clips schneidet, suchte in jeder Reihe nach den Kacheln, die ihn angehen. Jetzt drei Spalten nebeneinander, jede zuklappbar, jede mit ihrem Handle und ihrer Zahl. Eine vierte Spalte gibt es nur, wenn sie gebraucht wird: Bilder ohne TikTok-Link gehoeren zu keinem Account, und sie verschwinden zu lassen waere der schlimmere Fehler. Die Reihenfolge kommt vom SERVER. Der Browser hatte dafuer eine eigene kleine Liste (KANAL_WORT) -- dieselben drei Namen in anderer Reihenfolge, ohne Handles. Beim vierten Account waere genau diese Kopie die vergessene. Dazu eine Zeitleiste: Aktuell (heute), Diese Woche, Dieser Monat, Dieses Jahr, Alles. Kalenderzeitraeume, keine Rueckblicke -- wer am Dienstag "diese Woche" fragt, meint Montag und Dienstag. Jeder Knopf traegt seine Zahl; ohne sie klickt man ins Leere und weiss nicht, ob es am Filter lag. Und beim Anlegen laesst sich der Account waehlen -- fuer Bilder und Momente ohne Link. Bei einem TikTok-Link leitet der Server ihn weiterhin aus dem Handle ab; das ist genauer, weil niemand sich vertippen kann. Beim Bauen gemessen statt vermutet: Der Spaltenkasten lag IM Galerie-Raster von #liste und bekam eine Zelle von 376 px -- Elternbreite 1160. Die drei standen untereinander. Die Galerie gehoert jetzt in die Spalte, nicht um sie herum. pruef-highlights.mjs: 26 Pruefungen, mit Gegenproben (Gast bekommt die Liste nicht, erfundener Account wird abgelehnt, zweiter Klick hebt den Filter auf). pruef-video.mjs weiterhin 67/0. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-20 19:28:22 +02:00
DogFatherGitandClaude Opus 5	d77dd216c5	Ein Termin von-bis belegt jeden Tag dazwischen ... Zwei Fehler, nicht einer. Der sichtbare: Die Kachel stand nur am Anfangstag. Wer im Monatsraster auf den Mittwoch sah, sah nichts -- obwohl die Aktion von Montag bis Freitag lief. Der unsichtbare, und der ist der schlimmere: Der SERVER suchte Eintraege, deren ANFANG im sichtbaren Fenster liegt. Eine Aktion vom 28.09. bis zum 05.10. kam im Oktober deshalb ueberhaupt nicht an -- nicht "nur am ersten Tag markiert", sondern gar nicht da. Wer im Oktober plante, sah eine freie Woche, die belegt war. Jetzt entscheidet die UEBERSCHNEIDUNG, nicht der Anfang. Gebaut wurde es in nachTag() -- der einzigen Stelle, an der Eintraege auf Tage verteilt werden. Monat, Woche, Liste und Zeitstrahl holen sich alle dort; vier Ansichten einzeln nachzuruesten waeren vier Stellen, an denen die fuenfte vergessen wird. Das Ende wird abgeleitet, nicht gepflegt: aus event_ende ODER aus Uhrzeit plus Dauer. Ein Live von 22:00 ueber vier Stunden endet um 02:00 am naechsten Tag -- das stand bisher nirgends, obwohl die Zahlen da waren. Der Tagesdialog filterte selbst auf den Anfangstag. Im Raster war der Mittwoch markiert, tippte man ihn an, stand da "An diesem Tag steht nichts." Jetzt fragt er dieselbe Stelle wie das Raster. pruef-zeitraum.mjs: 16 Pruefungen, beide Fehler einzeln, mit drei Gegenproben (vor dem Anfang, nach dem Ende, Punkttermin). pruef-terminregel.mjs weiterhin 35/0. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-20 19:20:18 +02:00
DogFatherGitandClaude Opus 5	947ea7ff49	Fertige Vorschlaege lassen sich wechseln ... Bisher kamen ALLE auf einmal -- damit gab es nichts zu wechseln, die Liste war entweder ganz da oder ganz weg. Bei 17 Vorschlaegen (Brett "regeln") ist eine Wand aus Karten ausserdem das Gegenteil von "uebernehmen, was passt". Jetzt vier auf einmal, und ein Knopf holt die naechsten vier. Der Server rechnet die Stelle mit Rest -- nach dem letzten kommt wieder der erste. Es gibt also keinen Zustand "durchgeklickt, jetzt leer". Bei hoechstens vier offenen Vorschlaegen erscheint der Knopf gar nicht: Ein Knopf, der dieselben Karten noch einmal malt, ist ein Knopf, der nichts tut. Was es NICHT ist: Die Vorschlaege werden nicht erzeugt. Sie sind ein geschriebener Vorrat von 113 Stueck auf 16 Brettern. pruef-vorschlaege.mjs: 21 Pruefungen. Die entscheidende vergleicht die Titel vorher und nachher -- ein Knopf, der nur gedrueckt werden kann, besteht jede Pruefung, die nur nach dem Knopf sucht. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-20 19:15:49 +02:00
DogFatherGitandClaude Opus 5	c4e26409b9	Die Seite laesst sich als App installieren ... Das Manifest war lange vollstaendig -- die App LIESS sich installieren. Nur bot das ausschliesslich der Browser an, versteckt in seinem Dreipunktemenue. Wer es nicht sucht, findet es nie. Und ohne installierte App gibt es auf dem Handy keine verlaesslichen Benachrichtigungen; genau daran hing im September das Telefonieren. Jetzt steht der Knopf in der Kopfleiste, auf allen Seiten, mit drei Antworten statt einer: schon installiert -> gar kein Knopf Browser bietet an -> der Knopf fragt ihn Safari am iPhone -> der Knopf erklaert den Weg Der dritte Fall ist der gefaehrliche: Dort gibt es beforeinstallprompt nicht und wird es nicht geben. Ein Knopf, der am iPhone nichts tut, waere schlimmer als keiner -- man drueckt ihn und sucht den Fehler bei sich. pruef-installieren.mjs: 14 Pruefungen, alle drei Zustaende, mit Gegenprobe in der installierten App. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-20 19:13:36 +02:00
DogFatherGitandClaude Opus 5	586eb51504	Profilfotos im Chat, rechte Hand zuerst, Karten lesbar ... ---- SCREEN 9: DIE FOTOS ------------------------------------------- Filipe: "da soll man im chat auch die profilfotos von den leuten sehen wenn die schon eins drin haben." ZWEI Luecken, beide an Stellen, wo ein Feld weggeworfen wurde: 1. Die GESPRAECHSLISTE bekam kein Bild. `teilnehmerVon` liest es aus der Datenbank, die Detailansicht nimmt es mit -- die Zeile fuer die Liste warf es weg. Folge: im offenen Gespraech ein Gesicht, in der Liste daneben ein Buchstabe. Vom selben Menschen. 2. Eine FRISCH GESENDETE Nachricht trug kein Bild. Der Verlauf beim Laden schon. Folge: Wer gerade zusieht, bekommt einen Buchstaben; wer neu laedt, ein Gesicht -- der Unterschied haengt nur daran, wann man geschaut hat. Der Buchstabe bleibt als Unterlage LIEGEN und wird nicht ersetzt: Laedt das Bild nicht, steht dort weiterhin etwas Sinnvolles statt eines kaputten Bildsymbols. Vier Stellen, ein Verhalten. ---- SCREEN 3: REIHENFOLGE UND AUSSEHEN ---------------------------- Filipe: "ich will dass hier wie ueberall die reihenfolge immer rechte hand und dan erst die modis." Die Abfrage sortierte nach `aktiv DESC, name` -- die ROLLE wurde nicht einmal mitgelesen. Die Seite konnte gar nicht wissen, wer rechte Hand ist; sie sortierte alphabetisch, und damit stand Diene vor Funny, weil D vor F kommt. Jetzt mit ROLLEN_SORTIERUNG -- derselben Regel, die auch Personenliste, Chat und Rechtetafel benutzen. "die kiste von rechte hand soll auch noch vieeeeeel krasser und spezieller aussehen ... der hintergrund von den kacheln soll auch viel krasser und geiler sein und so dass man texte und so besser erkennt. weil gerade ist es schwer lesbar." ZUERST DAS LESEN: Der Grund fuer die schlechte Lesbarkeit war der durchscheinende Untergrund -- die Karten lagen auf dem Buehnenbild, und ein Foto wird stellenweise hell. Sie bekommen jetzt eine DECKENDE Unterlage und erst darueber die Verlaeufe. Die Verlaeufe sieht man weiterhin, nur nicht mehr das Bild dahinter. DANN DAS BESONDERE: Die rechte Hand bekommt einen goldenen Ton, eine deutlich hellere Kante und eine schmale Leiste an der linken Seite -- man sieht den Rang aus zwei Metern, ohne ein Wort zu lesen. KEIN zweiter Bauplan: dieselbe Karte, dieselben Felder, nur ein Merkmal am Element. Zwei Karten zu bauen hiesse, jede kuenftige Aenderung zweimal zu machen. ---- EINE PRUEFUNG, DIE EINE POSITION FESTNAGELTE ------------------ `ok(leute[0]?.id === idMarina, "die Aktiven stehen oben")` wurde rot, sobald die rechte Hand nach vorn sortierte. Richtig wurde sie dadurch nicht: Die Aussage "die Aktiven stehen oben" hat mit Marinas Platz nichts zu tun. Jetzt prueft sie die EIGENSCHAFT (keine Pause vor einer Aktiven) -- eine Pruefung, die eine Position festnagelt, verbietet jede Umsortierung, auch die gewollte. GEPRUEFT: pruef-team-stufen 28/0 (zwei Aussagen mehr), pruef-erwaehnung 69/0 (zwei mehr: das Bild kommt in der Liste an, und wer keines hat, bekommt auch keines vorgegaukelt), pruef-css-klassen. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-20 19:07:06 +02:00
DogFatherGitandClaude Opus 5	c59517cb23	Ein Anruf faengt leise an ... Filipe: "uebrigens soll man auswaehlen koennen ob man lautsprecher will oder nicht bitte. es soll ohne lautsprecher anfangen das gespraech und nur wenn man drauf klickt soll es laut werden ... es soll nicht raushaengen oder so, das ist nicht cool." DER GRUND IST DER STREAM. Ein Anruf, der beim Annehmen sofort aus den Lautsprechern kommt, ist im schlimmsten Fall fuer alle Zuschauer zu hoeren, bevor irgendjemand reagieren kann. Das laesst sich nicht zurueckholen. HIER STAND `hoeren = true` mit der Begruendung: "Wer den Ton abgestellt hat, will ihn nicht beim naechsten Gespraech wieder an." Das war richtig gedacht und ist jetzt umgedreht -- aus demselben Grund, nur in die andere Richtung: Der Zustand soll NICHT ueberdauern. Eine Entscheidung von vorhin darf nicht fuer ein Gespraech gelten, von dem man noch nichts wusste. Zurueckgesetzt wird an BEIDEN Wegen, beim Anrufen und beim Rangehen -- einer allein waere die Haelfte, und die andere Haelfte faellt niemandem auf, bis es einmal zu laut war. UND MAN SIEHT ES. Leise anfangen ohne Hinweis waere die naechste Sackgasse: "ich hoere nichts" ohne Grund und ohne Weg. Ein Balken sagt es, solange es gilt, und verschwindet in dem Moment, in dem man den Ton anmacht. Er ist SELBST der Knopf -- wer liest "tippen, um den Ton anzumachen", will genau das tun. Gedaempftes Bernstein statt Alarmrot: Es ist kein Fehler, sondern ein Zustand. DABEI EINEN EIGENEN FEHLER GEFANGEN: Der Balken fragte `!anruf` -- und diese Variable wird erst gesetzt, NACHDEM der Kasten aufgeht. Beim Aufbauen blieb er deshalb versteckt, und man sass in einem stummen Gespraech ohne einen Satz dazu. Genau der Zustand, den er verhindern soll. Jetzt haengt er am sichtbaren Kasten. DIE PRUEFUNG WURDE ROT und hat damit ihre Arbeit getan -- sie hielt das alte Verhalten fest. Umgedreht, nicht gestrichen: Die wichtigste Falle (ueberlebt der Schalter das Neuzeichnen, wenn jemand auflegt?) bleibt, nur der erwartete Zustand hat sich gedreht. GEPRUEFT: pruef-anruf 117/0 (war 114) -- drei Aussagen mehr, darunter dass der Hinweis da ist, 44 px hoch und im richtigen Moment verschwindet. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-20 19:01:28 +02:00
DogFatherGitandClaude Opus 5	01151574ae	Die rechte Hand verteilt Aufgaben und wechselt Rollen ... Filipe: "jeder soll sich selber aufgabe vergeben koennen aber nur die rechte hand und dogfather aufgaben an andere verteilen." Und: "ich will dass ich da auch die rollen der leute wechseln kann ohne dass ich denen einen neuen account machen muss ... perfektionier das fuer die rolle dogfather und rechte hand." ---- AUFGABEN VERTEILEN --------------------------------------------- Die Regel gab es schon -- sie fragte `istLeitung`, und darin steht die rechte Hand NICHT. Sie konnte also keine Aufgabe weitergeben. `hand` DORT EINZUTRAGEN WAERE FAHRLAESSIG GEWESEN: `istLeitung` wird an 57 Stellen in 19 Dateien gefragt -- unter anderem im vertraulichen Meldeweg, in der Personenverwaltung und in den Auswertungen ueber Menschen. Das haette in einem Zug ueber Einsicht in fremde Meldungen entschieden, und das hat niemand gewollt. Stattdessen `darfAufgabenVerteilen` -- eine eigene Regel mit eigenem Namen. Man sieht an der Aufrufstelle, worum es geht, und wer sie spaeter aendert, aendert genau diese eine Sache. Wer nicht verteilen darf, bekommt KEINE Absage: Die Aufgabe landet bei ihm selbst. Das ist genau, was Filipe wollte ("jeder soll sich selber aufgabe vergeben koennen") und freundlicher als ein Fehler. ---- ROLLEN WECHSELN ------------------------------------------------ Auch das gab es schon, samt dem wichtigen Satz in der Rueckfrage: "Der Zugangscode bleibt derselbe." Es konnte nur DogFather (und Spicy Media). DREI GRENZEN, JEDE MIT GRUND: * Niemand wird zu "admin" -- unveraendert seit dem 11.09.2026. * Die rechte Hand ernennt keine zweite rechte Hand. Wer jemanden auf die eigene Ebene hebt, vergibt Vertrauen, das ihm nicht gehoert. Und wer eine Rolle UEBER sich aendern koennte, koennte sich selbst befoerdern, indem er zuerst den anderen herabstuft. * Niemand aendert die eigene Rolle -- sonst waere jede Grenze nur ein Umweg. SPICY MEDIA BEHAELT, WAS SIE HATTE. Beim ersten Anlauf waere sie durch die neue Regel ausgesperrt gewesen -- ein Rueckschritt, den ich selbst verursacht haette. Sie steht jetzt ausdruecklich in der Tabelle. ---- UND DIE OBERFLAECHE RECHNET NICHT MEHR SELBST ------------------ Die Rollenwahl nahm die Knoepfe des ANLEGE-Formulars. Fuer die rechte Hand ist das leer -- sie legt niemanden an. Die Wahl waere leer geblieben, das Recht unbenutzbar. Der Server schickt jetzt zwei Listen mit: wozu ich machen darf (`rollen_zum_aendern`) und wessen Rolle ich anfassen darf (`rollen_anfassbar`). Beide aus denselben Funktionen wie die Schranke. Damit kann die Seite weder zu streng sein (ein Recht, das niemand findet) noch zu grosszuegig (ein Knopf, der eine Absage bringt) -- der Fehler vom 10.09.2026, als zwei Listen drei Zeilen auseinander einander widersprachen. Dabei fast hineingelaufen: `ROLLEN_REIHE` ist die SORTIERUNG, und darin fehlt "gast" mit Absicht. Wer sie fuer eine Aufzaehlung nimmt, verliert die Community still -- genau diese Verwechslung hat am 17.09.2026 schon einmal verhindert, dass sich jemand zu "Community" machen liess. ---- AUSSERDEM ------------------------------------------------------ Screen 2: "Unsere Seiten" und "Regeln & Hilfe" haben die Plaetze getauscht -- nur diese zwei. GEPRUEFT: pruef-verteilen 11/0 (neu, inkl. der Abgrenzung "darf verteilen, ist aber NICHT Leitung"), pruef-rollen-anlegen 11/0, pruef-personen-formular 36/0, pruef-personen-liste 33/0, pruef-personen-loeschen 40/0, pruef-rechtetafel 19/0, pruef-treff 72/0. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-20 18:56:03 +02:00
DogFatherGitandClaude Opus 5	e378514bb4	Einmal anmelden reicht -- und beim Zurueckgehen bleibt die Seite stehen ... Filipe: "kannst du bitte machen dass die leute sich nur einmal anmelden muessen und dan nur noch abgemeldet werden wenn sie sich selbst abmelden. damit sie auch die benarichtigungen sofort kriegen ... und auch sofort die anrufe annehmen koennen." ---- 1. DIE ANMELDUNG BLEIBT ---------------------------------------- VORHER: zwoelf Stunden, feste Frist ab dem Anmelden. Wer morgens um acht anfing, flog abends um acht raus -- mitten im Betrieb. Und wer abgemeldet ist, hat die Seite nicht offen; ein Anruf erreicht ihn dann nur noch ueber die Benachrichtigung, und bis er sich wieder angemeldet hat, ist das Klingeln vorbei. Genau das beschreibt Filipe. JETZT: ein gleitendes Fenster von 180 Tagen, das sich bei jeder Nutzung verlaengert. Wer die Seite benutzt, bleibt angemeldet -- ohne Ende. NICHT UNENDLICH, und das ist Absicht: In diesem Haus liegen vertrauliche Meldungen ueber Menschen. Ein Zugang, der nie ablaeuft, ist auf einem verlorenen Handy fuer immer offen. Ein halbes Jahr ohne Besuch schliesst das Geraet und ist niemandem zu viel zugemutet. An EINER Stelle gebaut: `sitzungLesen` -- durch die gehen alle 26 Fachmodule. Ein Parameter mehr haette 26 Aufrufe geaendert und beim 27. Modul vergessen werden koennen; `req.res` haengt ohnehin an der Anfrage. Verlaengert wird erst, wenn weniger als die Haelfte des Fensters uebrig ist -- sonst waere das ein Schreibzugriff bei jedem Bild und jedem Herzschlag des Ereignisstroms. Drei Texte, die noch "zwoelf Stunden" behaupteten, sagen es jetzt richtig -- inklusive der Abmelde-Nachfrage, die jetzt dazusagt, dass man angemeldet bleiben SOLLTE, um Anrufe zu bekommen. ---- 2. BEIM ZURUECKGEHEN BLEIBT DIE STELLE ------------------------- Filipe, zum dritten Mal und in Grossbuchstaben. Also erst gemessen: gescrollt auf: 900 gemerkt: 900 gelandet: 1054 <- 154 px daneben, zuverlaessig Die Wiederherstellung LIEF also -- sie traf nur nicht. Ursache ist Chromes Scroll-Verankerung: Waechst Inhalt OBERHALB der Stelle, verschiebt der Browser den Bildlauf mit, damit das Sichtbare stehen bleibt. Im Alltag genau richtig; beim Wiederherstellen das Gegenteil. Sie wird jetzt fuer die Dauer des Wiederherstellens abgeschaltet und danach wieder eingeschaltet -- nicht dauerhaft, sonst spraenge einem im Chat der Text unter dem Finger weg. Dazu wird die Stelle nachgesetzt, solange die Seite noch waechst, und aufgehoert, sobald sie 400 ms lang ruhig ist. Ergebnis: 900 -> 900, und es bleibt dort. DAZU, und das ist der groessere Teil: Der Ereignisstrom in kopf.js laeuft auf 32 Seiten und wird jetzt beim Weggehen geschlossen. Eine offene EventSource sperrt den Vor-/Zurueck-Speicher des Browsers aus -- deshalb wurde bisher JEDE Rueckkehr ein vollstaendiger Neuaufbau. Filipe hat genau das beschrieben ("OHNE DASS DIE SEITE ... NEU LAEDT"). EHRLICH DAZU: Playwright schaltet diesen Speicher fuer Tests ab, und er liess sich hier nicht einschalten. Ich kann also NICHT messen, dass er jetzt greift -- die Aenderung ist trotzdem richtig (eine offene Verbindung ist die dokumentierte Sperre, und ein Strom, der beim Weggehen offen bleibt, ist ohnehin ein Zuhoerer, den niemand mehr liest). Gemessen und abgesichert ist der Weg OHNE diesen Speicher -- also der schlechteste Fall. ---- 3. DABEI GEFUNDEN: pruef-schranke mass seit neun Tagen nichts -- Sie suchte `const GESCHUETZT = {` per Textmuster in workspace.js. Diese Tabelle ist am 11.09.2026 nach rechte.js umgezogen -- seitdem fand das Muster nichts, und die Pruefung meldete "0 geschuetzte Seiten", "alle 0 Seiten leiten um", "0 Schreibweisen ausprobiert". Drei rote Zeilen, die nach einem Zaehlfehler aussahen und in Wahrheit hiessen: hier wird nichts mehr geprueft. Jetzt wird die Tabelle IMPORTIERT. Ein Textmuster auf fremden Quelltext reisst beim naechsten Umzug still; ein import reisst laut. Ergebnis: 33 geschuetzte Seiten, 363 Schreibweisen -- alles gruen. GEPRUEFT: pruef-rollstelle 8/0 (neu, mit Spur ueber die Zeit und zwei Gegenproben), pruef-schranke (war rot), pruef-code 17/0, pruef-haerte 20/0. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-20 18:48:34 +02:00
DogFatherGitandClaude Opus 5	75019ec8c3	Am Handy stand nicht da, mit wem man schreibt ... Gemessen in der Kopfzeile eines Gespraechs, Name "Team-Runde": 360 px -> 0 px sichtbar (98 noetig) 390 px -> 12 px 412 px -> 33 px 1280 px -> passt Auf JEDEM Telefon stand also kein Name da -- man oeffnet ein Gespraech und sieht nicht, mit wem. Und weil die Zeile nicht leer aussieht (Zurueck-Pfeil, fuenf Knoepfe), wirkt sie nicht kaputt, sondern eng. URSACHE: `flex: 1` heisst ausgeschrieben `1 1 0%` -- Grundbreite NULL. Damit "passt" der Name rechnerisch immer, egal wie eng es ist, und es bricht nie etwas um. Die Knopfreihe daneben hat `flex: none` und schrumpft nie; seit die Knoepfe am Finger 44 px breit sind, bleibt bei sechs Knoepfen nichts uebrig. Zwei Stellen setzten dieselbe Eigenschaft, die spezifischere gewann -- die erste Reparatur wirkte deshalb nur bei 360 px und sonst nicht. Beide nennen jetzt dieselbe Grundbreite. KEINE NEUE SCHWELLE: `flex-wrap` bricht genau dann um, wenn der Platz wirklich nicht reicht. Dieses Haus ist an festen Breiten schon zweimal gescheitert (Kopfleiste, 06.09.2026); kommt morgen ein siebter Knopf dazu, stimmt es weiter. Ergebnis: 244 / 268 / 289 px statt 0 / 12 / 33. ---- WARUM DER HANDY-RUNDGANG DAS NICHT GEFUNDEN HAT ---------------- Zwei eigene Entscheidungen, jede fuer sich vernuenftig, zusammen ein Loch: 1. `sichtbar()` verlangt `width > 0`. Ein auf null gequetschtes Element ist unsichtbar -- und "unsichtbar" hiess "nichts zu pruefen". Genau falsch herum: Nichts zu sehen IST der Befund. 2. `text-overflow: ellipsis` gilt als Absicht. Das stimmt auch -- ein langer Name soll gekuerzt werden. Es stimmt nur nicht mehr, wenn nichts uebrig bleibt. Die neue Regel ist bewusst schmal: gemeldet wird nur, was unter 40 px sichtbar ist und mindestens das Doppelte braeuchte. "Jede Kuerzung melden" waeren die ~350 Fehlalarme, die diese Pruefung schon einmal zugedeckt haben. NACHGEMESSEN: 206 Seitenaufrufe, 91 638 Elemente. Die Regel schlaegt an genau EINER Stelle an (kalender.html, sechsmal) und sonst nirgends -- 64 -> 70 Befunde. Die Pruefung ist genauer geworden, nicht die App schlechter. DER KALENDER-FUND BLEIBT OFFEN: Im Monatsraster ist ein Tag am Handy 36 px breit, ein Eintrag braucht 186 bis 317. Das ist kein Versehen im Code, sondern die Frage, ob die Monatsansicht am Telefon ueberhaupt die richtige Vorgabe ist -- eine Entscheidung, keine Reparatur. GEPRUEFT: pruef-chat-optik 39/0 (drei neu, mit einer Gegenprobe, die den gemessenen Fall HERSTELLT -- fuenf Knoepfe wie in einer Gruppe; der erste Anlauf blieb gruen, weil in einem Zweiergespraech nur drei stehen und der Platz auch ohne Reparatur reicht: 12 px mit der alten Angabe, 268 mit der neuen, im selben Aufbau). Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-20 18:14:08 +02:00
DogFatherGitandClaude Opus 5	2a26a49f91	Mit "@" jemanden im Chat ansprechen ... Filipe: "ich will das man die leute mit @ markieren kann im chat." MARKIEREN IST KEINE FARBE, SONDERN EINE ANSPRACHE. Sie funktioniert nur, wenn drei Dinge zusammen stimmen: Der Richtige ist gemeint, er MERKT es, und man sieht es im Satz. Fehlt eines davon, ist es eine Attrappe -- und zwar eine, die gut aussieht. WER GEMEINT IST, ENTSCHEIDET DER SERVER. Der Browser schickt nur Text. Damit wirkt ein von Hand getipptes "@VanVan" genauso wie eines aus der Auswahlliste, und niemand kann jemanden ansprechen, der gar nicht im Raum sitzt -- auch nicht ueber die Schnittstelle. Die Regeln stehen in server/chat-erwaehnung.js, jede mit Begruendung. Zwei davon sind keine Feinheit, sondern der Unterschied zwischen brauchbar und laestig: * Das Zeichen VOR dem "@" darf kein Buchstabe sein. Sonst piepst jede E-Mail-Adresse im Chat jemanden an ("[email protected]"). * Das Zeichen DANACH auch nicht, und der laengste Name gewinnt. Sonst spricht "@Tilikum" Tili an. MAN MERKT ES AUCH OHNE OFFENEN RAUM. Eine Zahl in der Gespraechsliste sagt "hier ist etwas" -- nicht, ob es an dich war. Wer morgens vier Raeume mit Zahlen sieht, macht den lautesten zuerst auf, und dort steht selten das, was auf ihn wartet. Jetzt steht ein "@" daneben. UND DIE MELDUNG AUFS HANDY SAGT ES: "VanVan hat dich erwaehnt" statt "Nachricht von VanVan". Als EIGENE Art, die sich getrennt abschalten laesst -- wer den lauten Chat stumm stellt, will trotzdem wissen, wenn ihn jemand direkt anspricht. Ohne Ausnahme von der Ruhezeit: Ein Anruf wartet auf eine Antwort, ein "@Anna" nicht. DIE AUSWAHL BEIM TIPPEN loest drei Dinge, die man sonst selbst wissen muesste: wie die Person genau heisst, wer ueberhaupt im Raum ist, und ob man sich vertippt hat. Tastatur zuerst (Pfeile, Enter, Tab, Escape). Sie erzwingt nichts -- wer weitertippt, schreibt einfach weiter. ZWEI RECHNUNGEN, EINE ANTWORT: Der Browser braucht dieselbe Aufloesung, um sofort hervorzuheben. Genau dort laufen Dinge auseinander, und dann haette die Seite jemanden hervorgehoben, den niemand benachrichtigt hat. pruef-erwaehnung LIEST die Browserfassung aus der Datei und fuehrt sie aus -- ein Nachbau wuerde pruefen, ob ich zweimal dasselbe schreiben kann. ---- DABEI GEFUNDEN: "gelesen bis 999999" ---------------------------- Der Server nahm fuer den Lesestand JEDE ganze Zahl an. Wer einmal eine Zahl hinter allem Vorhandenen schickte, sah in diesem Gespraech nie wieder einen Zaehler und nie wieder ein @-Zeichen: Alles Kuenftige galt als gelesen, bevor es geschrieben war. Das faellt niemandem als Zusammenhang auf -- man merkt nur, dass "die Benachrichtigungen nicht gehen". Der Browser schickt heute immer die letzte gesehene Nummer, ist also nicht der Grund. Aber eine Grenze, die nur davon lebt, dass der Aufrufer sich benimmt, ist keine. Jetzt wird auf die juengste Nachricht des Raums begrenzt -- abgeleitet, nicht geraten. Gefunden hat es meine eigene Pruefung: Sie setzte zum Aufraeumen 99999 und wunderte sich danach, warum das frische "@" nicht leuchtete. WOHER MAN ERFAEHRT, DASS ES DAS GIBT: Im Chat gibt es keinen Hilfeknopf. Der Hinweis steht deshalb im Leersatz einer neuen Gruppe -- dort, wo man beim ersten Oeffnen ohnehin hinsieht, und nur ab drei Leuten. In einem Zweiergespraech waere er Ballast. GEPRUEFT: pruef-erwaehnung 67/0 (neu) -- 13 Regelfaelle ohne Server, der Weg durch die Schnittstelle, das Zeichen in der Liste samt Gegenprobe bei jemandem, der dabei aber nicht gemeint war, beide Aufloesungen nebeneinander, und der ganze Ablauf am echten Bildschirm bis "Enter waehlt und schickt NICHT ab". Dazu pruef-chat 48/0, pruef-chat-optik 36/0, pruef-treffchat 110/0, pruef-chat-kanaele 79/0, pruef-glocke 31/0, pruef-push 24/0, pruef-anruf-klingelt, pruef-css-klassen, pruef-meldungen, pruef-nachfrage, pruef-tippziele. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-20 17:54:16 +02:00
DogFatherGitandClaude Opus 5	409ed551f3	"Review" heisst jetzt "Zur Freigabe" -- und Datumsfelder sind so hoch wie alle anderen ... Im Code stand die Begruendung selbst: "«Review» allein sagt einem Neuen nichts." Das Wort ist englisch, ein Hauptwort ohne Handlung, und es verraet nicht, WER jetzt dran ist. "Zur Freigabe" sagt beides: fertig von mir, wartet auf jemanden. Geaendert wurde nur, was ein Mensch LIEST -- der Zustandsschluessel bleibt `review`, der gehoert der Datenbank. Betroffen: Spalte und Weiterknopf im Aufgabenbrett, Dateien-Filter, Startseiten-Zaehler, Kachel-Unterzeile, Hinweis "Datei wartet auf Freigabe", Report. NICHT geaendert: der Kalender. Dort ist `review` eine TERMINART (ein Gespraech, in dem man zurueckschaut), kein Zustand. Ich hatte das beim Umbenennen selbst verwechselt und wieder zurueckgenommen -- ein Kommentar an der Stelle haelt die zwei Bedeutungen jetzt auseinander. pruef-sprung hing an der Wortwahl (`/review/i` auf der Beschriftung) und wurde rot, obwohl der Filter richtig stand. Sie prueft jetzt `data-status` -- den Schluessel, der sich nicht mit der Sprache aendert. DAZU, unabhaengig gefunden: Datumsfelder waren 48 px hoch, alle anderen Felder 44. Gemessen auf drei Seiten bei 390 px. Alle liegen auf dem 44-px-Beruehrziel -- nur das Datumsfeld drueckte sich darueber, weil Chromium in `::-webkit-datetime-edit` eine eigene Innenpolsterung setzt, die sogar ein gesetztes `height: 44px` ueberstimmt. Zwei Anteile, einzeln nachgemessen (jeder allein 48->46, erst beide zusammen 48->44): 1 px Polsterung oben und unten im Feldkasten, und eine Zeilenhoehe von 24 statt 22. Keine feste Hoehe gesetzt -- die Zeilenhoehe wird aus Beruehrziel und Polsterung gerechnet, damit sie mitwandert, wenn sich eines davon aendert. Geprueft: pruef-formulare 19/0 (war 16 mit 3 Fehlern), pruef-sprung 43/0, pruef-start-ansicht 151/0, pruef-aufgabenbrett 49/0, pruef-uebersicht 35/0, pruef-uebersicht-browser 20/0, pruef-deutsche-texte, pruef-css-klassen. Ausserdem: vorlagen.js geloescht (8,2 KB). `vorlagenBlock(` wurde in ca104799 eingebaut und in 9267797d wieder ausgebaut -- seither laedt die Datei auf zwei Seiten, ohne dass jemand sie aufruft. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-20 17:27:09 +02:00
DogFatherGit	0f5faf7ee6	Eine Seite, die nicht laedt, sagt es -- und bietet einen Weg zurueck ... Fuenf Suchlaeufe parallel, ihre Funde selbst nachgemessen und behoben. DER GROESSTE: 13 VON 21 SEITEN SCHLUCKTEN JEDEN NETZFEHLER. Jede Seite beginnt mit `try { await hole('/api/ich') } catch { return; }`. Faellt das Netz aus -- Aufzug, U-Bahn, Funkloch --, bricht der Block ab, und die Seite bleibt fuer immer auf "wird geladen …" stehen. Gemessen: 0 von 32 Stellen setzten `aria-busy` im Fehlerfall zurueck, und es gab KEINEN EINZIGEN "Nochmal versuchen" auf allen 21 Seiten. Im Code stand der richtige Satz dazu -- an genau einer Stelle: "Ein Platzhalter, der nie ersetzt wird, ist eine Luege mit Fortschrittsanzeige." Er galt ueberall ausser dort. Neu: window.ladefehler() in meldung.js. Sie ersetzt alles, was gerade "laedt", durch drei Dinge: was los ist, was das bedeutet, und einen Knopf, der es noch einmal versucht -- ohne die Seite neu zu laden. 21 Dateien angeschlossen. Neu: server/pruef-ladefehler.mjs, 26/0, mit abgeklemmtem Netz im echten Browser. UND DIE STARTSEITE WARF BEI EINEM FUNKLOCH AUF DIE ANMELDUNG. `catch { location.assign('/workspace/') }` -- der Mensch glaubt, er sei rausgeworfen, und tippt seinen Code neu. Dabei haelt seine Sitzung 12 Stunden; nur die Anfrage kam nicht durch. Umgeleitet wird jetzt nur noch bei einer ANTWORT, die das sagt (401). DER ANMELDEHINWEIS FUEHRTE MODIS IN DIE SPERRE. Nach zwei Fehlversuchen stand: "Stimmt die Auswahl oben? Ein Code gehoert immer zu genau einer davon." Auf der Crew-Wand ist das FALSCH -- `stillerZugang()` sucht ueber die Codekennung, die angetippte Kachel spielt fuer hand/modi keine Rolle. Sie probieren alle vier durch, sammeln vier Fehlversuche, und nach acht in zehn Minuten ist ihre Adresse gesperrt. Ein Hinweis, der die Sperre herbeifuehrt, gegen die er helfen soll. Auf der Agenturwand stimmt der Satz weiter -- deshalb wird gefragt, auf welcher Wand man steht. Dazu: Die Crew-Wand nannte nur der Community einen Weg ("Frag im Live nach"). Wer zum Team gehoert und dessen Code nicht geht, fand dort niemanden. SACKGASSE AUF DER KERNSEITE EINES MODI. treff-moderation sagte: "Zugaenge legst du in 'Personen & Zugaenge' an" -- eine Seite, die ein Modi nicht oeffnen darf. Am ersten Tag, bei leerer Community, war das der einzige Satz im Abschnitt. Jetzt fragt die Seite ueber `window.__ich.seiten`, ob es den Weg fuer DIESEN Menschen gibt. Und ein 404 wirft ihn nicht mehr wortlos auf die Startseite. TOTE KNOEPFE AN FREMDEN KARTEN. "◀ zurueck" und "▶ In Arbeit" standen an JEDER Aufgabenkarte, auch an fremden. Ein Modi sieht das Brett des ganzen Teams; er tippt, der Server lehnt mit 403 ab, und die Meldung erscheint GANZ OBEN. Bei einer Karte weiter unten sieht er nichts. Zwei Zeilen tiefer stand die Regel im Klartext: "niemandem etwas anzubieten, das dann abgelehnt wird." Der Server schickt jetzt `darf_aendern` mit. 13 STELLEN ROLLTEN GEGEN DEN WILLEN DES NUTZERS. `scrollIntoView({ behavior: 'smooth' })` beachtet "Animationen reduzieren" NICHT. Wer das eingestellt hat, hat es meist wegen Schwindel getan. Zwei Stellen fragten vorher, dreizehn nicht. Jetzt `window.sanft()`, einmal statt dreizehnmal. DAS WORT UEBER DEN BRETTERN EINES MODI HIESS "BETREUUNG". Fest im HTML, ueberschrieben nur bei Brettern mit eigenem `ober` -- sechs haben keines. Jetzt faellt es auf die GRUPPE der Kachel zurueck, ueber die er hergekommen ist. Je Rolle richtig, ohne zweite Liste. DER HINWEIS-ZU-KACHEL-WEG WAR DOPPELT KAPUTT. `bereichZu` suchte nur in GRUPPEN -- der Liste der AGENTUR. Die Kacheln von Team Dogi schickt der Server; fuer einen Modi fand die Zeile entweder nichts oder eine fremde Kachel und uebernahm deren Farbe. Und sie suchte ueber den NAMEN: "LIVE-Analyse" heisst auf der Crew-Adresse "Live-Ablauf". Beim Beheben erst den Namen umgedreht -- und damit die Agenturseite kaputt gemacht (pruef-start-ansicht sofort rot). Jetzt ueber das ZIEL, das in beiden Haeusern dasselbe ist. UND EIN BRETT WAR SEIT GESTERN GESPERRT. `TREFF_BRETTER` wird aus Kachelzielen abgeleitet. Als die Kachel "Regeln & Hilfe" am 19.09. auf `treff-regeln.html` umgelenkt wurde, fiel `regeln` heraus -- und `treff-regeln.html` verweist weiterhin darauf ("Haeufige Fragen stehen auf dem Brett Regeln & Hilfe"). Gefunden hat es pruef-treff, die seit gestern rot war. 72/0. NEBENBEI 7 SEITEN LEICHTER: meldung.js wird jetzt abgeleitet eingebunden -- nur dort, wo sagWas/ladefehler/sanft wirklich gebraucht werden. Die Anmeldewand traegt es nicht mehr. Gruen: pruef-ladefehler 26/0, pruef-sackgassen 11/0 (582 Wege, 0 ins Leere), pruef-start-ansicht, pruef-treff 72/0, pruef-treffchat, pruef-community-sicht 10/0, pruef-aufgabenbrett, pruef-code 17/0, pruef-chat-optik, pruef-nachfrage 49/0, pruef-meldungen 8/0, pruef-css-klassen, pruef-tippziele 11/0, pruef-leerzustand 13/0, pruef-rechtetafel.	2026-09-20 15:49:57 +02:00
DogFatherGit	cc39552b4f	Eine Eingabe geht nicht mehr wortlos verloren ... Filipe: "Was passiert, wenn jemand eine Funktion abbricht?" GEMESSEN: Acht Dialoge im Workspace enthalten Eingabefelder -- "Aufgabe bearbeiten" (10 Felder), der Tageseintrag in der Leistung (8), Ziele, Netzwerk, Import, ein neuer Chat-Raum, ein Creator. Bei allen galt: Esc, Klick daneben oder "Abbrechen" wirft ALLES weg, wortlos. Wer zehn Felder ausgefuellt hat und mit dem Daumen den Rand trifft, faengt von vorn an. Neu: window.verwurfWache() in nachfrage.js. BEIDE SCHLIESSWEGE, denn sie laufen verschieden: Esc / Klick daneben loest `cancel` aus, close() wird NICHT gerufen "Abbrechen"-Knopf ruft close(), loest kein `cancel` aus Wer nur einen abfaengt, hat eine halbe Sicherung -- und die ist schlimmer als keine, weil man ihr vertraut. NICHT VON HAND VERTEILT: Jeder Dialog mit Feldern bekommt sie automatisch (ausser dem Nachfrage-Dialog selbst -- er wuerde beim Schliessen nach sich selbst fragen, in sich selbst, und haenge fuer immer). Wer morgen einen neunten baut, hat sie, ohne daran zu denken. UND SIE FRAGT NUR BEI WIRKLICHER AENDERUNG. Beim Oeffnen wird ein Abbild der Felder genommen, beim Schliessen verglichen. Wer einen Dialog aufmacht und gleich wieder zu, merkt nichts. ZWEI SACHEN BEIM BAUEN GEMESSEN STATT VERMUTET: MEINE EIGENE "ROBUSTHEIT" HAT DIE WACHE STILL AUSGESCHALTET. Gegen den Fall "Felder werden erst nach dem Oeffnen gefuellt" hatte ich einen zweiten Schnappschuss beim Hineinklicken (`focusin`) eingebaut. Gemessen: Der entstand NACH dem Tippen -- Fokus und Werteingabe passieren im selben Atemzug. `beimOeffnen` war danach gleich dem getippten Text, und der Dialog ging wortlos zu. Die Sicherung sah eingebaut aus und tat nichts. Jetzt wird im naechsten BILD nachgetragen: Was das Skript beim Oeffnen nachtraegt, ist drin; getippt haben kann in derselben Sechzehntelsekunde niemand. (Nachgemessen: Alle acht Dialoge fuellen heute VOR showModal.) ZWEIMAL ESC HINTEREINANDER SCHLIESST TROTZDEM. Das ist Chromiums "close watcher": Eine Seite darf den Nutzer nicht mit Esc einsperren. Die Regel ist richtig; dagegen anzubauen waere falsch. Sie steht deshalb im Code und in der Pruefung -- festgehalten, nicht umgangen. Der Knopf unterliegt ihr nicht, und am Handy gibt es ohnehin kein Esc. Elf Speicherwege rufen `vergessen()`, damit nach erfolgreichem Speichern nicht gefragt wird. Eine Warnung nach dem Speichern waere genau die, die man wegklickt -- und danach auch die echte. pruef-nachfrage 49/0 (war 33), davon zehn am Bildschirm: unberuehrt geht er ohne Nachfrage zu nach einer Aenderung fragt Esc nach, der Dialog bleibt offen "Weiter bearbeiten" laesst ihn offen UND der Text steht noch da auch der Abbrechen-Knopf fragt -- jedes Mal "Verwerfen" schliesst wirklich, und der Text steht nirgends pruef-aufgabenbrett, -leistung, -uebersicht-browser, -chat-optik, -css-klassen gruen, pruef-tippziele 11/0.	2026-09-20 15:11:25 +02:00
DogFatherGit	285038f400	Der vertrauliche Meldeweg vergisst jetzt -- und sagt, bis wann ... Zwei Entscheidungen, die offenstanden. Beide getroffen, nachdem gemessen war, was wirklich da ist. 1. WIE LANGE BLEIBEN ABGESCHLOSSENE FAELLE? 90 Tage. Die Entscheidung war bereits getroffen: `AUFBEWAHRUNG_TAGE = 90` steht seit dem 19.09. in hilfe-tabellen.js, mit Begruendung ("ein Fall kommt manchmal wieder auf"). Nur hat sie NIEMAND durchgesetzt -- `hilfeAufraeumen()` gab es, und der einzige Aufrufer war ihre eigene Pruefung. Der Kommentar darueber behauptete "Wird beim Start aufgerufen (siehe index.js)"; das war nie wahr. Jetzt steht die Regel in workspace-aufbewahrung.js, dem Loeschkonzept, das sich selbst durchsetzt -- beim Start und danach taeglich. Die zweite Fassung in workspace-hilfe.js ist WEG, nicht doppelt: Zwei DELETEs auf dieselben Daten waeren morgen verschieden, und der Unterschied fiele erst auf, wenn er zaehlt. GEMESSEN VOR DEM EINSCHALTEN: In der echten Datenbank steht heute KEIN einziger Fall. Der erste Lauf loescht nichts, und der erste Fall kann fruehestens in drei Monaten 90 Tage alt werden. Jetzt einschalten ist frei -- spaeter waere es der riskante Moment gewesen. PRAGMA foreign_keys steht im Dienst auf 1, und hilfe_nachrichten traegt ON DELETE CASCADE. An einem echten Fall mit Nachricht nachgemessen: vorher 1/1, nachher 0/0. Ohne diese Messung waere der Fall verschwunden und der eigentliche Text liegengeblieben. 2. SOLL EIN GESCHLOSSENER FALL WIEDER ZU OEFFNEN SEIN? Nein. Im Kopf von workspace-hilfe.js steht: "EIN GESCHLOSSENER FALL IST GESCHLOSSEN. Auch fuer die Leitung -- sonst ist 'zugemacht' eine Meinung und keine Tatsache." Das ist eine gute Regel, und sie bleibt. Nachgemessen, dass sie auch traegt: Ein Melder kann seinen geschlossenen Fall weiter LESEN, und ein geschlossener Fall zaehlt nicht gegen das Limit von drei offenen. Wer eine Wiederholung melden will, kann das also jederzeit -- die Bauweise ist stimmig. NUR WUSSTE DAS NIEMAND. Dort stand ein Satz: "Dieser Fall ist abgeschlossen (Datum)." Jetzt stehen drei -- und sie beantworten die drei Fragen, die man in dem Moment hat: Kann ich noch schreiben? Nein, und er laesst sich nicht oeffnen. Bleibt das hier stehen? Bis zum TT.MM.JJJJ, dann geloescht. Und wenn es wieder passiert? Neu melden, der alte zaehlt nicht mit. Das Datum kommt vom Server (`lesbar_bis`), die Frist ebenso -- sie steht nur an EINER Stelle. Und sie steht jetzt auch im Dialog BEIM Schliessen: Wer eine Uhr startet, soll das vorher wissen, nicht danach. OHNE UHRZEIT, und das ist kein Schoenheitsgrund: Ein Fall, der am 20.09. um 14:04 (Sommerzeit) geschlossen wird, verfaellt 90 Tage spaeter um 13:04 -- die Uhr wird dazwischen zurueckgestellt. Richtig gerechnet, sieht aus wie ein Fehler. Wer eine Stunde sucht, die es nicht gibt, hat Zeit verloren. UND DIE URSACHE, DAMIT ES NICHT WIEDER PASSIERT: hilfe_faelle kam am 19.09. dazu, das Loeschkonzept ist vom 15.09., und nichts hat die beiden je verglichen. Neue Pruefung in pruef-aufbewahrung: Jede Tabelle mit einer Spalte, die "hier ist etwas zu Ende" sagt, MUSS im Konzept stehen. Kein "jede Tabelle muss drinstehen": 46 Tabellen, 41 mit Personenbezug -- das gaebe 38 Meldungen, von denen fast alle falsch waeren (sie sind ueber personen_geloescht gedeckt). Eine Pruefung, die 38-mal meldet, wo einmal richtig waere, wird abgeschaltet. Gesucht wird das schmale Merkmal: GENAU ZWEI Tabellen im Haus tragen so eine Spalte. Beide jetzt im Konzept -- hilfe_faelle mit Frist, aufgaben ausdruecklich OHNE (erledigte Aufgaben sind Arbeitsdokumentation, keine Meldung ueber einen Menschen). pruef-hilfe 84/0 (war 59) -- darunter zehn neue am Bildschirm: "drei Saetze statt einem", "sie stehen untereinander, nicht nebeneinander" (ein <p> in einem <p> waere ungueltig, der Container ist jetzt ein <div>), "und WANN, mit Datum". pruef-aufbewahrung 45/0 (war 41), mit Gegenprobe.	2026-09-20 14:10:38 +02:00
DogFatherGit	9e9ed67c4a	Keine Sackgassen -- fuer JEDE Rolle, nicht nur fuer den Gast ... Filipe: "Es darf keine Sackgassen geben." pruef-community-sicht prueft genau das -- aber nur fuer den GAST. Ein Modi hat 25 Kacheln, eine rechte Hand 30, DogFather 39. Keine dieser drei Rollen war je darauf geprueft worden, ob ihre Seiten auf etwas verweisen, das sie nicht oeffnen darf. Und genau dort ist es zweimal passiert: Am 19.09. warf "Klingelt nichts?" ALLE DREI Team-Rollen auf die Startseite zurueck, und der Kalender-Verweis fuehrte die Community seit jeher ins Leere. Beides hat jemand zufaellig gefunden, nicht eine Pruefung. Neu: server/pruef-sackgassen.mjs -- 11/0. 4 Rollen, 126 Seitenansichten, 582 sichtbare Wege, 0 ins Leere. DREIMAL ABGELEITET STATT AUFGEZAEHLT: Die ROLLEN kommen aus der Anmeldewand (data-rolle), nicht aus einer Liste. Kaeme eine fuenfte dazu, stuende sie sonst nicht drin und niemand wuerde es merken. Die SEITEN kommen aus der Rechtetafel -- derselben, nach der der Server entscheidet. Keine zweite Liste, die auseinanderlaufen kann. Die BRETTER hinter bereich.html kommen aus den Kacheln dieser Rolle. Die Altersbestaetigung des Gastes wird an der ANTWORT erkannt (400 + alter_offen), nicht an der Rolle: Eine Liste "wer bestaetigen muss" waere morgen falsch, wenn die Schranke noch woanders gilt. Und sie braucht weder HTTPS-Front noch umgebogenen Namensdienst: Das Haus einer Person kommt aus ihrer ROLLE, nicht aus der Adresse. Ein Modi ist auch auf 127.0.0.1 im Crew-Haus. GEGENPROBE: Ein erfundener Weg auf eine gesperrte Seite wird gefunden. Ohne sie waere "0 ins Leere" auch dann wahr, wenn nichts geladen haette -- deshalb steht die Zahl der Wege zusaetzlich in der Bedingung.	2026-09-20 12:52:51 +02:00
DogFatherGit	0a2363374c	Eine Nachricht, die nicht ankommt, sieht man jetzt -- und schickt sie neu ... DER KOMMENTAR STAND DA, DIE SACHE NICHT. Im Chat stand woertlich: "NICHT STILL VERSCHWINDEN LASSEN. Wer etwas schreibt und es sieht, glaubt, es sei angekommen." Gemessen: `markiereAlsGescheitert` setzte `n.gescheitert = true` -- und gelesen hat das Merkmal NIEMAND, weder das Skript noch das CSS. Eine gescheiterte Nachricht sah exakt aus wie eine zugestellte. Im CSS stand an der Stelle eine leere Regel mit dem Kommentar "Platzhalter, damit :has unterstuetzt bleibt". Ein Kommentar, der eine Absicht beschreibt, erfuellt sie nicht. Jetzt: sichtbare Kante an der Blase, blasse Darstellung solange sie unterwegs ist, und ein Knopf "Nochmal senden" daneben. Der Satz in der Meldezeile bat vorher ums Kopieren -- fuenf Handgriffe fuer etwas, das die Seite in einem tun kann; den Text hat sie ja noch. KEIN ZWEITER SENDEWEG: Der Knopf legt den Text zurueck ins Feld, stellt das Antwortziel wieder her und ruft `abschicken`. Ein eigener Weg waere morgen anders als dieser, und der Unterschied fiele erst auf, wenn er zaehlt. "ZUM NEUESTEN" STAND AUF EINER RECHNUNG VON GESTERN: `bottom: 96px` -- die Hoehe der Schreibleiste an dem Tag, an dem der Knopf gebaut wurde. Das Textfeld waechst aber bis 160. Wer lange tippt und gleichzeitig oben liest, hatte den Knopf HINTER der Leiste. Und darueber koennen noch das Nachtruhe-Band und der Hochlade-Balken stehen. Jetzt misst die Seite den ganzen Unterbau selbst -- ueber einen Beobachter statt einer Liste von Ausloesern, denn das Band erscheint um Mitternacht von selbst. Kommt morgen ein viertes Bauteil dazu, rechnet es von allein mit. NEUE PRUEFUNG FUER EINEN WEG, DEN NIE ETWAS GEPRUEFT HAT: pruef-chat-optik faengt die Sendeanfrage jetzt einmal ab und geht den ganzen Fehlerweg durch -- 10 Aussagen, darunter: der Unterschied ist auch zu SEHEN, nicht nur im Merkmal (Rand 1px) die Nachricht steht danach GENAU EINMAL da, nicht doppelt und sie ist beim Gegenueber angekommen Der letzte ist der eigentliche: Alles davor koennte gut aussehen und trotzdem nichts zugestellt haben. pruef-treffchat war seit gestern rot -- 8 Fehler ueber "undefined". Sie suchte die Kachel mit `ziel === "chat.html"`, seit dem 19.09. heisst es `chat.html?raum=treff` (sie fuehrt direkt in den Raum). Kein Befund ueber das Haus, sondern einer ueber sich selbst. Sie sucht jetzt nach der SEITE und prueft statt des Wortlauts das, worauf es ankommt: Man erkennt den Chat, und der Name kommt genau einmal vor. 110/0 statt 108 mit 8 Fehlern. pruef-chat, -anhaenge, -kanaele, -optik, -ausbau gruen, pruef-start-ansicht 151/0, pruef-tippziele 11/0, pruef-nachfrage 33/0, pruef-leerzustand 13/0, pruef-meldungen 8/0, pruef-css-klassen gruen.	2026-09-20 12:44:31 +02:00
DogFatherGit	18148675a9	Die gepflegte Liste der Tippziele wird jetzt bewacht ... In module.css steht ein Block, der ein Dutzend Klassen auf 44 Pixel hebt. Diese Liste wurde von Hand gepflegt -- genau die Falle, vor der die Hausregeln warnen: Wer einen Knopf mit `width: 34px` baut, traegt ihn dort nicht nach und merkt es nicht. GEMESSEN: FUENF Bedienelemente standen nicht drin. .nachricht__weg 24 breit (das x an einer Nachricht) .antwort-leiste__weg 28 breit .chat__weg 34 breit <- der unangenehmste .todo__weg 36 breit .sicht__weg 28 breit `.chat__weg` ist der Knopf, der ein Gespraech wegraeumt -- und direkt daneben sitzt der, der es FUER ALLE aufloest. Zwei 34-Pixel-Ziele nebeneinander, eines davon unwiderruflich. Neu: server/pruef-tippziele.mjs -- 11/0, ohne Browser, unter einer Sekunde. Sie leitet die Bedienelemente aus dem CSS ab und verlangt fuer jedes eine Abdeckung. Die Liste bleibt (CSS kann nicht rechnen), aber sie kann nicht mehr still veralten. DER ERSTE ANLAUF WAR ZU GROB und meldete 21 Treffer, davon 15 falsch: `.chat__weg svg` ist 17 Pixel gross und soll das auch sein -- getroffen wird der Knopf darum herum. Eine Pruefung, die zu viel meldet, wird abgeschaltet; das ist kein besseres Ergebnis als eine, die zu wenig meldet. Jetzt unterscheidet sie Bedienelement und Innenteil (svg, ::after, __punkt, __lupe, __pfeil). UND DIE REPARATUR WAR ERST ZU KLUG. Fuer das 24-Pixel-x in einer Chat-Nachricht hatte ich eine unsichtbare Trefferflaeche gebaut (`::after { inset: -10px }`), um die Zeile nicht hoeher zu machen. Dann gemessen: Die Zeile IST schon 44 hoch -- `start.css` hebt unter 760 px bereits JEDEN button. Es fehlte nur die BREITE. Die Flaeche haette ein Problem geloest, das es nicht gibt, und dafuer einen Trick eingefuehrt, den man beim naechsten Lesen erst verstehen muss. Jetzt schlicht `min-width: 44px`. Gemessen am Bildschirm, mit und ohne Finger: Maus .nachricht__weg 24x24 .chat__weg 34x34 (unveraendert) Finger .nachricht__weg 44x44 .chat__weg 44x44 `pointer: coarse` und nicht `max-width`: Ein Tablet ist 1024 breit und wird trotzdem mit dem Finger bedient. NACHTRAG ZUR PRUEFUNG SELBST: Sie verlangte kurz, dass es die Trefferflaeche GIBT -- und fiel um, als sie wieder verschwand. Eine Pruefung, die eine Bauweise erzwingt statt eines Ergebnisses, steht dem Aufraeumen im Weg. Sie erkennt sie jetzt an, verlangt sie aber nicht. pruef-tippziele 11/0, pruef-chat-optik gruen, pruef-css-klassen gruen, pruef-nachfrage 33/0, pruef-leerzustand 13/0.	2026-09-20 12:36:02 +02:00
DogFatherGit	2f3fb03ffe	Eine Pruefung, die nach der ersten Aussage stirbt, prueft nichts ... pruef-start-ansicht kam seit gestern Nachmittag ueber die ERSTE Aussage nicht hinaus: 1 statt 151. Sie starb mit "Failed to execute getComputedStyle: parameter 1 is not of type Element" -- und sagte damit gar nichts mehr ueber die Startseite. URSACHE WAR MEIN EIGENER HINWEIS VON GESTERN. "Bei dir klingelt nichts" gehoert absichtlich zu keinem Bereich (die Anruf-Probe ist ein Werkzeug, keine Kachel). Dadurch bekam die Zeile kein Zeichen -- und die Pruefung rief getComputedStyle auf null. ZWEI FEHLER, ZWEI REPARATUREN: Die ZEILE sah kaputt aus. Sie stand als einzige ohne Zeichen zwischen allen anderen, der Text begann weiter links. Genau der stille Fehler, der wie Absicht aussieht. Sie bekommt jetzt immer ein Zeichen -- aber KEINE Farbe, denn sie soll keinen Bereich behaupten, zu dem sie nicht gehoert. Die PRUEFUNG durfte daran nicht sterben. Ein fehlendes Teil ist ein BEFUND, kein Absturz. Und sie nahm an, jeder Hinweis zaehle etwas. Seit gestern gibt es zwei Sorten: zaehlende ("2 Aufgaben sind ueberfaellig") und Zustaende ("Bei dir klingelt nichts"). Sie unterscheidet das jetzt und nennt beide Anzahlen -- faellt eine Sorte ganz weg, sieht man es. Das ist die GENAUERE Pruefung, nicht die schwaechere. GEBAUT, GEMESSEN, WIEDER ENTFERNT: Auf dem Weg dahin hatte ich die Kachelgruppen beim ersten Besuch einklappen lassen -- 25 Kacheln in 5 Gruppen sind fuer den ersten Tag eine Wand. Drei Messungen haben es widerlegt: Die erste Gruppe ist nicht die wichtigste. Bei DogFather heisst sie "Rund um das Team" und hat GENAU EINE Kachel. Er haette eine Kachel gesehen und sieben zugeklappte Ueberschriften. Die Regel "nur wenn es nicht auf den Schirm passt" haette auch auf 1280x900 gegriffen -- bei 30 Kacheln passt es nie. Es gibt keinen "ersten Besuch": Der Merker entsteht erst beim Klappen. Wer die Seite seit Wochen benutzt und nie geklappt hat, faende am Morgen seine Startseite umgebaut. Die Begruendung steht jetzt im Code, damit es niemand ein zweites Mal baut. pruef-start-ansicht 151/0, pruef-nachfrage 33/0, pruef-leerzustand 13/0, pruef-meldungen 8/0, pruef-css-klassen gruen.	2026-09-20 12:29:59 +02:00
DogFatherGit	e5eed8506c	Der gefaehrlichste Handgriff im Haus wird jetzt am Bildschirm geprueft ... pruef-personen-loeschen gibt es seit Langem -- sie kennt aber nur die Schnittstelle: kein Browser, kein Knopf, kein Dialog. Der Weg, den ein Mensch geht, um eine Person zu loeschen, war nie geprueft. Und das ist der eine Handgriff, den man nicht zuruecknehmen kann. pruef-nachfrage hat jetzt einen Browserteil (33/0 statt 17/0): der Dialog geht auf und nennt den Namen im Titel er sagt, dass es endgueltig ist, was passiert und was bleibt ein FALSCH abgetippter Name schliesst ihn NICHT und sagt, warum der Abbruchknopf loescht nichts richtig abgetippt wird geloescht (Liste 2 -> 1) Abmelden fragt nach und nennt den Grund (Zugangscode) Esc bricht ab -- man bleibt angemeldet BEIM BAUEN ZWEIMAL DANEBENGEGRIFFEN, beide Male gemessen statt vermutet: Die Liste zeigte nur eine Person, obwohl vier in der Datenbank standen. Das sah nach einem Befund aus. Die Rollen-Abschnitte sind standardmaessig ZU -- nur der eigene ist offen, und das ist richtig so. Die Pruefung klappt ihn jetzt auf. Vorher wurde mit einer festen Wartezeit gearbeitet. Jetzt wird auf den Zustand gewartet, nicht auf die Uhr. Neu: server/helfer-nachfrage.mjs (bestaetige/verwerfe/nachfrageText) kennt beide Wege -- den <dialog> und den confirm()-Notnagel fuer Safari vor 15.4. Ohne den zweiten liesse sich der Notnagel nie pruefen.	2026-09-19 20:24:28 +02:00
DogFatherGit	1207b79a33	Hochladen sieht man jetzt, Leerzustaende sagen was hingehoert ... DREI BLOECKE AUS DEM PERFEKTIONSLAUF. 1. HOCHLADEN MIT FORTSCHRITT UND ABBRUCH Alle fuenf Wege (Dateien, Chat-Anhang, Wissen-PDF, Aufgaben-Anhang, Profilbild) benutzten `fetch`. Das kann beim SENDEN nicht sagen, wie weit es ist -- sichtbar war "wird hochgeladen …", von der ersten bis zur letzten Sekunde gleich. Bei 40 MB im Mobilfunknetz zwei Minuten. Wer das sieht, drueckt noch einmal und laedt dieselbe Datei doppelt. Neu: workspace/assets/js/hochladen.js (XMLHttpRequest, das Einzige, was `upload.onprogress` kann) samt gemeinsamer Anzeige. Drei Ausgaenge: fertig / abgebrochen / schiefgegangen -- und ein Abbruch ist KEIN Fehler und bekommt keine rote Meldung. DABEI AUFGEFALLEN: KEINE EINZIGE PRUEFUNG im Haus laedt eine Datei ueber die Oberflaeche hoch. Der ganze Umbau waere gruen gewesen, ohne dass ein Byte je den Weg der Nutzer gegangen waere. Neu: server/pruef-hochladen.mjs -- 18/0, mit echter Datei. Zwei Irrtuemer beim Bauen, beide gemessen statt vermutet: Ohne Drosselung gibt es auf localhost EINEN Fortschritt-Stand. Das sah nach Befund aus und war keiner. Jetzt 2 MBit/s ueber CDP -- derselbe Verlauf wie bei den Modis im Mobilfunk, 57 gemessene Zwischenstaende. Gewartet wurde auf den Dateinamen "irgendwo im Dokument" -- der stand auch im Fortschrittsbalken. Die Bedingung war erfuellt, bevor etwas angekommen war. 2. LEERZUSTAENDE Elf von 18 Brettern fielen auf "Noch kein Eintrag in diesem Bereich" zurueck. Am ersten Tag ist ALLES leer -- wer da achtzehn Bretter oeffnet und achtzehnmal denselben Satz liest, lernt nichts ueber die Bretter, sondern dass das System kaputt ist. Jeder Satz sagt jetzt, was hier hingehoert UND was der naechste Schritt ist. Neu: server/pruef-leerzustand.mjs -- 13/0, leitet die Bretter aus BEREICHE ab; ein neunzehntes ohne Satz macht sie rot. 3. ABMELDEN UND KONTRASTMODUS Abmelden war am Handy ein 44-Pixel-Zeichen neben Glocke und Suche, sofort wirksam. Teurer als es aussieht: Zum Wiederanmelden braucht man den Zugangscode, und den gibt es EINMAL. Jetzt mit Rueckfrage, die genau das sagt -- und dazu, dass Zumachen reicht (12 Stunden). Kontrastmodus: 68 Regeln zeigen einen Zustand NUR ueber Farbe (35x aria-pressed, 33x data-an). Der Modus ersetzt alle Farben und entfernt box-shadow -- gedrueckt sah aus wie nicht gedrueckt. 14 CSS-Dateien hatten gar keinen Block. Statt 14 Bloecke zu pflegen eine Regel in gate.css, die den ZUSTAND trifft statt die Datei. Gemessen mit forcedColors: active -- vorher ununterscheidbar, jetzt `solid 2px Highlight`. Was seinen Zustand als WORT traegt (.marke-status, .t-stufe, .spalte), braucht nichts -- nachgesehen, nicht vermutet. PRUEFUNGEN, DIE AUF confirm() WARTETEN: Fuenf Dateien benutzten `seite.once("dialog", d => d.accept())`. Playwright faengt confirm() selbst ab, einen <dialog> nicht -- pruef-chat-anhaenge meldete acht Fehler, keiner davon im Code. Neu: server/helfer-nachfrage.mjs, der beide Wege kennt (auch den Notnagel fuer Safari vor 15.4). pruef-chat-anhaenge, -ausbau, -optik und pruef-code wieder gruen. hilfeAufraeumen bleibt ausgeschaltet -- das loescht echte Daten und ist Filipes Entscheidung.	2026-09-19 20:16:23 +02:00
DogFatherGit	c516aad4ed	Nichts verschwindet mehr ohne eine Nachfrage, die sagt was passiert ... Filipe: "Es darf vor allem keine Stellen geben, an denen ein Benutzer etwas falsch machen kann, nur weil die Seite es nicht verstaendlich genug erklaert." Gemessen: 30 Stellen in 16 Dateien benutzten confirm() oder prompt(). Das Haus hatte die richtige Bauweise laengst -- einen <dialog>, in aufgaben.html sogar ausfuehrlich begruendet -- aber sie stand IN EINER SEITE. Wer anderswo etwas loeschen liess, hatte sie nicht. confirm('Wirklich loeschen?') stellt die falsche Frage: Es fragt, ob man sicher ist, und nennt nicht, WAS passiert, was BLEIBT und ob es ZURUECK geht. Jetzt beantwortet jeder der 41 Dialoge alle drei. Neu: workspace/assets/js/nachfrage.js -- window.frageNach() mit Pflichtgrund, Zahlenfeld, einzeiliger Eingabe und Abtippsicherung. Drei Ausgaenge: <dialog> / confirm()-Notnagel fuer Safari vor 15.4 / Abbruch (Esc, Klick daneben, "Doch nicht" -- immer false). DREIMAL DERSELBE FALLSTRICK, dreimal nachgemessen statt vermutet: .dialog stand in aufgaben.css und leistung.css -> auf dateien.html waere der Dialog ein weisser Systemkasten gewesen. 14 Regeln klammergenau nach module.css verschoben (Klammern gezaehlt, nicht per Muster geschnitten -- heute frueh hat ein nicht-gieriges Muster schon einmal CSS zerrissen). Das Formular trug .neu neu--blank -- und .neu gibt seine Abstaende nur in aufgaben.css. Gemessen: padding 0px, und die Felder verloren ihre height:44px. Jetzt steht alles unter .nachfrage__form in module.css; der Dialog borgt nichts mehr. Die erste Fassung der Pruefung zaehlte nachfrage.js SELBST als Nutzer -- damit war jede Seite trivialerweise "Nutzer" und die Pruefung gruen ohne Inhalt. Jetzt ausdruecklich ausgenommen. ZWEI FUNDE NEBENBEI: hilfeAufraeumen() wird im Betrieb NIE aufgerufen. Der Kommentar behauptete "wird beim Start aufgerufen (siehe index.js)" -- das war nie wahr; einziger Aufrufer ist die eigene Pruefung. Folge: geschlossene vertrauliche Faelle bleiben unbegrenzt stehen. NICHT eingeschaltet (das loescht echte Daten und ist Filipes Entscheidung), sondern der Kommentar richtiggestellt. Einen Hilfe-Fall zu schliessen ist endgueltig -- es gibt keine Route, die ihn wieder oeffnet. Vorher stand darueber nur die Frage nach einem Schlusswort. Jetzt sagt der Dialog es. pruef-struktur hat meine eigene Pruefung von heute Nachmittag erwischt: Sie bildete ihr Datum aus UTC. Beim Beheben erst heuteLokal(datum) genommen -- die Funktion nimmt gar kein Argument und haette still "heute" statt "+3 Tage" geliefert. Jetzt tagLokal(3), nachgerechnet: Abstand 3 Tage. Am Bildschirm angesehen (Rechner 1280, Handy 390): passt rein, Esc ergibt false, Fokus liegt auf dem harmlosen Knopf, Knoepfe 44px auf Touch. Der Platzhalter im Abtippfeld zeigte den erwarteten Namen -- das sah aus wie ein schon ausgefuelltes Feld, entfernt. Neu: server/pruef-nachfrage.mjs -- 17/0, mit sechs Gegenproben und beiden Richtungen (wer fragt, laedt die Datei; wer nie fragt, laedt sie nicht -- sonst truege die Anmeldewand 4,8 KB fuer nichts). pruef-meldungen 8/0, pruef-css-klassen gruen, pruef-struktur gruen, pruef-leistung gruen.	2026-09-19 19:57:43 +02:00
DogFatherGitandClaude Opus 5	26937dda16	Ein klingelndes Telefon haengt nicht mehr an einem einzigen Kanal ... Filipe: "wenn vanvan rangeht und redet klingelt es immer noch bei mir weiter, der anruf verbindet nicht richtig." === WAS DAS PROTOKOLL SAGT === 17:04:52 anruf_start Person 1 (Filipe) 17:05:25 anruf_ende Person 4 (VanVan) 24 s 17:05:31 anruf_ende Person 1 (Filipe) 39 s Sie WAR im Gespraech -- der Server hat sie 24 Sekunden als Teilnehmerin gefuehrt. Das Ereignis "dabei" ist also verschickt worden. Bei Filipe kam es nicht an: `tonAus()` ist das Erste im `dabei`-Zweig, noch vor jeder Pruefung, und das Tuten lief weiter. === GEPRUEFT UND AUSGESCHLOSSEN === Raumzugehoerigkeit beide in Raum 1, bei keinem `raus_am` gesetzt Verkabelung Server sendet mit `art: "anruf"`, chat.js reicht an window.anrufEreignis weiter, anruf.js nimmt entgegen -- alle drei Stellen stimmen Tonsteuerung ein einziger Taktgeber, `tonAus` raeumt ihn; kein zweiter Weg, der ihn neu startet Ereignisstrom Keep-alive vorhanden, Kopfzeilen richtig (no-transform, X-Accel-Buffering: no) Service Worker hat gar keinen fetch-Handler, kann also kein altes Skript ausliefern teilnehmerVon vs. teilnehmerFuerAnruf reicht nur durch, dieselbe Abfrage Es geht unterwegs verloren, auf einem Weg, der von hier aus nicht messbar ist: Ereignisstrom ueber Cloudflare, ein schlafender Reiter, ein Neustart im falschen Moment. === ALSO NICHT WEITERSUCHEN, SONDERN DIE ABHAENGIGKEIT BESEITIGEN === Ein klingelndes Telefon darf nicht an einem einzigen, zerbrechlichen Kanal haengen. Solange es klingelt, fragt der Anrufer jetzt SELBST nach: "ist schon jemand dran?" -- alle zwei Sekunden an `/workspace/api/anruf/:raum`, das es laengst gibt. Der Ereignisstrom bleibt der erste Weg, er ist schneller. Das hier ist das Netz darunter. Kommt das Ereignis an, hat die Nachfrage nichts mehr zu tun und haelt von selbst an (sie prueft `anruf.beginn` und die bekannten Teilnehmer). Sie hoert an JEDEM Ende auf: beim Auflegen, wenn die Verbindung steht, wenn das Ereignis doch ankommt, wenn der Anruf vorbei ist. Eine Schleife, die weiterlaeuft, fragt sonst auf jedem Geraet, das je telefoniert hat, alle zwei Sekunden nach einem Anruf, den es nicht mehr gibt. Alle zwei Sekunden und nicht jede halbe: Es klingelt hoechstens zwei Minuten, das sind sechzig Abrufe. === ZWEI DINGE, DIE DIESE SUCHE ERST SO MUEHSAM GEMACHT HABEN === DAS PROTOKOLL KANNTE ANFANG UND ENDE, ABER NICHT DEN MOMENT DAZWISCHEN. Die wichtigste Frage -- "ist sie ueberhaupt rangegangen?" -- war nur ueber einen Umweg zu beantworten (ein `anruf_ende` mit ihrer Nummer). Das ist eine Schlussfolgerung, keine Auskunft. `anruf_dabei` steht jetzt drin, mit der Zahl der Beteiligten. UND EINE PRUEFUNG WAR GRUEN, OHNE ETWAS ZU PRUEFEN. In chatEreignis stand `(zuschauer.get(personId) || []).length` -- `zuschauer` haelt aber Mengen, und eine Menge hat kein `length`. Der Ausdruck war IMMER undefined, also immer falsch, also wurde nie uebersprungen: Wer die Seite offen hatte, bekam zusaetzlich zur Nachricht auf dem Bildschirm noch eine Meldung aufs Handy. Der Kommentar drei Zeilen darueber warnt woertlich davor ("der schnellste Weg, dass er Benachrichtigungen abschaltet"), und `siehtZu()` weiter unten macht es mit `.size` richtig. Die Absicht stand da, die Zeile tat das Gegenteil. Meine eigene Pruefung hat das mitgetragen: Sie bestaetigte den alten WORTLAUT statt sein VERHALTEN und war deshalb gruen. Genau die Hausregel vom 01.09. -- ein gruener Haken sagt nur, dass die Bedingung erfuellt war, nicht dass sie das Richtige geprueft hat. Jetzt prueft sie auf `.size`. GEMESSEN: pruef-anruf-klingelt 24/0 (vorher 17), pruef-anruf 114/0, pruef-turn-wege 15/0, pruef-meldungen 8/0. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-19 19:15:51 +02:00
DogFatherGitandClaude Opus 5	9a1287aa0e	Es hat nie geklingelt -- und die Vermittlung war nie das Problem ... Filipe: "irgendwas klappt mit dem telefonieren nicht." === WIE DER FEHLER GEFUNDEN WURDE === Ich habe zuerst wieder die Vermittlung verdaechtigt. Stattdessen das Protokoll des Servers gelesen -- und dort stand es die ganze Zeit: 24x anruf_start, jeder nach 7 bis 39 Sekunden beendet im Chat danach jedes Mal: "Verpasster Anruf" die Gegenseite schrieb: "Hab keinen Anrufeingang gehabt und keine Benachrichtigung" Es ging nie um Ton oder Verbindung. Es hat bei der anderen Person schlicht nicht geklingelt. Dieselbe Lehre wie am 06.09. ("kommt keine Mail an" -- erst fragen, OB gesendet wurde) und am 14.09. (zwei Tage Audiowege verfolgt, waehrend die CPU bei 98 % stand). Eine halbe Minute in der richtigen Tabelle haette Stunden gespart. Nebenbefund zur Messbarkeit: Das coturn-Protokoll kann die Frage gar nicht beantworten -- es schreibt Zuteilungen bei dieser Stufe nicht mit. Meine eigene Zuteilung von 16:35 taucht dort ebenfalls nicht auf. Wer daraus "null Zuteilungen, also kaputt" liest, sucht am falschen Ende. Das ist der dritte Ausgang: nicht "in Ordnung" und nicht "kaputt", sondern "kann ich hier nicht sehen". === WAS WIRKLICH DEFEKT WAR === Die Benachrichtigung WURDE zugestellt -- `zuletzt_ok` am Geraet stand auf genau die Anrufminute. Sie hat nur nicht geklingelt: 1. `Urgency: "normal"` STAND FEST IM TRANSPORT, fuer jede Meldung. Auf Android entscheidet dieser Kopf, ob sofort zugestellt wird oder bis zum naechsten Aufwachen gewartet. Im Stromsparmodus werden daraus Minuten -- bei einem Anruf, der 120 Sekunden klingelt, ist das ein verpasster Anruf mit Zeitstempel. 2. `renotify: false` UND `tag: d.art`. Eine zweite Meldung mit derselben Kennung ersetzt die erste LAUTLOS. Wer ein zweites Mal anruft, WEIL nicht abgehoben wurde, loest damit gar keinen Ton mehr aus -- genau im wichtigsten Moment. 3. KEIN vibrate, KEIN requireInteraction. Ein stiller Kasten, der von selbst verschwindet. In einer Hosentasche unsichtbar. Fuer "Aufgabe ueberfaellig" ist all das genau richtig, und der Kommentar daneben stimmte auch ("eine Meldung, die stehen bleibt, ist eine Zumutung"). Fuer ein klingelndes Telefon ist es das Gegenteil. Jetzt unterscheidet das Haus beides: - eigene Kennung je Anruf, damit der zweite den ersten nicht stillschweigend ersetzt - renotify, vibrate (zweimal lang, wie ein Telefon), requireInteraction - Urgency: high und eine TTL von 150 Sekunden -- ist der Anruf vorbei, verfaellt auch die Meldung, statt eine Stunde spaeter nachtraeglich aufzuploppen - alle ANDEREN Meldungen bleiben unveraendert ruhig. Das ist kein Nebensatz: Wuerde alles vibrieren und stehenbleiben, schaltet es nach drei Tagen jemand ab -- und dann klingelt auch der Anruf nie wieder. Die Dringlichkeit haengt an derselben Bedingung wie die Nachtruhe (`art === "test" || art === "anruf"`). "Darf das nachts stoeren?" und "darf das warten?" haben dieselbe Antwort; zwei Bedingungen waeren die, die beim naechsten Nachschaerfen auseinanderlaufen. === ERREICHT ES AUCH JEMANDEN? === Der Service Worker ruft skipWaiting() und clients.claim() -- die neue Fassung greift beim naechsten Oeffnen der App, ohne dass jemand etwas tun muss. ABER: Nachgemessen haben NEUN von fuenfzehn aktiven Zugaengen KEIN Geraet angemeldet -- darunter eine rechte Hand und zwei Modis. Bei ihnen kann keine Benachrichtigung ankommen, so laut sie auch waere. Das ist kein Codefehler; das muessen die Leute einmal selbst tun. === GEMESSEN === pruef-anruf-klingelt 17/0 (neu, mit drei Gegenproben), pruef-anruf 114/0, pruef-turn-wege 15/0, pruef-meldungen 8/0. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-19 18:51:43 +02:00
DogFatherGitandClaude Opus 5	5c3bfcb47d	Der Handy-Rundgang, den es fuer die Modis nie gab ... Filipe: "mach einen kompletten check dass die app auf dem handy perfekt funktioniert ... weil die modis haben schon probleme." Auf die Rueckfrage: "einfach ALLES ABCHECKEN ALLES MOEGLICHE." === DER BEFUND, DER ALLES ERKLAERT === Es gibt seit dem 02.09. einen grossen Rundgang (pruef-grosscheck). Er geht ueber jede Seite, zwei Bildschirmgroessen und VIER Rollen: admin . manager . scout . creator Vier von acht. Es fehlen modi, hand und gast -- also genau die drei Rollen, die auf crew.dogfather-universe.com leben, und genau die, von denen die Beschwerden kommen. Ihre Seiten waren nie im Ganzen auf einem Handy durchgemessen worden. Kein Vorwurf an den Rundgang: Er wurde fuers Agenturhaus gebaut, und Team Dogi kam spaeter dazu. Aber es erklaert, warum Fehler dort ueberleben konnten. pruef-handy-teamdogi.mjs schliesst die Luecke: 4 Rollen x 2 Breiten x bis zu 32 Seiten = 206 Seitenaufrufe, 91 052 Elemente, 3 880 Bedienelemente. Gemessen wird: kommt die Seite an, stuerzt etwas ab, laeuft etwas ueber den Rand, ist Text abgeschnitten, kann man es treffen, liegt etwas uebereinander, weiss man was es tut. === WAS ES GEFUNDEN HAT === DIE KOPFLEISTE WAR AUF JEDER SEITE ZU KLEIN. Bei Breiten bis 400 px schrumpften alle Knoepfe auf 34x34, bis 560 px auf 36x36. Das sind zehn Pixel unter dem, was ein Daumen sicher trifft -- und es betraf jede Seite, jede Rolle, jeden Aufruf. Genau das erlebt man als "der Knopf geht nicht". Die Verkleinerung war nie noetig. Am echten Aufbau nachgemessen: Breite belegt bei 44px noetig verfuegbar 360 px 237 284 328 390 px 237 284 358 412 px 245 284 380 Es passt ueberall, mit Luft. Jetzt 44x44 -- und dazu `flex-wrap: wrap` als Regel statt einer dritten festen Zahl: Die Reihe bricht genau dann um, wenn der Platz wirklich nicht reicht. DER ZURUECK-KNOPF war 38x44 -- die Hoehe stimmte, die Breite nicht. Der Rundgang hat ihn 192-mal gemeldet. Er ist der Knopf, den man auf jeder Unterseite am haeufigsten trifft. DIE KLEINEN UMSCHALTER (38 px) waren eine begruendete Ausnahme -- begruendet fuer die Maus. Auf Geraeten, die mit dem Finger bedient werden, gilt jetzt 44. Gefragt wird `pointer: coarse` und nicht die Breite: Ein schmales Browserfenster am Rechner braucht keine 44 px, ein 1200 px breites Tablet sehr wohl. DIE KALENDERPILLEN waren 26 px hoch, das Rechtefeld 34 px breit, die Kalenderpfeile 38 px. Alle auf 44. EINE BESCHRIFTUNG HING NICHT AM FELD. In checkliste.js stand ein <label> ohne `for` neben einem <select> ohne `id`. Optisch richtig -- fuer ein Vorleseprogramm ein namenloses Feld. Und weil wahl.js das Systemmenue durch einen eigenen Knopf ersetzt und dessen Namen AUS DEM LABEL holt, blieb auch der Knopf namenlos. === DREI FEHLER IN MEINER EIGENEN PRUEFUNG === Und sie sind der lehrreichere Teil. (1) DER ERSTE LAUF MELDETE EIN 1647 px BREITES BILD auf einem 390 px breiten Schirm. Das sah nach dem Fund des Tages aus. Es war einer in MEINER Pruefung: `dogfather-universe.com` steht in der fest eingebauten HSTS-Liste von Chromium, der Browser schaltet unabaenderlich auf https um, und mein Testserver sprach http. Ergebnis: JEDE Stilvorlage schlug fehl. Gemessen wurde eine Seite ganz ohne CSS. Haette ich den Befund gemeldet statt nachzusehen, waere ein halber Tag in eine Reparatur geflossen, die nichts repariert. Die Pruefung spricht jetzt selbst https, mit eigenem Zertifikat und einem winzigen Vorbau. (2) 350 FEHLALARME. `span.zurueck-knopf__text` wurde 192-mal als abgeschnitten gemeldet, `span.teilen__text` 154-mal -- beide sind ABSICHTLICH 1 px gross und weggeschnitten, damit ein Vorleseprogramm sie liest und das Auge nicht. Dazu 24-mal `-webkit-line-clamp` (gewolltes Kuerzen auf zwei Zeilen), 14-mal Textfelder MIT Beschriftung (ich fragte `labels` nur bei input und select, nicht bei textarea) und 26-mal Zierrat mit `aria-hidden="true"`. Eine Warnung, die immer kommt, ist keine Warnung mehr -- und diese haetten jeden echten Fund zugedeckt. (3) DIE UEBERLAUF-MESSUNG WAR BLIND. Sie rechnete `scrollWidth - clientWidth`; `body { overflow-x: hidden }` macht beide Werte immer gleich. Die Pruefung fand nichts und meldete trotzdem gruen. Gefunden hat das die GEGENPROBE -- sie ist genau dafuer da. Jetzt zaehlt, ob ein sichtbares Element ueber den rechten Rand ragt. === UND EIN FEHLER BEIM AUFRAEUMEN === Beim Verschieben der Touch-Regeln von start.css nach module.css hat ein NICHT-GIERIGES Suchmuster am ersten `}` am Zeilenanfang aufgehoert und dabei mehr mitgenommen als gemeint: die Schriftgroessen-Regeln fuer schmale Fenster. Die haetten danach nur noch auf Geraeten mit Finger gegolten. Gefunden hat es wieder der Rundgang, nicht das Lesen: `.k-pille` blieb 26 px hoch, obwohl die neue Regel 44 sagte -- die alte stand weiter unten und gewann. Zurueckgeholt aus HEAD, an ihren Platz gesetzt. Nebenbei kam dabei heraus, WARUM eine Regel nicht ankam: Jede Seite laedt gate -> start -> seite -> module -> haus. `aufgaben.css` setzt `.schnitt { min-height: 38px }` mit derselben Staerke, kommt aber spaeter. Eine Regel, die man geschrieben hat und die nicht wirkt, sieht im Editor genauso aus wie eine, die wirkt. === STAND === Befunde: 120 -> 64. Weg sind: alle abgeschnittenen Texte (0), alle namenlosen Bedienelemente (0), alle zu kleinen Knoepfe in Kopfleiste, Zurueck-Weg, Filterreihen, Kalender. Es bleiben 64, und sie sind alle von derselben Sorte: 48-mal der Ersatzknopf eines Auswahlfeldes (34-42 px breit, aber 44 hoch), 8-mal Kalenderpillen (36-39 breit, 44 hoch), 8 Ueberstaende. Alle sind in der HOEHE gross genug und nur in der Breite knapp -- die komfortable Empfehlung, nicht die Mindestanforderung. Sie stehen namentlich im Prueflauf und sind der naechste Schritt. GEMESSEN: pruef-css-klassen ALLES IN ORDNUNG, pruef-meldungen 8/0, pruef-rechtetafel 19/0, pruef-turn-wege 15/0, und beide Gegenproben des neuen Rundgangs schlagen an. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-19 17:16:49 +02:00
DogFatherGitandClaude Opus 5	d6df590224	Telefonieren ging nur ueber UDP -- und die Seite sprang immer hoch ... === 1. WARUM TELEFONIEREN NICHT GING === Filipe: "es klingelt erscheint auch alles bei jedem aber telefonieren klappt immer noch nicht." GEMESSEN, BEVOR ETWAS GEAENDERT WURDE -- und alles war gruen: coturn laeuft aktiv STUN von aussen antwortet, nennt meine oeffentliche Adresse echte Zuteilung von aussen 7/7, Testpaket kam an (Port 49183) Dreier-Anruf im Prueflauf verbindet, alle hoeren alle Vier Messungen, vier Mal in Ordnung -- und das Telefon ging trotzdem nicht. Der Grund: Der Prueflauf faehrt BEIDE Seiten auf demselben Rechner. Dort finden sie sich ueber die direkte Adresse, und die Vermittlung wird nie gebraucht. Draussen sitzen sie in verschiedenen Netzen. DER FUND: Eingetragen war eine einzige Adresse -- turn:159.195.212.167:3478 Ein `turn:` OHNE `?transport=` heisst UDP, und nur UDP. Nachgemessen hoert coturn aber auf beidem: 3478/UDP offen, 3478/TCP offen (5349/TLS ist zu). Angeboten wurde nur der halbe Server. Wer in einem Netz sitzt, das UDP nach draussen sperrt -- Mobilfunk mit strengem Profil, Gast-WLAN, Firmennetz --, bekam damit KEINEN Vermittlungsweg. Es klingelt (das laeuft ueber die Website, also ueber 443), und danach passiert nichts. Genau das gemeldete Bild. Aus einem Eintrag werden jetzt drei Wege: stun:host:port die eigene Adresse finden, ohne Vermittlung turn:host:port?transport=udp der schnelle Weg turn:host:port?transport=tcp der Weg durch fast jede Sperre ABGELEITET, NICHT EINGETRAGEN: Drei Zeilen von Hand waeren drei Stellen, an die beim naechsten Serverumzug jemand denken muesste -- die abgeschriebene Liste, die hier schon zweimal teuer war. Ein Eintrag MIT `?transport=` bleibt unangetastet, ein fremder Dienst mit eigenem Passwort sowieso. pruef-turn-wege (neu, 15/0) sichert beides: dass jeder Weg herauskommt UND dass jeder turn:-Weg Zugangsdaten traegt. Das Zweite ist das wichtigere -- auffaechern ohne anmelden haette den Fehler nur verschoben. === 2. DIE SEITE SPRANG BEIM ZURUECKGEHEN IMMER HOCH === Filipe: "das nervt man muss dan immer wieder runter scrollen bis man da ist wo man vorher war." Der Browser versucht es sogar -- scrollRestoration steht ab Werk auf "auto". Nur: Jede Seite hier kommt fast leer an und holt ihren Inhalt danach per Abruf. In dem Moment, in dem der Browser die alte Position wiederherstellen will, ist das Dokument ein paar hundert Pixel hoch. Er kann nicht auf Zeile 900 springen, die es noch nicht gibt -- und er versucht es kein zweites Mal. Jetzt macht es kopf.js selbst (gilt damit auf allen 21 Seiten): Stelle merken beim Verlassen, beim Oeffnen zurueckholen und jeden Bildaufbau lang versuchen, bis das Dokument hoch genug ist. Nach drei Sekunden wird aufgegeben. Drei Dinge sind Absicht: - NUR beim Zurueckgehen, nicht bei jedem Oeffnen. Wer eine Kachel anklickt, will oben anfangen. - WER SELBST SCROLLT, GEWINNT. Rad, Wisch oder Taste beenden das Nachspringen sofort. - Nach einer Stunde vergessen -- auf Zeile 900 zu landen, weil man gestern dort war, ist keine Hilfe. === 3. DIE LISTE IST NACH ROLLE GETRENNT === Filipe: "die rechte hand rolle immer zuerst und dan die modis. die sollen auch schoen getrennt sein und verschieden aussehen also die rechte hand viel spezieller." Die Reihenfolge macht der Server ueber ROLLEN_SORTIERUNG -- dieselbe Konstante wie ueberall sonst im Haus, nicht eine zweite. Eine Sortierung nach ROLLE ist ausdruecklich keine Rangliste: Sie sagt nichts darueber, wie gut jemand ist, nur welche Aufgabe er hat. Deshalb steht ueber jeder Gruppe ein Satz und keine Zahl. "Spezieller" heisst hier Material, nicht Groesse: eigener Farbton als Kante und Schimmer, hellere Flaeche, kraeftigerer Name. Beide Karten sind GLEICH GROSS und tragen dieselben Zeilen -- zwei Sorten Aufgabe, keine Rangfolge. Im Kontrastmodus traegt eine doppelte Kante die Unterscheidung, weil dort keine Farbe mehr wirkt. === 4. DER ANRUFKASTEN === Vorher: vier gleich aussehende Pillen nebeneinander, darunter eine Geraeteauswahl, die das breiteste Element war. Kein Name, keine Ordnung, und der einzige Knopf mit Folgen sah aus wie die anderen. - MAN SAH NICHT, MIT WEM. Der wichtigste Satz eines Telefonats fehlte. Der Chat kennt den Namen und gibt ihn jetzt mit; wer rangeht, sieht den Anrufer. - "MIKRO AN" WAR ZWEIDEUTIG -- "ist an" oder "schalt an"? Wer falsch raet, sitzt stumm da. Jetzt traegt ein durchgestrichenes Zeichen den Zustand, das Wort nur die Sache. aria-pressed bleibt die Wahrheit, auch fuer Vorleseprogramme. - DIE GERAETEAUSWAHL liegt hinter einem kleinen Knopf, der nur erscheint, wenn es ueberhaupt etwas zu waehlen gibt. - AUFLEGEN ist als einziger Knopf farbig und steht immer rechts. - Ein ruhiger Puls atmet, solange die Verbindung aufbaut, und haelt an, sobald sie steht. Bei prefers-reduced-motion steht er still. === NEBENBEFUND, DEN DIE PRUEFUNG GEFUNDEN HAT === pruef-anruf wurde durch die Auffaecherung an vier Stellen rot: Sie griff `adressen[0]` und erwartete dort Zugangsdaten. Das ist jetzt der STUN-Weg, und der hat richtigerweise keine. Gesucht wird nicht mehr nach PLATZ, sondern nach ART -- ein Index ist eine Annahme darueber, wie die Liste aussieht, und die hat sich gerade geaendert. Dazu angepasst: Die Pruefung "die Uhr laeuft" verlangte, dass die Uhr schon beim Klingeln zaehlt. Seit heute frueh beginnt sie beim Rangehen (sonst standen im Kasten und im Chat zwei verschiedene Zahlen). Sie prueft jetzt das Gegenteil -- statt sie zu streichen, denn eine Zeile weniger haette den Fehler beim naechsten Umbau wieder durchgelassen. GEMESSEN: pruef-anruf 114/0 (vorher 111 -- drei MEHR, weil die Auffaecherung mitgeprueft wird), pruef-turn-wege 15/0, pruef-meldungen 8/0, pruef-css-klassen ALLES IN ORDNUNG, pruef-rechtetafel 19/0. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-19 15:23:15 +02:00
DogFatherGitandClaude Opus 5	18a5231b70	Die Tuer ohne Klingel, der Anruf ohne Ende, die Glocke ohne Liste ... Siebter Durchgang durch die Team-Dogi-Seiten aus Benutzersicht. Alles am Code belegt, die Groessenangaben nachgerechnet. === DIE ANMELDUNG === WOHER BEKOMMT MAN EINEN CODE? Stand nirgends. Vier Kacheln, ein Feld, ein Knopf -- wer keinen Code hatte, fand keinen einzigen Satz dazu. Fuer die Community besonders teuer: Sie ist die einzige Rolle, die von aussen kommt und niemanden im Haus kennt. "BITTE KURZ WARTEN" SIND BIS ZU ZEHN MINUTEN (VERSUCHE_FENSTER_MIN). Wer nach zwanzig Sekunden nachsieht und dieselbe Meldung liest, haelt die Seite fuer kaputt. Jetzt steht die Zahl da. EIN RICHTIGER CODE AN DER FALSCHEN KACHEL fiel in dieselbe Absage wie ein erfundener -- der Server sucht nur unter der gewaehlten Rolle. Wer aus der Community kommt und auf "Modi" tippt (das klingt ja danach), tippt seinen richtigen Code dreimal Buchstabe fuer Buchstabe. Ab dem zweiten Fehlversuch kommt jetzt ein Hinweis auf die Auswahl -- ohne zu sagen, welche die richtige waere. === DER ANRUF: VIER FEHLER, EINE ERFAHRUNG === DAS FREIZEICHEN LIEF UNENDLICH. Es gab keinen Zeitgeber, der aufhoert. Wer niemanden erreichte, sass vor einem piependen Kasten mit "02:47" darauf, als telefoniere er laengst. Der Server schickt den Verfallszeit- punkt sogar mit (`laeuft_bis`) -- benutzt hat ihn nie jemand. DER KLINGELKASTEN VERSCHWAND NACH 46 SEKUNDEN, waehrend der Server 120 gibt. Wer beim Klingeln das Handy aus der Tasche holt und in Sekunde 50 hinsieht, fand nichts mehr -- kein Kasten, keine Knoepfe -- waehrend der Anrufer noch siebzig Sekunden Freizeichen hoerte. Die 120 Sekunden sind im Server ausdruecklich damit begruendet, dass man Zeit zum Entsperren braucht; eine Zeile im Browser hat diese Entscheidung aufgehoben. DAS FREIZEICHEN PIEPTE WEITER, waehrend daneben "Keine Verbindung." stand. Ton sagte "es klingelt noch", Text sagte "vorbei". DIE UHR ZAEHLTE AB DEM WAEHLEN. Wer 30 Sekunden klingeln liess und 12 Sekunden sprach, las im Kasten "00:42" und danach im Chat "Anruf . 12 Sekunden". Der Server rechnet es richtig; der Kasten hat es wieder kaputtgemacht. Dazu: Die Mikrofon-Absage verwies auf "das Schloss-Symbol neben der Adresse" -- in der installierten App gibt es weder Adresszeile noch Schloss. Das Haus kennt diesen Fehler und hat ihn beim Weg zur Anruf-Probe schon behoben; hier stand er noch. Und die Anruf-Probe: Ihr einziger Punkt ohne Handlungsanweisung war "Antwort 503." -- auf einer Seite, die ausdruecklich fuer jemanden gebaut ist, der nicht technisch ist. Ihr Rueckweg fuehrte ausserdem immer in den Chat, auch wenn man von der Startseite kam. === DER TREFF === EIN EINZEILER MACHTE SECHS ERKLAERTEXTE UNSICHTBAR. bewerben.js las `g.unter`, der Server schickt `g.text` -- also immer undefined. Damit fehlten ALLE SECHS Gruppeneinleitungen des Fragebogens ("Kein Test mit richtigen Antworten"), und die CSS-Regel dafuer lief ins Leere. Uebrig blieben sechs nackte Ueberschriften ueber fuenfzehn Fragen. DIE EINZIGE "SO LAEUFT DAS HIER"-SEITE WAR FAST UNERREICHBAR. Die Kachel "Regeln & Hilfe" zeigte auf ein Brett, das am ersten Tag leer ist. Die Regeln, die es wirklich gibt (Begruessung, fuenf Regeln, drei Stufen, Mindestalter), stehen auf treff-regeln.html -- erreichbar ueber genau einen kleinen Textlink auf einer Brettseite. Die Kachel zeigt jetzt dorthin. FIEL /api/treff/lage AUS, versprach die Seite einem Zuschauer Schreibrechte, die der Server ablehnt: Die Pruefung fiel bei `lage === null` auf `true` durch -- von "darf auf keinem Brett" auf "darf ueberall". Formular auf, getippt, 403. Dazu: hilfe.js hatte eine eigene kleine Fehlertabelle fuer zwei Kennungen und endete sonst bei "Ging nicht." -- ausgerechnet die Seite, auf der jemand mit einem Problem sitzt, hatte die inhaltsleerste Absage im Haus. Und der gesperrte "Neue Meldung"-Knopf erklaerte sich nur im Maus-Tooltip; die Community kommt von TikTok, also vom Handy. === DIE STARTSEITE === DIE COMMUNITY BEKAM EIN WORT. Unter dem Titel steht bei jeder Rolle ein Satz -- beim Community-Mitglied stand "Community". Woertlich derselbe Mangel, den der Kommentar bei MODI_ROLLENTEXT beschreibt und fuer den Modi behebt. DER RING MELDETE 100 %, bevor man irgendetwas getan hat. Am ersten Tag, ohne eine einzige Aufgabe, stand das groesste Element der Seite auf "100 % -- HEUTE NICHTS OFFEN". Gelesen wird zuerst die Zahl, und 100 % heisst fuer jeden "fertig", nicht "leer". UND BEI EINER STOERUNG BLIEB "wird geladen" FUER IMMER STEHEN -- der fruehe `return` liess den Platzhalter unberuehrt. === DIE ZUGANGSVERWALTUNG === Der Code-Kasten sagte "jetzt weitergeben" und gab die Haelfte nicht mit, die man weitergeben muss: WO sich die Person anmeldet. DogFather ruft den Code durchs Zimmer, der andere fragt "und wo?". Die Adresse kommt jetzt vom Server (anmeldeAdresseFuer, abgeleitet aus derselben Weiche), dazu ein Knopf "Code und Adresse kopieren". Er verschwieg ausserdem den Rettungsweg: "danach nicht mehr abrufbar" stimmt fuer DIESEN Code -- man kann jederzeit einen neuen vergeben. Wer das nicht weiss, glaubt, er habe einen Menschen angelegt, der nie hereinkommt. Und das Fenster liess sich wortlos schliessen, waehrend der Code offen stand. === OPTIK: NACHGERECHNET, NICHT VERMUTET === DIE GLOCKE STAND NICHT IN DER LISTE. Sie ist ein echtes <button> und wurde von der 44-px-Regel erfasst, waehrend ihre vier Nachbarn durch einen staerkeren Selektor auf 36 px gehen. Zwischen 401 und 560 px -- also bei 412 px (haeufigste Android-Breite) und 430 px (iPhone Pro Max) -- stand eine 44 px hohe runde Pille zwischen fuenf 36-px-Quadraten. Der 400er-Block listet sie korrekt; genau dieses Band fiel durch beide Rechnungen. Dasselbe Muster wie am 06.09. DIE 9,6-px-REPARATUR IM KALENDER WAR SEIT WOCHEN WIRKUNGSLOS. kalender.css wird NACH start.css geladen, beide Selektoren sind gleich stark -- also gewann `.6rem` auf jeder Breite unter 760 px. Genau der Wert, den start.css als behobenen Fehler protokolliert. Und die Hebung selbst unterschritt ihre eigene Grenze: Die Regel, die zu kleine Schrift hochziehen soll, zog `.k-pille` auf 11,2 px -- 0,3 px unter die 11,5, die 33 Zeilen darueber aufgestellt werden. Weitere nachgerechnete Groessen: Spaltenkopf und KW-Spalte im Kalender (10,56 px), Kalenderwoche am Balken (9,92 px), Wecker-Knopf (30 px -- der kleinste im Haus, 14 unter der Vorgabe), Chat-Zurueck auf dem Tablet (34x34, 40 % weniger Flaeche als noetig, und der einzige Weg zurueck in die Liste), Emoji-Knoepfe (34 px bei 2 px Abstand -- wer danebentippt, verschickt ein anderes Zeichen, und das ist sofort abgeschickt). IM WINDOWS-KONTRASTMODUS HATTE DIE STARTSEITE KEINE UEBERSCHRIFT. `.ztitel` und der Team-Dogi-Schriftzug sind mit `background-clip: text` gesetzt; faellt der Verlauf weg, bleibt durchsichtiger Text. Beide haben jetzt den Rueckfall, den gate.css schon lange hat. UND MEIN EIGENES STREIFENRASTER rechnete die Spaltenzahl aus der Breite statt aus den Daten (`auto-fit`): Bei 390 px passten sechs, alles darueber fiel in eine zweite, unbeschriftete Zeile. Das `overflow-x` daneben konnte nie greifen -- ein auto-fit-Raster wird nie breiter als sein Kasten. Der Kommentar beschrieb ein Verhalten, das es nicht gab. GEMESSEN: pruef-meldungen 8/0, pruef-css-klassen ALLES IN ORDNUNG, pruef-rechtetafel 19/0, alle Module laden, keine doppelten Kachelnamen/-ziele/-farben in allen vier Rollen. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-19 15:07:31 +02:00
DogFatherGitandClaude Opus 5	273318dd9c	Vier Sackgassen, zwei Kacheln namens "Chat" -- und eine Seite ohne Kopf ... Durchgang durch die Team-Dogi-Seiten aus der Sicht von jemandem, der sie zum ersten Mal sieht. Alles hier ist am Code belegt und nachgemessen. 1. "KLINGELT NICHTS?" WARF ALLE DREI TEAM-ROLLEN AUF DIE STARTSEITE. anruf-probe.html erklaert, WARUM das Telefon stumm bleibt. Sie steht in der Rechtetafel offen, und aus dem Chat zeigen zwei Knoepfe darauf. Nur hatte sie nie eine Kachel -- absichtlich, sie ist kein Bereich. Seit die Adressregel vom 15.09. eine Kachel VERLANGT, landete jeder Klick wortlos auf start.html. Das ist die schlimmste Sorte Sackgasse: Man ruft sie auf, WEIL schon etwas nicht geht, und sie wirft einen hinaus. Mit derselben Zeile geheilt: Die Hinweisleiste wirft jeden Hinweis weg, dessen Ziel es auf dieser Adresse nicht gibt -- "Bei dir klingelt nichts" wurde auf crew deshalb NIE angezeigt. Ausgerechnet der Hinweis, der acht von elf Leuten betrifft. 2. UND DIESE SEITE HATTE GAR KEINE GESTALTETE KOPFLEISTE. .kopfleiste, __zurueck, __mitte, __titel stehen in KEINER Stilvorlage -- sie leben in start.css, die diese Seite absichtlich nicht laedt. Die Leiste war nackter Text. Auf einer Seite, die man im Stoerfall aufruft, sieht unfertig aus wie kaputt. Jetzt im <style>-Block der Seite, aus demselben Grund wie ihr uebriges CSS. 3. EIN MODI KAM NICHT AN SEINE EIGENE AUSWERTUNG. entwicklung.html und werdegang.html haben BEIDE eine ausgearbeitete Eigensicht, und die Rechtetafel laesst ihn hinein. In seiner Kachelliste stand keine von beiden -- der Weg existierte fuer ihn nicht. Die ganze Eigensicht war toter Code, ausgerechnet fuer den, fuer den sie ist. Mein eigener Fehler vom Vortag. Zwei eigene Kacheln in "Fuer dich", aus den Leitungskacheln abgeleitet. Sie loesen zugleich eine Namenskollision: Bis heute setzten BEIDE Seiten fuer ihn die Ueberschrift "Deine Entwicklung". 4. DER KALENDER-LINK WAR FUER DIE COMMUNITY EINE SACKGASSE. Auf jeder Brettkarte mit Termin stand "Im Kalender am 24.09." als Link. kalender.html steht auf ALLE -- und ALLE ist ausdruecklich ohne "gast". Jetzt fragt der SERVER die beiden Schranken (kalender_offen) und die Karte zeigt den Termin als Text statt als Link. Die Auskunft bleibt, nur der Weg ins Leere faellt weg. Die Regel im Browser nachzubauen waere die vierte Stelle fuer dieselbe Frage gewesen. 5. EIN MODI KAM AN DIE TALENTE-NOTIZEN, DIE IHM VERWEHRT SIND. BRETTER_UEBER_SEITEN war eine feste Liste ("wer die Seite darf, muss auch dorthin kommen") und fragte nie, WER fragt. Ueber bereich.html?b=talente kam er an Notizen zu Zuschauern, obwohl talente.html fuer ihn gesperrt ist -- Begruendung dort: "Hier stehen Namen von Menschen, die nichts davon wissen." Aus der Liste wurde eine Zuordnung Brett -> Seite, gefragt wird darfSeite(). Nachgemessen: modi/talente 404, modi/entwicklung darf, hand+admin unveraendert. Dazu stand in workspace-bereiche.js ein Kommentar, der das GEGENTEIL des Codes behauptete ("entwicklung, talente bleiben 404"). Ein falscher Kommentar an einer Rechtestelle ist schlimmer als keiner. 6. ZWEI KACHELN "CHAT", BEIDE AUF DIESELBE SEITE. Seit dem Treff-Chat von gestern sahen Modi und rechte Hand zweimal "Chat" mit demselben Ziel. Jetzt "Treff-Chat" mit ?raum=treff, das den Raum direkt oeffnet -- gesucht an denselben zwei Merkmalen, an denen ihn der Rest der Datei erkennt. 7. VERTRAUEN: "WIE GEHT'S DIR?" VERSPRACH MEHR, ALS ES HALTEN KANN. Dort stand: "Niemand aus dem Team sieht deine Antworten -- auch DogFather nicht." Punkt. Fast wahr und deshalb gefaehrlich: Aus denselben Antworten entsteht eine namenlose Ampel fuer die Leitung. Der ehrliche Satz war laengst geschrieben und wurde vom Server sogar mitgeliefert (block.text) -- nur hat ihn nie jemand angezeigt. Er steht jetzt im HTML, nicht im Skript: Wer die Seite oeffnet, soll ihn lesen, BEVOR er tippt. 8. DIE NEUE AUSWERTUNG, AUS BENUTZERSICHT NACHGEBESSERT. - Der Streifen hatte keine Zeichenerklaerung. Im Dateikopf stand "wer Farben schlecht unterscheidet, liest dasselbe Zeichen" -- das stimmt nur, wenn irgendwo steht, was die Zeichen heissen. Jetzt eine Legende, aus `stufen` gebaut statt abgeschrieben. - "nie gesetzt" war ein Mittelpunkt, "Kann ich nicht sagen" ein Halbgeviertstrich. Zwei kurze Striche nebeneinander fuer den Unterschied zwischen "niemand hat hingesehen" und "jemand hat hingesehen und konnte es nicht sagen". Leer ist jetzt wirklich leer, mit gestricheltem Rahmen. - Die Aufschluesselung der Balken stand nur im Mausueberfahren -- am Handy also nie, und dort steht jemand damit im Stream. Jetzt als Text. - Die Modi-Sicht bekam Balken ohne Erklaerung, ein "Frag danach" ohne Adressaten und bei fehlender Bewegung ein LEERES Element. Jetzt Lesehilfe, ein Leerkasten mit Satz und zwei Wege weiter. 9. NEBENBEFUNDE, DIE DIE PRUEFUNG GEFUNDEN HAT. pruef-css-klassen war schon VOR dieser Arbeit rot (nachgemessen mit git stash). Alle drei Befunde behoben: - hilfe.html und unsere-seiten.html luden ihre Seitendatei NACH module.css und haus.css und ueberschrieben damit das Haus. - Zwei Schriftgroessen unter 11,5 px aus dem gestrigen Bau (.71rem Monatsbeschriftung, .68rem Marke) auf .75 und .72 gehoben. - Die Pruefung selbst war blind fuer <style>-Bloecke in der Seite und meldete deshalb dauerhaft drei Fehler an einer Seite, die ihre Stile mit Absicht selbst traegt. Eine Warnung, die immer kommt, ist keine Warnung mehr -- jetzt sieht sie hin, statt die Seite auszunehmen. Kleinkram nebenbei: "die Antworten sieht nur du" -> "siehst nur du" auf der Kachel zur empfindlichsten Seite des Hauses. "Bewertet wird dort" -> "Eingeschaetzt wird dort" in teamlage.html, zwei Zeilen unter "keine Bewertung von Menschen". "1 Aufgabe(n) angelegt" ausgeschrieben. GEMESSEN: pruef-css-klassen ALLES IN ORDNUNG (vorher 3 Fehler), pruef-meldungen 8/0, pruef-rechtetafel 19/0, alle Module laden, keine doppelten Kachelnamen/-ziele/-farben mehr in allen vier Rollen. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-19 14:57:55 +02:00
DogFatherGitandClaude Opus 5	461d41943a	Keine Maschinensprache mehr auf dem Bildschirm ... Filipe: "keine kryptischen oder technischen fehlermeldungen, sondern klare aussagen darueber, was passiert ist und wie man das problem loesen kann." DAS PROBLEM, NACHGEMESSEN. Der Server antwortet im Fehlerfall mit { fehler: "..." }. Darin stehen ZWEI verschiedene Dinge, und von aussen sehen sie gleich aus: Maschinenkennungen (nicht_verfuegbar, nicht_gefunden, ungueltig -- 43 verschiedene) und fertige deutsche Saetze. An 84 Stellen stand `textContent = d.fehler` -- ungefiltert. Wer beim Hochladen einer Datei Pech hatte, las woertlich "nicht_verfuegbar" auf dem Bildschirm und wusste nicht einmal, ob er selbst schuld war. Gezaehlt: 474 Antworten mit "nicht_verfuegbar", 392 mit "nicht_gefunden", 125 mit "ungueltig". DREI AUSGAENGE, NICHT ZWEI. `sagWas()` in workspace/assets/js/meldung.js: bekannte Kennung -> ihr Satz unbekannte Kennung -> der Ersatzsatz der Stelle, NIE die Kennung (sie geht in die Konsole, wo sie jemandem auffaellt, der sie beheben kann) fertiger Satz -> unveraendert durch Erkannt wird eine Kennung daran, dass sie nur aus Kleinbuchstaben, Ziffern und Unterstrichen besteht. Ein deutscher Satz hat immer Leerzeichen; eine Kennung nie. Die Unterscheidung ist entschieden, nicht geraten. UND WARUM DIE TABELLE NICHT ALTERN KANN. Eine von Hand gepflegte Liste ist hier schon zweimal teuer geworden (die abgeschriebene Spaltenliste, die feste Umbruchschwelle). Deshalb rechnet pruef-meldungen.mjs die Kennungen AUS DEM SERVER aus statt sie zu kennen -- eine neue ohne Satz macht sie rot. Man kann es nicht mehr vergessen. Sie prueft drei Dinge und beweist zu jedem, dass sie auch "nicht in Ordnung" sagen kann: 1. vollstaendig -- jede Kennung hat einen Satz 2. angeschlossen -- keine Rohanzeige, und jede Seite, deren Skript sagWas benutzt, laedt auch meldung.js 3. lesbar -- kein Satz enthaelt Kennung, Zahl oder englisches Wort GEFUNDEN HAT SIE SOFORT EINEN ECHTEN FEHLER: leistung.html laedt seine Skripte ohne `defer` und fiel damit durch meinen Einbau. Dort waere sagWas nicht definiert gewesen -- aus einer Fehlermeldung waere ein Absturz geworden, also schlimmer als vorher. NEBENBEFUND, DER MICH FAST EINE FALSCHE MELDUNG GEKOSTET HAETTE: "alter_offen" heisst NICHT "etwas Aelteres ist offen", sondern "Altersbestaetigung steht noch aus" (workspace.js:4864). Geraten haette ich es falsch uebersetzt. GEMESSEN: pruef-meldungen 8/0, alle 46 Skripte syntaktisch in Ordnung. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-19 14:46:13 +02:00
DogFatherGitandClaude Opus 5	7be85c265b	Der Treff bekommt einen Chat -- mit Nachtruhe, ohne Telefon ... Filipe, auf die Frage ob die Community einen Chat bekommen soll: "eine geile mischung von punkt 2 und drei. mach es perfekt so das quasi nach mitternacht bis morgens 6 uhr keiner schreiben kann damit auch die privatsphaere beruecksichtig wird ueber nacht ... und die sollen nicht anrufen koennen. nur schreiben." Zur Auswahl standen "gar kein Chat", "nur mit Oeffnungszeiten" und "offen wie im Team". Seine Antwort ist eine vierte, die nicht auf dem Zettel stand, und sie ist die bessere. 1. WARUM DIE NACHTRUHE MEHR IST ALS EINE EINSTELLUNG Sein Grund war Privatsphaere -- und zwar die der Leute, die moderieren. Die Forschung zu ehrenamtlichen Moderatoren sagt genau das: Die beiden meistgenannten Gruende fuers Aufhoeren sind ZU WENIG ZEIT und STREIT IM TEAM. Ein Chat, der nachts um drei weiterlaeuft, erzeugt beides. SIE GILT FUER ALLE, AUCH FUER DIE LEITUNG. Das ist die unbequeme Entscheidung: Der bequeme Weg waere, DogFather auszunehmen. Aber wenn er um halb vier schreibt, liest es jemand -- und wer liest, fuehlt sich zustaendig. Eine Nachtruhe, von der die Leitung ausgenommen ist, ist keine, sondern eine Bitte. MODERIEREN GEHT WEITER. Verbergen, loeschen, herausnehmen sind keine Nachrichten. Wer nachts etwas Schlimmes sieht, kann es wegnehmen -- er kann nur nicht darueber diskutieren. Und der vertrauliche Meldeweg bleibt offen: Er ist ein Fall mit einer Zustaendigkeit, kein Raum mit dreissig Leuten. GERECHNET IN ORTSZEIT, nicht in UTC. `getHours()` auf einem UTC-Server haette den Chat im Sommer von 2 bis 8 geschlossen -- zwei Stunden daneben, und nur denen sichtbar, die um diese Zeit wach sind. Dieses Haus ist mit der Rechnung schon zweimal hereingefallen. DER RIEGEL SITZT IM SERVER, nicht im Browser. Ein ausgegrautes Feld ist eine Hoeflichkeit; wer die Adresse kennt, spricht die Schnittstelle direkt an. Nachrichten UND Anhaenge werden abgelehnt -- ein offener Anhangweg waere der Umweg, den jeder findet, der es einmal versucht. 2. KEIN TELEFON -- UND WARUM DAS EINEN EIGENEN RIEGEL BRAUCHT Ein Anruf haengt in diesem Haus an der RAUMMITGLIEDSCHAFT, nicht an der Rolle. Solange die Community keinen Raum hatte, war die Frage muessig. Seit sie einen hat, waere Telefonieren erlaubt -- nicht, weil es jemand entschieden haette, sondern weil es niemand verboten hat. Der Riegel steht ganz vorne am Anruf-Router, nicht in den neun Routen dahinter. Alle sieben Wege sind geprueft, einzeln. 3. DER FUND, DER DIE GANZE NACHTRUHE UMGANGEN HAETTE Ein Gast konnte ein PRIVATES ZWEIER-GESPRAECH mit DogFather aufmachen. Die Route antwortete mit 200 und legte den Raum an. `ohneAussen` nimmt die Community aus den Listen ANDERER heraus -- damit kein Creator einen Zuschauer anschreibt. Die Gegenrichtung kam nie vor, weil die Chatseite fuer 'gast' gar nicht offen war. Seit heute ist sie offen, und damit war die Erlaubnis da. Ein Zweier-Gespraech ist kein Kanal: keine Nachtruhe, kein Modi liest mit, niemand koennte moderieren. Aus "die Community bekommt einen Chat" waere ungewollt "jeder Zuschauer bekommt eine Standleitung zu DogFather" geworden. GEFUNDEN HAT ES DIE PRUEFUNG, NICHT DAS LESEN -- und zwar in dem Moment, in dem ich zwei Dateien weiter selbst vor genau dieser Sorte Erlaubnis gewarnt hatte. 4. ZWEI TOTE WEGE, EINER DAVON MEINER pruef-community-sicht sucht nach sichtbaren Wegen, die ins Leere fuehren. Sie fand zwei: a) "Bei dir klingelt nichts" -> anruf-probe.html. Der Hinweis von heute Vormittag, und die Seite steht einem Gast ausdruecklich NICHT offen. Mein Fehler, und einer, der jedem naechsten Hinweis genauso passiert waere. AN DER WURZEL BEHOBEN: Die Hinweise pruefen jetzt auch die ROLLE (`darfSeite`), nicht nur die Adresse. Das ist der 15.09. noch einmal, eine Ebene tiefer -- damals die Adresse, diesmal die Rolle, und dieselbe Lehre: Die Hinweise sind eine DRITTE Stelle neben Seiten und Schnittstellen. b) Der Verweis "Kalender" im Tagesblick. Steht fest im HTML, fuehrt fuer die Community ins Leere -- und zwar SCHON VOR den Aenderungen dieses Tages. Aufgefallen nur, weil (a) daneben stand. Der Weg wird jetzt abgeleitet: Wer die Kachel hat, hat den Weg. 5. DIE PRUEFUNG LAEUFT ZWEIMAL Die Nachtruhe laesst sich nicht in EINEM Lauf in beiden Zustaenden pruefen -- die Zeiten werden beim Laden gelesen, und ein zweiter Server braeuchte denselben Port. pruef-treffchat ruft sich deshalb selbst noch einmal auf, mit einem Fenster, das jetzt gilt. Dieselben Pruefungen, andere Lage. DIE UHR WIRD NICHT GEFAELSCHT. Verschoben wird die GRENZE, nicht die Zeit -- eine Pruefung, die an der Systemzeit dreht, faelscht danach auch anderes mit und ist nur nachts gruen. 6. WAS SICH NEBENBEI GEAENDERT HAT - pruef-treff war SCHON VORHER ROT (8 Fehler): Sie erwartete sieben Kacheln fuer die Community, es waren gestern Nacht schon zehn. Feste Zahlen, Rechnung von gestern. Jetzt abgeleitet -- 72 Pruefungen statt 66, alle gruen. - Ein 404 bei jedem Seitenaufruf der Community: `anruf.js` holte die Verbindungsadressen, bevor es wusste, wer fragt. Der Browser protokolliert das, BEVOR JavaScript abfangen kann -- also darf die Anfrage gar nicht erst gestellt werden. `/api/ich` sagt es jetzt vorher. Ein Fehler, der immer kommt, macht den naechsten echten unsichtbar. - Reaktionen (Daumen) bleiben nachts erlaubt. Ausdruecklich, mit Begruendung im Code: Ein Daumen ist keine Nachricht, er loest keine Meldung aus und kann keinen Streit anfangen. Eine Luecke ohne Begruendung wird beim naechsten Durchsehen entweder geschlossen oder uebersehen -- beides falsch. GEMESSEN: pruef-treffchat 108/0 (neu, laeuft zweimal), pruef-treff 72/0 (vorher 66 mit 8 Fehlern), pruef-chat gruen, pruef-rechtetafel 19/0, pruef-community-sicht gruen. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-19 11:47:31 +02:00
DogFatherGitandClaude Opus 5	790b77a73d	Bei dir klingelt nichts -- und 49 Pruefungen, die blind waren ... 1. SIEBEN VON ELF HATTEN KEIN GERAET ANGEMELDET. Gemessen am echten Server, nicht geschaetzt (die Notiz von heute Nacht sagte acht -- Tamy hat inzwischen eins). Bei ihnen kommt nichts an, solange die Seite zu ist: keine Aufgabe, kein Termin, kein Anruf. Die Glocke sagt das seit jeher korrekt und kennt sogar den iPhone-Sonderfall ("erst zum Home-Bildschirm"). Nur tippt sie niemand an -- sie ist ein stiller Schalter in einer Leiste. Jetzt steht es dort, wo man hinsieht: als Hinweis in "Was ist dran?", mit Weg auf anruf-probe.html. Als OFFENER PUNKT, nicht als Warnung -- eine Warnung, die bei sieben von elf Leuten dauerhaft oben steht, ist nach einer Woche unsichtbar, und mit ihr die echten daneben. Er verschwindet von selbst, sobald ein Geraet da ist (Gegenprobe in pruef-glocke). Und ohne die "1" davor: Er zaehlt nichts, er beschreibt einen Zustand. FUENF DER SIEBEN DURFTEN DIE SEITE GAR NICHT OEFFNEN. anruf-probe.html stand nur Leitung und Modis offen. Das war die falsche Einschraenkung: Die Seite prueft die ganze Kette bis zur Geraete-Kennung, und die traegt auch jede Aufgaben- und Terminerinnerung. Jetzt alle Team-Rollen, ohne "gast" (die Community bekommt keine Erinnerungen). 2. 49 PRUEFUNGEN KONNTEN "BELEGT" NICHT VON "KAPUTT" UNTERSCHEIDEN. Aufgefallen beim Nachsehen, warum ein Lauf rot war: Es war mein eigener, haengengebliebener Lauf, der den Port hielt. Kein Befund. Dabei gemessen: Von 130 Pruefungen hatten 49 keinen Portwaechter, und SIEBEN Portnummern sind doppelt vergeben (4186, 4188, 4189, 4193, 4198, 4321, 4345). Bei belegtem Port startet der eigene Server STILL nicht -- und alles Weitere misst gegen einen fremden Stand. Das hat in diesem Haus schon zweimal Stunden gekostet (27.08. und 05.09.). Der Waechter existierte seit dem 05.09., er war nur nie ausgerollt. Jetzt haben ihn alle 130. Gegenprobe gemacht: Port belegt -> Rueckgabewert 3 mit Begruendung statt stillem Messen. pruef-content bekommt BEIDE Ports -- sie startet zwei Server, und der zweite gehoert zur Gegenprobe. Nur den ersten zu schuetzen hiesse, ausgerechnet den Teil ungeschuetzt zu lassen, dem man glaubt. Die sieben doppelten Nummern bleiben vorerst. Mit dem Waechter ist eine Kollision jetzt laut statt still; Umnummerieren ist ein eigener Schritt. 3. pruef-rollen IST ABGESTUERZT, SEIT WANN WEISS NIEMAND. "Target crashed" bei der fuenften Rolle, nach 234 gruenen Pruefungen. Kein Fehlschlag -- ein toter Browser. NACHGEMESSEN GEGEN DEN STAND VOR HEUTE (0b73fbb): dort genauso, an derselben Stelle. Es lag also nicht an den Aenderungen dieses Tages. Aufgefallen ist es nie, weil ein abgestuerzter Browser von aussen wie ein Programmfehler aussieht und die 234 gruenen Zeilen davor sich wie ein fast bestandener Lauf lesen. Ursache ist die Menge: fuenf Rollen mal sechzehn Seiten in EINEM Browserprozess. Die Kontexte wurden je Rolle geschlossen, der Prozess darunter lief durch. Jetzt bekommt jede Rolle ihren eigenen Browser, und ein Absturz meldet sich selbst statt als Zeitueberschreitung irgendwo weiter unten aufzuschlagen. Ergebnis: 321 Pruefungen, alles in Ordnung -- statt Absturz bei 234. 4. DAS SYMBOL FUER TIKTOK. assets/img/app-symbole/workspace-1024.png, frisch gerendert statt hochskaliert (das Huskygesicht lebt von harten Kanten) und als VOLLES Quadrat ohne Rundung: Die Aufnahme hat keinen Alphakanal, die Ecken waeren sonst weiss. App-Portale wollen ohnehin das volle Quadrat, die Rundung macht das Betriebssystem. Die sechs vorhandenen Groessen sind dabei bitgleich geblieben -- gepruefte Nebenwirkung, nicht gehofft. GEMESSEN: pruef-glocke 31/0 (neu: 5 zum Hinweis), pruef-rollen 321/0 (vorher Absturz), pruef-rechtetafel 19/0, pruef-struktur 0 Fehler, pruef-betreuung und pruef-werdegang gruen. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-19 11:14:18 +02:00
DogFatherGitandClaude Opus 5	6c10ef0600	Wie geht's dir?: fester Kern, wechselnde Fragen -- und die leere Runde ... Dein Auftrag von vorher, zusammen mit zwei Saetzen, die sich zu widersprechen schienen: "viel mehr Fragen" und "kurz und knapp". 1. DER FEHLER, DEN ICH DABEI GEFUNDEN HABE, WAR GROESSER. Eine Runde galt als vollstaendig, sobald zu jeder Frage IRGENDEIN Stand vorlag. Nach der ersten Runde ist das immer der Fall -- die Antworten bleiben ja stehen. Ab da liess sich jede weitere Runde abschliessen, OHNE eine einzige Frage anzufassen: Die alten Antworten wanderten mit neuem Datum ein zweites Mal in den Verlauf. Der Verlauf zeigte dann eine gerade Linie, und die bedeutete nicht "es ist gleich geblieben", sondern "niemand hat gefragt". Genau die Sorte Zahl, die hier verboten ist: eine, die etwas Falsches behauptet, und der man glaubt. Bei DIESEM Gegenstand -- dem Befinden eines Menschen -- waere das der schlechteste denkbare Ort dafuer. DIE VORHANDENE PRUEFUNG HAT DEN FEHLER NICHT GEFUNDEN, SIE HAT IHN FESTGESCHRIEBEN. Dort stand woertlich `ok(zweite.code === 201, "eine zweite Runde geht auch sofort")` -- gruen, und ein Beleg fuer genau das Gegenteil dessen, was sie pruefen sollte. Sie aenderte eine Antwort von zwoelf und war zufrieden. Ab jetzt zaehlt nur, was NACH der letzten Runde gesetzt wurde. Die alte Antwort bleibt sichtbar -- sie ist nicht falsch, nur alt -- und traegt, solange eine Runde faellig ist, den Hinweis "Das war deine Antwort beim letzten Mal". Der Knopf zum Abschliessen ist weg, bis bestaetigt wurde. 2. FUENF FESTE FRAGEN, DREI WECHSELNDE. Kern sind die, bei denen ein Ausfall teuer waere: die beiden meistgenannten Gruende fuers Aufhoeren (zu wenig Zeit, Streit im Team), die Erholung, die Sicherheit vor Anfeindung und der beste Fruehindikator ("kann ich mir vorstellen, in ein paar Monaten noch dabei zu sein"). Eine davon nur jede dritte Runde zu fragen hiesse, die Antwort im Schnitt sechs Wochen spaeter zu bekommen. Alle anderen rotieren, drei je Runde. Damit bleibt eine Runde bei acht Fragen -- die Quellen sagen fuenf bis fuenfzehn, unter zwei Minuten -- und der Katalog kann WACHSEN, ohne dass eine Runde laenger wird. Das ist der eigentliche Gewinn und die Aufloesung deines Widerspruchs. Gerechnet, nicht gewuerfelt: aus der Zahl der bisherigen Runden. Zufall hiesse, dass bei jedem Neuladen etwas anderes dasteht. Und weil sieben Zusatzfragen und drei Plaetze nicht glatt aufgehen, wird der Versatz erhoeht, falls er je einen gemeinsamen Teiler mit der Laenge haette -- sonst kaemen nur zwei feste Haelften dran, und der Rest nie. 3. WAS DARAUS FOLGTE, OHNE DASS ES IM PLAN STAND. - `rhythmus()` zaehlte gegen ALLE Fragen. Mit der Rotation waere das nie wieder erfuellt gewesen: Jede Runde haette sich selbst fuer unvollstaendig erklaert und die Seite haette taeglich gefragt. Jetzt gegen den Kern, der in jeder Runde enthalten ist. - Die Auswertung sieht ALLE zwoelf Fragen, nicht die acht dieser Runde. Der Verlauf hoert nicht auf, wenn eine Frage pausiert. - Der Verlauf zeigt jede Frage MIT Geschichte (nach zwei Runden elf von zwoelf), nicht die der aktuellen Runde. Leere Felder heissen jetzt ausdruecklich "war nicht dran", nicht "keine Antwort". - "seit 2 Runden" heisst jetzt "die letzten 2 Male". Mit der Rotation war die alte Formulierung eine Behauptung ueber eine Runde, in der gar nicht gefragt wurde. 4. ZWEI DINGE, DIE KEIN ZAHLENVERGLEICH GEFUNDEN HAT -- nur das Ansehen des Bildschirmfotos, und beide waren wahr und trotzdem irrefuehrend: - Der Satz "diese Runde sind 8 von 12 dran" stand nur, solange etwas offen oder faellig war. Im Ruhezustand -- dem, den man am haeufigsten sieht -- fehlte er. Wer acht Fragen zaehlt, wo zwoelf im Katalog stehen, haelt vier fuer verschwunden. - "Das war deine Antwort beim letzten Mal" stand an JEDER Frage, unmittelbar nachdem man sie beantwortet hatte. Beide haben jetzt eine Pruefung, inklusive Gegenprobe ueber eine zurueckdatierte Runde. GEMESSEN: pruef-befinden 100/0 (vorher 75 -- die Zahl ist gestiegen, nicht gefallen), pruef-entwicklung 43/0, pruef-push-ziel 10/0, pruef-werdegang 95/0. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-19 10:33:07 +02:00
DogFatherGitandClaude Opus 5	19e9f471d3	Entwicklung: die Auswertung je Person -- und elf Seiten ohne Farbe ... Filipe: "dan perfektionierst du eine neue wo diagramme texte und so zu jedem modi gemacht wird und diese kategorie kannst du entwicklung nenen." 1. DAS EIGENTLICHE PROBLEM WAR, DASS ES KEINE VERGANGENHEIT GAB. `entwicklung_stand` hat den Schluessel (person, punkt, beurteiler) und wird bei jeder Aenderung UEBERSCHRIEBEN -- dort richtig, eine Beobachtung ueber einen Menschen soll aktuell sein. Nur: Damit existierte nichts, woraus sich ein Verlauf zeichnen liesse. Nachgemessen: 43 Zeilen Stand, NULL Zeilen Geschichte. Ein Diagramm ueber einen einzigen Zeitpunkt ist kein Diagramm, sondern ein Balken. Neu: `entwicklung_lauf` haengt jede Aenderung an, statt zu ueberschreiben. Sie steht in workspace-entwicklung.js, bei der Tabelle, zu der sie gehoert -- die Auswertung liest nur. Andersherum gaebe es einen Ring zwischen zwei Modulen, und Ringe halten in JavaScript genau so lange, bis jemand eine Konstante auf oberster Ebene benutzt. KEIN ANLASS, NIE. Neben jedem "da hakt es" steht ein Satz, woran man es gemerkt hat -- fuer ein Gespraech aufgeschrieben. Eine Chronik dieser Saetze waere das Belastendste, was dieses Haus speichern kann. Die Spur hat gar keine Spalte dafuer, und die Pruefung liest die TABELLE, nicht die Ausgabe: Eine Spalte, die es gibt, wird eines Tages gefuellt. Die Startaufnahme uebernimmt den heutigen Stand mit seinen ECHTEN Daten, damit die Seite am ersten Tag nicht leer ist -- und zaehlt ausdruecklich NICHT als Bewegung. Der Tag, an dem die Spur entstand, war kein Tag, an dem 43 Dinge gleichzeitig passiert sind. 2. WAS GEZEIGT WIRD: BEWEGUNG, KEINE NOTE. Keine Punktzahl, kein Prozentwert, kein Durchschnitt, keine Rangliste, kein Vergleich zwischen zwei Menschen. Das ist die Recherche, nicht Vorsicht: Ueberrechtfertigung (Deci), sozialer Vergleich senkt die Leistung derer, die schlechter dastehen, Schwaechenfokus ebenso. Stattdessen das progress principle (Amabile/Kramer, ~12 000 Tagebucheintraege): Sichtbarer Fortschritt ist der staerkste einzelne Treiber. Deshalb Diagramm 1 "Was sich bewegt hat" -- zwei Richtungen um eine Nulllinie, ein Massstab fuer beide. Diagramm 2 der Streifen (Punkt x Monat), fortgeschrieben, aber nach 90 Tagen sichtbar verblasst. Und die Texte in dieser Reihenfolge: was sich bewegt hat, was traegt, erst danach was liegt. Selbst gezeichnet, kein Diagrammpaket: 60 kB ueber die Leitung von jemandem, der mit dem Handy im Stream steht -- und es braechte eigene Farben neben die Hausfarben. Jede Zelle traegt ihr Zeichen als Text, jeder Balken seine Zahl, darunter eine Legende: Die Farbe ist nie die Auskunft. Zwei Gesichter: Die Leitung sieht die Karten, ein Modi ausschliesslich die Bewegung in der eigenen -- ohne Namen, ohne Anlass, ohne Streifen. 3. NEBENBEFUND, GROESSER ALS ERWARTET: ELF SEITEN OHNE FARBE. Der Umbau von heute frueh heisst "Jede Seite traegt die Farbe ihrer Kachel". Nachgemessen traf das auf 18 von 34 Seiten zu. Elf Seiten mit echter Kachel gingen leer aus -- ausgerechnet die von Team Dogi: befinden, bewerben, bewerbungen, entwicklung, hilfe, rechte, talente, teamlage, teilen, treff-moderation, treff-regeln, unsere-seiten. Der Grund: `zuSeite()` sucht nur in `Bereiche.GRUPPEN`, und dort stehen ausschliesslich die Kacheln der Agentur. Die von Team Dogi liefert der Server (`ich.bereiche`, `ich.bereiche_zusatz`). Auffallen konnte das nicht -- eine Seite ohne Farbe sieht aus wie eine, die eben keine hat. kopf.js faerbt jetzt zweimal: sofort aus GRUPPEN (Agenturseiten ohne Flackern wie bisher), und noch einmal aus den Serverkacheln, sobald `werZeigen` sie bringt. Nur, wenn beim ersten Mal nichts gefunden wurde. pruef-buehne misst den Kontrast an echten Bildpunkten und kannte diese zwoelf Seiten nicht. Jetzt stehen sie in der Liste; ihre Frist waechst mit der Laenge, statt als feste Zahl irgendwann zu reissen. Gemessen fuer werdegang.html: 4,83:1 am Computer, 6,22:1 am Handy. 4. TON 38 SAH FREI AUS UND WAR ES NICHT. Erster Anlauf war Ton 38, weil 37 die hoechste Nummer in workspace.js ist. Gezaehlt in start.css sind es 39, alle vergeben. Genau davor warnt das Farbwerkzeug im eigenen Kopf ("Ton 22, weil er frei AUSSAH"). Dabei aufgefallen: Die zwei Kacheln von heute Nacht wurden ohne das Werkzeug gesetzt. Ton 39 lag 0,0362 von Ton 15 entfernt -- der engste Abstand im ganzen Haus, zwei praktisch gleiche Cyan-Toene. Filipe dazu mehrfach: "keine die sich irgendwie aehnlich sind". Neues Werkzeug `tools/kachel-farbe-einzeln.mjs`: zieht EINE Farbe nach, ohne die anderen anzufassen. Das grosse Werkzeug haette alle 40 neu gefaerbt -- jede Kachel im Haus, ungefragt. Es bricht ab, wenn es nicht alle Toene lesen kann: Der erste Anlauf las 31 von 40, weil einstellige Nummern mit ZWEI Leerzeichen dastehen, und rechnete froehlich weiter. Ergebnis: kleinster Abstand 0,0362 -> 0,0840, durch Aendern von zwei Kacheln, die es erst seit gestern Nacht gibt. 5. anruf-probe.html lud `basis.css` und `kopf.css` -- beide gibt es nicht. Ausgerechnet dort faellt es nicht auf, weil die Seite ihre eigene Stilangabe im Kopf hat. pruef-struktur war deshalb rot (5 Befunde) und ist jetzt gruen. GEMESSEN: pruef-werdegang 95/0 (neu), pruef-entwicklung 43/0, pruef-befinden 75/0, pruef-rechtetafel 19/0, pruef-zwischenspeicher 21/0, pruef-start-ansicht 0 Fehler, pruef-struktur 0 Fehler (vorher 5), pruef-buehne fuer werdegang.html 0 Fehler. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-19 10:22:02 +02:00
DogFatherGitandClaude Opus 5	0b73fbb501	Jede Seite traegt die Farbe ihrer Kachel -- und der alte Name ist weg ... 1. DIE FARBE DER KATEGORIE GILT JETZT AUF DER GANZEN SEITE. Filipe: "die kacheln sollen auch in jeder seite die farben der kategorie haben. ich will dass alles perfekt angepasst ist." Vorher war jede Bereichsseite gleich blau, egal aus welcher Kachel man kam -- beim Klick verlor man die einzige Farbe, an der man sich orientieren konnte. KEINE DRITTE LISTE: Der Ton steht bereits in den Kacheln, und der Browser hat beide Quellen vorliegen (`ich.bereiche` vom Server, `Bereiche.GRUPPEN` fuer die Agentur). `tonSetzen` sucht dort und setzt `data-ton` am <body>; die Zuordnung Nummer->Farbe gilt ueber start.css ohnehin schon. Gefunden wird ueber das ZIEL, nicht ueber den Namen -- der aendert sich (heute zweimal), das Ziel nicht. Der Akzent der Seite wird daraus gemischt, nicht rein uebernommen: Einige Toene sind sehr hell (Ton 30 fast Weissgruen, Ton 36 Zitronengelb) und wuerden als duenne Linie auf dunklem Grund blenden. 12 % ruhiges Blaugrau nehmen die Spitze, ohne die Kategorie unkenntlich zu machen. 2. DER UMBENANNTE NAME WAR NOCH AN VIER STELLEN. Die Kachel heisst seit heute "Eure Aufgaben" -- Titel und Kopfleiste der Seite sagten aber weiter "Entwicklung", und zwei Pruefungen suchten die Kachel ueber ihren alten Namen. Sie waeren beim naechsten Lauf rot geworden, ohne dass etwas kaputt ist. pruef-befinden sucht die Kachel jetzt ueber ihr ZIEL statt ueber den Namen: Das ist die Angabe, die sich nicht aendert, wenn jemand den Namen nachschaerft. GEMESSEN: pruef-entwicklung 43/0, pruef-befinden 75/0, pruef-community-sicht 10/0, pruef-wege-nach-draussen 64/0, pruef-bereiche-lesend gruen. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-19 02:09:02 +02:00
DogFatherGitandClaude Opus 5	b40089ff79	Testfoto aus dem Commit nehmen ... server/_foto-logos.png war ein Bildschirmfoto zum Nachsehen, wie die schwebenden Logos aussehen -- kein Bestandteil der Anwendung. Es ist beim 'git add -A' mitgekommen. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-19 02:04:14 +02:00
DogFatherGitandClaude Opus 5	f62ade3573	Vertraulicher Meldeweg, klappbare Abschnitte, lila Stunden, Logos ... Eine Nacht voller Auftraege von Filipe. Der Reihe nach: 1. VERTRAULICH MELDEN -- der groesste neue Teil. "es soll auch eine kategorie also eine hauptkachel geben wo die community leute sich anonym melden koennen wenn sie probleme haben ... rechte hand und dogfather sollen zugriff auf diese anonyme nachrichten haben. also anonym fuer die anderen." WICHTIG, UND ES STEHT SO AUF DER SEITE: "anonym" heisst hier VERTRAULICH. DogFather und die rechte Hand sehen den Namen -- so bestellt und auch richtig, ohne Namen kann man niemandem helfen. Anonym ist es gegenueber allen anderen: kein Modi, kein anderes Mitglied. Wer glaubt, er schreibe unerkannt, schreibt anders und fuehlt sich hinterher getaeuscht -- deshalb steht der Satz im Formular, bevor jemand tippt. Der strikte Wechsel (melden -> warten -> antworten -> warten) ist im SERVER erzwungen, nicht nur im Knopf. Ein ausgegrauter Knopf ist keine Regel. Geschlossen wird nur von der Leitung; abgeschlossene Faelle werden nach 90 Tagen samt Nachrichten geloescht -- hier stehen die empfindlichsten Texte des Hauses. Modis sind ausdruecklich AUSSEN VOR: Sehr oft geht es in diesen Meldungen um eine Moderationsentscheidung. 2. JEDE KATEGORIE LAESST SICH ZUKLAPPEN. "man soll auf dieser seite jede kategorie auf und zu klappen koennen mit einem button ... ueberall wo so eine liste entstehen kann." Das Muster gab es auf der Startseite schon; es steht jetzt als `abschnittKlappbar` in kopf.js und wird von den Brettern und dem Zeitstrahl benutzt. Die Koepfe sind echte <button> (fuer die Tastatur), der Zustand haelt in localStorage, und er haengt je Brett UND Art -- sonst waere "Regel zugeklappt" ueberall gleichzeitig zu. 3. DIE SPRUNGLEISTE SIEHT AUS WIE ETWAS ZUM ANFASSEN. Vorher unterstrichene Woerter, die aussahen wie eine Fusszeile. Jetzt Marken mit Rahmen in einem eigenen Block. 4. DIE STUNDEN SIND LILA. UMGERECHNET, NICHT NEU GEWAEHLT: Jeder der fuenf Verlaufsstopps wurde nach OKLCH zerlegt, der Farbton auf 303 Grad gedreht, zurueckgerechnet. Helligkeit und Buntheit blieben gleich -- eine frei gegriffene Palette waere heller oder bunter geworden, und die Uhr damit unruhiger. 5. DIE KARTEN "UNSERE SEITEN": babyblau und lila, mit schwebenden Logos. Beide Logos wurden zu MASKEN gerechnet (tools/logo-maske.mjs): Die PNG tragen nur Alpha, die Farbe kommt aus dem CSS. Dadurch passt dasselbe Logo in jede Kachel, egal welchen Ton sie hat -- und VanVans 378-KB- Logo wurde dabei zu 109 KB. Vier Stueck je Karte, verschieden gross, zwei Bahnen, 26 bis 41 Sekunden Umlauf. Der erste Versuch war mit 5-9 % Deckkraft praktisch unsichtbar; jetzt 10-16 %. 6. "ENTWICKLUNG" HEISST JETZT "EURE AUFGABEN". Filipe hat recht: Die Kachel fuehrt seit dem 11.09. auf den Katalog -- eine Aufgabenliste. Der Name blieb stehen, weil beim Umhaengen des Ziels niemand ihn angefasst hat. Der Name "Entwicklung" ist damit frei fuer das, was er darunter versteht (Auswertung je Person mit Verlauf und Text) -- das ist noch NICHT gebaut. DREI PRUEFUNGEN, DIE ZUFAELLIG GRUEN WAREN, sind nebenbei aufgefallen: - pruef-kachelraster wartete feste 500 ms auf eine gestaffelte Einblendung und mass vier Reihen, wo drei sind. Jetzt reducedMotion. - pruef-start-ansicht scrollte 600 px und nahm an, danach liege keine Kachel mehr unter dem Zeiger. - pruef-wege-nach-draussen zaehlte das Kachelraster ueber ALLE Gruppen statt je Gruppe. GEMESSEN: pruef-hilfe (neu) 55/0, pruef-wege-nach-draussen 64/0, pruef-jeder-hat-eine-seite 65/0, pruef-community-sicht 10/0, pruef-bereiche-lesend, pruef-steckbrief, pruef-start-ansicht, pruef-kachelraster alle gruen. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-19 02:04:03 +02:00
DogFatherGitandClaude Opus 5	63f2b2bc55	Jeder hat einen Steckbrief -- und die Kacheln stehen in der richtigen Reihenfolge ... Filipe: "jeder soll ein steckbrief haben, jeder der ein account hat, rechte hand, modis und community, jeder soll genau wie ich foto und so hinzufuegen koennen." Und: "ich will das oben die sachen fuer dogfather sind, dan die sachen fuer modis und dan community bereich." 1. JEDER HAT EINEN STECKBRIEF. In rechte.js fehlte "gast" -- und damit ausgerechnet die groesste Gruppe. Die Seite selbst konnte es die ganze Zeit: `/mein` fragt nach der eigenen Nummer und kennt gar keine Rolle. Es fehlte nur die Tuer und die Kachel. DABEI EIN ZWEITER FUND, der schon laenger da war: In assets/js/steckbrief.js stand eine Liste aus drei Gruppen (Management, Scouting, Creator). Wer in keine passte, verschwand LAUTLOS aus der Uebersicht -- betroffen waren die rechte Hand und die Modis. Ein Modi, der die Seite oeffnete, sah seine eigenen Leute nicht. Kein Fehler, keine leere Liste, sie waren einfach nicht da. Die Zuordnung kommt jetzt vom Server (`abschnittFuer`). Damit kann sie nicht mehr veralten, und in der ausgelieferten Datei steht keine Liste von Rollennamen mehr -- was ohnehin Hausregel ist. Wer kuenftig vergessen wird, landet sichtbar unter "Weitere" statt zu verschwinden; die Gegenprobe dafuer steht in der Pruefung. "Wer hier mitarbeitet" heisst jetzt "Wer hier dabei ist" -- ein Mitglied arbeitet nicht mit, es schaut zu. 2. DIE REIHENFOLGE. Die Moderationskachel trug dieselbe Gruppe wie die sieben Bretter und landete deshalb HINTER ihnen: Wer moderiert, musste an der ganzen Community vorbeiscrollen. Sie hat jetzt eine eigene Gruppe und steht davor. ERST ZU VIEL GEMACHT, DANN KORRIGIERT: Mein erster Entwurf schrieb auch die Reihenfolge der Arbeitsgruppen fest. Die ist an mehreren Stellen bewusst gewaehlt und begruendet -- pruef-start-ansicht hat es sofort gemeldet, zu Recht. Jetzt wandern nur noch Moderation, Community und "Fuer dich" ans Ende; alles andere bleibt, wo es war. 3. ZWEI PRUEFUNGEN, DIE ZUFAELLIG GRUEN WAREN. pruef-kachelraster zaehlte Reihen ueber die Y-Koordinate und wartete feste 500 ms. Die Kacheln laufen aber gestaffelt ein -- mit einer Gruppe mehr war die Messung zu frueh und meldete vier Reihen, wo drei sind. Das Bildschirmfoto derselben Seite zeigte ein makelloses Raster. Jetzt misst sie mit `reducedMotion: reduce`, also den Endzustand. pruef-start-ansicht scrollte 600 px und nahm an, danach liege keine Kachel mehr unter dem Zeiger. Dieselbe Falle wie eine feste Umbruchschwelle: eine Rechnung von gestern. Sie fragt jetzt, was gemeint ist -- leuchtet die ALTE Kachel noch? GEMESSEN: pruef-jeder-hat-eine-seite (neu) 65 Pruefungen 0 Fehler, pruef-steckbrief, pruef-start-ansicht, pruef-kachelraster, pruef-community-sicht alle gruen. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-19 01:40:16 +02:00
DogFatherGitandClaude Opus 5	f30227c873	Unsere Seiten, klickbare Video-Karten -- und coturn, das nie vermittelt hat ... Drei Sachen von Filipe, und eine davon war ein Fehler von mir. 1. DER VERMITTLUNGSSERVER HAT NIE EINEN ANRUF GETRAGEN. Am 18.09. habe ich gemeldet, coturn laufe und sei "von aussen nachgewiesen". Das war falsch. Im Protokoll: null Zuteilungen, jemals. Beim ersten echten Versuch "check_stun_auth: Cannot find credentials" -- in /etc/turnserver.conf fehlte `static-auth-secret`, also suchte coturn die Zugangsdaten in seiner eigenen Datenbank und wies jeden ab. Und mein eigenes Werkzeug meldete die ganze Zeit gruen: "Eingetragen, Geheimnis lesbar, Server antwortet." Jedes Wort wahr -- und keins beantwortete die Frage, um die es geht. Eine STUN-Bindung fragt "bist du da?", eine Zuteilung fragt "traegst du meinen Anruf?". `tools/turn-sprache.mjs` (neu) versucht jetzt eine ECHTE Zuteilung und schickt ein Paket darueber. `turn-einrichten.mjs` benutzt sie und hat drei Ausgaenge statt zwei: traegt / traegt nicht / konnte nicht nachsehen. Nach Filipes Reparatur auf dem Server gemessen: Zuteilung auf Port 49199, Paket angekommen -- von Luxemburg durch Deutschland. 2. UNSERE SEITEN -- die erste Kachel, die HINAUSFUEHRT. Website und VanVans Shop, mit dem Rabattcode DOGI10. Der Code wurde nachgesehen, nicht abgeschrieben: partnercodes.json, 10 Prozent, aktiv, "zum weitergeben an Community" -- und giltAufSale: false, weshalb der Satz zu reduzierten Artikeln danebensteht. Der zweite Code dort ist als "nur fuer Filipe persoenlich" vermerkt und steht nirgends. Auch Name und Beschreibung des Shops stammen von der Seite selbst. Meine erste Fassung hiess "Van's DIY Bastelbedarf" und nannte "Perlen, Anhaenger, Werkzeug" -- ausgedacht und falsch. Er heisst mit "&" und verkauft Haekelwerke, Plushies, Schmuck. Der Ton der Kachel wurde GESUCHT, nicht gewaehlt: sieben geratene Blautoene schafften den noetigen Abstand nicht, also 372 600 Kombinationen abgesucht. #087ce7, Abstand 0.310, Kontrast 4.51:1. 3. DIE GANZE VIDEO-KARTE KLICKT -- "egal wo man drauf drückt". Und hier steckte der lehrreiche Fehler: Zuerst stand der Klick-Block unten vor `return k`. Diese Funktion hat DREI Rueckgabepunkte, und der erste lautet `if (!darfEintragen()) { ...; return k; }` -- also genau fuer die Mitglieder, fuer die Filipe es wollte. Beim Team ging es, bei der Community nicht. Jetzt haengt er dort, wo `videoWeg` entsteht. Nicht klickbar bleiben Karten ohne Video und solche, deren Video bei TikTok geloescht wurde -- sonst fuehrt der Klick auf eine Fehlerseite, und wir sehen kaputt aus. GEMESSEN: pruef-wege-nach-draussen (neu) 63 Pruefungen, 0 Fehler, auf 1400 und 412 px. Mit Gegenproben: der Kopierknopf oeffnet nichts, der eigene Knopf wirkt genau einmal, auf einer Karte ohne Video passiert nichts. pruef-community-sicht 10/0 auf jetzt 11 Seiten, 0 tote Wege. Nebenbei: Der Pfeil klebte bei langen Untertiteln am Text (auf dem Bildschirmfoto gesehen). 0.45rem Abstand. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-19 01:17:09 +02:00