7 Commits
Author SHA1 Message Date
DogFatherGitandClaude Opus 5 24f9be8e4f Drei Fächer, Gesichter, Zeichen an jedem Handgriff -- der Chat ist nicht wiederzuerkennen
Filipe: "ich will 3 kategorien haben. chats mit einzelnen personen,
gruppen chats und kanäle." Und: "ich will dass du überhaupt die
komplette kachel veränderst, ich will dass alles anderst aussieht und
gestaltet ist, mach wirklich was verrücktes und übertrieben krank
geiles ... dass die ganze community und team morgen total überrascht
sind und den chat nicht wieder erkennen."

DIE LISTE HAT DREI FÄCHER. Personen, Gruppen, Kanäle -- als Mulde mit
drei Schaltern über dem Suchfeld, nicht als drei freie Knöpfe: Drei
Dinge, die einander ausschließen, liest man nur als EINE Entscheidung,
wenn sie in einer gemeinsamen Fassung sitzen. Das gewählte Fach liegt
oben auf (Licht, Schatten, Akzentsaum), die anderen liegen darin -- man
sieht die Wahl an der Tiefe, nicht nur an der Farbe. Die Wahl überlebt
das Neuladen; beim Suchen gilt sie nicht, wer einen Namen tippt will
ihn finden und nicht raten, in welchem Fach er liegt.

WAS EIN GESCHLOSSENES FACH NICHT VERSCHLUCKEN DARF: die Ungelesenen und
den Ruf. Beides steht deshalb AM Fach -- die Zahl in der Warnfarbe, das
@ in der Akzentfarbe. Gefunden hat die Lücke nicht ein Blick, sondern
pruef-erwaehnung: Die Erwähnung lag in einer Gruppe, offen war
"Personen", und das @ war damit nirgends zu sehen.

EIN LEERES FACH MERKT MAN SICH NICHT. Wer nur einen Kanal hat -- jeder
Neue im Haus -- landete auf "Personen" und sah eine leere Liste neben
einem vollen Kanal. Beim ersten Zeichnen wird deshalb ins erste Fach
gewechselt, in dem etwas steht; Reihenfolge: gerufen, dann ungelesen,
dann überhaupt vorhanden. Gespeichert wird das NICHT -- es ist geraten,
nicht gewählt. Gefunden von pruef-gifs.

EIN GESICHT IM KOPF DES GESPRÄCHS. Links in der Liste trägt jedes
Gespräch sein Zeichen, und ausgerechnet beim Öffnen verschwand es. Es
ist dasselbe Zeichen, nicht ein ähnliches: `zeichenFuellen()` füllt jetzt
Liste und Kopf -- rund fünfzig Zeilen standen vorher mitten im Zeichnen
und hätten sonst ein zweites Mal dagestanden. Am Handy bleibt es weg,
nachgerechnet: mit ihm blieben dem Namen 126 px bei 128 Untergrenze, die
Knopfreihe fiele eine Zeile tiefer.

JEDER HANDGRIFF BEKOMMT SEIN ZEICHEN. Unter jeder Blase standen fünf
Wörter in Versalien -- bei zwölf Nachrichten sechzig. Jetzt Pfeil,
Gesicht, Papierkorb, Nadel und zwei Blätter, das Wort klein daneben.
Die Wörter bleiben: "anheften" und "lösen" sehen als Nadel gleich aus,
und "löschen (Notfall)" darf nie ein Rätsel sein. Breiter wird es
trotzdem nicht -- gesperrte Versalien kosten rund ein Viertel mehr
Breite, genau das, was die Zeichen brauchen. Die Zeichen sind Masken:
sie folgen `currentColor` und damit jedem Zustand der Schrift daneben.

AUS DER FUSSZEILE WIRD EINE MULDE, und der Grund wird dabei dunkler,
nie heller -- das ist die Bedingung dafür, dass die Kontrastzusage
gültig bleibt. Die Uhrzeit bekommt ein eigenes Schild: eine Angabe,
keine Bedienung.

AUS DEM FARBFLECK WIRD EIN RING. Der Knopf für die eigene Kachel war
ein voller Kreis in der gewählten Farbe, direkt neben einer gleich
großen Marke -- man las ihn als Meldung, und er meldet nichts. Farbe
erscheint auf dieser Seite überall als Kontur; jetzt auch hier.

AUS DEM TOTEN TRENNER WIRD LICHT. Die senkrechte Linie am Verlauf
stammte aus der Zeit, als Liste und Verlauf EIN Kasten waren; seit dem
Umbau auf zwei Tafeln klebte sie ohne Aufgabe an der Kante. An ihrer
Stelle ein sehr weicher Schein oben rechts, unter vier Prozent Deckung
-- Tiefe, kein Leuchten.

