d26cdc78ff88ee7edc339883e0d53213ec208fed
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  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]>
|
||
|
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]>
|
||
|
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]>
|
||
|
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]> |