Commit Graph
7 Commits
Author SHA1 Message Date
DogFatherGitandClaude Opus 5 150555bc33 Der Notizblock -- und eine Pruefung, die zwoelf Kacheln nie angesehen hat
Filipe: „fuer die modis, rechte und linke hand und dogfather eine
kachel hinzufuegst, sie soll: Notizen, heissen. ich will dass du das
auch wie ein notizblock erstellst. ich will dass es uebelst geil und
einzigartig ist."

=================================================================
TEIL 1: DIE FARBE -- UND WAS DABEI AUFFIEL
=================================================================

Fuer die neue Kachel braucht es einen Ton. Beim Suchen fiel auf, dass
tools/kachelton-entzerren.mjs zwoelf der 45 Farben fuer FREI hielt.

Sie sind es nicht. bereicheFuer() gibt fuer die fuenf Rollen des
Agenturhauses null zurueck -- das heisst „nimm die Liste aus dem
Browser", und die steht in workspace/assets/js/bereiche.js. Dort
stehen die Toene 1 bis 22 und 44: Dashboard, Zahlen, Team-Lage,
Scout-Pipeline. Kacheln, die jeden Tag jemand ansieht.

pruef-kachelfarben hatte denselben blinden Fleck. Sie meldete seit
Wochen „33 benutzte Toene" und war gruen. Was sie dadurch NICHT sah:

  * Der Farblauf von gestern Nacht hat zwoelf dieser Kacheln
    verschoben und drei davon unter die Buntheitsgrenze gedrueckt.
    Gruen geblieben.
  * Ton 7, 16 und 22 lagen SEIT JEHER unter der Grenze (0,112 / 0,116
    / 0,068). Nie gemeldet.

Das ist die Sorte gruener Haken, vor der die Hausregel warnt: Er sagt
nur, dass die Bedingung erfuellt war -- nicht, dass sie das Richtige
angesehen hat.

BEHOBEN, und zwar an der Wurzel: Die REGELN (Kontrast, Buntheit)
gelten jetzt fuer jeden Ton, der irgendwo an einer Kachel steht --
gelesen aus denselben fuenf Dateien, die auch pruef-kachel-universum
liest. Dazu die Namen der Kacheln, damit „Ton 1 traegt Dashboard"
ueberhaupt pruefbar ist.