DIE KONSOLE: Das Schreibfeld ist eine Rinne statt eines flachen
Kastens, die vier Werkzeuge sprechen dieselbe Sprache, und der
Absendeknopf ist als einziger gefüllt. Keine Maßzahl angefasst -- die
Zeile ist seit dem 23.09. auf den Pixel voll.

ZWEI PRÜFUNGEN WURDEN GENAUER, NICHT NACHSICHTIGER:

  pruef-chatkachel suchte ihre "freie Stelle" nicht, sie rechnete sie
  aus -- 6 px vom rechten Rand, halbe Höhe. Das lag mal auf dem
  Rollbalken, mal auf einer Blase, und meldete beides Mal "das
  Bühnenbild ist gar nicht da". Sie sucht die Stelle jetzt mit
  `elementFromPoint` und sagt es, wenn es keine gibt.

  pruef-erwaehnung prüft jetzt beides: dass das Fach den Ruf meldet,
  ohne geöffnet zu werden, UND dass die Zeile nach dem Wechsel dasteht
  -- mit der Gegenprobe, dass das Fach wirklich filtert. 126 -> 129.

Nachgebessert: die Ungelesen-Marke am Fach stand auf 0,64 rem = 10,24 px,
unter der Hausgrenze von 11,5. Gemeldet von pruef-css-klassen, bevor es
jemand auf einem Telefon sehen musste -- der zweite Anlauf desselben
Reflexes an einem Tag.

Geprüft: pruef-chat-optik, pruef-chatkachel (40), pruef-chat (ALLES IN
ORDNUNG), pruef-chat-neu (32), pruef-chat-ausbau (64),
pruef-chat-kanaele (81), pruef-chat-aufloesen (126),
pruef-chat-anhaenge (109), pruef-erwaehnung (129), pruef-css-klassen,
pruef-tippziele (11), pruef-lesbarkeit. pruef-gifs hat weiterhin die
zwei Fehler, die schon vor diesem Umbau da waren (an HEAD nachgemessen).

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-25 02:25:06 +02:00
DogFatherGitandClaude Opus 5 d47ccf0d5f Die Blase hört auf, eine Farbfläche zu sein -- der Chat sieht anders aus
Filipe: „es hat sich nichts verändert quasi … auch die kachel das
aussehen. die blasen. die schriften. alles soll anders und geiler
aussehen, moderner und spezieller."

ER HATTE RECHT, UND ICH WEISS JETZT WARUM. Der erste Anlauf hat
poliert statt umgebaut -- weil ich die FARBE der Blase für unantastbar
gehalten habe. Genau sie war das Problem: Zwei Drittel jeder Nachricht
waren eine deckende, kräftige Fläche, und darauf kämpfte alles andere
um Aufmerksamkeit. Jede Feinheit, die man darauf legt, verschwindet.

DIE BLASE IST JETZT DUNKLES GLAS -- für jeden dieselbe. Die persönliche
Farbe ist vollständig erhalten, sie sitzt nur woanders:
  * als leuchtende KANTE an der Sprechseite (links beim Gegenüber,
    rechts bei einem selbst),
  * im NAMEN, aufgehellt, damit auch ein dunkler Ton trägt,
  * als Hauch im oberen Verlauf und als Schein unter der Blase.
Man erkennt die Person weiterhin an der Farbe -- und der Text steht
endlich auf einem ruhigen Grund.

DAZU: Die Fußzeile bekommt eine Kante in der Farbe und wird zur
Beschriftung (Versalien, gesperrt, gedämpft); die Uhrzeit trennt sich
von den fünf Handgriffen; die Blase wird schmaler (66 % / 62 Zeichen --
darüber verliert man beim Zeilenwechsel die nächste Zeile); der Text
bekommt Durchschuss, weil helle Schrift auf dunklem Grund optisch
ausstrahlt; das Zeichen neben der Blase spricht dieselbe Sprache wie
die Liste; die offene Gesprächszeile bekommt dieselbe Kante wie die
Blasen.

WAS DAS FÜR DIE MESSUNGEN HEISST -- und das ist der wichtigere Teil:

