28 Commits

Include renames

Author	SHA1	Message	Date
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	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