DIE PALETTE WURDE NEU GERECHNET, mit dem dritten Verfahren an einem
Tag -- die ersten zwei stehen als Fehler im Kopf des Werkzeugs:

  1. Alle 45 neu verteilt. Lief ueber zwei ausdrueckliche Wuensche
     hinweg (#ff1a1a, #a8d8ff).
  2. Nur die Kollisionen, aber immer nur EINEN der beiden bewegt.
     Ergebnis: Ton 1 sprang vom Tuerkis ins Altrosa, 0,197 weit.
  3. BEIDE duerfen sich bewegen, und zwar beide nur ein bisschen.
     Zwei Toene, die 0,02 auseinanderstehen und 0,09 brauchen, teilen
     sich das -- jeder rueckt 0,045, und beide bleiben, was sie waren.

  kleinster Abstand   0,0154  ->  0,0905
  zu blass                 4  ->  0
  sichtbar veraendert           7 Kacheln (ueber 0,05)
  kaum zu sehen                28 (13 zwischen 0,02 und 0,05, 15 darunter)

EINE AUSNAHME MIT ZAHL, keine mit Achselzucken: Ton 1 (Dashboard)
bleibt acht Tausendstel unter der Buntheitsgrenze. Gemessen ueber ALLE
16,7 Millionen sRGB-Farben ist die naechste, die alle Regeln haelt,
#7a75c8 -- ein Blauviolett, 0,113 entfernt. Tuerkis erreicht in sRGB
schlicht keine hoehere Buntheit, und das schmale Band teilen sich
schon sieben Toene. Eine Kachel, die ihre Farbfamilie behaelt, ist die
bessere Antwort auf „richtig geil und speziell" als eine, die acht
Tausendstel bunter ist und niemand wiedererkennt. blassBis sagt jetzt
bei jeder Ausnahme, WIE WEIT sie reicht -- vorher hiess blassErlaubt
schlicht „hier wird weggesehen".

DIE NEUE FARBE IST GRUEN UND WOLLTE BERNSTEIN SEIN. Gesucht war die
Farbe von Papier. Gemessen gibt es sie nicht mehr: Der beste Bernstein
im ganzen Farbraum haelt 0,0799 Abstand -- unter der Hausgrenze. Und
Platz schaffen hilft nicht: Setzt man ihn fest, muss ein warmer Ton
das Band verlassen (Ton 45 waere 0,212 weit ins Magenta gewandert).
Die groesste wirklich freie Luecke liegt im Gruen, bei 0,0917. Ein
linierter Block in Gruen ist Papier, seit es Papier gibt.

=================================================================
TEIL 2: DER BLOCK
=================================================================

DREI ENTSCHEIDUNGEN, AUS DENEN DER REST FOLGT:

1. ES GIBT KEINEN SPEICHERN-KNOPF. Nirgends. Wer einen Block
   aufschlaegt und lostippt, drueckt hinterher nicht auf „sichern";
   er klappt ihn zu. Gesichert wird 800 ms nach dem letzten
   Tastendruck. Geht das nicht, bleibt der Text im Browser liegen und
   wird nachgereicht -- und der Fuss sagt ehrlich „noch nicht
   gesichert", statt einen Verlust zu melden, den man gerade nicht
   verhindern kann.

2. DAS BLATT IST EIN SCHREIBFELD MIT EINER DECKSCHICHT. Das Feld
   traegt Text und Cursor und ist unsichtbar; darueber zeichnet eine
   zweite Schicht denselben Text noch einmal -- mit Kaestchen,
   Ueberschriften, Strichen und Links.

   DARAUS FOLGT EINE EISERNE REGEL, und sie steht dreimal im Code:
   KEINE Auszeichnung darf die BREITE eines Zeichens aendern. Kein
   Fettdruck, keine andere Groesse, keine Sperrung. Erlaubt sind nur
   Farbe, Flaeche, Rahmen und Durchstreichen. Ein einziges
   font-weight: 700 verschoebe den Umbruch, und ab der zweiten Zeile
   stuende der sichtbare Text neben dem Cursor.

   pruef-notizen misst das am echten Umbruch: eine Probe mit allen
   Auszeichnungen und einer Zeile, die umbrechen MUSS. Sind beide
   Schichten verschieden hoch, sitzt der Umbruch woanders. Mit
   Gegenprobe -- Fettdruck auf der Deckschicht bricht die Deckung um
   genau eine Zeile (30 px), und die Zeile wird rot.

3. DIE TASTATUR FUEHRT DIE LISTE FORT, NICHT EINE LEISTE. Ein
   Spiegelstrich und Enter macht den naechsten Punkt, ein leeres
   Kaestchen und Enter das naechste Kaestchen -- und ein GESETZTER
   Haken wird dabei nicht mitgenommen, die naechste Aufgabe ist ja
   noch nicht erledigt. Zweimal Enter beendet die Liste. Ein Klick
   aufs Kaestchen hakt ab. Es gibt keine Werkzeugleiste, weil man beim
   Schreiben nie den Stift wechselt.

UND: NIEMAND SIEHT DIE NOTIZEN EINES ANDEREN. Auch DogFather nicht.
Es gibt in workspace-notizen.js keinen siehtAlles()-Zweig, keinen
Umschalter, keine fremde Liste -- jede Abfrage hat person_id = ? fest
eingebaut. Die Kachel steht deshalb in „Fuer dich" und nicht in
„Taeglich": Die Gruppe sagt die wichtigste Eigenschaft, bevor man sie
anfasst.

NUR AUF DER TEAM-ADRESSE. Auf der Agenturadresse ist die Seite ein
404 -- auch fuer DogFather. Das ist dieselbe Trennung wie bei Chat,
Kalender und Aufgaben, und sie steht an zwei Stellen: in
GEHOERT_ZU_ADRESSE (die Datei) und in der Schnittstelle (die Daten).
Die Seite ist nur HTML; die Daten sind die Sache.

Dazu: sechs Papierfarben, Anheften, Suche mit Hervorhebung im Text,
Papierkorb mit dreissig Tagen und einem Eintrag in der
Aufbewahrungsliste (ohne den waere die Frist ein Satz in einem
Kommentar -- genau das ist dem Support am 24.09. passiert).

=================================================================
EIN FUND BEIM BAUEN, DER ALLEN GEHOERT
=================================================================

DELETE /workspace/api/notizen/:id gab es schon -- in
workspace-aufgaben.js, fuer die Notizen AN einer Aufgabe. Weil jener
Router frueher eingehaengt ist, hat er jeden Loeschversuch des Blocks
abgefangen und mit 404 beantwortet.

Von aussen sah das aus wie ein Fehler im neuen Modul: Anlegen ging,
Aendern ging, Loeschen nicht. Man sucht dann im eigenen Code, und dort
ist nichts. Express meldet so etwas nicht -- es nimmt die erste Route,
die passt, und schweigt ueber die zweite.

Der Block liegt jetzt unter /workspace/api/notizblock. Und
pruef-notizen geht seitdem den Routenbaum von express durch und meldet
jedes Paar aus Methode und Pfad, das zweimal vergeben ist. Gemessen:
307 Wege, keine Dublette. Die Pruefung gilt fuers ganze Haus, auch
wenn sie in dieser Datei steht -- hier ist sie gefunden worden.

Nebenbei berichtigt: pruef-crew-adresse verlangte von jedem Eintrag
der Haustafel HTTP 200 mit Inhalt. Das stimmte, solange dort nur
oeffentliche Dateien standen. notizen.html ist die erste Seite hinter
der Anmeldung -- sie antwortet mit 302, und das ist richtig. Gefragt
wird jetzt, was die Tafel wirklich meint: GIBT es das hier.

GEMESSEN, alles nach den Aenderungen:

  pruef-notizen             76 Punkte, 0 Fehler (neu)
  pruef-kachelfarben        31 Punkte, 0 Fehler (vorher 26)
  pruef-kachel-universum    13 Punkte, 0 Fehler
  pruef-crew-adresse       157 Punkte, 0 Fehler
  pruef-buehne             230 Punkte, 0 Fehler -- notizen.html neu in
                           der Liste, schlechtester Kontrast 6,73:1,
                           also 50 % ueber der Grenze
  pruef-rechtetafel, -haus-seiten, -struktur, -css-klassen,
  -jeder-hat-eine-seite, -workspace-seiten, -kachelraster,
  -rueckmeldung            alle 0 Fehler

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-26 12:42:59 +02:00
DogFatherGitandClaude Opus 5 80988f2d23 Berichtigt: Die Rechnung hat zwei ausdrueckliche Wuensche ueberfahren
Der Commit davor hat alle 45 Kachelfarben neu verteilt, um acht fast
gleiche Paare zu trennen. Das Ergebnis war rechnerisch besser und
praktisch falsch. pruef-kachelfarben hat sechs Fehler gemeldet:

  Ton 38  #ff1a1a -> #ff241e   „nur die soll knall rot sein!!!"
  Ton 44  #a8d8ff -> #90c3ff   „soll auch babyblau sein mit bissl lila"
  Ton 40, 10, 33          unter die Buntheitsgrenze von 0,12 gedrueckt
  und die Regenbogenkachel zeigte noch die 32 alten Farben

Beide Farben standen mit Datum, Zitat und Begruendung in der Pruefung.
Ich habe sie nicht gelesen, weil ich ein GLOBALES Ziel optimiert habe
-- „alle 45 moeglichst weit auseinander" -- und eine globale Rechnung
kennt keine Einzelfaelle.

=== DIE LEHRE IST NICHT „DIE RECHNUNG WAR FALSCH" ===

Sondern: Eine Gesamtloesung fuer ein LOKALES Problem bezahlt man mit
allem, was an den nicht betroffenen Stellen schon richtig war. Acht
Paare standen zu eng. Verschoben wurden 45.

Der zweite Anlauf (tools/_toene-reparieren.mjs) macht es umgekehrt:
Solange ein Paar zu eng steht, wird das engste genommen und EINER der
beiden auf die naechste erlaubte Farbe geschoben. Sonst nichts.

Und dabei kam das Beste des Tages heraus -- gemessen, nicht geahnt:
Von den 45 Toenen tragen nur 33 eine Kachel, zwoelf stehen bereit. In
JEDEM der acht zu engen Paare ist mindestens einer dieser zwoelf
dabei. Wer den Unbenutzten verschiebt, loest dasselbe Problem, ohne
dass sich fuer irgendjemanden auch nur eine Kachel veraendert.

  kleinster Abstand   0,0154  ->  0,0940
  Paare unter 0,09        14  ->  0
  veraendert                       14 von 45
  davon in Gebrauch                 4 -- und zwar um 0,003 bis 0,012

Vier Zehntausendstel OKLab sind nicht zu sehen. Es gibt also KEINE
Kachel, die ihre Farbe wechselt. Das ist mehr als Bequemlichkeit: Wer
zwei Jahre lang „das Tuerkise" angesteuert hat, sucht danach, wenn es
plötzlich rosa ist.

=== UND DIE WUENSCHE STEHEN JETZT DORT, WO GERECHNET WIRD ===

Die Liste FESTGELEGT ist von server/pruef-kachelfarben.mjs nach
tools/kachelton-regeln.mjs gewandert -- neben die Schwellen, aus
genau demselben Grund, aus dem die Schwellen dort stehen.

In der Pruefung konnte sie nur EINES: eine Abweichung melden, nachdem
sie passiert ist. Das hat sie getan, und das ist ihr Verdienst. Aber
eine Bedingung, die erst NACH dem Schaden spricht, ist die schwaechere
Form. Wer die Farben rechnet, soll gar nicht erst die Moeglichkeit
haben, sie zu verschieben -- das Werkzeug liest die Liste jetzt selbst
und setzt festgelegte Toene sogar zurueck, wenn es sie verschoben
vorfindet.

Dasselbe gilt fuer die Buntheitsgrenze: Sie kommt aus der Regeldatei,
und sie gilt nur fuer benutzte Toene -- so, wie die Pruefung sie
anwendet. Das ist nicht Nachgiebigkeit, sondern Rechnung: Mit
Buntheit >= 0,12 fuer ALLE 45 ist ein Mindestabstand von 0,09
nachweislich unmoeglich (Decke 0,0853). Die zwoelf unbenutzten duerfen
blasser sein und nehmen genau den Druck aus dem engen
Blau-Tuerkis-Bereich, an dem der erste Anlauf gescheitert ist.

GEMESSEN: pruef-kachelfarben 26 Pruefungen, 0 Fehler (vorher 26 mit
6 Fehlern). pruef-kachel-universum 13 Pruefungen, 0 Fehler.
Regenbogenkachel mit tools/kachel-regenbogen.mjs neu geschrieben --
99 Punkte in drei Groessen, je 33 Farben.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-25 23:44:40 +02:00
DogFatherGitandClaude Opus 5 257c01b8f0 Support: Babyblau mit Lila, und der Melder bekommt seine Knoepfe wirklich
Nachtrag zu cebdd88e. Ein Bildschirmfoto der fertigen Seite hat drei
Dinge gezeigt, die keine Pruefung sehen konnte.

1. DIE KACHEL WAR IMMER NOCH ORANGE.

   Filipe: "die hauptfarbe der kachel soll auch babyblau sein mit bissl
   lila." Die Seite trug zwar `--akzent: #a8d8ff`, aber der Kopf faerbt
   sich ueber `--ton` -- und der stand am body auf Ton 44, dem Orange
   vom 24.09. Die Variable war gesetzt und wirkungslos.

   Ton 44 ist jetzt #a8d8ff. WEIL DIE FARBE DIESMAL AUS EINEM WUNSCH
   kam und nicht aus einer Rechnung, wurde sie nachgemessen:

     Kontrast gegen den dunklen Grund   12,46:1   (Hausgrenze 4,5)
     Abstand zur naechsten Kachelfarbe  0,1125    (Ton 15)
     Engstes Paar im Haus ohnehin       0,0154
     -> 7,3-fach weiter weg als das schwaechste Glied

   Babyblau haelt die Buntheitsgrenze (0,12) NICHT und kann sie nicht
   halten -- das liegt am Wort. Nachgemessen mit einer Suche ueber den
   ganzen Blaubereich: Es gibt KEINE Farbe, die gleichzeitig babyblau
   aussieht, Buntheit >= 0,12 und Abstand >= 0,09 schafft; der beste
   Kandidat kommt auf 0,075 Abstand. Der Blaubereich ist von sechs
   Toenen besetzt.

   DIE GRENZE WURDE DESHALB NICHT GESENKT, sondern BENANNT ausgenommen
   (`blassErlaubt` in pruef-kachelfarben). Eine gesenkte Grenze gaelte
   fuer alle 45 Toene; eine benannte gilt fuer eine und steht mit
   ihrem Grund da. Und sie kostet etwas: Wer blass sein darf, muss
   beim Abstand >= 0,10 halten -- gemessen, nicht versprochen, mit
   Gegenprobe.

   NEBENBEI ZWEI ALTE ROTE BEHOBEN: Die Prüfung war seit dem 24.09.
   rot (engstes Paar 0,0862 zwischen Ton 41 und 45, und zwei Farben in
   der Regenbogenkachel stimmten nicht mehr). Ton 45 neu gerechnet
   (0,0914) und die Kachel nachgezogen. 22 -> 26 Pruefungen, 0 Fehler.

2. DIE LEITUNG SAH DIE KNOEPFE DES MELDERS.

   Der Server lehnte sie richtig mit 404 ab -- die Karte bot sie ihr
   trotzdem an. `darf_bestaetigen` war eine Aussage ueber die MELDUNG
   statt ueber den BETRACHTER. Zwei Knoepfe, die nur eine Fehlermeldung
   koennen, sind schlimmer als gar keine.

   Jetzt fragen Route UND Anzeige dieselbe Funktion `darfBestaetigen`.
   Es ist ausdruecklich "ist der Melder" und nicht "ist nicht Leitung":
   Die Leitung darf ihre EIGENE Meldung bestaetigen, nur keine fremde.

   Und die Leitung sieht bei "wartet" jetzt, wer dran ist -- "Liegt bei
   Miss" mit ruhig atmendem Punkt, dazu "Noch etwas nachschicken ..."
   statt "Behoben - nachfragen ...". Sie hat ja schon nachgefragt.

3. NACHLEGEN HAETTE DEN VERLAUF VERDOPPELT.

   Antwortet die Leitung ein zweites Mal, waehrend die Meldung beim
   Melder liegt, entstand eine ZWEITE Zeile "Runde 1" -- und sein
   spaeteres Urteil haette beide gleichzeitig beschriftet. Jetzt
   ersetzt ON CONFLICT die Antwort in derselben Runde.

   DER EIGENTLICHE FUND STECKTE IM INDEX: `CREATE UNIQUE INDEX IF NOT
   EXISTS` unter dem alten Namen tut auf dem Server NICHTS -- dort gibt
   es den Namen schon, als gewoehnlichen Index, und IF NOT EXISTS
   sieht nur den Namen, nicht die Bauart. Der Index waere nie eindeutig
   geworden, ON CONFLICT haette kein Ziel gefunden, und das Nachlegen
   waere abgebrochen -- genau dort, wo lokal alles gruen ist, weil jede
   Pruefung ihre Datenbank frisch anlegt. Gefunden beim Durchspielen
   auf einer KOPIE der echten Datenbank. Der alte Index wird jetzt
   ausdruecklich weggenommen, der neue heisst anders.

GEMESSEN:
- pruef-support 59 -> 63 Pruefungen, 0 Fehler (darunter: die Leitung
  bekommt die Knoepfe NICHT, und Nachlegen laesst EINE Runde stehen).
- Die Index-Umstellung auf einer Kopie der echten Datenbank
  durchgespielt: alter Index weg, neuer eindeutig, ON CONFLICT trifft.
- pruef-kachelfarben 26/0, pruef-css-klassen, pruef-deutsche-texte: gruen.
- server/mess-support-runde.mjs (neu) macht vier Bilder: Leitung,
  Melder, Melder auf dem Handy, und den Verlauf nach zwei Runden.
  Es misst den "wer ist dran"-Hinweis ausdruecklich mit -- der war
  einmal stumm ausgefallen (before() auf einem Element ohne
  Elternknoten tut nichts, ohne Fehlermeldung).

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-25 05:10:58 +02:00
DogFatherGitandClaude Opus 5 b79b75ab70 A3: Calls & Protokolle gibt es jetzt auch bei Team Dogi
Filipe, 22.09.2026: „ich will diese kachel vom workspace auch im team
dogi seite. ich will dass jeder immer nur seine eigenen sachen von
seinem kalender sieht mehr nicht. perfektioniere das bitte. jeder der
einen kalender hat soll auch sowas haben danke."

GEMESSEN, BEVOR GEBAUT WURDE:

    Rolle   Kacheln   Kalender   Calls
    admin      31       ja        NEIN
    hand       31       ja        NEIN
    linke      30       ja        NEIN
    modi       26       ja        NEIN
    gast       12       nein      nein

Die Community hat keinen Kalender. Sein Satz „jeder der einen kalender
hat" beschreibt die Lage also genau -- „alle bekommen es" waere falsch
gewesen.

ES IST EINE REGEL, KEINE VIERFACHE EINTRAGUNG. Hinter jeden Kalender
einer Liste kommt eine Calls-Kachel, in derselben Gruppe. Vier Stellen
von Hand zu pflegen waere die Stelle, an der es beim naechsten neuen
Rollenzuschnitt auseinanderlaeuft. Erkannt wird der Kalender am ZIEL,
nicht am Namen -- Namen sind im Haus schon gewandert, Ziele nicht.

„JEDER SIEHT NUR SEINE EIGENEN" GAB ES SCHON, seit dem 07.09.
(`termineSichtbar`). Es wird jetzt aber nicht mehr GELESEN, sondern am
laufenden Server ausprobiert: Zwei Leute legen je einen Call an und
sehen den des anderen nicht -- auch DogFather nicht. Wer als
Teilnehmer eingetragen ist, sieht ihn schon; das ist die Gegenprobe,
ohne die „niemand sieht etwas" auch bei einer kaputten Liste gruen
waere.

DER TON WAR EINE RECHNUNG UEBER DREI ANLAEUFE

  1. Ton 15, derselbe wie im anderen Haus. Als Zahl frei, auf dem
     BILDSCHIRM nicht: 0,0139 zu „Was ansteht", unter der Grenze 0,02.
  2. Ton 16, ausgerechnet als der entfernteste brauchbare. Die Pruefung
     kennt aber zwei Regeln mehr, die ich nicht beruecksichtigt hatte:
     Rohabstand >= 0,090 (er lag bei 0,0854) und Buntheit >= 0,12 (er
     lag bei 0,116). Und Ton 16 gehoert im anderen Haus zu
     „Start-Check" -- ihn umzufaerben haette dort eine Kachel
     veraendert, nach der niemand gefragt hat.
  3. Unter allen elf freien Toenen erfuellte KEINER alle drei Regeln.
     Eine 32. Kachel braucht einen 32. Ton. Also einen neuen gerechnet,
     additiv, ohne einen vorhandenen anzufassen:

         Ton 43  #027afb   Abstand 0,0925  Buntheit 0,212  Kontrast 4,63:1

     Es bleibt ein Blau -- die Kachel ist damit als dieselbe
     wiedererkennbar wie im anderen Haus.

EIN WIDERSPRUCH IM HAUS, DABEI GEFUNDEN
`tools/kachel-farbe-einzeln.mjs` suchte die Buntheit von 0,30 bis
herunter auf 0,04, `pruef-kachelfarben` verlangt mindestens 0,12. Das
Werkzeug lieferte fuer Ton 43 zuerst ein blasses #bcdbff (Buntheit
0,060) mit dem besten Abstand weit und breit -- und die Pruefung lehnte
es ab. Beide hatten recht; zwei Zahlen fuer dieselbe Regel in zwei
Dateien, die nichts voneinander wissen. Ein Werkzeug, dessen
Vorschlaege die Pruefung danach verwirft, ist schlimmer als keines --
man haelt das Ergebnis fuer fertig.