pruef-chatkachel und pruef-chat-neu haben bis heute gerechnet „Schrift
X auf Kachelfarbe Y". Das gibt es nicht mehr. Die eine wäre GRÜN
geblieben und hätte nichts mehr über den Bildschirm gesagt (die
gefährlichste Sorte, in diesem Haus schon dreimal vorgekommen), die
andere wurde sofort rot. Beide sind mitgezogen:

  * Die feste Schrift wird gegen den festen Blasengrund gemessen --
    und zwar im SCHLIMMSTEN Fall: Die Blase ist zu 92 % deckend,
    dahinter liegt ein Foto, gerechnet wird mit Weiss dahinter.
    Gemessen 14,2:1 (nötig 7) und 7,9:1 (nötig 4,5).
  * NEU: Jede der 13 Kacheln UND alle 360 Töne des Farbrings müssen
    als NAME auf diesem Grund lesbar sein. Das ist die Stelle, an der
    es heute kippen kann.
  * Beides liest `--blasengrund` und `--namen-anteil` aus chat.css
    statt sie abzuschreiben. Wer dort etwas ändert, ändert die
    Prüfung mit.

UND SIE HAT SOFORT ETWAS GEFUNDEN: Mit 58 % Aufhellung schaffte der Ton
„Ziegel" als Name nur 4,31:1 -- unter den nötigen 4,5. Auf dem
Bildschirm sah er gut aus, weil hinter der Blase gerade nichts Helles
lag. Jetzt 50 % und 5,20:1. Dazu eine Gegenprobe, die beweist, dass das
Aufhellen keine Zierde ist (ohne sie: 2,05:1).

DREI EIGENE FEHLER, ALLE VON PRÜFUNGEN GEMELDET
  * 0,66 rem für die Fußzeile = 10,56 px, drei Stellen unter der
    Hausgrenze von 11,5 px. Jetzt 0,72 rem; leise wirkt sie durch
    Versalien und Deckung, nicht durch Kleinheit.
  * Auf dem Handy brach die Fußzeile in drei Zeilen -- schuld war meine
    eigene Regel `margin-right: auto` an der Uhrzeit, die am Rechner
    richtig ist. Dort jetzt Kleinbuchstaben und kein Schub.
  * Der Handy-Block stand MITTEN in der Datei. Eine Medienabfrage
    erhöht die Spezifität nicht -- jede spätere Basisregel gewann
    gegen ihn, und er wirkte halb. Er steht jetzt am Ende.

GEPRÜFT: chatkachel, chat-optik, chat-ausbau, chat, chat-neu,
chat-kanaele, css-klassen, lesbarkeit, tippziele — alle 0 Fehler.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-25 01:42:19 +02:00
DogFatherGitandClaude Opus 5 2bea133feb Das Protokoll spricht deutsch -- und zwei Pruefungen messen wieder
Filipe: "ich will dass das alles viel anders und krasser und geiler
gestaltet ist bitte ... viel profissioneller und moderner."

--- DIE PERSONENSEITE ---

Auf seinem Bildschirmfoto stand woertlich, was in der Datenbank steht:
"treff_freigegeben", "video_eingelesen", "einstellung_geaendert". Das
sind Spaltenwerte, keine Saetze fuer Menschen. Daneben die rohe
IP-Adresse, quer ueber ein Viertel der Zeile.

KEINE TABELLE MIT 77 EINTRAEGEN. So viele Aktionen gibt es; eine
Liste davon waere am Tag der naechsten unvollstaendig, und niemand
merkte es -- dann stuende einfach wieder der Rohname da. Dieselbe
Falle wie jede abgeschriebene Liste in diesem Haus.

Stattdessen eine REGEL: Unterstriche werden Leerzeichen, der erste
Buchstabe gross. Das ergibt fuer jede Aktion einen lesbaren Ausdruck,
auch fuer die, die es noch nicht gibt. Nachgeprueft an allen echten
Namen:

  treff_freigegeben      -> Treff freigegeben
  einstellung_geaendert  -> Einstellung geändert
  chat_zurueckgenommen   -> Chat zurückgenommen
  vorlage_uebernommen    -> Vorlage übernommen

Die Umlaute sind der zweite Teil: In der Datenbank stehen sie als
ae/oe/ue. Blind zurueckzusetzen waere falsch ("neue" wuerde "neü"),
deshalb nur in Wortteilen, die sicher sind -- gemessen an den 77
echten Namen, nicht geraten.

Der Rohname bleibt als Titel an der Zeile: Wer im Server danach sucht,
braucht ihn genau so, wie er in der Spalte steht.

DIE IP TRITT ZURUECK, verschwindet aber nicht: feste schmale Spalte,
leiser Ton. Sie beantwortet eine Frage, die man selten stellt.

UND DIE BESCHREIBUNGEN BRECHEN UM. Die der linken Hand lief ueber 150
Zeichen in einer Zeile; der Augensprung ans naechste Zeilenende ist
dann so weit, dass man die Zeile verliert. Setzer rechnen seit
Jahrhunderten mit 60 bis 80. Gekuerzt wird nichts -- "78ch" misst in
ZEICHEN und stimmt darum auch, wenn die Schrift groesser gestellt wird.

--- UND DIE ZWEI ALTLASTEN, BEIDE GESTERN GEMELDET ---

pruef-chatkachel suchte dreizehn Toene als dreizehn Knoepfe. Das
stimmte, bis die Kachelfarbe ein FARBKREIS wurde (7a674963): Seither
liegen die meisten auf einem Schieberegler und werden durch Drehen
gewaehlt. Sie meldete seither "mit allen 13 Toenen (2)" -- nichts war
kaputt, sie stellte eine Frage, die es nicht mehr gibt. Jetzt fragt
sie, was zaehlt: Ist der Kreis da, ist er bedienbar, sagt er welche
Farbe eingestellt ist, und stehen die uebrigen daneben. 36 Pruefungen,
alles in Ordnung.

pruef-galerie mass "#liste". Das war richtig, bis die Highlights am
20.09. in Kanalspalten umzogen -- seither nimmt bereich.js dem
Listenkasten sein data-galerie ausdruecklich wieder weg und setzt es
an die einzelne Spalte. Die Pruefung mass also eine leere Huelle.
Dazu erwartete sie "mindestens zwei Spalten", und das ist in einer
schmalen Kanalspalte schlicht falsch: Dort gehoert EINE Kachel je
Reihe. Jetzt sucht sie das Raster ueber das BILD (nicht ueber einen
Kastennamen -- der naechste Umbau darf umbenennen) und fragt nach der
KACHELBREITE: "1 Spalte à 219 px in einem 243 px breiten Kasten".
Eine Galerie, die sich in vier Spalten à 90 px quetscht, waere der
Fehler -- nicht eine Spalte in einem schmalen Kasten.

Beide waren monatelang rot, ohne dass etwas kaputt war. Eine Warnung,
die immer kommt, liest irgendwann niemand mehr -- und dann faellt die
echte daneben auch nicht mehr auf.

Gemessen: pruef-chatkachel 36, pruef-galerie, pruef-css-klassen,
pruef-deutsche-texte -- alle ohne Befund.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-24 00:00:47 +02:00
DogFatherGitandClaude Opus 5 60802170a1 B4 + B5: Loeschen heisst Loeschen, die Schrift wechselt mit, und Blau wird Babyblau
Die beiden Auftraege gehoeren zusammen, und zwar in dieser Reihenfolge:
Eine babyblaue Kachel ist HELL. Ohne mitwechselnde Schrift waere sie
unlesbar (1,63:1 gemessen). Erst B4 macht B5 moeglich.

B4a -- LOESCHEN HEISST LOESCHEN
  "Geloeschte Nachrichten verschwinden vollstaendig - keine Spur, kein
   'wurde geloescht'-Hinweis, bei niemandem, auch nicht bei DogFather."

Bis heute blieb die Zeile stehen: Text geleert, weg_am gesetzt, und im
Chat stand "Nachricht zurueckgenommen". Das war ausdruecklich so
begruendet ("ein Loch im Verlauf wirft mehr Fragen auf"). Das Argument
beantwortet aber eine andere Frage: Ein Hinweis "hier stand etwas"
MARKIERT die Stelle. Wer etwas aus Versehen schreibt, will es weg
haben und nicht unterstrichen.

Jetzt ein echtes DELETE. Vier Raender, an denen eine Spur bleiben
koennte, alle gemessen:
  1. die Zeile selbst
  2. chat_reaktionen    (ON DELETE CASCADE - nachgesehen, nicht angenommen)
  3. chat_erwaehnungen  (ebenso)
  4. letzte_am am Raum  - wird neu gerechnet, sonst stuende er oben in
                          der Liste mit einem Zeitpunkt, zu dem es
                          nichts mehr gibt
Dazu: ein Zitat auf eine geloeschte Nachricht wird weggelassen; in der
Gespraechsliste steht kein Hinweis mehr; der Knopf heisst "loeschen".

Die 5 alten zurueckgenommenen Zeilen (Text bereits leer) raeumt eine
einmalige, wiederholbare Umstellung ab - mit Sicherung davor, und nur
wenn es wirklich etwas zu tun gibt.