Die Schwellen stehen jetzt in tools/kachelton-regeln.mjs, und beide
Seiten lesen sie von dort.

NEU: server/pruef-calls-rudel.mjs, 32/0. Sie prueft die REGEL (Calls
genau dann, wenn Kalender -- und direkt dahinter, in derselben
Gruppe), dass Kachel und Zutrittsrecht zusammenpassen, und am
laufenden Server, dass jeder nur seine eigenen sieht.

pruef-kachelfarben 22/0, pruef-start-ansicht, pruef-willkommen,
pruef-struktur, pruef-treff, pruef-modi-checkliste gruen.

ZWEI ALTLASTEN DABEI GEFUNDEN, nicht von dieser Aenderung und noch
nicht behoben (beide vorher schon rot, nachgemessen mit `git stash`):
  pruef-kachelraster        3 Fehler (erwartet acht Community-Kacheln,
                            es sind zehn)
  pruef-jeder-hat-eine-seite 1 Fehler („fehlt: linke" -- die Rolle kam
                            dazu, die Pruefung nicht mit)

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-22 15:15:00 +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 e12392a289 Die Kachelfarben kommen jetzt WIRKLICH auf dem Bildschirm an
Filipe: "ich raste aus im ernst, was verstehst du nicht darunter wenn
ich sage das alle kacheln eine andere farbe haben sollen ich seh
immer wieder sehr viele die einfach komplett die gleiche farbe haben."