B4b -- WER DARF WAS
  "jeder nur seine eigenen - ausser DogFather und rechte Hand"
`darfJedeNachrichtLoeschen` = admin oder hand. NICHT fuehrtTeamDogi
(das schloesse die linke Hand ein) und nicht istLeitung (das schloesse
Spicy Media ein, die private Chats nicht einmal sehen darf). Das Recht
kommt vom Server ins Skript, nicht aus einer Rolle im Browser: chat.js
bekommt jeder, der die Seite oeffnet.

B4c -- DIE SCHRIFT WECHSELT MIT
  "am besten schwarz auf hellen Kacheln - und weiss, wenn jemand eine
   schwarze Kachel waehlt"
`schriftFuer(farbe)` waehlt zwischen zwei Paaren, gerechnet aus der
Leuchtdichte, mit denselben Schwellen wie das Rechenwerkzeug (7:1 fuer
den Text, 4,5:1 fuer die Fusszeile). Keine dritte Spalte in
CHAT_KACHELN, die jemand pflegen muesste. Flaeche und Schrift werden
im Browser in EINEM Griff gesetzt (blaseFaerben) - zwei Stellen waeren
irgendwann eine helle Kachel mit heller Schrift.

B4d -- DIE NAMEN
Der Name ist jetzt ein eigener Streifen mit Kante darunter, .84rem,
und der Rollenpunkt wird ein 3x14-Balken. Vorher stand er als erste
ZEILE in der Blase und las sich wie der Anfang des Satzes.

B5 -- BABYBLAU
  "jedes normales blaues herz durch babyblaues herz ersetzen ... jeder
   normale blaue farbe, sei es die kachel im chat oder emojis, nur
   babyblau bitte."
* Herz: U+1F499 -> U+1FA75. Nicht geglaubt, sondern gemessen: 43,9 px
  breit wie die anderen Herzen, ein Ersatzkaestchen waere 20,7. Die
  vier vorhandenen blauen Herzen in der Datenbank wandern mit - sonst
  waeren es vier Reaktionen, die ERLAUBT nicht mehr kennt: still weg.
* Kachel: neue, HELLE Kachel "Babyblau" mit dem Wert von --akzent.
  Gemessen: Text 10,78:1, Fusszeile 4,87:1. Sie steht bewusst nicht in
  der Rechnung des Werkzeugs (das rechnet elf Toene auf EINE
  Leuchtdichte) - sie hat eine andere Leuchtdichte und dafuer ihre
  eigene Schrift. Dasselbe Versprechen, anderer Weg.

PRUEFUNGEN
  pruef-loeschen.mjs (NEU, 20/0): alle vier Raender, die vier Faelle
    der Rechtegrenze (auch: die linke Hand darf NICHT), das babyblaue
    Herz am laufenden Server, und dass der Satz "Nachricht
    zurueckgenommen" nur noch in Kommentaren steht - mit Gegenprobe,
    dass die Suche diesen Unterschied wirklich macht.
  pruef-chatkachel.mjs (33/0): misst jede Kachel mit IHRER Schrift und
    fragt dafuer dieselbe Funktion wie der Server. Neu: dass die
    Schrift ueberhaupt wechselt. Die Leuchtdichte-Regel gilt jetzt fuer
    die gerechneten Toene - das Versprechen dahinter loest die
    Kontrastzeile darueber direkt ein.
  Vier alte Pruefungen umgedreht, die den alten Zustand festgeschrieben
    hatten: pruef-chat, pruef-chat-ausbau, pruef-chat-aufloesen,
    pruef-chat-optik. Alle mit scharferer Messung als vorher (Zahl
    davor/danach statt "ein Hinweis ist da").
  Mitgelaufen und gruen: pruef-alle-sehen-es, pruef-treffchat (110/0).

Gesichert: workspace-vor-loeschumbau-20260922-233313.db
(946 KB, integrity_check ok, 111 Nachrichten, 49 Reaktionen).

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-22 23:33:43 +02:00
DogFatherGitandClaude Opus 5 80dee4d0c8 Highlights nach vorn, kraeftige Chatfarben, alle Farben in einer Kachel
screen1 -- HIGHLIGHTS AUF ANSCHLAGBRETTS PLATZ
  Kein Tausch, sondern ein Aufruecken: Highlights nimmt die Stelle,
  alle anderen wandern eine weiter. Inhaltlich stimmt das auch --
  was die Leute selbst gemacht haben, steht vor dem, was ihnen
  angesagt wird.

screen2 -- DIE CHATFARBEN SIND GERECHNET, NICHT GEGRIFFEN
  Gemessen, was drinstand: Buntheit 0,002 bis 0,048, im Mittel 0,028
  -- auf dem Bildschirm zwoelf Grautoene. Das lag nicht an fehlendem
  Mut, sondern an der Fusszeile der Blase: Sie stand auf der leisen
  Hausschrift, und gegen die darf die Flaeche kaum Farbe haben.

  Deshalb ZUERST die Schrift (--blase-text/--blase-leise, eigene
  Farben der Blase), DANN die Flaeche. Andersherum waere es der
  Fehler vom selben Vormittag gewesen, als 27 von 31 Startkacheln
  unlesbar wurden.

  tools/chat-kacheln-rechnen.mjs liest beide Schriftfarben aus dem
  CSS und rechnet daraus die hellste Flaeche, die sie noch tragen.
  Ergebnis: Buntheit 0,072 bis 0,268, alle zwoelf auf DERSELBEN
  Leuchtdichte -- also exakt demselben Kontrast (7,02 bis 7,13:1).

  Zwei Anlaeufe waren falsch und stehen im Werkzeug begruendet:
    - hoechste Buntheit nehmen, dann Kontrast pruefen. Musste
      scheitern: gesaettigtes Gelb ist bei gleicher empfundener
      Helligkeit viel heller als Blau.
    - gleiche OKLab-Helligkeit statt gleicher Leuchtdichte. Das
      Versprechen der zwoelf lautet "ueberall gleich gut lesbar",
      und Lesbarkeit haengt an der Leuchtdichte, nicht am Eindruck.

  WER NICHTS EINSTELLT, BEKOMMT TROTZDEM EINE FARBE. Gemessen an der
  Live-Datenbank hatten vier von fuenfzehn eine gewaehlt -- der Chat
  war fuer alle anderen einfarbig. Jetzt vergibt der Server einen der
  elf bunten Toene aus der Personennummer, stabil. Schrittweite 4:
  elf ist prim, also laufen alle Toene durch, und vier Schritte sind
  131 Grad im Farbkreis -- aufeinanderfolgende Nummern landen so weit
  auseinander wie moeglich. Mit id % 11 sassen zwei Nachbarn im
  selben Gespraech magenta und rot nebeneinander.

  Niemand verliert seine Wahl: veilchen, ziegel und moos sind die
  drei gewaehlten und behalten ihren Farbbereich.

  Dazu: Blasen mit 22px runden Kanten (nur die Ecke zur Person bleibt
  spitz -- sie sagt, wer spricht), Lichtsaum oben innen, weicher
  Schatten. Der Name hell und fett mit Rollenpunkt davor; er stand
  auf leisem Grau mit 85 Prozent Deckung und war der schwaechste Text
  der Seite, ausgerechnet der, der sagt, wer spricht.

  ZWEI REGELBLOECKE FUER DIESELBE BLASE ZUSAMMENGELEGT. Der untere
  gewann und hat an einem Tag zweimal Schaden angerichtet: Er stellte
  die runden Kanten auf 16px zurueck (die Aenderung waere wirkungslos
  ausgeliefert worden), und er mischte 26 Prozent Akzentfarbe in die
  eigene Blase -- die hatte damit eine Farbe, die in CHAT_KACHELN
  nicht vorkommt und die die Kontrastpruefung nie angesehen hat.

screen3 -- ALLE FARBEN DES HAUSES IN EINER KACHEL
  tools/kachel-regenbogen.mjs leitet die 31 benutzten Toene ab
  (bereicheFuer/zusatzBereicheFuer ueber alle Rollen und beide
  Haeuser) und schreibt daraus einen Streifenverlauf mit harten
  Kanten -- "nicht gemischt" war die eigentliche Ansage. Ein Verlauf
  ergaebe Zwischentoene, die es im Haus nicht gibt.

  Gegen einen deckenden Grund gemischt, nicht gegen --flaeche: Die
  ist halbdurchsichtig, und durch 31 schmale Baender schien das
  Buehnenbild -- sie verloren genau das, wofuer sie da sind.

  Der Lesesaum ist staerker als auf den anderen Kacheln, und zwar
  gemessen: Mit deren Werten kam der Text auf 4,45:1, fuenf
  Hundertstel unter der Grenze. Gefunden hat das pruef-kachelfarben,
  nicht der Blick -- 4,45 gegen 4,50 sieht man nicht.