ER HATTE RECHT, UND MEINE PRUEFUNG WAR TROTZDEM GRUEN.
Der Grund war ein Messfehler, und zwar meiner: pruef-kachelfarben las
`--ton` aus start.css -- die ROHFARBE. Die lag zwischen allen 31
Kacheln weit auseinander (0,0978 in OKLab). Nur steht sie so nie auf
dem Bildschirm.

GEMESSEN an echten Bildpunkten (neu: tools/kachel-echtfarbe.mjs):
  Rohfarben:              0,0978 auseinander
  Auf dem Bildschirm:     0,0141
  Es kamen an:            14,4 Prozent
  Fuer ein Auge gleich:   ACHT Paare

Drei Stellen haben die Farbe geschluckt, alle in .kachel:
  1. Eine Wolke mit 16 Prozent -- in immer DEMSELBEN Blau, auf jeder
     Kachel. Der staerkste Gleichmacher der ganzen Wand. Sie traegt
     jetzt den Ton der Kachel.
  2. Die Vignette legte bis zu 55 Prozent Dunkelblau darueber.
  3. Der Grund trug den Ton zu 24 Prozent und ging ab 58 Prozent in
     fast reines Schwarz. Zwei Drittel jeder Kachel waren damit
     dieselbe Farbe, egal welcher Ton darueber stand.

Danach: 51,1 Prozent kamen an, NULL ununterscheidbare Paare.

UND DANN HAETTE ICH EINEN FEHLER GEGEN EINEN ANDEREN GETAUSCHT.
Gemessen an jedem einzelnen Kacheltext: VORHER war 1 von 31 unter
4,5:1, DANACH 27 von 31. Also genau das, was Filipe schon zweimal
gemeldet hat ("man bekommt fast nichts gelesen"). Kein Messwert hat
es angezeigt -- pruef-buehne nimmt Stichproben und traf die
Kacheltexte nicht.

Behoben mit einem Lesesaum: ein dunkler Verlauf VON UNTEN, der genau
den Streifen abdunkelt, auf dem gelesen wird, und die oberen zwei
Drittel in Ruhe laesst. Dasselbe Mittel, mit dem jede Bildunterschrift
auf einem Foto lesbar gemacht wird.

  Texte unter 4,5:1:   1 -> 27 -> 0
  Farbe kommt an:      14,4 % -> 51,1 % -> 36,5 %

VERTRAULICH MELDEN IST JETZT KNALLROT.
Filipe: "nicht die kachel draussen soll rot sein sondern die kachel
vertraulich melden nur die soll knall rot sein!!!" Ich hatte screen5
und screen6 vertauscht. Ringtausch ohne neue Farbe:
  Vertraulich melden  28 -> 38  (#ff1a1a, knallrot)
  Draussen            38 -> 39  (die Farbe, die Regeln & Hilfe hatte)
  Regeln & Hilfe      39 -> 28  (das frei gewordene Gruen)

NEU, UND DER EIGENTLICHE LERNEFFEKT:
server/helfer-kachel-echtfarbe.mjs misst beides in EINER Messung --
Farbunterschied UND Lesbarkeit. Wer sie trennt, verbessert das eine
und verliert das andere; genau das ist heute passiert. Benutzt von
der Pruefung und vom Werkzeug, damit es nur eine Fassung gibt.

pruef-kachelfarben 18/0 (war 13), davon fuenf am echten Bildschirm:
  - kein Paar sieht auf dem Bildschirm gleich aus (0,0357)
  - mindestens ein Drittel der Rohfarbe kommt an (36,5 %)
  - jeder Kacheltext erreicht 4,5:1 (schlechtester: 4,80:1)
Mit drittem Ausgang: kein Browser heisst "konnte nicht nachsehen",
nicht "in Ordnung".

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-22 10:26:49 +02:00
DogFatherGitandClaude Opus 5 227c6c0425 screen5 und screen4: zwei Farben gesetzt, 14 auseinandergezogen
screen5 (ausdruecklich VOR screen4, wie gewuenscht):
  "Vertraulich melden" traegt jetzt Ton 28 -- die Farbe, die "Regeln
  & Hilfe" hatte. Beide gehoeren zusammen: Wer Hilfe sucht, landet
  bei einem von beiden. "Regeln & Hilfe" bekam dafuer einen eigenen
  Ton; zwei Kacheln mit derselben Farbe in derselben Ansicht waeren
  genau das, was screen4 abschaffen soll.
  "Draussen" ist knallrot: Ton 38 = #ff1a1a, voll gesaettigt,
  Kontrast 4,84:1 gegen den Grund. Gemessen, nicht geschaetzt -- von
  zehn Rotwerten zwischen #ff0000 und #ff5555 erfuellen alle die
  4,5:1, dieser ist der knalligste, der auf dunklem Grund nicht
  flimmert. Er traegt ab 20 Uhr den LIVE-Punkt.
  Beide sind ab jetzt GESETZT: pruef-kachelfarben wird rot, wenn ein
  Farblauf sie anfasst. Eine Festlegung, die nur im Kommentar steht,
  ist eine Bitte.

screen4: neues Werkzeug tools/kachel-farben-entzerren.mjs.
  Der Unterschied zu den zwei vorhandenen: Es rechnet nur mit den
  BENUTZTEN Toenen. In start.css stehen 42, benutzt werden 31 -- die
  anderen Werkzeuge weichen also Farben aus, die kein Mensch sieht,
  und machen dadurch die Abstaende zwischen den sichtbaren unnoetig
  klein. Welche benutzt werden, wird aus den Kachellisten ABGELEITET.
  Von jedem aehnlichen Paar aendert sich genau EINER -- der, der
  nicht gesetzt ist.
  Ergebnis: engstes Paar 0,0741 -> 0,0978 (Faktor 1,32), 14 Toene
  geaendert, alle 31 erreichen 4,5:1.

ZWEI DINGE, DIE ERST DAS MESSEN GEZEIGT HAT
1. Der erste Lauf schlug fuer "Dateien" ein #ffe5ae vor -- Buntheit
   0,076, ein helles Creme. Rechnerisch die beste Stelle im Farbraum,
   auf dem Bildschirm genau das, was Filipe seit Wochen abschafft.
   Mindestbuntheit eingebaut, Schwelle GEMESSEN: Median aller Toene
   0,168, die fuenf blassesten 0,064-0,088. 0,12 liegt dazwischen.
2. Die Abstandsrechnung fasst einen Ton nie an, der weit weg von
   allen liegt -- auch wenn er blass ist. So blieben drei benutzte
   Toene unter 0,12 stehen. Zweite Runde: jeder blasse wird kraeftig
   gemacht, solange das Minimum ueber 0,095 bleibt. Gemessener Preis
   0,1028 -> 0,0978, also 5 Prozent; auf dem Bildschirm nicht zu
   sehen, waehrend Filipes Klage ueber helle Kacheln konkret ist.

NEU: pruef-kachelfarben 13/0 -- getrennt, eindeutig je Ansicht,
festgelegt, lesbar und nicht blass. Mit vier Gegenproben, damit sie
auch rot werden KANN.
NEU: tools/farben-blick.mjs -- sieht die Wand mit echten Augen an und
misst das, was eine Abstandstabelle nicht beantwortet: ob zwei
NEBENEINANDER liegende Kacheln aehnlich aussehen. Gemessen bei
DogFather und Community: kein Nachbarpaar unter 0,09.

Co-Authored-By: Claude Opus 5 <[email protected]>
2026-09-22 09:21:54 +02:00