pruef-buehne -- DIE ZAHL GEHOERT IN DIE BEDINGUNG
  Die Abtastung wurde nachsichtiger (fremde Flaechen zaehlen nicht
  mehr als Untergrund eines Textes). Das war richtig und hat einen
  Fehlalarm beseitigt, der seit Tagen kam. Eine Lockerung kann aber
  zu weit gehen, deshalb muss jetzt jeder gefundene Text in genau
  einem von drei Toepfen landen: gemessen, ohne freien Untergrund,
  oder aussortiert. Geht die Rechnung nicht auf, ist unterwegs etwas
  still verschwunden.

  Erster Anlauf war "mindestens 5 Stellen" -- und wurde auf
  uebersicht.html sofort rot, weil die Seite nur vier Texte hat.
  Eine feste Schwelle ist eine Rechnung von gestern; diese war keine
  fuenf Minuten alt.

Gemessen: pruef-kachelfarben 22/0 (war 18, neu: die Willkommenskachel
traegt wirklich alle benutzten Farben, in beide Richtungen geprueft),
pruef-buehne 192/0, pruef-chatkachel 32/0, pruef-chat-optik 45/0,
pruef-chat 48/0, pruef-erwaehnung 69/0, pruef-start-ansicht 153/0,
pruef-treff 80/0, pruef-willkommen 67/0, pruef-treffchat 110/0,
pruef-css-klassen 30/0.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-22 12:57:56 +02:00
DogFatherGitandClaude Opus 5 6e46a08543 Portnummern werden abgeleitet, nicht mehr vergeben
Gemessen: 165 Pruefdateien, 129 verschiedene Nummern -- NEUNZEHN
doppelt, vier davon dreifach. Niemand hatte das gewollt; jede neue
Pruefung wurde von einer vorhandenen abgeschrieben, und die Nummer kam
mit. Meine eigene Notiz sagte "sieben" -- auch eine Bestandsliste
altert.

Der Waechter faengt den Schaden ab, aber er kann nur melden, was schon
passiert ist: Zwei Pruefungen mit derselben Nummer koennen nie
gleichzeitig laufen, und ein liegengebliebener Prozess der einen laesst
die andere abbrechen mit einer Meldung, die wie ein Befund aussieht.
Genau das ist mir am 20.09. zweimal passiert.

Jetzt leitet jede Datei ihre Nummer aus ihrer STELLE IM ALPHABET ab
(eigenerPort in helfer-port.mjs), zwei je Datei. Nicht ueber eine
Pruefsumme: Bei 165 Namen in 4900 Nummern waeren nach dem
Geburtstagsproblem rund DREI Zusammenstoesse zu erwarten -- ein Hash
tauscht eine sichtbare Doppelung gegen eine unsichtbare. Die Stelle im
Alphabet ist eindeutig von der Bauart her.

--- ZWEI FEHLER AUF DEM WEG, BEIDE LEHRREICH -------------------------

1. DER ERSTE VERSUCH WAR GRUEN UND KAPUTT. Ersetzt wurde mit einem
   Muster: "([^"]*4231[^"]*)". Das hielt

     { host: "127.0.0.1", port: 4231, path: "/404.html" }

   fuer eine Zeichenkette -- ein Muster kann eine oeffnende nicht von
   einer schliessenden Anfuehrung unterscheiden. Heraus kam

     { host: "127.0.0.1`, port: ${PORT}, path: `/404.html" }

   also GUELTIGER Code ohne port-Feld. `node --check` sagte gruen fuer
   alle 164 Dateien. Aufgefallen ist es erst, weil ich vier Vertreter
   gegen eine vorher gemessene Grundlinie laufen liess: pruef-schranke
   39/0 vorher, 38/1 nachher.

   Alles zurueckgenommen und mit einem Zerleger neu gemacht, der weiss,
   ob eine Stelle Code, Zeichenkette, Vorlage, Kommentar oder
   regulaerer Ausdruck ist. In pruef-ics stand die Nummer in einem
   regulaeren Ausdruck -- der wird jetzt gebaut statt hingeschrieben.

2. EIN MODUL, DAS BEIM IMPORTIEREN ARBEITET, IST EINE FALLE. Der
   zweite Durchgang importierte den ersten, um seine Mechanik zu
   benutzen -- und fuehrte dessen Hauptlauf gleich mit aus. Die
   zweiten Nummern wurden dadurch als erste behandelt, zwei Aufrufe
   bekamen dieselbe Nummer, und in pruef-content stand `const PORT`
   zweimal.

--- WAS DAS DAUERHAFT HAELT -----------------------------------------

pruef-portnummern.mjs (neu, 8 Pruefungen) fragt nicht "welche Nummern
sind doppelt", sondern "wer traegt ueberhaupt noch eine von Hand ein"
und "wer startet einen Server, ohne seine Nummer abzuleiten". Die
zweite Frage hat sofort etwas gefunden, das in KEINER Doppelungsliste
stand: pruef-push-weg belegte 4341 und 4342, rief den Waechter aber
gar nicht auf -- dieselbe Nummer wie pruef-agentur. Eine Liste zeigt
nur, was auf ihr steht.

Mit Gegenprobe: Eine unbekannte Datei bekommt keine geratene Nummer,
sondern einen Abbruch, und eine dritte Nummer je Datei gibt es nicht.

--- NACHGEMESSEN ----------------------------------------------------

Sechzehn Pruefungen gegen ihre vorher gemessene Grundlinie, je eine
Vertreterin jeder umgestellten Bauweise (eine Nummer, zwei Nummern,
Nummer in einer Zeichenkette, in einer Vorlage, in einem regulaeren
Ausdruck, dynamische Einfuhr, Nachtlauf mit zwei Laeufen):

  crew-adresse 132/0 · schranke 39/0 · content 45/0 · entwicklung 46/0
  anruf 127/0 · ics 37/0 · push-weg 20/0 · arten 28/0 · video 67/0
  kanalzeile 14/0 · agentur 62/0 · spicy 83/0 · creator-anlegen 50/0
  push-ziel 10/0 · portnummern 8/0

Alle exakt wie vorher. Zwei waren schon vorher rot und sind es
unveraendert geblieben (crew-wand-bild 41/4, teilen 14/3) -- per
`git stash` belegt, nicht angenommen.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-20 22:51:21 +02:00
DogFatherGitandClaude Opus 5 9d086eccaf Chat: das Buehnenbild scheint durch, jeder Account bekommt seine Kachel
Hinter jeder Seite steht ohnehin eine Buehne (neun Szenen, fuer den
Chat die Lounge). Sie lag bisher hinter einer deckenden Flaeche --
vorhanden, geladen, unsichtbar. Sie durchscheinen zu lassen kostet
keine einzige Datei mehr, und auf der Adresse von Team Dogi kommt
damit von selbst deren eigene Fassung.

Das geht aber NUR, wenn der Text auf einer deckenden Kachel steht.
Sonst liegt Schrift auf einem Foto: an der dunklen Stelle lesbar, an
der hellen nicht, und beim Scrollen wechselt es. Filipes zweiter Satz
("die texte sollen immer in einer kachel sein") ist deshalb kein
Zusatzwunsch, sondern die Bedingung fuer den ersten.

Und jeder Account waehlt seinen Ton. Zwoelf Stueck, alle gleich
dunkel und gleich gesaettigt -- sie unterscheiden sich im Farbton und
in sonst nichts. Ein freier Farbwaehler klingt grosszuegiger und ist
die schlechtere Loesung: Mit ihm laesst sich Schwarz auf Schwarz
einstellen oder Neongelb, das allen anderen in die Augen sticht. Die
Kachel gehoert einem selbst, GESEHEN wird sie von allen anderen.
Gemessen: der schlechteste Kontrast liegt bei 13,9:1 (noetig 7).

Drei eigene Fehler beim Bauen, alle von der Pruefung gefunden:

1. Es gibt ZWEI Regeln fuer dieselbe Kachel (Grundform und
   Feinschliff). Ich hatte nur die erste umgestellt, die zweite gewann
   -- die eigene Kachel waere durchsichtig geblieben.
2. Die Pruefung las backgroundColor und pruefte den Alphawert. Eine
   Kachel mit einem VERLAUF hat dort rgba(0,0,0,0); sie meldete
   "durchsichtig" bei einer Kachel, die voellig deckt. Jetzt werden
   zwei Bildpunkte verglichen, einmal mit und einmal ohne Buehnenbild
   -- das misst die Sache selbst, nicht ihren Stellvertreter.
3. Dieselbe Pruefung suchte nur die rgba-Schreibweise. Chrome gibt
   das Ergebnis von color-mix als color(srgb r g b / a) zurueck; der
   Rueckfall war "Alpha 1", und sie meldete "deckt" bei einer
   Flaeche, die durchscheint. Genau das Gegenteil.

pruef-chatkachel.mjs: 27 Pruefungen, mit eingebauter Gegenprobe (auf
der freien Flaeche MUSS sich etwas aendern, sonst misst der Vergleich
nichts). pruef-chat-optik und pruef-erwaehnung unveraendert gruen.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-20 19:58:50 +02:00