05f262eb6117e99e91c6d1fba323ee23181ebd24
159
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
05f262eb61 |
Modis verteilen Aufgaben statt sie zu bekommen -- und Angebote zur Entscheidung
Die drei Beurteilungs-Bereiche liefen bisher in die falsche Richtung: Sie
bewerteten die Modis. Filipe: "die modis sind ja da um mir zu helfen."
Also umgedreht.
WAS SICH GEDREHT HAT
- Alle 101 Punkte sind jetzt Beobachtungen ueber den Stream, nicht
Pflichten des Modis ("Der Ton blieb verstaendlich" statt "Ton geprueft").
- Nur der Modi selbst drueckt auf seiner Liste. Wer sonst darauf zeigt,
bekommt 403 und den Weg zur Team-Lage -- bewerten wird hier niemand.
- "Verbessern" landet als Eingang bei DogFather. Ein Klick macht daraus
eine Aufgabe mit dem Satz des Modis im Text, oder eine Absage mit Grund.
Beides schreibt eine Nachricht zurueck, damit der Modi sieht: angekommen.
ANGEBOTE
Neuer Bereich, in dem Modis planen und vorschlagen: Nutzen und Aufwand
statt Bewertung und Dringlichkeit, dazu ein Feld "was DogFather danach
tun muss". Wird ein Angebot angenommen, entstehen zwei Aufgaben -- eine
beim Modi zum Umsetzen, eine bei DogFather aus genau diesem Feld.
GEMESSEN
pruef-modi-checkliste 59 Pruefungen, 0 Fehler (neu geschrieben)
pruef-rollen 245 statt 244 -- der Zuwachs ist die neue
Angebote-Kachel, alle 11 Modi-Kacheln kommen an
pruef-modi-ideen 30, pruef-modi-verborgen 75, pruef-bereiche-lesend: gruen
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
6122ea6972 |
Eigene Checklisten fuer die Modis -- und eine Seite fuer euch beide
Wunsch Filipe (10.09.2026): *"diese kategorien mussen auf dieser seite auch noch auf die modis perfektionniert werden, da mussen lauter sachen sein die vanvan und ich danach verteilen können und da anpassen können ob gut oder nicht."* Und: *"da soll es eine kategorie geben für uns beide nur sonst keinen wo wir dass alles sehen und behandeln können."* === TEIL 1: SEIN EIGENER PUNKTESATZ === 101 Punkte in workspace-modi-punkte.js -- Live-Ablauf 40, Community 36, Technik 25. Die vorhandenen sagen "Upload messen", "Sendeplan festlegen", "Verweildauer vergleichen": Ein Modi sendet nicht, er moderiert. Ihm dieselbe Liste vorzulegen hiesse, ihn an Dingen zu messen, die nicht seine Arbeit sind. DIESELBE EINTEILUNG (Vor/Waehrend/Nach usw.), nur andere Punkte darin. Zwei verschiedene Einteilungen waeren zwei Dinge zum Lernen statt einem, und die Oberflaeche kaeme ohne Umbau nicht damit zurecht. DIE SCHLUESSEL BEGINNEN MIT "m-". Der Stand haengt an (bereich, schluessel, person) -- ohne Praefix koennte ein Modi-Punkt eines Tages denselben Namen tragen wie ein Creator-Punkt und dessen Bewertung erben. BEIDE SAETZE STEHEN IN GUELTIG. Stuenden dort nur die Creator-Punkte, kaeme die Liste an und jeder Klick darauf brachte einen 404 -- die Sorte Fehler, die man erst beim Benutzen merkt. Ein Modi sieht SEINE Liste, ohne jemanden auszuwaehlen (wie ein Creator), und bewertet sich nicht selbst. Ohne diese Zeile waere er in den Betreuer-Zweig gefallen, haette eine Auswahl fremder Creator vorgesetzt bekommen und seine eigene Liste gar nicht gesehen. DER HEIKELSTE PUNKT WAR EIN ANDERER: `darfCreator` sagt bei siehtAlles() pauschal ja -- und darin steckt auch Spicy Media. Wer die Modi-Auswahl daran haengt, oeffnet sie ihr nebenbei mit, ohne dass an der Stelle etwas davon steht. Deshalb eine eigene Regel (darfPerson), und die Pruefung versucht es ueber die Liste, ueber die Adresse UND ueber das Bewerten. Die Auswahl heisst bei der DogFather-Rolle jetzt "Person" statt "Creator" -- ein Feld namens "Creator", in dem ein Modi steht, ist falsch beschriftet. Das Wort kommt vom Server; ein Rollenvergleich im Browser waere die Stelle, an der der Name in einer ausgelieferten Datei landet. === TEIL 2: DIE GEMEINSAME SEITE === teamlage.html, nur fuer die DogFather-Rolle -- also Filipe und VanVan. Fuer alle anderen gibt es weder die Kachel noch die Seite noch die Schnittstelle (404, wie bei einer Adresse, die es nicht gibt). Zwei Schloesser, absichtlich: die Schranke und die Abfrage. Faellt eines weg, haelt das andere. Je Person: offene und ueberfaellige Aufgaben, beigetragene Ideen, Rueckmeldungen, und je Bereich gut/verbessern/offen. Jede Zeile fuehrt in den Bereich -- MIT DER PERSON VORAUSGEWAEHLT. Dafuer liest die Checkliste jetzt `creator_id` aus der Adresse; ohne das landet man auf der erstbesten Person und weiss beim zweiten Suchen nicht mehr, warum man hier war. SIE ZAEHLT, SIE BEWERTET NICHT. Bewertet wird dort, wo die Punkte stehen. Eine zweite Stelle dafuer waere eine zweite Stelle, an der es auseinanderlaeuft. UND SIE IST KEINE UEBERWACHUNG. Ueber team.html steht schon, dass eine Seite mit Zahlen ueber Kollegen als Kontrolle gelesen wird -- und dann arbeitet niemand mehr offen damit. "Offen" heisst hier deshalb ausdruecklich: darueber habt ihr noch nicht geredet. Eine Merkliste fuer euch beide, keine Note. ALLES IN VIER ABFRAGEN, nicht vier je Person -- bei zehn Modis waeren das vierzig. Denselben Fehler hat das Haus bei den Terminen schon gemacht und ihn dort vermerkt. KEINE NEUEN CSS-KLASSEN: Fuer genau diese Karten gibt es sie schon (tperson, tz, schritt -- aus team.html). Elf neue haetten gepflegt werden muessen fuer ein Aussehen, das bereits da ist. ZUSATZKACHELN sind ein neuer, kleiner Mechanismus: `bereiche` ERSETZT die Liste im Browser (fuer Rollen, die dort nicht vorkommen), `bereiche_zusatz` HAENGT an. Gebraucht fuer Kacheln, die nur eine einzige Rolle bekommt -- in bereiche.js duerften sie nicht stehen, weil eine Kachel, die nur bei einem erscheint, die Frage aufwirft, fuer wen sie ist. Findet sich die genannte Gruppe nicht, wird eine eigene angelegt: Sonst faellt die Kachel lautlos weg, sobald jemand eine Gruppe umbenennt. EHRLICH ZUM UMFANG: Technik ist mit 25 Punkten der duennste Bereich. Das ist Absicht -- der technische Spielraum eines Moderators ist kleiner als der eines Streamers. Auffuellen haette Fuellmaterial in eine Liste gebracht, die Filipe und VanVan durchgehen muessen. GEPRUEFT: pruef-modi-checkliste (39, neu), pruef-rollen (244 statt 243 -- die neue Kachel wird angeklickt und muss ankommen), pruef-modi-verborgen (75), pruef-workspace-seiten. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
fb45072d25 |
Die Live-Checkliste am Termin -- ein Knopf, keine Automatik
KAPITEL 5.7 UND 11: "Wird pro Live-Termin als Checkliste erzeugt und den
eingeteilten Modis zugewiesen."
DAS DOKUMENT SAGT "AUTOMATISCH", FILIPE HAT SICH FUER EINEN KNOPF
ENTSCHIEDEN (10.09.2026). Vierzehn Aufgaben, die bei jedem Termin von
selbst erscheinen, ueberrumpeln -- und was ungefragt Dinge anlegt, ist
schwer wieder loszuwerden. Wer einen Termin nur zum Merken eintraegt,
haette danach aufzuraeumen.
Ein Druck erzeugt die vierzehn Punkte aus Kapitel 11 (fuenf vorher,
fuenf waehrend, vier danach), mit dem TERMINTAG als Frist -- eine
Vorbereitung, die nach dem Live faellig wird, ist keine -- verteilt auf
die eingeteilten Modis, jede mit ihrer Kategorie.
DREI STELLEN, AN DENEN SO ETWAS ERFAHRUNGSGEMAESS KIPPT. Alle drei
vorher benannt, dann gemessen:
* ZWEIMAL DRUECKEN. Der zweite Druck legt nichts an. Und der Knopf
zeigt die Zahl ("Checkliste (14)") -- sonst drueckt man ihn zur
Sicherheit noch einmal und weiss hinterher nicht, ob doppelt
angelegt wurde.
* DAS ZWEITE LIVE. Hier waere der Fehler teuer: Die Kennung, an der
"schon uebernommen" erkannt wird, traegt jetzt die TERMINNUMMER
(`mk-vor-technik#42`). Ohne sie stuende beim zweiten Live alles als
erledigt da, und niemand bekaeme seine Liste. Geprueft mit zwei
echten Terminen.
* EIN TERMIN OHNE EINGETEILTE MODIS. Vierzehn herrenlose Aufgaben
waeren schlimmer als keine -- stattdessen kommt eine Rueckfrage.
KEIN ROLLENNAME IM BROWSER, wie ueberall: Der Server schickt ein Ja/Nein
("gehoert der Knopf hierhin") und eine Zahl ("wie viele stehen schon").
Aus einer Zahl laesst sich nichts schliessen. Ein Manager bekommt den
Knopf gar nicht erst -- und wenn er es ueber die Schnittstelle versucht,
wortgleich dieselbe Absage wie fuer eine erfundene Art.
DIE ZAEHLUNG LAEUFT IN EINER ABFRAGE fuer alle Termine im Blick, nicht
je Zeile eine. Bei dreissig Terminen waeren das dreissig Abfragen -- den
Fehler hat das Haus bei den Teilnehmern schon einmal gemacht und drei
Zeilen darueber ausdruecklich vermerkt.
DIE TERMINE IN DER PRUEFUNG LIEGEN RELATIV in der Zukunft (+3 und +10
Tage). Ein festes Datum holt der Kalender irgendwann ein, und dann ist
die Pruefung rot, ohne dass etwas kaputt ist -- genau so ist es am
06.09.2026 bei der Oeffnungsschranke des Shops passiert.
GEPRUEFT: pruef-modi-livecheck (16, neu), pruef-kalender, pruef-serien
(69), pruef-vorlagen, pruef-modi-katalog (29).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
e1608ee783 |
Das Ideen-Board -- und fuenf Kacheln, die ins Leere fuehrten
KAPITEL 5.6: "Sammelstelle fuer Content-, Live- und Community-Ideen mit
Priorisierung." Fast nichts davon musste neu gebaut werden: `eintraege`
hat Titel, Text, Status und `dringlichkeit` (hoch/mittel/niedrig) -- und
das IST die Priorisierung. Eine eigene Tabelle daneben waere eine VIERTE
Sichtbarkeitsregel gewesen; genau deren Vervielfaeltigung hat heute
schon ein Leck verursacht.
Der Bereich gehoert niemandem einzeln (`ohneCreatorBezug`) -- eine Idee
gehoert der Runde. KEIN `fuerAlle`: Das waere der naheliegende Griff
gewesen und der falsche, denn es heisst woertlich JEDER. Wer die
Sammlung sieht, entscheidet dieselbe Regel wie ueberall.
DER RISKANTE TEIL WAR DIE DATENBANK. Die erlaubten Bereiche stehen als
CHECK-Regel, und SQLite kann die nicht aendern -- die Tabelle muss neu
gebaut werden. Die alte Umstellung fuer 'agentur' schreibt dafuer den
ganzen Bauplan von Hand ab; im Kommentar dort steht, dass dabei schon
einmal drei Spalten vergessen wurden. Statt einer vierten Abschrift ist
die Fassung von heute Morgen jetzt tabellenunabhaengig
(checkListeErweitern): Spaltenliste aus der Tabelle, Sicherung vorher,
Zaehlung innerhalb der Transaktion.
UND DABEI WAERE EIN STILLER TOTALAUSFALL PASSIERT. Das Muster fuer den
Tabellenkopf stand in einem Template-Literal -- dort verschluckt
JavaScript den Backslash, aus `\s` wird `s`, das Muster hiess
"CREATE TABLEs+..." und traf nie etwas. Die Umstellung haette
SCHWEIGEND nichts getan: kein Fehler, kein Hinweis, nur ein Bereich, den
es nie gegeben haette. Im Quelltext war das nicht zu sehen; gefunden hat
es eine Messung. Jetzt steht dort gar kein Muster mehr -- alles vor der
ersten Klammer IST der Tabellenkopf, und das kann man nicht falsch
maskieren.
Die Pruefung baut deshalb eine ECHTE ALTE Tabelle und laesst die
Umstellung darauf laufen. Eine frische Datenbank bringt den Bereich
schon mit -- die Umstellung liefe gar nicht erst an, und alles waere
gruen, ohne das Riskante angesehen zu haben.
=== DER GROESSERE FUND ===
FUENF VON ZEHN MODI-KACHELN FUEHRTEN INS LEERE. Der Server hat eine
Liste, welche Rolle welche Seite oeffnen darf; bereich.html und
profil.html schlossen 'modi' aus. Vier Bereichs-Kacheln und das eigene
Profil leiteten wortlos auf die Startseite zurueck.
Der Rollen-Rundgang meldete sie trotzdem als "ok", und zu Recht: Eine
Umleitung ist kein Fehler. Die Seite laedt, keine rote Konsole, keine
4xx-Antwort. Sie ist nur eine ANDERE. Das ist eine eigene Fehlerklasse
-- nicht "kaputt", sondern "fuehrt woandershin" -- und sie faellt nur
dem auf, der die Anwendung benutzt und merkt, dass ein Knopf nichts tut.
Beinahe waere meine eigene Pruefung darauf hereingefallen: Sie fand auf
der zurueckgeleiteten Startseite das Wort "Ideen-Board" -- den Text der
KACHEL -- und hielt sie fuer das Board. Jetzt steht die Adresse in der
Bedingung.
DIE SPERRE DAGEGEN GILT AB SOFORT FUER ALLE: pruef-rollen klickt fuer
JEDE Rolle jede Kachel durch, die sie angeboten bekommt, und verlangt,
dass sie dort ankommt. Geprueft wird die Zusage der Startseite, nicht
eine Liste daneben -- eine Liste koennte selbst veralten. 113 -> 243
Pruefungen; der Zuwachs ist genau das.
Er hat im ersten Anlauf zwei weitere Loecher gefunden:
* "Mein Profil" war die falsche Seite. profil.html ist der
Creator-Entwicklungsplan und antwortet mit 404, wenn die Person kein
Creator ist. Die eigene Seite heisst steckbrief.html.
* content.html stand auf `null` ("jede angemeldete Rolle") -- mit der
neuen Rolle also auch sie. Die Seite laedt, ihre Schnittstelle gibt
404. Das ist die Kehrseite von "geschuetzt ist die Regel, nicht die
Ausnahme": Eine NEUE ROLLE erbt jedes `null` automatisch.
Und ein Modi kommt nur in SEINE Bereiche -- sonst waere er ueber die
Adresszeile in der Agentur-Ablage gelandet. Welche erlaubt sind, wird
aus seinen Kacheln abgeleitet statt danebengeschrieben.
=== KLEINERES, ABER SICHTBARES ===
Ueber dem Board stand "Betreuung" -- die Beschriftung fuer Akten, die
UEBER jemanden gefuehrt werden. Eine Sammelstelle ist das Gegenteil.
Aufgefallen auf dem Bildschirmfoto, wie so oft heute.
Der Farbton der Kachel ist nicht nach Gefuehl gewaehlt: Alle 22
vorhandenen waren belegt, also wurde der Abstand zu jedem ausgerechnet
und der genommen, der sich am deutlichsten unterscheidet, ohne grau zu
wirken (#5f8a9f, Abstand 127).
BEINAHE HAETTE ICH EIN LOCH REPARIERT, DAS ES NICHT GIBT: Meine Pruefung
meldete, die Suche verrate die Ideen an Spicy Media. Tatsaechlich fand
sie null Treffer -- die Pruefung hatte ihren EIGENEN Suchbegriff
wiedergefunden, weil die Antwort ihn im Feld `frage` zurueckspiegelt.
Gezaehlt wird jetzt, was gefunden wurde.
pruef-spicy erwartete den alten Wortlaut der Umstellungsmeldung. Sie
nennt jetzt Tabelle und Spalte statt "Rolle"; geprueft wird der Sinn,
nicht der Satz.
GEPRUEFT: pruef-modi-ideen (30, neu), pruef-rollen (243 statt 113),
pruef-modi-verborgen (75), pruef-modi-katalog (29), pruef-spicy (60),
pruef-css-klassen, pruef-start-ansicht.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
60e875814b |
Die 60 Aufgaben aus Teil 2 -- und kein Wort zu viel im Browser
Kapitel 14 des Anforderungsdokuments: "Alle Aufgaben dieses Katalogs
koennen 1:1 als Vorlagen in die App importiert werden -- inklusive
Kategorie, empfohlener Rolle und Frequenz. So ist das Aufgaben-Board ab
dem ersten Tag vollstaendig befuellt, statt leer zu starten."
DER KATALOG. 60 Aufgaben, Verteilung wie im Dokument: 12 Aufbau, 9
Alltag, 5 vor / 5 waehrend / 4 nach dem Live, 8 Content, 5 Woche, 5
Monat, 7 Community. Neun Etappen statt sechs Phasen -- Phase 3 zerfaellt
in Vor/Waehrend/Nach und Phase 5 in Woche/Monat, und das sind fuer den,
der davorsitzt, verschiedene Momente. "Waehrend des Lives" sucht man
nicht in derselben Liste wie "einmal im Monat".
Die TEXTE sind neu. Das Dokument nennt nur die Titel, und ein Titel
allein ("Eskalationsregeln definieren") sagt nicht, woran man erkennt,
dass man fertig ist. Jeder Satz nennt das EINE, was zaehlt -- nicht
drei, denn wer sich fuenf Dinge vornimmt, macht keines.
Uebernehmen legt eine ganz normale Aufgabe an, einzeln oder eine ganze
Etappe. Die Kategorie wandert mit: Ohne sie muesste man 60-mal von Hand
einsortieren, was im Dokument bereits danebensteht -- und niemand
merkte es, weil die Aufgabe ja da ist. Genau das prueft die neue
Pruefung ausdruecklich.
KEINE NEUE ADRESSE, kein neuer Feldname mit dem Rollennamen darin: Der
Katalog kommt unter "katalog" in der vorhandenen Antwort, das
Uebernehmen ueber die vorhandene Route mit einer neuen Art. Wer ihn
nicht bekommt, sieht `null` -- und ein Manager, der die Art trotzdem
schickt, bekommt WORTGLEICH dieselbe Absage wie fuer eine erfundene.
ZWEI SELBSTKORREKTUREN, beide von derselben Sorte:
* Die Kategorien waren auf ACHT zusammengefasst, begruendet damit,
dreizehn Knoepfe seien auf einem Handy unbedienbar. Gebaut ist aber
ein AUSWAHLFELD, keine Knopfleiste -- die Begruendung passte nicht
zu dem, was ich getan hatte, und haette eine Uebersetzungstabelle
noetig gemacht ("Branding gehoert zu Planung"), die spaeter niemand
nachvollzieht. Jetzt sind es die vierzehn des Dokuments, und jede
Aufgabe traegt genau die Kategorie, die danebensteht.
* Zwei Erwartungen in meiner eigenen Pruefung waren veraltet, beide
durch Aenderungen, die ich absichtlich gemacht hatte. Die eine
suchte woertlich nach "Clipping & Schnitt" -- nach dem Umbenennen
haette sie nach etwas gesucht, das es nicht mehr gibt, und waere
gruen gewesen, ohne etwas zu pruefen. Die Namen kommen jetzt aus
derselben Quelle wie die Oberflaeche.
UND WIEDER HAT ES DAS BILDSCHIRMFOTO GEZEIGT, nicht der Code: Die
Kopfleiste sagte auf jeder Seite "Creator Workspace" -- fuer jemanden,
der moderiert statt einen Kanal aufzubauen, der falsche Name. Sie folgt
jetzt demselben Weg wie die Zierzeile auf der Startseite. Nur der
Verweis wird umgeschrieben, der Seitenname dahinter bleibt; das
geschuetzte Leerzeichen ebenfalls, sonst faellt die Leiste auf schmalen
Handys in zwei Zeilen.
BEWUSST NICHT ANGEFASST: Im Hintergrundbild steht schwach "SPICY
MEDIA". Es ist kein Element im HTML, sondern in die buehne-*.webp
eingebacken -- dafuer braeuchte es einen zweiten Bildersatz. Nachgesehen
statt vermutet: Im DOM der Seite kommt der Text nicht vor.
GEPRUEFT: pruef-modi-katalog (29, neu), pruef-modi-kategorien (25),
pruef-modi-wortleck (4), pruef-rollen (113), pruef-kopf-messen,
pruef-vorlagen, pruef-aufgabenbrett.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
ede34fe386 |
Der Rollenname stand in zwei Dateien, die jeder bekommt
SELBST EINGEBAUT, EINE STUNDE VORHER. Beim Bau der Kategorien habe ich
SECHS Vergleiche und VIER Kommentare mit dem Rollennamen nach
assets/js/aufgaben.js und assets/js/start.js geschrieben -- waehrend ich
an anderer Stelle penibel darauf achtete, ihn herauszuhalten.
Alles unter workspace/ geht an JEDEN, der die Seite oeffnet. Ein Blick in
den Quelltext, und der ganze verborgene Zugang waere gefunden gewesen:
nicht wer ein Modi ist, aber dass es die Rolle ueberhaupt gibt -- und
genau das war Filipes Bedingung ("damit die von der workspace auch nicht
mal sehen dass die modis von mir einen eigenen zugang haben").
Gefunden habe ich es durch Nachsehen, nicht durch Nachdenken. Nachgedacht
hatte ich vorher schon, und zwar richtig -- beim Anzeigenamen und bei der
Rollenauswahl habe ich es sauber ueber den Server geloest. Eine Stunde
spaeter habe ich dieselbe Regel dreimal gebrochen, ohne es zu merken.
WAS AN DIE STELLE TRITT, dreimal derselbe Gedanke:
* Das Vorlagenbrett: /workspace/api/vorlagen liefert den Katalog jetzt
schlicht nicht an die Betroffenen. `if (!vorlagen) return` laesst das
Brett dann verborgen -- dieselbe Wirkung, ohne eine Zeile, die
verraet, fuer wen sie gilt.
* Das Kategorie-Feld: statt `ich.rolle === '...'` kommt vom Server
`kategorie_fuer` -- NUMMERN statt eines Rollennamens. Aus Nummern
laesst sich nichts schliessen; wer keine bekommt, sieht eine leere
Liste, und eine leere Liste sagt nichts. `null` heisst "gilt immer"
und muss `null` bleiben: Ein `|| []` daraus zu machen waere der
stille Fehler, aus "gilt immer" wuerde "gilt nie".
* Die Kommentare sagen jetzt, WAS gilt, ohne zu sagen, FUER WEN.
UND EINE SPERRE DAGEGEN: pruef-modi-wortleck durchsucht alle 73
ausgelieferten Dateien nach dem Rollennamen. Die Regel ist damit kein
Vorsatz mehr, sondern ein Werkzeug -- wer ihn dort hineinschreibt,
bekommt einen roten Lauf statt eines erhobenen Zeigefingers im Kommentar.
Mit Gegenprobe in beide Richtungen: Eine eingebaute Fundstelle MUSS
erkannt werden, und "modifiziert", "Modul", "Modus" duerfen NICHT
anschlagen -- eine Pruefung, die staendig Fehlalarm gibt, wird
abgeschaltet und faengt dann auch den echten Fall nicht mehr.
Die Dateizahl steht in der Bedingung, nicht nur im Meldetext: Faende die
Suche keine einzige Datei, waere sonst alles gruen, ohne dass etwas
angesehen wurde.
AUSSERDEM BELEGT statt behauptet: Dass das Kategorie-Feld bei DogFather
nur erscheint, wenn er wirklich einen Modi eintraegt, steht jetzt in der
Pruefung -- erst ein Creator (Feld bleibt weg), dann ein Modi (Feld
kommt). Ohne den zweiten Schritt waere "bleibt weg" auch dann gruen,
wenn es NIE kaeme.
GEPRUEFT: pruef-modi-wortleck (4, neu), pruef-modi-kategorien (25),
pruef-modi-verborgen (57), pruef-vorlagen, pruef-aufgabenbrett.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
114a00eed5 |
Der Modi bekommt seine eigene Seite -- und sein Brett zurueck
DER WICHTIGSTE FUND, und er kam nicht aus dem Nachdenken: Ein Modi sah
auf dem Aufgabenbrett GAR NICHTS -- nicht einmal seine eigenen Aufgaben.
sichtbar() endet mit `default: 0=1`, und 'modi' stand nicht darin.
Genau dieser Fehler ist am 01.09.2026 schon dem Manager passiert; der
Kommentar zwei Zeilen darueber warnt woertlich davor ("Ein leeres Brett
sieht aus wie 'nichts zu tun', nicht wie ein Fehler; deshalb ist das
vermutlich lange niemandem aufgefallen"). Der Rollen-Rundgang meldete
fuer den Modi trotzdem brav "aufgaben.html ok" -- die Seite laedt ja,
sie war nur leer. Gefunden hat es erst eine Pruefung, die eine Aufgabe
ANLEGT und sie danach wiederzufinden versucht.
Ein Modi sieht jetzt die Aufgaben des ganzen Modi-Teams (Filipes
Entscheidung "sie sind untereinander ein Team"), aendern darf er
weiterhin nur seine eigenen. Die Nummern werden bei jeder Abfrage frisch
gelesen -- eine beim Serverstart gebaute Liste waere ab dem naechsten
neuen Modi falsch, und niemand wuesste warum.
DIE STARTSEITE. Ein Modi hatte keine einzige Kachel: Jede traegt eine
feste Rollenliste, und 'modi' darf dort nicht stehen -- bereiche.js
bekommt jeder ausgeliefert, der die Seite oeffnet. Die Kacheln kommen
deshalb vom Server (MODI_BEREICHE), samt Beschriftung. Nur die Ziele zu
schicken haette nicht gereicht: Unter "Dashboard" stuende sonst "Alle
Creator auf einen Blick" -- fuer jemanden ohne Creator. Die Worte
gehoeren zum Empfaenger, nicht zum Ziel.
Neun Kacheln in drei Gruppen: Aufgaben, Chat, Kalender, Dateien /
Live-Ablauf, Community, Technik / Profil, Wissen. Nichts aus der
Agentur -- diese Seiten drehen sich um betreute Creator oder um Rechte.
`null` heisst "nimm deine eigene Liste", eine LEERE Liste hiesse "keine
Kacheln". Verwechselte man die beiden, haetten die fuenf bekannten
Rollen ab sofort eine leere Startseite.
ZWEI DINGE HAT DAS BILDSCHIRMFOTO GEZEIGT, NICHT DER CODE:
* Ueber der Modi-Startseite stand "Spicy Media" -- die Marke einer
Agentur, mit der er nichts zu tun hat. Jetzt "Team Dogi", wie auf
der oeffentlichen Seite. Ersetzt wird nur der Textknoten: In dem
Element sitzen zwei Zierrauten, ein textContent haette sie lautlos
geloescht.
* Auf seinem Aufgabenbrett stand das Creator-Vorlagenbrett, 80
Aufgaben fuer den Aufbau eines Kanals. Fuer einen Moderator ist
davon nichts gedacht. Ausgeblendet, bis sein Katalog aus Teil 2 des
Anforderungsdokuments da ist -- nichts ist ehrlicher als etwas
Fremdes.
Dazu: "0 betreut" stand dauerhaft auf seiner Startseite, eine Zahl, die
nie etwas anderes sagen kann. Jetzt zaehlt sie, wie viele im Modi-Team
sind. Und der Satz unter der Begruessung war nur das Wort "Modi", neben
fuenf Rollen mit einem ganzen Satz -- das sah nicht verborgen aus,
sondern unfertig.
KATEGORIEN (Kapitel 6.1), nach Filipes Entscheidung nur bei den Modis.
Acht Stueck; hier steht, wohin die dreizehn aus Teil 2 fallen
(Branding/Team/Kommunikation -> Planung, Wachstum -> Community).
Der heikelste Fall ist nicht das Setzen, sondern das SCHICKEN durch
jemanden, der es nicht darf: Eine Absage ("Unbekannte Kategorie") waere
die Auskunft, dass es das Feld gibt. Also faellt der Wert lautlos weg
und die Aufgabe entsteht ganz normal. Wer die Kategorien benutzen darf,
bekommt bei einem Tippfehler dagegen sehr wohl eine Absage.
Das Feld erscheint nur, wenn die Aufgabe wirklich zu einem Modi gehoert
-- bei DogFather also erst, wenn er einen als Person auswaehlt. Sonst
stuende es auch an jeder Creator-Aufgabe. Verborgen heisst dabei auch
"nichts mitschicken": Ein Wert in einem unsichtbaren Feld wandert sonst
beim naechsten Speichern mit.
KEINE NEUE CSS-KLASSE fuer die Kategorie auf der Karte. Sie muesste in
sieben gleichlautenden Kopien der Modulliste gepflegt werden -- sieben
Gelegenheiten fuer einen Unterschied, fuer eine Zeile Text.
AUSSERDEM BERICHTIGT, UND ES WAR SCHON VORHER ROT: pruef-start-ansicht
erwartete drei Kachelgruppen. Seit
|
||
|
DogFatherGitandClaude Opus 5
|
7be488e0ca |
Ein Zugang, den ausser DogFather niemand bemerkt
Aus dem Anforderungsdokument (Master-Blueprint V3.0) fehlte die Rolle
"Modi" ganz -- es gab nur spicy, admin, manager, scout, creator. Filipes
Bedingung dazu: "dass die keine neue eingangs kachel bekommen wie spicy
dogfather und so sondern einfach einen code. damit die von der workspace
auch nicht mal sehen dass die modis von mir einen eigenen zugang haben."
DER EINGANG. Es gibt keine sechste Kachel und es laesst sich auch keine
erzwingen: Wer von aussen `rolle: "modi"` schickt, bekommt wortgleich
dieselbe Antwort wie bei einer erfundenen Rolle. Ein Modi tippt auf
irgendeine vorhandene Kachel -- welche, ist gleichgueltig -- und gibt
seinen Code ein. Der Code allein entscheidet.
Moeglich macht das eine neue Spalte `code_kennung`: ein HMAC ueber den
Code, in Mikrosekunden nachgeschlagen. Zwei naheliegende Wege wurden
verworfen, weil man sie finden kann: ein Merkmal im Code ("M-...") waere
ein sichtbares Kennzeichen auf dem Zettel des Modis, eine eigene Adresse
(/modi.html) eine Seite, die man aufrufen kann. Der Suchschluessel steht
VOR dem gewohnten Weg, nicht dahinter -- ein Rueckfall nach einem
Fehlversuch haette genau die Fehlversuche verlaengert, und daran waere
es zu erkennen gewesen.
Unbedenklich, weil nachgemessen: Ein Code hat 16 Zeichen aus einem
32er-Alphabet, also 80 Bit Zufall. Der Suchschluessel sagt ausserdem nur,
WEN man pruefen soll -- ob der Code stimmt, sagt weiterhin scrypt.
DIE UNSICHTBARKEIT sitzt in verborgeneIds(), also an derselben einen
Stelle wie die Regel fuer den zweiten Admin-Zugang, und nicht in den
rund 170 Abfragen, die Personen lesen. Sie haengt dabei an der ROLLE und
nicht an einer Nummer -- die Schwachstelle, die im Kommentar der alten
Regel offen dasteht (wird Zugang 1 geloescht, rueckt der naechste nach),
kann einer Rolle nicht passieren.
Nach Filipes Entscheidungen: Die Modis sehen sich untereinander (Kapitel
7.2 des Dokuments), VanVan sieht sie mit (Kapitel 3, sie traegt dieselbe
Rolle), Codes gibt Filipe selbst weiter -- kein Einladelink, der in einem
Verlauf landen kann.
ZWEIMAL WAERE DAS WORT "MODI" BEINAHE IN EINER DATEI GELANDET, DIE JEDER
BEKOMMT: in den Rollenlisten von start.js und personen.js. Ein Blick in
den Quelltext haette genuegt. Der Anzeigename kommt jetzt aus
/workspace/api/ich (beschreibt immer nur den Angemeldeten selbst), die
Rollenauswahl aus der Antwort des Servers und nur an die DogFather-Rolle.
GEPRUEFT mit pruef-modi-verborgen.mjs (45 Pruefungen): fuenf Kacheln
fuehren mit dem Modi-Code hinein, ein Manager-Code auf fremder Kachel
weiterhin nicht (sonst waere nebenbei die Rollenpruefung abgeschafft),
und ueber fuenf Schnittstellen sieht ausser DogFather, VanVan und den
Modis niemand etwas -- auch nicht die ZAHL daneben.
Die Gegenprobe steht bewusst ganz unten, weil sie eine Person absichtlich
aus der Regel aushaengt: Weiter oben haette sie jeden Abschnitt danach
verfaelscht. Beim ersten Anlauf stand sie in der Mitte, und prompt tauchte
die Person in einer spaeteren Managerliste auf.
Abschnitt 5 prueft den Weg durch die Anwendung selbst (DogFather legt an,
der Modi meldet sich an). Die Abschnitte davor tragen die Personen von
Hand ein und rechnen den Suchschluessel selbst aus -- damit waere NICHT
bewiesen, dass personAnlegen() ihn im Betrieb schreibt. Ohne ihn kaeme
kein einziger echter Modi herein, und oben waere trotzdem alles gruen.
Die Umstellung der Rollenliste in der Datenbank steht ab jetzt einmal in
rollenRegelUmstellen() statt zum dritten Mal abgeschrieben. Jede Abschrift
waere eine Gelegenheit, eine der vier Absicherungen zu vergessen: Sicherung
vorher, Zaehlung innerhalb der Transaktion, Spaltenliste aus der Tabelle,
Pruefung auf verwaiste Verweise danach.
pruef-personen-formular erwartet jetzt sechs Rollen statt fuenf und prueft
die Liste statt nur die Anzahl -- sechs Karten koennten auch fuenf richtige
und eine doppelte sein. Dass die sechste dort auftaucht, ist gleichzeitig
der Nachweis, dass der Weg ueber den Server funktioniert.
Unveraendert bestanden: pruef-spicy (60), pruef-rollen (97),
pruef-verborgen, pruef-personen-liste, pruef-css-klassen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
88e2b5cd5d |
Der Wecker: das Zeitfeld ging auf -- nur ausserhalb des Bildschirms
Filipe: "wenn ich am handy auf den wecker drücke dan sieht man nichts."
Er hat woertlich recht. Der Knopf tut, was er soll, und das Zeitfeld
klappt auf -- es steht nur nicht im Bild. Aufgeklappt gemessen, fuenf
Breiten:
320 px Feld bei -127 .. -8 komplett draussen
360 px Feld bei -107 .. 12
390 px Feld bei -92 .. 27
412 px Feld bei -81 .. 38
430 px Feld bei -72 .. 47
DER GRUND IST EIN ANKER, DER GEWANDERT IST. `.tagesruf__feld` steht mit
`right: 56px` da -- "56 px nach links vom Knopf". Am Rechner ist das
richtig: Dort sitzt der Knopf am rechten Rand einer breiten Kachel, und
links davon liegt die Luecke zwischen Text und Uhr. Auf dem Handy wird
derselbe Knopf aus dem Fluss genommen und neben die zentrierte Uhr
gehaengt -- er steht dann ganz LINKS, und 56 px weiter links ist kein
Raum mehr, sondern der Bildschirmrand.
Der Abstand stimmte also noch, der Bezugspunkt nicht mehr. Dieselbe
Sorte Fehler wie die feste Umbruchschwelle und die 62 px Kopfhoehe: eine
Zahl, die fuer eine Anordnung ausgerechnet wurde und in der zweiten
still falsch ist.
Es oeffnet jetzt auf dem Handy nach RECHTS statt nach links -- in die
Richtung, in der dort der Platz ist. Das ist keine zweite Zahl, sondern
dieselbe Regel andersherum ("ins Freie oeffnen"). Der linke Rand des
Knopfes ist nie kleiner als 0, das Feld 119 px breit, der schmalste
Bildschirm 320 -- damit liegt es auf jeder Breite im Bild, ohne dass
eine Schwelle stimmen muss. `max-width: calc(100vw - 24px)` als
Sicherung, falls das Feld je breiter wird.
Die Regel steht in heim.css direkt neben der Regel, die den Knopf
verschiebt. Sie gehoeren zusammen: Wer den Anker bewegt, sieht die
Folge in derselben Medienabfrage.
GEPRUEFT WIRD ES JETZT AUCH (pruef-handy, 99 -> 115 Pruefungen). Das
Feld wird dafuer aufgeklappt gemessen, nicht zugeklappt -- ein
verstecktes Feld hat keine brauchbare Lage, und genau die ist die
Frage. Gegenprobe ist die Messung von vorher: Mit demselben Messmittel
lag das Feld bei -92..27, die Bedingung waere rot gewesen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
6c48579f66 |
Die Kopfleiste bleibt auch in einer fremden Sicht in EINER Reihe
Filipe, mit Bildschirmfoto aus der installierten App: "es ist noch nicht alles in einer zeile und irgendwie funktionieren nicht alle knoepfe." DER GRUND WAR NICHT DIE BREITE SEINES GERAETS, SONDERN DER ZUSTAND. In der eigenen Sicht klappt der Umschalter auf 36 px zusammen; sobald man die Sicht einer anderen Person uebernimmt, stand der Name darin und er war 152 px breit. Gemessen waren es dann zwei Zeilen bei 320, 360, 390, 412 UND 430 px -- ausnahmslos. Auf seinem Bild stand "Miesmus..." im Umschalter und der goldene Rahmen um die Seite: er war in einer fremden Sicht. MEINE PRUEFUNGEN HABEN DEN FALSCHEN ZUSTAND GEMESSEN. pruef-handy lief ausschliesslich in der eigenen Sicht und war deshalb gruen, waehrend es beim Nutzer zweizeilig war. Ein gruener Haken sagt nur, dass die Bedingung erfuellt war -- nicht, dass sie den Zustand geprueft hat, in dem der Nutzer ist. Die Pruefung wechselt jetzt selbst in eine fremde Sicht (92 -> 99 Pruefungen). WAS SICH AENDERT - Auf dem Handy ist der Umschalter auch in fremder Sicht ein Zeichenknopf: Auge + Anfangsbuchstabe, 46-48 statt 152 px, in der ROLLENFARBE der Person, deren Sicht laeuft. Die Farbe kommt aus `data-rolle` -- dieselbe Zuordnung, die gate.css ohnehin hat, keine zweite Farbliste. - Der volle Name wandert in ein Band unter die Leiste, zusammen mit "Zurueck zu meiner Sicht" als ganzem Satz statt als 28-px-Kreuz. Er steht dort GANZ statt als "Miesmus...". Am Rechner bleibt alles wie bisher; dort ist Platz. - Der Rahmen um die Seite nimmt dieselbe Farbe an. Man sieht damit nicht nur DASS eine fremde Sicht laeuft, sondern WESSEN. - Das `:not([data-fremd="ja"])` faellt an beiden Stellen weg. Es war der ganze Fehler: eine Regel, die den wichtigeren Fall ausnahm. UND DER BLOCK FUER SCHMALE GERAETE STAND AN DER FALSCHEN STELLE Er galt bis 340 px und stand 3600 Zeilen VOR dem 560er-Block -- bei gleicher Spezifitaet verliert er damit. Gewirkt hat er nur, weil sein Selektor zufaellig ein `:not()` trug. Jetzt steht er direkt hinter dem 560er und gilt bis 400 px (34 px je Knopf, 4 px Abstand). Damit bleibt auch bei 360 px auf den UNTERSEITEN alles in einer Reihe -- dort stehen zusaetzlich der Zurueck-Knopf und die Glocke. Gemessen nach dem Umbau, eigene und fremde Sicht, Start- und Unterseite: 360, 390, 412 und 430 px alle einzeilig. Offen bleibt 320 px (iPhone SE 1. Generation bzw. Anzeige-Zoom) -- dort passt es ohne das Weglassen einer Funktion nicht, das ist eine Entscheidung und kein Handgriff. DER SICHERE BEREICH (auf Filipes Zusage) Jede der 20 Seiten sagt `viewport-fit=cover`, aber im ganzen Workspace stand kein einziges `env(safe-area-inset-*)`. Sein Android ist NICHT betroffen (im Bildschirmfoto nachgesehen), ein iPhone waere es: Von einem 36-px-Knopf blieben unter einer 47 px hohen Statusleiste rechnerisch 5 px zum Antippen. Einmal zentral benannt (gate.css) und an den vier Stellen angewandt, wo etwas am Rand klebt: Kopfleiste (oben und seitlich), Inhalt (seitlich und unten), Speichern-Leiste im Profil, Chat-Eingabe. Auf Geraeten ohne Aussparung sind alle vier Werte 0. Nebenbei: chat.js misst die Hoehe ueber der Chatflaeche jetzt einschliesslich des Bandes -- sonst stuende das Eingabefeld genau um dessen Hoehe unter dem Bildschirmrand. Derselbe Fehler wie mit den festen 62 px, nur mit einem anderen Element. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
d0ac8ee8d1 |
Das Logo: aus dem Fleck wird wieder ein Hund
Filipe: "kannst du bitte das logo wenn man es installiert auf pc oder handy und oben rechts in der leiste noch perfektionnieren." Beide Stellen hatten denselben Fehler, und er war derselbe wie an mehreren Stellen davor: Der Husky lag als MASKE auf einer Farbflaeche. Von einer Maske zaehlt nur der Alphakanal, und die Vorlage ist rundum freigestellt -- uebrig blieb eine geschlossene Flaeche in Hundeform. Kein Auge, keine Schnauze, kein Ohrinneres. Ein Fleck. Jetzt liegt an beiden Stellen dieselbe Zeichnung im Mischmodus "screen" ueber einer stahlblauen Silhouette: Schwarz laesst das Fell dunkel, Weiss hebt Gesicht, Ohren und Auge heraus. Gleiche Farben, gleicher Daempfer (.88) -- ein Zeichen, zwei Orte. App-Symbol ausserdem: - Die Chili lief mit ihrem Stiel quer ueber den Fang. Sie ist jetzt gespiegelt, kleiner und liegt hinter dem Hals. - Der Hals endete in einer geraden Kante (die Vorlage ist unten angeschnitten). Eine zweite Maske blendet ihn aus, statt ihn abzuschneiden. - Der Grund war matschig: Rot und Blau trafen sich diagonal genau dort, wo der Kopf steht. Jetzt kaltes Licht oben, warmes unten. - Unter 64 px faellt die Gesichtszeichnung weg, die Chili aber NICHT -- klein erkennt man ein Zeichen zuerst an der Farbe. - Alle Masse haengen an einer Zahl (Groesse der Gruppe), nicht an sechs. Kopfleiste ausserdem: - Die Chili links hatte einen BLAUEN Schein -- aus der Zeit, als dort der Husky stand. Der Schein ist nie mitgewandert. Jetzt warm. - `filter` ersetzt, es ergaenzt nicht: Beim Ueberfahren wurde der Schein geloescht und das Zeichen dabei flacher statt heller. Behoben. Damit die Aenderung auch ankommt: - Der Stempel gilt jetzt auch fuer die App-Symbole und fuer das Manifest. Bilder werden einen Tag zwischengespeichert, das Symbol der INSTALLIERTEN App gar nicht neu geholt -- ohne Stempel haette niemand das neue Zeichen gesehen. - pruef-zwischenspeicher prueft das (18 -> 21 Pruefungen). Werkzeuge: - tools/ausschnitt.mjs (neu): schneidet aus einem Bildschirmfoto ein Stueck heraus und vergroessert die PNG-Datei. Noetig, weil eine Vergroesserung per CSS-transform den Browser NEU rechnen laesst -- ich habe damit 264 px beurteilt und geglaubt, es seien 22, und daraus den falschen Schluss gezogen, ein Gesicht trage bei 22 px nicht. - tools/ansicht.mjs: AUSSCHNITT=<selektor> nimmt nur ein Element auf. - workspace-symbol.mjs: SYMBOL_ZIEL lenkt die Ausgabe um (Entwuerfe ansehen, ohne die sechs echten Dateien zu ueberschreiben), und zwei Gegenproben pruefen jetzt, dass Gesicht und Chili wirklich zu sehen sind -- die alte Pruefung sagte nur "es steht etwas drauf" und haette den Fleck anstandslos durchgewunken. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
bec46ed991 |
Team-Seite: Kopf und Karten sind jetzt echte Kacheln
Filipe, mit Bildschirmfoto: "perfektionnir das in einer kachel in der
farbe von der kategorie bitte. und die kacheln unten in der seite auch
perfektionnieren und geil machen bitte."
--- DER KOPF ---
Er war eine freistehende Ueberschrift auf dem Buehnenbild. Jetzt ist er
eine Kachel wie jede andere im Haus: gefraeste Fase, Kantenlicht,
Eckwinkel, Raster -- alles aus der Modulliste in module.css, wo
`.t-kachel` seit diesem Commit steht.
DIE FARBE IST NICHT ABGESCHRIEBEN. Die Kachel traegt `data-ton="22"`,
und die Regel dazu steht in start.css -- dieselbe, aus der die Kachel
auf der Startseite ihre Farbe zieht (#ffd166). Es gibt weiterhin genau
EINE Stelle, an der die Farbe dieser Kategorie steht; wer sie dort
aendert, aendert beides. Eine zweite Hexzahl in team.css waere die
naechste gewesen, die auseinanderlaeuft.
Der Grenzsatz ("Termine, Chats und Dateien kommen hier nicht vor")
wechselt von Gruen in denselben Ton: In einer Kachel, die schon eine
Farbe hat, ist eine zweite Farbe daneben eine zweite Aussage.
--- DIE KARTEN UNTEN ---
`.tperson` und `.tl` stehen ebenfalls in der Modulliste. Ein
Manager-Kasten leuchtet damit lila, ein Scout-Kasten gruen, ein
Lueckenkasten rot -- ueber `--ton`, ohne dass eine einzige Farbe hier
ausgeschrieben stehen muss.
DER STREIFEN LINKS IST DAFUER WEG, und das ist kein Verlust: module.css
belegt ::before und ::after selbst (Kantenlicht und Eckwinkel) und
laedt NACH team.css -- ein eigenes ::after waere ohnehin wirkungslos
gewesen. Das Kantenlicht traegt die Rollenfarbe jetzt rund um die ganze
Karte statt auf drei Pixeln links.
DIE KENNZAHLEN BLEIBEN SCHLICHT, und das ist eine Entscheidung: Sie
stehen zu acht in einer Karte. Jede davon mit Fase, Kantenlicht und
Eckwinkel waere ein Schaufenster voller Rahmen und keine Auskunft mehr
-- eine Kachel in der Kachel in der Kachel liest niemand. Sie bekommen
nur die abgeschnittene Ecke aus derselben Formel, damit sie erkennbar
zur Familie gehoeren.
--- EIN FEHLER, DEN NUR DAS HANDY GEZEIGT HAT ---
Der Grenzsatz-Kasten hat `flex: 1 1 300px`. Am Rechner ist das richtig:
Dort ist die Hauptachse waagerecht, und er teilt sich die Breite mit
dem Titel. Am Handy dreht die Reihe auf eine SPALTE -- und derselbe
Wert liess ihn in die HOEHE wachsen. Auf dem Bildschirmfoto stand
danach die halbe Kachel leer.
Ein Flexwert gilt fuer eine Richtung, nicht fuer ein Element. Wer die
Richtung dreht, muss ihn mitdrehen.
--- Pruefung ---
pruef-css-klassen: die Modulliste steht weiterhin siebenmal und
Zeichen fuer Zeichen gleich (jetzt 48 Klassen).
pruef-team, 51 Pruefungen: darunter acht Kontrastmessungen an der
WIRKLICHEN Flaeche -- die Hintergruende haben sich durch den Umbau
geaendert, und eine Kachel mit Raster und Verlauf ist etwas anderes als
ein flacher Kasten. Gemessen jetzt 6,71 bis 15,12:1.
Ausserdem gruen: pruef-handy, pruef-lesbarkeit, pruef-buehne.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
b45de940e8 |
Rund um das Team -- die Arbeitslage von Managern und Scouts
Filipe: "so eine kategorie wie ueber die creator will ich dass nur fuer
die spicy und dogfather rolle auch ueber manager und scouts gibt ...
ich will dass es so ultra krass gut ist dass die spicy und dogfather
rolle einen kompletten teil haben mit daten ueber die arbeit von den
manager und scout. keine geheimen sachen also termine, chats und
geheime dateien soll auch so bleiben dass keiner."
--- ZUERST DIE KOPFLEISTE ---
Filipe meldete, die Kopfleiste sei bei DogFather "nicht gemacht".
Nachgemessen auf ALLEN 18 Seiten, in allen fuenf Rollen, bei drei
Breiten: einzeilig, Spanne 4 px. Und die neuen Dateien liegen
nachweislich auf dem Server (
|
||
|
DogFatherGitandClaude Opus 5
|
a70bc4f235 |
Kalender: blaettern direkt ueber dem Raster, rot und gruen
Filipe, mit Bildschirmfoto: "ich will dass genau da ueber dem kalender
auch noch buttons sind um den monat zu wechseln, tage wechseln.
perfektionnier mir das bitte. und mach auch die buttons die schon da
sind noch viel klarer bitte und die neuen auch. lass die neuen auch
richtig geil aussehen, die einen rot und die anderen gruen."
--- WARUM DAS EINE ECHTE LUECKE WAR ---
Die Pfeile gab es schon -- oben neben der Ueberschrift, einen halben
Bildschirm ueber dem Raster, das sie bewegen. Wer durch Monate
blaettert, sieht auf das Raster und nicht auf die Ueberschrift; der Weg
dorthin war jedes Mal ein Blicksprung.
Die neuen Knoepfe rufen DIESELBE Funktion (`springen`), sie kopieren sie
nicht. Zwei Fassungen desselben Schritts waeren zwei Gelegenheiten,
dass die eine spaeter anders springt als die andere.
--- BESCHRIFTET, NICHT NUR BEPFEILT ---
Ein Pfeil sagt nicht, WIE WEIT er springt. In der Monatsansicht ist ein
Schritt ein Monat, in der Wochenansicht eine Woche, in Liste und
Zeitstrahl sechs Wochen. Genau das steht jetzt drauf und wird beim
Umschalten mitgefuehrt -- steht "Monat vor" und es springt eine Woche,
ist das schlimmer als gar keine Beschriftung.
"Heute" ist ausgegraut, solange man schon dort steht. Ausgegraut und
nicht versteckt: Sonst springen die drei Knoepfe beim Blaettern in der
Breite. Ein Knopf, der nichts tut, wird sonst einmal gedrueckt und
danach nicht mehr ernst genommen.
--- ROT UND GRUEN, ABER NICHT SIGNALROT ---
Diese beiden Knoepfe stehen den ganzen Tag auf dem Bildschirm. Genommen
sind die Haustoene: das gedeckte Rot der Warnfarbe, das Gruen der
Scout-Rolle. Beide hell genug fuer Schrift auf dunklem Grund, keins
leuchtet.
Die Richtung steckt zusaetzlich in der FORM: Der Pfeil steht links beim
Zurueck und rechts beim Vor. Wer Rot und Gruen nicht unterscheidet --
etwa acht Prozent der Maenner --, liest die Richtung trotzdem.
--- UND DIE VORHANDENEN KNOEPFE ---
Der Ansichts-Umschalter: Die drei nicht gewaehlten Knoepfe waren nackte
Schrift auf dunklem Grund -- sie sahen aus wie Beschriftungen, nicht wie
Schaltflaechen. Wer nicht weiss, dass "Woche" anklickbar ist, klickt
nicht darauf. Sie haben jetzt eine eigene Flaeche; die gewaehlte bleibt
das gebuerstete Metall und hebt sich dadurch sogar deutlicher ab.
Die Filterknoepfe standen auf --text-still, der leisesten Schrift der
Seite -- ausgerechnet an einem Bedienelement. Und "aus" unterschied
sich nur am hohlen Punkt.
--- EIN EIGENER FEHLER UNTERWEGS ---
Am Handy verschwindet das Wort, damit die Leiste nicht umbricht. Der
erste Anlauf liess die Polsterung stehen: Uebrig blieb ein 30 px
breites Pillchen mit einem winzigen Pfeil -- kleiner als das, was man
mit dem Daumen sicher trifft, und die Farbe war darauf kaum noch zu
sehen. Jetzt ein rundes Ziel von 44 px mit einem Pfeil, der die Flaeche
fuellt. Gesehen habe ich das erst auf dem Bildschirmfoto, nicht beim
Schreiben.
--- Pruefung ---
pruef-kalender, elf neue Messungen: beide Knoepfe blaettern wirklich,
die Beschriftung nennt die Schrittweite und folgt der Ansicht
("Monat vor" -> "Woche vor"), "Heute" graut sich richtig aus und wird
wieder anklickbar.
Rot und Gruen werden an ECHTEN Farbwerten geprueft (ueber ein Canvas
zurueckgelesen, weil color-mix() als "color(srgb ...)" herauskommt und
ein Muster ueber die Ziffern Unsinn liest -- derselbe Fehler wie heute
Mittag bei der Personenkachel). Dazu die Gegenprobe, dass die beiden
sich wirklich unterscheiden: Abstand 187.
Ausserdem gruen: pruef-css-klassen, pruef-lesbarkeit, pruef-handy.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
f3acfab10a |
Aufgaben: die Bedienung, nicht die Kacheln
Filipe: "ich will dass du dass system jetzt wie die vier kategorien bedient werden, perfektionnierst ... ich red von den aufgaben. das system von den aufgaben, die bedienung ... die hauptkachel von der kategorie nicht veraendern oder anfassen, die bleiben so." Die vier Kacheln sind unberuehrt. Geaendert ist, was danach kommt. --- 1. DAS VORLAGENBRETT WAR IM WEG --- Gemessen am Handy: Der Vorlagenblock fuellte ANDERTHALB BILDSCHIRME, bevor die erste eigene Aufgabe kam. Und mein eigener Ausbau von Profi und Meister ein paar Stunden vorher hat ihn noch laenger gemacht -- aus 48 Vorlagen wurden 80. Das ist die falsche Reihenfolge: Vorlagen holt man selten, das Brett benutzt man jeden Tag. Der Block bleibt an seiner Stelle (dort gehoert er hin, weil daraus Aufgaben auf das Brett darunter wandern), ist aber zugeklappt. Zugeklappt steht dort, WIE VIEL darin liegt -- sonst sieht er aus wie eine Ueberschrift ohne Inhalt und niemand macht ihn auf. Wer ihn aufmacht, findet ihn beim naechsten Mal offen: Wer Vorlagen holt, holt meistens mehrere. Und zugeklappt werden die achtzig Karten GAR NICHT ERST GEBAUT, nicht nur versteckt. --- 2. MAN SAH NICHT, WAS MAN SCHON GEHOLT HATTE --- Dieselbe Vorlage liess sich zweimal uebernehmen, und die Aufgabe stand dann zweimal auf dem Brett -- ohne jeden Hinweis. Bei achtzig Vorlagen ueber vier Stufen weiss niemand auswendig, was er letzten Monat schon geholt hat. Die Kennung der Vorlage steht jetzt an der Aufgabe (neue Spalte `vorlage`). Ueber den TITEL zu vergleichen waere die naheliegende Abkuerzung gewesen -- und faellt in dem Moment um, in dem jemand den Titel einer uebernommenen Aufgabe aendert. Uebernommene Karten treten zurueck (nicht: verschwinden -- wer sie ausblendet, nimmt die Moeglichkeit, sie bewusst noch einmal zu holen), tragen "schon uebernommen" MIT ZUSTAND, und ihr Knopf heisst "Nochmal". Darunter steht der Stand: "5 von 7 noch nicht uebernommen." Es braucht dafuer keine zweite Abfrage -- die Aufgaben liegen ohnehin im Browser. --- 3. DRINGEND SCHLAEGT WICHTIG --- Die Liste war nach PRIORITAET sortiert, dann nach Frist. Auf dem Brett stand damit eine seit vier Tagen ueberfaellige Aufgabe mit Prioritaet "niedrig" UNTER einer, die als "hoch" eingetragen ist und erst in dreissig Tagen faellig wird. Wer die Spalte von oben liest, faengt dann mit dem Falschen an. Eine Prioritaet ist eine Einschaetzung von damals, eine ueberschrittene Frist eine Tatsache von heute. Jetzt: erst was faellig ist, dann nach Datum, und die Prioritaet entscheidet nur noch bei gleichem Datum. Die Sortierung steht im SERVER -- Startseite und Uebersicht lesen dieselbe Liste, und zwei Sortierungen fuer dieselbe Frage laufen auseinander. --- 4. "WICHTIG" STEHT JETZT DA --- Die Prioritaet war ein 3 px breiter Rand links -- direkt neben der farbigen Kante der Spalte und damit praktisch unsichtbar. Als Wort steht sie dort, wo man sie liest. NUR bei "hoch" und nur solange nicht erledigt: Eine Marke an jeder Karte waere keine Marke mehr. --- Pruefung --- pruef-aufgaben-vorlagen: zugeklappt als Vorgabe (gemessen wird, dass die Karten gar nicht gebaut werden), Aufklappen, uebernommene Vorlage markiert samt Zustand und "Nochmal"-Knopf, Stand darunter, Zustand ueberlebt das Neuladen -- mit Gegenprobe, dass die uebrigen NICHT markiert sind. Dabei fiel eine eigene Nachlaessigkeit auf: Die Pruefung "die Karten sind gestaltet" mass zu einem Zeitpunkt, an dem es zugeklappt gar keine Karte gab -- getComputedStyle auf null liefert nichts, und der Haken wurde rot, ohne dass etwas kaputt war. Sie misst jetzt nach dem Aufklappen. pruef-aufgabenbrett: die Sortierung an zwei absichtlich unguenstig angelegten Aufgaben (ueberfaellig+niedrig gegen fern+hoch), plus die Gegenprobe, dass bei GLEICHER Frist weiterhin die Prioritaet entscheidet -- sonst waere die Prioritaet wirkungslos geworden, und das waere die andere Uebertreibung. Ausserdem gruen: pruef-css-klassen, pruef-start-ansicht, pruef-uebersicht. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
38416962b3 |
Kopfleiste am Handy: alles in einer Reihe
Filipe, mit Bildschirmfoto: "ich will dass es ueberall perfektionniert
wird. ich will dass du das richtig geil machst es soll alles in einer
reihe sein." Auf dem Bild stand "Abmelden" allein in einer zweiten
Zeile, darueber Teilen, Chat, Suche und das Profilbild.
--- GEMESSEN, BEVOR ETWAS GEAENDERT WURDE ---
Bei 390 px, alle fuenf Rollen:
verfuegbar fuer die rechte Gruppe 275 px
gebraucht als DogFather 393 px
(Sicht 150 · Teilen 38 · Chat 37 · Suche 47 · Bild 28 · Abmelden 93)
gebraucht als Scout/Manager/Spicy 243 px
gebraucht als Creator 205 px
Der Umbruch war also die richtige Antwort auf ein echtes
Platzproblem. `flex-wrap` misst und rechnet nicht -- das bleibt so.
Geaendert wird der PLATZBEDARF, nicht die Reaktion darauf. Eine
Schwelle, ab der nicht mehr umgebrochen wird, waere wieder eine
Rechnung von gestern: Beim naechsten Knopf staende alles uebereinander.
--- WAS SCHRUMPFT, UND WAS NICHT ---
Die drei Zeichen-Knoepfe waren 38, 37 und 47 px breit -- nebeneinander
sah das unruhig aus. Jetzt alle 36.
"Abmelden" wird auf schmalen Bildschirmen zum Zeichen (93 -> 36). Das
Wort bleibt im aria-label und am Rechner sichtbar: Dort ist Platz, und
ein Wort ist eindeutiger als ein Bild. Der Aufbau steht in kopf.js und
nicht in neunzehn HTML-Dateien -- neunzehn Stellen sind achtzehn
Gelegenheiten, eine zu vergessen.
Der Sicht-Umschalter wird ein Zeichen-Knopf wie die anderen (150 -> 36),
ABER NUR solange die eigene Sicht laeuft. Bei einer fremden behaelt er
den Namen, und dann darf die Leiste auch umbrechen: Dass man fremde
Zahlen ansieht, ist wichtiger als eine gerade Zeile. Das ist der
gefaehrlichste Fall dieser Funktion, und er bleibt unangetastet.
--- ZWEI DINGE, DIE ERST DIE MESSUNG GEZEIGT HAT ---
1. `max-width: 30px` am Umschalter-Kasten wirkte NICHT. Gemessen stand
da: berechnete Hoechstbreite 30 px, tatsaechliche Breite 104. Der
Knopf DARIN behielt seine Groesse und schob den Kasten wieder auf.
Wer nur den Rahmen begrenzt, begrenzt nichts -- die Breite kommt vom
Inhalt. Jetzt liegt der Knopf unsichtbar UEBER dem Auge: die ganze
Flaeche ist das Ziel, der Fokusring bleibt, die Breite ist 36.
2. Bei 360 px brach es weiter um, obwohl es rechnerisch passte. Ursache
war eine eigene Regel bei 380 px, die Marke und Bedienelemente
ausdruecklich in zwei Zeilen zwang -- richtig, solange die
Bedienelemente 243 bis 393 px brauchten, falsch seit sie 136 bis 238
brauchen. Die Schwelle liegt jetzt bei 300 px; darunter gibt es
Geraete, auf denen es wirklich nicht reicht.
--- Pruefung ---
pruef-handy, 15 neue Messungen (fuenf Rollen x 360/390/412): alle Teile
der Kopfleiste stehen in einer Reihe, Spanne 4 px.
Gemessen wird die ZEILENZAHL ueber die Oberkanten, nicht die Hoehe der
Leiste. Eine Hoehengrenze waere wieder eine Zahl von gestern -- sie
stimmt, bis jemand die Polsterung anfasst. Ob zwei Dinge in derselben
Zeile stehen, sieht man an ihrer Oberkante, und das gilt immer.
Ausserdem gruen: pruef-css-klassen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
9b1826721b |
Handy-Mitte, Babyblau und Spicy im Umschalter
Drei Bildschirmfotos, drei Befunde -- und alle drei waren messbar. --- SCREEN 2: RING UND UHR STANDEN SCHIEF --- Filipe: "ich will dass auf dem handy die uhr und der kreis ganz oben mit den erledigten aufgaben, schoen mittig, zentriert sind. die stehen sehr verzogen von der mitte. das soll bei jedem und jeder rolle verbessert werden." Gemessen bei 390 und 412 px, in allen fuenf Rollen, immer dieselbe Zahl: Ring 31 px nach links, Uhr 31 px nach rechts. Gleicher Betrag, entgegengesetzte Richtung -- eine Ursache, nicht zwei. `justify-content: center` zentriert den INHALT der Reihe, und in der Reihe steht neben dem Instrument noch ein Knopf (Glocke rechts vom Ring, Wecker links von der Uhr). Zentriert wurde also [Knopf + Abstand + Instrument] als Block; das Instrument rutschte um die halbe Knopfbreite zur Seite. Die Knopfbreite steht seit jeher als `--instrument-knoepfe: 62px` in derselben Datei -- 62 / 2 = 31. Die gemessene Zahl war von Anfang an aufgeschrieben, nur an anderer Stelle. Der Knopf zaehlt jetzt nicht mehr mit: aus dem Fluss genommen, neben das zentrierte Instrument gehaengt. NICHT um 31 px verschoben -- das waere dieselbe Zahl ein zweites Mal, und beim naechsten Knopf waere sie falsch. Jetzt folgt seine Lage dem Instrument, wie gross das auch ist. Nachher: 0 px Abweichung, alle fuenf Rollen, beide Breiten. --- SCREEN 3: DAS BABYBLAU WAR STAHLGRAU --- Filipe: "die rolle dogfather soll eine uebertrieben geile babyblau haben." Zum dritten Mal -- und die ersten beiden Male habe ich das Falsche vergroessert. Beide Male hatte ich den Abstand zwischen Rot- und Blaukanal im HEXWERT erhoeht (45 Stufen, dann 86). Diesmal zuerst gemessen, was am Bildschirm ankommt: Die DogFather-Zeile traegt 98,7 % farbige Bildpunkte -- MEHR als jede andere Rolle. An der Menge lag es also nie. Ihr Mittelwert war rgb(43,62,78): 35 Stufen zwischen Rot und Blau. Das ist Stahlgrau. Die richtige Groesse ist die SAETTIGUNG. In OKLab hatte #9ed3f4 eine Buntheit von 0,0718 -- der blasseste Wert aller fuenf Rollen. #5fbdff hat 0,1303, also 81 Prozent mehr. Die Zeile kommt damit auf rgb(36,60,79), und der mittlere Kanalabstand steigt von 35,2 auf 43,0. Nachgerechnet, was NICHT verlorengeht: Kontrast auf dem Grund 9,75:1 (vorher 12,49) -- weit ueber den 7 fuer AAA. Abstand zur naechsten Rollenfarbe 0,1608 in OKLab, vorher 0,1466; die Hausgrenze liegt bei 0,0973. DogFather ist also SICHERER unterscheidbar als vorher. Gemessen an der echten Flaeche: 8,84:1 und 9,60:1. --- SCREEN 4: SPICY FEHLTE IM UMSCHALTER --- Filipe: "ich will da auch noch die spicy rolle sehen und die leute in der rolle wie die anderen." Der Sicht-Umschalter fuehrte eine EIGENE Rollenliste -- vier Eintraege, Spicy Media fehlte. Zum vierten Mal derselbe Fehler: eine zweite Fassung einer Liste, die es zentral schon gibt. Vorher traf es die Leitungsliste (ein Set), die Rollennamen (ein Objekt in fuenf Skripten -- im Chat stand "UNDEFINED" ueber einem Namen) und die Personenliste. Jetzt steht dort keine Liste mehr, sondern eine Ableitung aus `ROLLENFOLGE` und `ROLLEN_GRUPPE`. Kommt eine sechste Rolle, ist sie ohne eine Zeile Arbeit dabei. --- Pruefung --- pruef-handy: zehn neue Messungen (fuenf Rollen x zwei Breiten), alle 0 px. Die beiden fehlenden Rollen sind dafuer in den Testdaten ergaenzt -- eine Pruefung an drei von fuenf haette "bei jeder Rolle" nicht belegen koennen. pruef-sicht: Cigdem als Spicy-Media-Person ergaenzt. Ohne sie waere es nie aufgefallen -- eine Rolle ohne Leute wird ohnehin weggelassen, und die alte Zusicherung "Manager, Scouts, Creator" waere weiter gruen gewesen. Dazu eine Gegenprobe, dass die Reihenfolge WIRKLICH aus der zentralen Liste kommt und nicht wieder abgeschrieben ist. pruef-personen-kachel: DogFather-Kontrast neu dabei. Ausserdem gruen: pruef-css-klassen, pruef-lesbarkeit. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
d5570ee501 |
Personenkachel: Rollenfarben, kein Leerband, dunklerer Grund
Filipe, mit Bildschirmfoto: "mach die ganze kachel perfekter detailliert schoenes. der hintergrund soll auch bissl dunkler sein von der kachel." --- 29 PIXEL NICHTS, FUENFMAL UNTEREINANDER --- Auf dem Bild stand unter jeder zugeklappten Rolle ein leerer Streifen. Nachgemessen: Abschnitt 74 px, Zeile darin 45 -- 29 px Leerraum. Sie kamen aus ZWEI Quellen, und nur eine stand in personen.css: padding-bottom: 14px am Abschnitt, plus margin-bottom: 14px an .gruppe__kopf aus start.css Zeile 765. Letzteres ist fuer die freistehenden Abschnitte der STARTSEITE geschrieben, wo unter der Ueberschrift wirklich gleich Karten kommen. Zugeklappt kommt hier aber nichts, und dann ist der Abstand Abstand zu nichts. Beide haengen jetzt am Zustand: offen -> Luft, zu -> keine. Die Kachel ist damit 383 px hoch statt 293 -- pardon, 293 statt 383. --- DIE ROLLEN HABEN FARBEN, NUR HIER NICHT --- Fuenf Zeilen sahen fuenfmal gleich aus. Das Haus fuehrt fuer jede Rolle eine Farbe (Anmeldeseite, Marken, Bereiche); ausgerechnet in der Liste, in der es NUR um Rollen geht, hoerten sie auf. Jeder Abschnitt traegt jetzt `data-rolle`, setzt daraus EIN --r, und alles Weitere liest davon: der Streifen links, die Anzahl, die Namenszeichen, der Pfeil, das Licht beim Aufklappen. Und `--ton`, die Variable, aus der module.css das Kantenlicht jeder Kachel zieht -- die Personenkarten in einem Manager-Abschnitt sind damit lila statt orange. Eine Zeile, und der Abschnitt wird ein Stueck. NEU: WER DRINSTEHT, OHNE AUFZUKLAPPEN. Vier Namenszeichen, ab dem fuenften "+n". Zugeklappt sagte die Zeile bisher nur, WIE VIELE es sind; wer wissen wollte, ob Patrick dabei ist, musste aufklappen. --- DER STREIFEN, DEN getComputedStyle NICHT SIEHT --- Erster Anlauf: 3 px breit, left: 0, volle Hoehe. Im Bild war nichts. getComputedStyle meldete trotzdem "3 px, sichtbar, Deckkraft 0,55". Der Grund steht in module.css: Jede Kachel traegt auf ::before ein Kantenlicht mit inset: 0 und z-index: 2 -- eine 1,6 px breite Linie UEBER allen Kindern. Vom Streifen blieben 1,4 px, und die lagen genau in der Kante. Er sitzt jetzt bei 3 px, gerundet, mit Luft oben und unten. Die Pruefung misst ihn deshalb an echten BILDPUNKTEN, und zwar dieselbe Stelle zweimal: einmal wie sie ist, einmal mit ausgeschaltetem Streifen. Was sich aendert, IST der Streifen -- und was sich nicht aendert, ist die Gegenprobe, ohne dass man sie erfinden muss. --- UND EINE PRUEFUNG, DIE GRUEN GELOGEN HAT --- Die Kontrastmessung las die Textfarbe mit `getComputedStyle(e).color.match(/\d+/g)`. Das geht, solange dort "rgb(148, 165, 187)" steht. Alle neuen Stellen kommen aus color-mix(), und Chromium antwortet darauf mit "color(srgb 0.36 0.51 0.42)". Aus dem Muster fielen "0", "510588", "0" -- die Pruefung meldete 775929299:1 und war gruen. Die Farbe wird jetzt in ein Canvas GEMALT und als Punkt zurueckgelesen; das versteht jede Schreibweise, die der Browser versteht. Davor steht eine Gegenprobe mit zwei bekannten Farben: Stimmt das Messgeraet nicht, ist alles darunter wertlos. Echte Werte jetzt: 7,95 bis 15,71:1. --- AM HANDY STAND DER PFEIL IN EINER DRITTEN ZEILE --- Der Zusatztext bekommt dort eine eigene Rasterzeile -- richtig, er passt sonst nicht. Der Pfeil bekam dadurch eine dritte und stand mittig unter dem Text wie ein vergessenes Zeichen: 106 px je Rolle. Er hat jetzt eine eigene Spalte und ueberspannt beide Zeilen: 75 px, und er steht da, wo die Hand ihn sucht. --- Pruefung --- server/pruef-personen-kachel.mjs, neu, 43 Pruefungen, alle gruen. Ausserdem gruen: pruef-personen-liste, pruef-css-klassen (die hat die Namenszeichen bei 10,56 px erwischt, bevor sie jemand lesen musste). Angesehen bei 1440 px und 390 px, zu und offen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
14e9bbf7a5 |
Chat: Fotos und PDFs schicken, Gespraeche wegraeumen
Filipe, mit Bildschirmfoto: "man muss die chats auch geloescht bekommen!!! am besten waere es auch wenn man da auch im chat pdfs schicken koennte. pdfs und fotos." Zwei Entscheidungen vorher abgestimmt, weil sie den Bau bestimmen: Geloescht wird NUR BEI MIR. Schicken duerfen ALLE im Gespraech, auch Creator -- anders als in der Dateiablage, wo etwas in einem Bereich landet, den mehrere sehen. Hier bekommt es genau der, mit dem man ohnehin gerade spricht. --- ANHAENGE --- Drei Wege zur selben Sache, weil Leute unterschiedlich arbeiten: die Bueroklammer, Hineinziehen und Einfuegen mit Strg+V (der Weg fuer einen Screenshot -- der liegt in der Zwischenablage und nirgends als Datei). Alle drei laufen durch dieselbe Funktion; drei Fassungen waeren drei Gelegenheiten, dass eine die Pruefung vergisst. Ein Foto wird GEZEIGT, ein PDF wird als Karte ANGEBOTEN. Das ist kein Schoenheitsunterschied: Ein Bild erkennt man in einer Zehntelsekunde, ein PDF muss man ohnehin oeffnen -- eine Vorschau davon waere ein grauer Kasten, der so tut, als koennte man etwas lesen. DIE SICHERHEIT STEHT IN dateiErkennen(). Dateiname und Content-Type kommen vom Absender und sind frei erfunden; der Typ wird deshalb aus den ersten Bytes bestimmt (PNG/GIF/WebP/JPEG/PDF, mit Breite und Hoehe im selben Durchgang). SVG steht absichtlich NICHT in der Liste -- das ist XML, das Skripte enthalten darf, ein als Bild getarntes Programm. Ausgeliefert wird spaeter genau der ERKANNTE Typ, nie der eingeschickte, dazu nosniff und "default-src 'none'; sandbox". Auf der Platte bekommt jede Datei einen erzeugten Zufallsnamen, in einem Ordner ausserhalb des Repos. Zuruecknehmen loescht die Datei wirklich -- sonst waere sie im Verlauf weg und ueber die Adresse noch da, also nur der Anschein einer Ruecknahme. --- WEGRAEUMEN --- Zwei Spalten in chat_teilnehmer statt einer, wegen eines Randfalls: Bei einem Gespraech ohne jede Nachricht waere die Grenze 0 -- und 0 heisst sonst "nie geloescht". geloescht_am unterscheidet die beiden. Die Grenze wirkt in der Liste, im Verlauf, in der Vorschau, in der SUCHE, bei den Anhaengen und in der Ungelesen-Zahl. Die Suche ist die Stelle, an der so etwas typischerweise durchrutscht: aus der Liste weg, ueber die Suche noch da. --- DER FUND: 323 PIXEL --- Ein Bild ist spaeter fertig als der Rest der Seite. Beim Oeffnen springt der Verlauf ans Ende, dann kommt das Foto an und schiebt alles darunter weg -- man steht ploetzlich mittendrin, ohne etwas angeklickt zu haben. Das width/height-Attribut am <img>, wie man es ueberall liest, hilft hier NICHT: Es gibt nur das Seitenverhaeltnis. Damit daraus eine Hoehe wird, muss die Breite feststehen -- bei "width: auto" und einem nicht geladenen Bild ist sie 0. Der Platz wird jetzt am KASTEN reserviert (aspect-ratio + max-width aus den gemessenen Massen). Und die Pruefung dazu hatte denselben Fehler wie das Auge: Sie mass in einem Fenster, in dem das Bild laengst im Zwischenspeicher lag, und meldete tadellose 0 px. Sie misst jetzt in einem FRISCHEN Browser -- der Fall, um den es geht, ist der erste. --- SICHERUNG --- chat-anhaenge/ ist im selben Zug in tools/sicherung-holen.sh eingetragen, nicht spaeter, wenn es auffaellt: Genau so ist die Luecke bei den Profilbildern entstanden. tools/wiederherstellung-proben.mjs bestaetigt: "der Server benutzt 4 Datenordner", keiner fehlt. --- Pruefung --- server/pruef-chat-anhaenge.mjs, neu, 60 Pruefungen, alle gruen. Abschnitt 3 versucht ausdruecklich, hereinzukommen: HTML als bild.png, SVG als foto.png, SVG als svg, eine Textdatei, ein PNG-Kopf ohne Inhalt -- alle fuenf mit 415 abgewiesen, ein echtes JPEG danach mit 201 angenommen (sonst bewiese der Block nur, dass gar nichts durchkommt). 13 MB geben 413 mit lesbarem Text, nicht 500. Konsolenfehler werden nach ZEITPUNKT getrennt, nicht nach Statusnummer: Was waehrend eines absichtlichen Versuchs entsteht, ist gewollt. Nach Nummer zu filtern waere bequem und wuerde ab morgen echte 404 mit verschlucken. Ausserdem gruen: pruef-chat, pruef-chat-optik, pruef-chat-ausbau, pruef-css-klassen. Angesehen bei 1440 px und bei 390 px. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
e28724564a |
Chat: sechs Ergaenzungen -- und ein Absturz, den nie jemand gesehen hat
Filipe: "die kategorie chat, boah ich will dass du die wirklich ueberall perfektionierst. wirklich alles was gratis ist und hinzugefuegt werden kann ohne problem will ich drin haben bitte. ich will das es hoch profissionel und ultra krass geil ist." Zuerst Bestand aufgenommen, nicht gebaut: Suche, Ungelesen-Zahlen, die "ab hier neu"-Linie, Lesestand, Live-Strom, Antworten mit Zitat, Zuruecknehmen und Enter-zum-Senden gab es schon. Dazugekommen ist, was gefehlt hat und ohne fremde Bibliothek geht: 1. ADRESSEN SIND ANKLICKBAR. Gebaut als echte Knoten, nie ueber innerHTML -- ein Chat ist die eine Stelle, an der jeder schreiben darf. Erkannt wird bewusst wenig (http, https, www.): Wer mehr erkennt, macht irgendwann aus "z.b." einen Link ins Nichts. Satzzeichen am Ende bleiben beim Satz. rel="noopener noreferrer". 2. KOPIEREN je Nachricht, mit Rueckfall auf "Text markieren", wenn der Browser die Zwischenablage nicht hergibt. 3. DER VERLAUF REISST NIEMANDEN MEHR WEG. Vorher sprang er bei JEDEM Neuzeichnen ans Ende -- wer weiter oben nachlas und dabei eine Nachricht bekam, verlor die Stelle. Jetzt bleibt er stehen, und ein Knopf sagt, WIE VIEL unten wartet, nicht nur DASS etwas da ist. 4. ENTWUERFE JE GESPRAECH. Wer mitten im Satz wechselt, findet ihn wieder. Im localStorage, nicht auf dem Server: Ein Entwurf ist nichts, was jemand anders sehen soll. Abgeschickt heisst geloescht. 5. EMOJI-AUSWAHL, dreissig feste Zeichen, eingefuegt an der Cursorstelle. Am Handy hat die Tastatur sie ohnehin -- am Rechner nicht, und dort sitzt die Betreuung. 6. ZEICHENZAEHLER, sichtbar ab 400 Rest. Die Grenze steht NICHT im Skript, sondern kommt aus dem maxlength des Feldes -- zwei Stellen fuer dieselbe Zahl laufen auseinander. --- DER FUND, um den es eigentlich geht --- Die neue Pruefung hoert auf "pageerror". Damit kam sofort neun Mal dieselbe Meldung: "Cannot set properties of null (setting 'hidden')", raumOeffnen, Zeile 278. Ursache: verlaufZeichnen() leerte den Verlaufskasten mit `textContent = ''`. Darin liegt aber #verlauf-leer, der Absatz "Links ein Gespraech auswaehlen". Nach dem ersten Zeichnen gab es ihn nicht mehr, und raumOeffnen faellt sechs Zeilen weiter darueber. Die Folge ist nicht die Fehlermeldung, sondern der Abbruch: Beim ZWEITEN Aufruf liefen history.replaceState, gelesenMelden() und raeumeZeichnen() nie. Der zweite Aufruf ist der Normalfall -- der Ereignisstrom ruft nach jedem Verbindungsaufbau genau das, um nachzuholen, was waehrend der Pause geschrieben wurde. Dieses Nachholen hat nie funktioniert. Von aussen sah alles normal aus; nur die Konsole wusste Bescheid. Behoben, indem nur noch die Nachrichten entfernt werden und der Absatz stehenbleibt. Abschnitt 8 der Pruefung wechselt jetzt dreimal zwischen zwei Gespraechen OHNE Neuladen und verlangt null Abstuerze. --- UND EIN ZWEITER, der schon laenger drin war --- Abschnitt 9 misst den Kontrast an der wirklichen Flaeche (Text kurz unsichtbar, Flaeche fotografiert). Die Fusszeile jeder Nachricht stand auf --text-still: auf der eigenen Blase 3,68:1, unter den 4,5:1 fuer Text dieser Groesse. Aufgefallen ist es nie, weil niemand nachgemessen hat. Jetzt traegt .chat-nachricht__fuss EINE Farbe (--text-leise, 4,81:1) und Uhrzeit, antworten, zuruecknehmen und kopieren erben sie -- statt vier eigener Angaben, die beim naechsten Mal auseinanderlaufen. --- Pruefung --- server/pruef-chat-ausbau.mjs, neu, 64 Pruefungen, alle gruen. Zu jedem Punkt eine Gegenprobe: kein Link ohne Adresse, keine Auszeichnung aus <b>/<img onerror>, kein Kopier-Knopf an zurueckgenommenen Nachrichten, kein Sprungknopf fuer den, der schon unten steht, kein Entwurf nach dem Abschicken, ein absichtlich zu dunkler Text faellt durch, und ein absichtlich geworfener Fehler wird bemerkt (sonst waere Abschnitt 10 auch gruen, wenn niemand zuhoert). Ausserdem gruen: pruef-css-klassen, pruef-chat, pruef-chat-optik. Angesehen bei 1440 px und bei 390 px. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
6676998af8 |
Niemand sieht VanVan ausser DogFather -- plus vier Punkte vom Screen
--- DAS WICHTIGSTE ZUERST: die Verbergungsregel --- Filipe, ausdruecklich und dringlich: "und noch gaaaaaanz wichtig keiner soll vanvan sehen ausser ich, ueberall soll keiner vanvan sehen ausser dogfather." ES GAB DAVON NUR EINE HAELFTE. In der Personenliste wurde der zweite Admin-Zugang fuer Spicy Media ausgeblendet (Wunsch vom 31.08.). Ueberall sonst -- Chat, Kalender, Aufgaben, Dateien, Zentrale -- war er sichtbar. `sichtbarePersonenIds` hat ihn sogar ausdruecklich JEDER Rolle gezeigt, weil sie alle Admins einsammelt. WORAN DIE BEIDEN AUSEINANDERGEHALTEN WERDEN: In der Datenbank tragen beide die Rolle `admin`, es gibt kein unterscheidendes Feld. Der Unterschied, den es wirklich gibt, ist das Alter -- DogFather ist der erste Zugang. Also: der Admin mit der kleinsten Nummer ist DogFather, alle weiteren sind verborgen. Drei Ausnahmen: DogFather sieht alle, ein verborgener Zugang sieht sich selbst, und bei nur einem Admin gibt es nichts zu verbergen. WARUM AN EINER STELLE UND NICHT IN DEN ABFRAGEN: Allein workspace-personen.js hat 23 Abfragen auf `personen`. Eine Regel, die man 23-mal wiederholt, ist 23 Gelegenheiten, sie zu vergessen -- und beim Vergessen faellt niemand auf die Nase, sondern jemand SIEHT etwas. Die Regel sitzt deshalb in `verborgeneIds()` und wird ueber einen MANTEL um die sechs Listenfunktionen gelegt: Diese haben zusammen achtzehn Rueckgabewege; sie einzeln zu flicken waeren achtzehn Gelegenheiten, einen zu uebersehen. Die ungefilterten Fassungen (`...Roh`) werden nicht mehr exportiert -- niemand kann sie versehentlich benutzen. `null` HIESS BISHER "SIEHT ALLES". Sobald es etwas zu verbergen gibt, gilt das nicht mehr: Die Liste wird ausgeschrieben. Das ist strenger, nicht lockerer. NEUE PRUEFUNG server/pruef-verborgen.mjs -- sechs Personen (darunter ein zweiter Admin), fuenf Schnittstellen, jede Rolle einzeln. Sie hat beim ersten Lauf sofort ein Loch gefunden, das ich sonst nicht bemerkt haette: Die ZENTRALE holt sich das Haus selbst und ging an allen Listenfunktionen vorbei -- Spicy Media sah VanVan dort als Segment im Team-Ring. Und beim Korrigieren der Pruefpfade fiel ein zweites auf: `darfEintragen` im Kalender liess die Leitung JEDEN eintragen, bevor ueberhaupt eine Liste befragt wurde. Eine Sichtbarkeitsregel, die nur beim Lesen gilt und nicht beim Schreiben, hat ein Loch in der Mitte. Die Pruefung hat eine Gegenprobe: Ein Manager MUSS DogFather in derselben Liste sehen -- sonst waere "sieht VanVan nicht" auch dann gruen, wenn die Listen leer zurueckkaemen. --- screen1 Punkt 1: Silber mit Babyblau --- "ich will dass diese farbe gemischt wird mit babyblau." #c7dcf4 statt #d8e0ec -- dieselbe Helligkeit, mit Blaurichtung. Nachgerechnet bleibt der Abstand zur naechsten Rolle bei 0,1790, immer noch weiter als das frueher benutzte Babyblau (0,1349). Gemischt ist es ausserdem SICHTBAR: Die Schiene laeuft von Silber nach Babyblau, und der Glanz traegt beide Toene. Eine Mischung, die man nur im Hexwert findet, ist keine. --- screen1 Punkt 2: das Wasserzeichen --- "soll viel groesser sein und nicht so abgecuttet sondern gut zu sehen sein." NACHGEMESSEN war es auf der Dashboard-Kachel zu 50 Prozent abgeschnitten, und zwar auf DREI Seiten: 36 px ueber dem oberen Rand, 44 rechts, 60 unten -- 220 px Zeichen auf einer 152 px hohen Kachel. UND ES GAB ZUM DRITTEN MAL DIESE WOCHE EINE DOPPELREGEL: 3600 Zeilen unter der sorgfaeltig begruendeten Fassung (156 px bei 0,14) stand eine zweite (118 px bei 0,085) mit derselben Spezifitaet. Sie gewann, und die Begruendung oben war wirkungslos. Am 08.09. hatte ich beim Wasserzeichen schon einmal genau so eine Doppelung gefunden -- und diese hier uebersehen. Jetzt eine Fassung, und die Groesse haengt an der KACHELHOEHE: Ein um 8 Grad gedrehtes Quadrat der Seite S braucht S x 1,129 Platz, also `min(132px, 100% - 30px)`. Nachgemessen 100 Prozent sichtbar statt 50, bei 0,14 statt 0,085 -- die sichtbare Flaeche hat sich verdoppelt. --- screen1 Punkt 3: die Personenliste in einer Kachel --- Die fuenf Rollengruppen standen als fuenf lose Abschnitte frei auf dem Hintergrundbild. Es ist aber EINE Liste mit fuenf Abschnitten. Jetzt eine Sammelkachel aus der Modulliste, mit dunklen Fugen statt Luft -- und dunkler als die Karten darin, wie eine Vitrine. --- screen1 Punkt 4: "Womit meldest du dich an?" --- Der einzige Satz auf der Anmeldeseite, der eine FRAGE stellt, stand als graue Feldbeschriftung da. Jetzt gebuerstetes Metall, ein Anschlag aus drei Kerben in Rot und Babyblau und eine auslaufende Linie -- dieselbe Sprache wie die Typenschilder im Workspace. Rueckfall vollwertig: Faellt `background-clip: text` aus, steht dort heller Text. Geprueft: pruef-verborgen (neu), pruef-rollen, pruef-start-ansicht, pruef-css-klassen, pruef-workspace-seiten, pruef-buehne, pruef-handy, pruef-chat, pruef-kalender -- alle in Ordnung. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
1ad22b55c4 |
Ring so gross wie die Uhr, Stunden geschaerft, Report-Karten gerade, Schutz wird Magenta
--- screen1: Glocke nach rechts, Ring so gross wie die Uhr ---
"dieser button links vom kreis soll rechts davon sein und der kreis
soll die gleiche groesse wie die uhr haben."
Die KAESTEN waren schon exakt gleich gross (248 x 248, seit gestern aus
einer Variablen). Der gezeichnete Ring aber nicht: Sein aeusserer Bogen
lag bei Radius 128 von 150, plus halbe Strichbreite also bei 132,5 --
88 Prozent des Kastens, gerendert 219 statt 248 px. Die Uhr daneben
fuellt ihren Kasten ganz aus, ihr Leuchtkranz ragt sogar 7 px darueber
hinaus. Zwei gleich grosse Kaesten mit ungleich grossem Inhalt sehen
ungleich gross aus.
Jetzt 145 statt 128 (aussen) und 120 statt 106 (die Segmente) --
dasselbe Verhaeltnis zueinander, nur bis an den Rand. 145 + 4,5 =
149,5 von 150: ein halber Pixel Luft, damit die runde Kappe nicht
abgeschnitten wird.
Die Glocke steht jetzt rechts vom Ring. Damit liegen beide Knoepfe
INNEN, zwischen den Instrumenten und dem Text -- vorher sassen sie an
den beiden Aussenkanten, so weit voneinander entfernt wie moeglich,
obwohl sie dasselbe tun: einstellen, was einen erreicht.
--- screen2: die Stunden ---
"die stunden muss noch perfektionnieren."
DIE LICHTKANTE WAR EIN KRATZER. Sie stand auf 50 Prozent Weiss bei 0,9
Breite. Auf den schmalen Sekunden- und Minutenbahnen ist das eine
Kante; auf dem 5,8 px breiten Stundenbalken war es ein zweiter,
weisser Balken auf dem roten. Der Grund ist Verhaeltnis UND Farbe:
0,9 von 3,2 sind 28 Prozent, 0,9 von 5,8 nur 16 -- aber die Stunde ist
die einzige deckende, kraeftig gefaerbte Bahn, und auf Rot faellt
dasselbe Weiss doppelt so stark auf wie auf Silber. Jetzt 22 Prozent
bei 0,6 Breite.
DER KOPF BLEIBT ROT. Er stand auf #ffd9dd, also fast weiss -- das
aktuelle Glied war zwar das hellste, hatte aber die Farbe seiner Bahn
verloren und sah aus wie ein Fremdkoerper zwischen den roten Balken.
Jetzt ein helles, deutliches Rot: Es hebt sich durch Helligkeit ab,
nicht durch eine andere Farbe.
--- screen3: die Report-Karten stehen gerade ---
"ich will dass alles passt, nicht bedeckt ist, schief steht oder zu
tief oder zu hoch."
NACHGEMESSEN, ALLE 17 KARTEN -- der Befund deckt sich genau mit dem,
was er beschreibt: Name und Zahl lagen 12 bis 28 px auf VERSCHIEDENEN
Hoehen, sie ueberlappten sich waagerecht (gemessener Abstand -183 bis
-524 px), und Karten in derselben Reihe waren verschieden hoch.
DIE URSACHE IST EINE ZEILE: `.kachel__zahl` steht `position: absolute`
bei top 13 / right 13. Auf der Startseite ist das richtig -- gleich
grosse Kacheln, einzeiliger Name. Hier bricht der Name um ("Community:
neue Eintraege"), die Karte waechst nach unten, die Zahl bleibt oben
kleben. Sie war ausserdem fuer die Hoehenrechnung unsichtbar, weshalb
es vorher schon eine `min-height` als Pflaster brauchte.
Jetzt ein echtes Raster: Name links (Zeile 1), Trend darunter, Zahl
rechts ueber beide Zeilen und mittig. `display: contents` auf dem
Wrapper -- so werden seine Kinder selbst zu Rasterfeldern, ohne dass am
HTML etwas geaendert werden muss und ohne dass die Startseite, die
dieselben Klassen benutzt, etwas davon mitbekommt.
Nachgemessen danach: 17 von 17 sauber -- nichts ragt heraus, nichts
ueberlappt, nichts abgeschnitten, kein Versatz ueber 5 px, und keine
Reihe mit ungleichen Hoehen.
--- screen4: Schutz & Regeln wird Magenta ---
"ich will dass die kategorie eine farbe bekommt die extrem krass
auffaellt. diese kategorie ist naemlich seeeehr wichtig."
MAGENTA, WEIL ES DAS EINZIGE IST, DAS ES SONST NICHT GIBT. Rot ist fuer
"ueberfaellig" und Spicy Media vergeben, Babyblau fuer DogFather, Lila
fuer Manager, Gruen fuer Scout, Bronze fuer Creator, Bernstein fuer
"dringend". #ff2fd0 stoesst mit keinem davon zusammen -- es faellt
nicht auf, weil es HELLER ist, sondern weil es einzigartig ist. Das
ist verlaesslicher: Helligkeit konkurriert mit den Nachbarn,
Einzigartigkeit nicht.
Gerechnet wie bei Ton 21: Abstand zum naechsten Nachbarn 0,1305 (die
Grenze im Satz liegt bei 0,0973), Buntheit 0,276 -- die hoechste im
ganzen Satz, das alte Gold lag bei 0,170 --, Kontrast 6,00:1. Von
sieben Kandidaten sind drei an der Abstandsgrenze gescheitert. Das
Saeuregelb #e0ff00 waere lauter gewesen (16,86:1), haette sich aber
mit dem Bernstein von "dringend" und dem Gold der Nachbarkacheln um
dieselbe Wirkung gestritten. Die Kachel bleibt gebaut wie alle
anderen; was sie heraushebt, ist die Farbe, keine Sonderform.
--- Eine Rueckwirkung, die pruef-buehne gefunden hat ---
Die Typenschilder von gestern nutzen `background-clip: text` -- dafuer
MUSS `color: transparent` sein. pruef-buehne las genau dieses `color`,
machte daraus Schwarz und meldete 1,07:1 fuer Text, der hell und gut
lesbar ist. Fuenf Fehlalarme auf drei Seiten.
Eine Warnung, die bei richtiger Arbeit anschlaegt, wird abgeschaltet.
Sie ist deshalb nicht weichgemacht, sondern GENAUER geworden: Bei
Verlaufsschrift zaehlt jetzt der DUNKELSTE Farbstopp der ersten
Hintergrundebene -- der schlechteste Punkt, den es auf dieser Schrift
wirklich gibt. Damit meldet start.html 4,74:1 (noetig 4,5), die
Pruefung findet also weiter die engste Stelle.
UND DIE GEGENPROBE HAT SOFORT EINEN FEHLER IN MEINEM EIGENEN CODE
GEFUNDEN: Ich suchte das Ende der ersten Ebene mit `"),"` -- diese
Zeichenfolge steht aber schon am Ende des ERSTEN `rgb(...)`. Die
Messung las damit immer nur den ersten Stopp und haette einen dunklen
Verlauf fuer hell gehalten. Jetzt wird ueber Klammern gezaehlt. Der
Helfer steht einmal und wird als Quelltext in beide Seiten-Aufrufe
gereicht -- zwei Kopien waeren zwei Gelegenheiten auseinanderzulaufen.
Geprueft: pruef-buehne (mit neuer Gegenprobe), pruef-start-ansicht,
pruef-css-klassen, pruef-handy, pruef-workspace-seiten -- alle in
Ordnung.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
7de32a5ec7 |
Punkt 15: Der Chat bekommt Suche, Antworten mit Zitat und die Ungelesen-Linie
Wunsch Filipe: "ich will dass du diese seite viel krasser und detaillierter machst, ich will dass du dich informierst und alles reinsetzt was wir noch gebrauchen koennten." NICHT ALLES, SONDERN WAS TAEGLICH FEHLT. Der Chat konnte schon Raeume, Verlauf, Gelesen-Stand, Live-Zustellung, Gruppen und Zuruecknehmen. Drei Dinge fehlten, und jedes davon kostet ohne es echte Zeit: 1. SUCHE IN DEN NACHRICHTEN. Ein Chat ohne sie ist ab dem zweiten Monat ein Archiv, in dem man nichts findet. Ein Suchfeld gab es -- es durchsuchte aber nur die NAMEN der Gespraeche, also die kleinere Haelfte. Jetzt durchsucht dasselbe Feld beides und zeigt die Fundstellen UNTER der Gespraechsliste: Wer "Patrick" eingibt, will vielleicht das Gespraech und vielleicht die Nachricht -- ein Umschalter haette ihn zwingen wollen, das vorher zu wissen. 2. ANTWORTEN MIT ZITAT. Zu zweit weiss man meistens, worauf sich etwas bezieht. In einer Gruppe laufen drei Faeden parallel, und "ja, mach das" kann alles heissen. Das Zitat steht IN der Blase (es gehoert zur Antwort, nicht darueber) und fuehrt per Klick zur Stelle. 3. DIE LINIE "AB HIER NEU". Wer nach zwei Tagen zurueckkommt, sucht sonst die Stelle, an der er aufgehoert hat, indem er Uhrzeiten liest. BEWUSST NICHT GEBAUT: Anhaenge (dafuer gibt es den Dateien-Bereich mit Rechten und Ablauf), Reaktionen (eine vierte Sache, bevor die drei sich bewaehrt haben) und Tipp-Anzeigen (dauernder Verkehr fuer eine Auskunft, die man in zwei Sekunden ohnehin sieht). DIE SICHERHEIT DER SUCHE STEHT IM JOIN, nicht in einer nachtraeglichen Pruefung: `chat_teilnehmer` wird mit der eigenen Personenkennung verbunden, und was dort nicht drinsteht, kommt gar nicht erst aus der Datenbank. Ein Filter, der erst hinterher aussortiert, ist eine Zeile davon entfernt, vergessen zu werden. Ebenso beim Zitat: Worauf geantwortet wird, muss im SELBEN Raum liegen -- sonst koennte jemand die Kennung aus einem fremden Gespraech mitschicken, und beim Empfaenger stuende ein Zitat aus einem Raum, den er nie gesehen hat. DREI FEHLER, DIE DER DURCHLAUF GEFUNDEN HAT: 1. `ESCAPE '\'` IN EINEM TEMPLATE-LITERAL. Dort ist `\'` eine Fluchtsequenz fuer das Anfuehrungszeichen -- SQLite bekam ein LEERES Fluchtzeichen und antwortete "ESCAPE expression must be a single character". Die Suche war damit komplett tot. Kein Syntaxfehler, kein Warnhinweis: Erst der Aufruf mit echten Daten hat es gezeigt. 2. DIE MASKIERUNG KANNTE ZWEI VON DREI ZEICHEN. `%` und `_` waren dabei, der Backslash nicht -- ausgerechnet das Fluchtzeichen selbst. Geprueft wird das jetzt an der ZEILE AUS DER DATEI, nicht an einem Nachbau: Mein erster Test hat die Maskierung nachgebaut und dabei die Shell-Maskierung mitgeschleppt -- er meldete einen Fehler, den nur er hatte. 3. DIE UNGELESEN-LINIE SCHIEN NICHT ZU FUNKTIONIEREN. Sie tat es -- mein Testaufbau war falsch: Filipes Seite war noch offen, die neuen Nachrichten kamen ueber den Live-Strom an und wurden sofort als gelesen gemeldet. Es gab schlicht nichts Ungelesenes. Erst als er die Seite verlaesst, bevor Patrick schreibt, steht die Linie da -- und zwar genau vor "Neu von Patrick, eins", und beim zweiten Oeffnen ist sie weg. Der Gelesen-Stand wird deshalb beim OEFFNEN mitgeschickt, bevor er gesetzt wird -- eine Zeile spaeter waere er immer die letzte Nachricht, und die Linie staende nie irgendwo. Ohne Volltextindex, mit Absicht: `LIKE` liest die Tabelle, und bei einem Team dieser Groesse sind das einige tausend Zeilen. Ein FTS5-Index waere eine zweite Tabelle, die synchron gehalten werden muss -- genau daran gehen solche Sachen kaputt. Wenn der Verlauf sechsstellig wird, ist das der Zeitpunkt dafuer, nicht heute. Geprueft: pruef-chat, pruef-chat-optik, pruef-css-klassen, pruef-workspace-seiten, pruef-handy -- alle in Ordnung. Dazu im Browser durchgespielt: Zitat gesetzt und gelesen, Suche nach "Bitrate" (1 Treffer), nach "100 %" (1 Treffer -- die Maskierung haelt), nach Unsinn (0), einbuchstabige Suche (zu kurz), Antwortleiste mit dem richtigen Namen, Ungelesen-Linie an der richtigen Stelle und beim zweiten Oeffnen weg. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
e616d88a30 |
Punkt 7: Vier Koennensstufen in den Bereichslisten -- Anfaenger bis Meister
Wunsch Filipe: "ich will dass es in diesen kategorien ... kategorien
gibt wie jetzt, aber fuer anfaenger, fortgeschrittene, profis .... falls
es noch eine kategorie gibt fuege ruhig hinzu. informiere dich so krass
wie es nur geht ... und dan will ich dass du das perfekt alles aufbaust
mit aufgaben und so."
VIER STUFEN, UND DIE VIERTE IST NICHT AUSGEDACHT. In den gaengigen
Kompetenzmodellen (Dreyfus) folgt auf "kompetent" eine Stufe, auf der
es nicht mehr um das eigene Koennen geht, sondern darum, dass es OHNE
einen weiterlaeuft. Genau daran haengen die elf Punkte der obersten
Stufe: Vorlagen, eingewiesene Vertretung, abgelegte Loesungen.
Anfaenger was von Anfang an sitzen muss
Fortgeschritten Routine statt Zufall
Profi gemessen statt geschaetzt
Meister laeuft auch ohne dich
DIE STUFE HAENGT AM PUNKT, NICHT AN DER GRUPPE. Eine Gruppe ist ein
ABLAUF ("Vor der Sendung"), eine Stufe ist ein KOENNEN. Als Gruppen
gebaut waeren es zwoelf Abschnitte statt drei, und dieselbe Frage
stuende viermal da. So bleibt der Ablauf die Gliederung und die Stufe
ein Filter darueber.
DIE INHALTE SIND RECHERCHIERT, NICHT AUSGEDACHT. 47 vorhandene Punkte
haben eine Stufe bekommen, 28 neue sind dazugekommen -- ueberwiegend
auf Profi und Meister, weil der Bestand dort duenn war. Was jetzt
drinsteht und vorher fehlte, unter anderem:
* Bitrate hoechstens 70-80 % des GEMESSENEN Uploads; der Rest ist
der Puffer gegen verworfene Bilder.
* Keyframe-Abstand zwei Sekunden -- alles andere kann beim
Zuschauer zu Puffern oder gar nicht erst zum Abspielen fuehren.
* Tonfilter in der Reihenfolge Rauschunterdrueckung, Kompressor,
Rauschsperre: Ein Kompressor davor hebt das Rauschen mit an.
* Hardware-Encoder statt Prozessor -- der groesste Einzelgewinn an
Stabilitaet.
* Verworfene Bilder ABLESEN: Leitung und Kodierung sind zwei
verschiedene Fehler mit zwei verschiedenen Loesungen.
* Eskalationsleiter in vier Stufen (ansprechen, loeschen, Auszeit,
Sperre) -- vorher festgelegt, weil Ungleichbehandlung das ist, was
Communitys spaltet.
* Moderatoren EINGEWIESEN, nicht nur ernannt: Regeln schriftlich,
Eskalationsleiter, Werkzeuge einmal gezeigt.
* Privater Probelauf statt Programmvorschau -- erst der zeigt, was
beim Zuschauer ankommt.
Zahlen: LIVE 33 Punkte (11/10/8/4), Community 23 (7/7/5/4), Technik 19
(6/6/4/3). Jeder Punkt hat genau eine Stufe -- nachgemessen, nicht
angenommen.
DIE VORGABE IST "ALLE". Ein Filter, der beim Oeffnen schon etwas
versteckt, laesst einen Punkte suchen, die man gestern noch gesehen
hat. Die Gruppenzahlen zaehlen mit dem Filter mit; eine Gruppe, in der
nichts uebrigbleibt, sagt das in einem Satz statt leer dazustehen.
Die vier Stufenfarben sind GELIEHEN, nicht ausgesucht: dieselben, die
auf der Uebersicht schon "offen / dringend / laeuft / erledigt"
tragen. Wer die eine Seite kennt, liest die andere ohne Legende.
ZWEI EIGENE FEHLER UNTERWEGS:
1. NAMENSKOLLISION. Ich habe die Marke `fest-punkt__stufe` genannt --
den Namen gibt es dort laengst fuer den BEARBEITUNGSstand (Offen /
Passt so / Verbessern). Gemessen standen danach 66 Marken an 33
Punkten, und mein neues CSS faerbte den alten Behaelter mit. Heisst
jetzt `__koennen`. Zwei verschiedene Dinge unter einem Namen ist
derselbe Fehler wie zwei Regeln fuer dieselbe Sache, nur eine Ebene
frueher.
2. SCHRIFTGROESSE. Die Marke stand auf 0,66 rem = 10,56 px.
pruef-css-klassen hat es sofort gemeldet (44 statt 43 Stellen unter
11,5 px). Jetzt 0,72 rem.
Geprueft: pruef-checkliste, pruef-css-klassen, pruef-workspace-seiten,
pruef-schulung -- alle in Ordnung. Dazu alle drei Bereiche im Browser
durchgefiltert.
Quellen der Recherche: obsproject.com (NVENC/Encoder), dacast.com und
obs-versions.com (Bitrate, Keyframe, Tonfilter), switcherstudio.com
(Probelauf), help.twitch.tv und sendbird.com (Moderation,
Eskalation), jeffbullas.com (Einweisung von Moderatoren).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
6815ba89ba |
screen1/2/3: Zahlen werden Ziele, Titel werden Typenschilder, DogFather wird Silber
--- screen1: die sieben Zahlen fuehren zu ihren Aufgaben ---
"wenn ich auf die druecke soll ich auf zu denen punkten gebracht
werden."
Der Weg dahin gab es laengst: `aufgaben.html?zeigen=<schluessel>`
springt zu den passenden Karten und legt eine Zeile darueber, was
gezeigt wird. Nur waren die sieben Karten `<li>` ohne Link -- die
Auskunft war da, der Weg dorthin nicht.
Zwei Schluessel fehlten und sind nachgetragen: "heute" (die Karten
tragen dafuer jetzt `data-heute`, denn "heute faellig" ist ein eigener
Zustand und kein Sonderfall von "ueberfaellig") und "abgebrochen" --
das klappt zusaetzlich den Kasten auf, in dem die Abgebrochenen
stehen. Ein Sprung in einen zugeklappten Kasten laesst einen glauben,
der Knopf sei kaputt.
EIN <a> IM <li>, NICHT DAS <li> KLICKBAR: Ein Listenpunkt mit einem
Klick-Zuhoerer ist fuer Tastatur und Vorleseprogramm kein Ziel. Die
Trefferflaeche wird ueber ein durchsichtiges `::after` auf die ganze
Kachel gestreckt -- im ersten Anlauf stand dort `padding: inherit`,
was die 14/16 der Kachel ein zweites Mal aufgetragen und sie siebenmal
um 28 px verbreitert haette.
DIE NULL BLEIBT EIN LINK. Der Sprung zeigt dann eine leere Spalte mit
der Zeile "Aufgaben, die offen sind" -- das ist eine Antwort. Ein
toter Knopf ist keine.
--- screen2: die Kategorietitel werden Typenschilder ---
"die titel von den kategorien sollen spezieller und geiler sein."
Fase statt Rundung (die Pille war das einzige Rund auf einer Seite aus
abgeschraegten Platten), ein gepraegter Anschlag aus drei Kerben
statt eines Strichs, gebuerstetes Metall in der Schrift und eine
auslaufende Linie nach rechts.
UND DABEI EIN FUND: Der "leuchtende Strich" vor "Was ist dran" und
"Deine Aufgaben" wurde NIE GEZEICHNET. `.zahlen-block .feldschild`
setzt `display: flex`, damit das Pseudoelement eine Box bekommt --
rund 1200 Zeilen spaeter steht `.inhalt .feldschild { display: block }`
mit derselben Spezifitaet, und die spaetere gewinnt. Das Schild war
`block`, das Pseudoelement damit `inline`, und ein Inline-Kasten
ignoriert `width` und `height`. Aufgefallen ist es nur, weil mein
neuer Anschlag ebenfalls unsichtbar blieb und die Messung sagte: Der
Text beginnt bei x=12, also genau an der Polsterung -- davor belegt
nichts Platz.
Die Gegenprobe hat mich dabei vor einer falschen Reparatur bewahrt:
Ich hatte den Textverlauf (`background-clip: text`) im Verdacht.
Einmal mit und einmal ohne gemessen -- in beiden Faellen x=12. Damit
war die Ursache ausgeschlossen, bevor ich an der falschen Stelle
gearbeitet habe.
--- screen3: DogFather wird Silber, der Husky wird das echte Logo ---
"dieses husky symbol soll ersetzt werden durch den husky oben in der
leiste. und die farbe von der rolle und die barre soll so richtig geil
silber sein ... und der husky soll eine geile babyblau [Auge] haben."
Damit kehrt die Rolle zu dem zurueck, was im allerersten Auftrag stand
("husky: silber und blaue augen").
DAS ZEICHEN war eine geometrische Eigenkonstruktion -- ein Fuenfeck mit
zwei dreieckigen Ohren. Ordentlich gebaut, aber nicht DER Husky: Oben
in der Leiste steht die richtige Marke, und zwei verschiedene Huskys
auf einer Seite sind einer zu viel. Jetzt das echte Logo als <image>,
eingefaerbt mit `feComponentTransfer` -- eine zweistufige Tabelle
bildet Schwarz auf dunklen Stahl und Weiss auf Silber ab. Ein
`feColorMatrix` koennte das nicht; er mischt nur linear und zoege die
Mitteltoene flach.
DAS AUGE IST GEMESSEN, NICHT GESETZT: Ein Durchlauf ueber die
Bildpunkte hat die Pupille als einzige dunkle Insel gefunden, die
ringsum von Hellem umgeben ist -- bei 165/258 von 512, also 32,2 % und
50,4 %.
DIE ROLLENFARBE NACHGERECHNET, weil Silber gefaehrlich ist: Es hat
kaum Buntheit und koennte neben einer anderen Rolle verschwinden. In
OKLab liegt #d8e0ec 0,1901 von seinem naechsten Nachbarn (Scout)
entfernt -- das bisherige Babyblau lag bei 0,1349. Die fuenf Rollen
sind dadurch BESSER auseinanderzuhalten als vorher. Kontrast 14,41:1.
"wie mit sternen" ist als GLANZ gebaut, nicht als Funkeln: ein
schmales schraeges Spitzlicht und drei winzige Lichtpunkte, alles
still. Ein wanderndes Glitzern auf der Anmeldeseite waere genau das,
was die Hausregel verbietet.
Nebenbei: `rs-silber` faerbte den alten Husky und wird jetzt nirgends
mehr benutzt -- entfernt statt liegengelassen.
--- Aufraeumen ---
`ruf.png` (ein Messbild von mir) war ueber `git add -A` ins Repo und
bis auf den Server gewandert -- die Loeschung kam eine Zeile zu spaet.
Entfernt, und `.gitignore` sperrt jetzt das Praefix `zz-`, das solche
Dateien ab sofort tragen. Eine Regel im Werkzeug ist besser als eine,
an die ich mich erinnern muss.
Geprueft: pruef-rollen (97), pruef-start-ansicht, pruef-css-klassen,
pruef-workspace-seiten -- alle in Ordnung. Dazu die sieben Links und
beide neuen Sprungziele im Browser durchgeklickt.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
cccafd2c31 |
Sechs Wuensche: Hintergruende, Knopfverteilung, Universum, Uhrkoepfe, Knallrot
--- screen3 + screen1: die Hintergruende draengeln nicht mehr --- "die hintergrunde sollen ueberall so sein dass die sich nicht in den vordergrund draengeln." / "mach den hintergrund von dieser kachel dunkler, so dass die die kacheln drin viel mehr auffallen." `--raster` stand auf .26 Deckkraft -- auf dunkler Flaeche kein Hauch mehr, sondern ein gezeichnetes Gitter. Im Tagdialog lief es sichtbar durch die Ueberschrift, in den Sammelkacheln stand es VOR den Karten darin. Jetzt .09: Man sieht eine Struktur, man zaehlt keine Linien. Eine Zahl fuer das ganze Haus -- sie steht einmal in module.css und wird an fuenf Stellen benutzt. Die Anlasskachel im Kalender lag mit rgba(19,26,38,.88) auf demselben Helligkeitsniveau wie die Karten darin: keine Vitrine, sondern eine dritte Flaeche gleicher Lautstaerke. Jetzt fast schwarz. An den Karten musste dafuer nichts geaendert werden -- der Abstand entsteht von selbst. --- screen2: ein Knopf wandert nach links --- "eins von diesen buttons soll links bei dem anderen kreis sein." Die GLOCKE geht nach links zum Ring, der WECKER bleibt rechts bei der Uhr. Das ist nicht ausgewuerfelt: Der Wecker ist eine Uhrzeit. Die Glocke entscheidet, ob man ueberhaupt etwas ueber sein Team erfaehrt -- und der Ring links zeigt genau das. Die Kachel ist damit spiegelsymmetrisch belegt: 48 px Knopf + 14 px Abstand + 248 px Instrument auf beiden Seiten. Genau das rechnet `--spalte`. Die Zentrierung des Rings ist weggefallen -- sie war noetig, solange er allein in einer fuer Instrument PLUS Knopf bemessenen Spalte stand. Der reservierte Platz schrumpft von 104 auf 48 px je Seite; die Begruendung fuer das Reservieren bleibt: Ein Platz, der erst mit der Antwort entsteht, laesst die Zeile springen. --- screen4: zwei Chilis und zwei Huskys dazu --- "setz in den hintergrund noch 1-2 peperonis und dan das logo von dogfather, also nur den husky." DER HUSKY IST EINE MASKE, KEIN BILD. Die Datei ist schwarz-weiss und freigestellt (nachgemessen: 49 % durchsichtig). Als Hintergrundbild bei 15 % verschwaenden die schwarzen Flaechen im dunklen Grund und uebrig blieben die hellen -- ein zerrissener Umriss, kein Hund. Als Maske ueber einer Farbflaeche wird daraus eine geschlossene Silhouette in DogFathers Babyblau. Im Universum schweben jetzt beide Marken in ihren beiden Farben: sieben Chilis rot, zwei Huskys blau. --- screen5: die Punkte sind ersetzt, das letzte Glied leuchtet --- "ich will dass du die punkte ersetzt und immer der letzte soll mehr strahlen oder so." / "alles ist mega ausser die stunden muss du noch perfektionnieren." DIE DREI UMLAUFENDEN PERLEN SIND WEG -- samt 60 Zeilen Rechnung. Sie waren ein zweites Ding an einer zweiten Stelle: eigene Uhr ab dem ersten Takt (weil die volle Unixzeit `rotate(1.07333e+10deg)` ergab), eigener Startwinkel je Bahn, drei Winkel, die die kleineren Einheiten anteilig mittragen mussten. All das war noetig, WEIL der Kopf neben der Reihe herlief statt Teil von ihr zu sein. Genau deshalb trugen sie am 08.09. noch die alten Farben, als die Bahnen getauscht wurden. Jetzt zeichnet eine zweite SVG-Lage genau EIN Glied heller -- dasselbe, das die Reihe darunter zuletzt gesetzt hat, aus denselben Zahlen. Sie kann gar nicht danebenstehen. Heller statt groesser: Waere der Kopf groesser, waere er ein Fremdkoerper in der Reihe. DIE STUNDEN WAREN BREITER ALS LANG -- 5,5 lang bei 7 breit, also 0,79:1. Ein Segment, das breiter ist als lang, liest sich als Klotz quer auf der Bahn statt als Balken entlang. Und weil die Kantenlage nur 0,4 versetzt ist, lief der 0,9 breite Lichtstrich MITTEN DURCH jeden Balken statt an seiner Kante. Jetzt 10 lang bei 5,8 breit (1,7:1), und der Kantenversatz ist nach Bandbreite gestaffelt: (Breite - 0,9) / 2, also 0,75 / 1,65 / 2,05 zusaetzlich zur Gruppe. --- screen6: die Scout-Pipeline wird knallrot --- "die farbe von dieser kategorie soll knall rot sein." Die anderen zwanzig Kachelfarben sind gerechnet (OKLab, groesstmoeglicher Abstand). Diese eine ist gewuenscht -- und wurde deshalb GEGEN den Satz geprueft statt eingetragen: Der engste vorhandene Abstand liegt bei 0,0973. #ff1f2e kommt seinem naechsten Nachbarn auf 0,1228 nahe, ist also weiter entfernt als das engste vorhandene Paar. Kontrast 5,01:1 (noetig 4,5). Von sechs geprueften Rottoenen der mit dem groessten Abstand UND genug Kontrast. tools/kachel-farben.mjs weiss jetzt davon: Ein kuenftiger Lauf wuerde wieder Rosa vorschlagen, und das waere eine stille Ruecknahme einer ausdruecklichen Entscheidung. --- Ein Messfehler, der festgehalten gehoert --- Beim Pruefen von screen4 meldete meine Foto-Methode vier Beschriftungen unter 4,5:1 -- bei einem Verlust von 0,00 bis 0,15 durch das Universum. Dass die Ursache nicht das Universum sein konnte, stand damit schon in den Zahlen. Exakt gerechnet (Vordergrundfarbe gegen die tatsaechliche Flaeche darunter) liegen dieselben Texte bei 9,13:1 bis 10,76:1. Die Foto-Methode mittelt ueber alle helleren Bildpunkte, und bei duenner Grossbuchstabenschrift ist die Haelfte davon halb ausgeleuchtete Kantenpunkte. Fuer grosse Schrift taugt sie, fuer kleine Versalien meldet sie systematisch zu wenig. Haette ich ihr geglaubt, haette ich vier Farben "repariert", die in Ordnung sind. Geprueft: pruef-start-ansicht, pruef-css-klassen, pruef-kalender, pruef-buehne, pruef-handy, pruef-workspace-seiten, pruef-tagesruf -- alle in Ordnung. Dazu Ring und Uhr auf 248/248 nachgemessen, die Kopf-Muster gegen die Uhrzeit nachgerechnet (01:24:59 -> Sekunde bei 281,115, Minute bei 96,76, Stunde bei 16,493) und die Kachelfarbe gegen alle zwanzig anderen in OKLab geprueft. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
ef6bf0d011 |
screen1 (neu): Aus dem Siegel wird eine Urkunde
Filipe: "wenn die kachel da ist soll die viel spezieller und geiler
sein. wirklich speziell machen bitte."
In der Nacht ist aus dem unsichtbaren Kasten ein Siegel geworden --
Flaeche, gruene Stempelschiene, gepraegte Muenze. Das war die halbe
Antwort. "Wirklich speziell" heisst: Es soll nicht nur ANDERS aussehen
als die Kacheln daneben, sondern nach etwas Bestimmtem.
ES IST EINE QUITTUNG. Alles auf dieser Seite ist eine Aufgabe -- etwas,
das noch zu tun ist. Dieses eine Feld sagt das Gegenteil. Die
Formensprache dafuer gibt es seit dreihundert Jahren und sie ist
ueberall dieselbe: Urkunde, Quittung, Wertpapier. Drei Merkmale machen
sie aus, alle drei sind jetzt gebaut:
1. GUILLOCHE -- das feine, sich kreuzende Linienwerk auf
Wertpapieren. Zwei Scharen in flachen gegenlaeufigen Winkeln.
2. DIE RAENDELUNG der Muenze -- der gekerbte Rand echter Geldstuecke,
28 Kerben, nur am Rand.
3. DIE PERFORATION rechts -- die Reisskante eines abgetrennten
Abschnitts. Sie sagt im Bild, was der Satz sagt: abgeschlossen.
KEIN EINZIGES NEUES ELEMENT: alles auf Pseudoelementen, die es schon
gab. Fuer eine Zierde gehoert nichts in den Dokumentbaum.
DREI ANLAEUFE, WEIL ICH ES DREIMAL ZU LAUT HATTE -- und jedes Mal hat
erst das Bild es gezeigt, nie eine Zahl:
* Die Raendelung lag mit `z-index: -1` HINTER der Muenze. Deren
Flaeche ist halbdurchsichtig, also schienen die Kerben ueber die
ganze Scheibe durch: eine Sonne mit Strahlen statt einer Muenze.
Jetzt liegt sie davor und wird maskiert.
* Das Maskenband war mit 70..74 % rund 0,6 px breit -- rechnerisch
ein Ring, auf dem Bildschirm ein Hauch. Jetzt 60..100 %, also
6,4 px, dasselbe Verhaeltnis wie an einem echten Geldstueck.
* Die Guilloche stand bei 4,5 % in Gruen: kein Material mehr,
sondern ein sichtbares Rautennetz, das die ganze Kachel nachfaerbte.
Jetzt 2 % in Silber und mit 9 statt 7 px Abstand -- dichte Linien
erzeugen mit dem Pixelraster ein Moiré, und das flimmert beim
Rollen.
Und noch ein Ausschnitt-Fehler wie gestern: Ich habe den ersten
Nachweis auf 640 px beschnitten und mich gewundert, wo die
Reisskante bleibt -- sie liegt am rechten Ende der Kachel, also
ausserhalb. Muenze und Perforation werden jetzt in ZWEI Ausschnitten
geprueft, weil sie an entgegengesetzten Enden liegen.
Kontrast unveraendert bei 14,47:1 (fett) und 7,39:1 (still).
Geprueft: pruef-start-ansicht, pruef-css-klassen, pruef-buehne -- alle
in Ordnung.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
8c7dc1fa94 |
Uhr und Ring sind jetzt gleich gross -- aus EINER Variablen
Wunsch Filipe: "die uhr und der [ring] sollen noch bissl groesser sein und ... dan auch am ende die selbe groesse haben bitte. sehr wichtig." WARUM SIE ES VORHER NICHT WAREN: Der Ring stand in heim.css (232 / 220 / 190), die Uhr in start.css (164 / 118). Zwei Dateien, zwei Zahlensaetze, und keine Stelle, an der jemand beide zugleich gesehen haette. Nachgemessen lagen sie am Rechner 68 px auseinander. Das war kein Versehen an einer Zahl, sondern die zwangslaeufige Folge davon, dass es zwei gab. Jetzt entscheidet `--instrument` ueber beide -- und ueber die Spalten, in denen sie sitzen. Gemessen: 248/248 am Rechner, 224/224 am Tablet, 196/196 am Handy. Ein Auseinanderlaufen ist nicht mehr moeglich, sondern muesste absichtlich geschrieben werden. Die alte Angabe in start.css ist ENTFERNT, nicht ueberschrieben: eine wirkungslose Zahl, die richtig aussieht, ist genau die Falle. ZWEI FOLGEN, BEIDE ERST IM BILD SICHTBAR: 1. DIE UHR HING 32 px UEBER DIE KACHELKANTE. Die rechte Spalte war auf das Instrument bemessen (248), braucht aber auch die Knopfreihe daneben (48 + 14 Abstand = 310). Die Seite liess sich trotzdem nicht seitlich schieben -- der Ueberstand lag INNERHALB der Kachel, also hat keine vorhandene Pruefung angeschlagen. Jetzt ist die Spaltenbreite abgeleitet (`--spalte`), nicht getippt. Beide Aussenspalten bekommen sie, obwohl links keine Knoepfe stehen: sonst saesse der Titel nicht mehr mittig. Der Ring wird in seiner Spalte zentriert. 2. DIE ZIFFERN WAREN ZU KLEIN. Sie standen in `rem` -- in einer Uhr von 164 px richtig, in einer von 248 verloren (29,76 px in einem 248-px-Zifferblatt, die Mitte eine leere Flaeche). Sie haengen jetzt ebenfalls an `--instrument`. Der Faktor ist nachgesehen, nicht gerechnet: 0,145 war noch zu klein, 0,168 fuellt die Mitte, ohne an die innerste Bahn zu stossen (Stundenbalken liegen bei Radius 31,5 von 50). Geprueft: pruef-start-ansicht (kein Text abgeschnitten, keine Konsolenfehler), pruef-handy, pruef-workspace-seiten (18 Seiten, Ueberstand 0 px), pruef-css-klassen -- alle in Ordnung. Dazu 1500/900/390 px einzeln nachgemessen: Uhr und Ring auf den Pixel gleich, Abstand zur Kachelkante 30 bzw. 64 px. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
b1810ddbc5 |
screen6: Die beiden Bestaetigungen werden zu Unterschriften
Filipe, mit Bildschirmfoto der beiden Felder: "die sollen geiler sein."
WAS SIE WIRKLICH SIND, stand nur im Klassennamen. Auf einer
Unterweisung bestaetigen ZWEI Personen, dass sie sie durchgegangen
sind -- der Creator und seine Betreuung. Das ist kein Statusfeld, das
ist eine Gegenzeichnung. Gezeichnet waren sie als zwei graue Kaesten
mit runden Ecken, die man auf dem dunklen Grund kaum sah. Zwei
Rechtecke sagen "hier steht etwas". Eine Unterschriftszeile sagt "hier
fehlt jemand".
ZWEI ZUSTAENDE, ZWEI BILDER -- und beide gab es im Code laengst als
`data-da="ja"/"nein"`, nur unterschieden sie sich um einen Hauch Gruen:
OFFEN eine gestrichelte Linie mit einem leeren Platz darauf. Sie
WARTET sichtbar. Der Federstrich links deutet an, wo man
ansetzt.
DA eine durchgezogene gruene Linie, der Name darueber, und ein
gepraegtes Siegel mit Haken -- wie ein abgestempeltes
Formular.
GLEICHE HOEHE IN BEIDEN ZUSTAENDEN, und das ist keine Kosmetik: Die
Felder stehen nebeneinander in einem Raster. Waere das unterschriebene
hoeher, spraenge die Karte in dem Moment, in dem jemand unterschreibt
-- unter dem Finger dessen, der gerade gedrueckt hat.
KEINE ZWEITE FASE. Die Karte drumherum steht schon in der Modulliste.
Eine abgeschraegte Ecke IN einer abgeschraegten Ecke liest sich als
Fehler, nicht als Absicht. Das Feld traegt deshalb die andere
Formensprache des Hauses: die Linie.
DER HAKEN IST EINE MASKE, kein Zeichensatz-Haken (der sieht in jeder
Schrift anders aus und faellt weg, wenn eine fehlt) und kein Bild
(eine Datei mehr fuer fuenfzehn Pixel). Erst stand er nur im
Kommentar, waehrend im Code eine leere Muenze lag -- nachgebaut, bevor
es committet wurde. Ein Kommentar, der mehr behauptet als der Code
tut, ist schlimmer als keiner.
ZWEI ANSICHTEN NACHGEMESSEN: Auf 1400 px nebeneinander, auf 390 px
untereinander. Das Siegel sass im ersten Anlauf mit
`translate(100%)` AUSSERHALB des Feldes -- breit sah das gut aus,
schmal waere es aus der Karte gelaufen. Jetzt sitzt es innen; die
Seite laesst sich bei 390 px nicht seitlich schieben.
(Fuer die Ansicht musste ich Testdaten anlegen -- ohne Unterweisung
gibt es keine Unterschriften, und ein Bildschirmfoto von einem leeren
Bereich beweist nichts. Die Daten liegen in der Wegwerf-Datenbank der
Pruefung, nicht im echten System.)
Geprueft: pruef-schulung, pruef-css-klassen -- beide in Ordnung.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
77ff1a1b52 |
screen1: Die vier Tafeln der Calls-Seite bekommen eine Flaeche und ihre Farbe
Filipe, mit Bildschirmfoto der vier Reiter: "lass die viel geiler aussehen bitte." `.gruppe[data-gruppe]` steht in der Modulliste und bekommt von dort Fase, Kantenlicht und Eckwinkel -- aber die Modulliste gibt nur die FORM. Die Flaeche bringt jedes Bauteil selbst mit, und hier stand nur `margin-bottom`. Die vier Reiter waren damit Silhouetten ohne Koerper: Das Hintergrundbild lag mitten in ihnen. DERSELBE FEHLER ZUM DRITTEN MAL IN DIESER NACHT -- beim Entscheidungsblock auf der Report-Seite, bei der Anlasskachel im Kalender und jetzt hier. Die Ursache ist jedes Mal dieselbe: Wer ein Bauteil in die Modulliste aufnimmt, haelt es fuer fertig gestaltet. Es hat dann eine Silhouette und keinen Koerper. Das gehoert in die Uebergabe, damit es beim vierten Bauteil nicht wieder passiert. DIE VIER FARBEN GAB ES SCHON -- an der falschen Stelle. `#f0c48a` fuer "Protokoll fehlt" und `#79d1a2` fuer "Festgehalten" standen bereits im Code, aber nur an den EINTRAEGEN in der aufgeklappten Tafel. Der Reiter selbst, den man zuerst sieht und der oft der einzige ist (drei von vier sind zugeklappt), trug sie nicht. Jetzt stehen sie einmal als `--gton` und faerben beides: die Flaeche und ueber `--ton` das Kantenlicht aus der Modulliste. Die Farben sind zugeordnet, nicht ausgesucht: Bernstein "etwas ist offen", Babyblau "kommt noch", Lila "laeuft von allein", Gruen "erledigt". EINE LEERE TAFEL TRITT ZURUECK -- dieselbe Ueberlegung wie bei den Zahlen auf der Uebersicht: Null darf leise sein. Vier gleich helle Reiter waeren vier gleich laute Rufe. EIN IRRTUM UNTERWEGS, DER FESTGEHALTEN GEHOERT: Nach der Aenderung sah ich im weiten Bildschirmfoto immer noch das Motiv "durch" die Tafeln scheinen und hielt die Reparatur fuer wirkungslos. Es waren die LUECKEN ZWISCHEN den Tafeln -- dort gehoert der Hintergrund hin. Erst ein enger Ausschnitt einer einzelnen Tafel hat es geklaert. Ein zu weiter Ausschnitt luegt genauso zuverlaessig wie ein zu schmaler (heute Nacht schon einmal, beim Messstreifen am linken Bildrand). Geprueft: pruef-call-kategorien, pruef-css-klassen, pruef-buehne -- alle in Ordnung. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
a4db78e937 |
screen2: Der Tagdialog bekommt die Silhouette des Hauses
Filipe: "die ganze kachel und button sollen geiler aussehen." Der INHALT war schon gebaut -- Eintraege mit Schiene in ihrer Farbe, Plaketten (TERMIN, FRIST), Knopfreihe, Akzentknopf. Nur die HUELLE nicht: ein Rechteck mit 18 px Rundung und einem gezeichneten Rand. Damit war der Dialog die einzige grosse Flaeche im Workspace ohne Fase -- und ausgerechnet die, die sich ueber alles andere legt. Man sieht es nicht als Fehler, sondern denkt "der gehoert wohl zum Browser". Jetzt dieselbe Bauart wie die Sammelkacheln: Der <dialog> traegt nur die Fassung (2 px Polsterung mit Farbverlauf darunter), alles Sichtbare liegt in einer neuen Ebene `.k-dialog__glas` darin. Ohne diese zweite Ebene muesste die Fassung ein `border` sein -- und ein Rand folgt dem Rechteck, nicht der abgeschraegten Ecke. ZWEI ECKEN, NICHT VIER: Bei einem Kasten, der mitten im Bild aufgeht, wirken vier abgeschnittene Ecken unruhig -- er soll wie eine Platte wirken, die man auflegt, nicht wie ein Achteck. Oben links und unten rechts geben die Richtung, die anderen beiden halten die Form. `border-radius: 0` ist dabei Pflicht und nicht Kosmetik: Bliebe der Radius neben dem `clip-path` stehen, wuerde er die Ecken der Flaeche INNERHALB der Silhouette runden -- an den nicht gefasten Ecken saehe man eine doppelte Kante. NEBENBEI EINEN WIRKUNGSLOSEN EFFEKT ENTFERNT: `backdrop-filter: blur(14px)` stand auf dem Dialog und waere mit auf die neue Glasebene gewandert. Die ist zu 97 Prozent deckend -- der Browser haette bei jedem Bild einen Weichzeichner ausgerechnet, den niemand sieht. Das Verwischen des Hintergrunds macht `.k-dialog::backdrop`, und dort gehoert es hin. Ein Effekt, der nichts bewirkt, ist nicht harmlos: Er kostet Rechenzeit und behauptet im Quelltext etwas ueber das Aussehen, das nicht stimmt. Geprueft: pruef-kalender, pruef-css-klassen, pruef-buehne -- alle in Ordnung. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
4c0f41762e |
screen18, zweite Haelfte: Die Tagesfelder werden Tasten in einer Platte
Filipe: "...und die kacheln vom kalender selber sollen viel krasser und geiler aussehen bitte." Die dunklen Fugen zwischen den Tagen waren die eine Haelfte des Wunsches und stehen seit dem 08.09. Die andere Haelfte sind die Felder SELBST: flache Rechtecke in drei Grautoenen. Eine gefraeste Platte mit Fugen, in der flache Flaechen liegen, ist halb fertig -- die Fuge sagt "Werkstueck", die Flaeche sagt "Tabelle". ZWEI PIXEL MACHEN DEN UNTERSCHIED: eine Lichtkante oben, eine Schattenkante unten. Dieselbe Rechnung wie ueberall im Haus -- Licht faellt von oben, also ist die obere Kante hell und die untere dunkel. Aus einer Flaeche wird ein Koerper, der in der Platte SITZT. Kein zusaetzliches Element, keine Groessenaenderung, kein Umbruch. DER WOCHENENDUNTERSCHIED WAR MESSBAR ZU KLEIN -- und das ist der eigentliche Fund. Werktag lag bei `rgba(11,15,25,.74)`, Wochenende bei `rgba(9,12,20,.8)`. Auf dem Bildschirm sind die beiden Spalten nicht auseinanderzuhalten. Die Angabe war also da und wirkungslos, und das ist die unangenehmste Sorte Fehler: Sie sieht im Quelltext nach einer Funktion aus, und niemand vermisst, was scheinbar existiert. Jetzt liegt das Wochenende sichtbar tiefer und etwas kuehler. Man sieht den Wochenrhythmus, ohne die Spaltenkoepfe zu lesen -- das ist keine Zierde, sondern die Information, wegen der ein Kalender ueberhaupt in Wochen gegliedert ist. HEUTE BLEIBT DAS LAUTESTE FELD, und das war die Bedingung fuer alles andere: Wenn jedes Feld eine Kante bekommt, muss das eine, auf das es ankommt, weiter herausstechen. Voller Ring plus ein leiser Schein nach innen. AUGENSCHONEND: Alle Werte unter 8 Prozent Deckkraft. Auf sechs mal sieben Feldern summiert sich jede Helligkeit -- was auf einer Kachel dezent ist, ist auf 42 Kacheln ein Raster. Geprueft: pruef-kalender, pruef-buehne (kalender.html schlechtester Kontrast 5,58:1 bei noetigen 4,5:1, 13 Stellen gemessen), pruef-css-klassen -- alle in Ordnung. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
f39e4d1133 |
screen29: Der Titel der Anmeldekarte wird in die Platte graviert
Filipe: "sehr gut aber ich will es noch viel geiler bitte." "Creator Workspace" stand als flaches Weiss ueber der Karte -- richtig gesetzt, aber ohne Material. Darunter liegt eine Karte aus Glas und Metall, darum ein Rahmen aus Rot und Babyblau; nur die Ueberschrift selbst gehoerte zu nichts davon. ZWEI SACHEN MACHEN AUS SCHRIFT EIN WERKSTUECK: 1. EIN VERLAUF VON OBEN NACH UNTEN, nicht von links nach rechts. Gebuerstetes Metall ist oben hell, in der Mitte dunkel und unten wieder hell -- weil es sich woelbt. Ein Verlauf, der nur von hell nach dunkel laeuft, ist eine Flaeche mit Farbverlauf; erst der WECHSEL liest sich als Metall. Dieselbe Ueberlegung wie bei der Fassung der Zentrale, nur hochkant. 2. EIN HARTER SCHATTEN DIREKT DARUNTER, ein Pixel. Er macht aus aufgelegter Schrift eingelassene: Das Auge liest die dunkle Linie als Kante der Vertiefung. Weich waere es ein Schlagschatten und damit das Gegenteil. Dazu ein feiner Lichtstrich unter der Markenzeile -- Rot links, Silber in der Mitte, Babyblau rechts, dieselbe Richtung wie der Rahmen der Rollenkachel darunter. DER RUECKFALL STEHT ZUERST UND IST VOLLWERTIG. `background-clip: text` traegt hier die Farbe -- faellt die Technik aus, waere durchsichtiger Text auf durchsichtigem Grund die Ueberschrift der wichtigsten Seite des Hauses. Also bleibt `color` gesetzt, und erst ein `@supports` schaltet den Verlauf dazu. `filter: drop-shadow` statt `text-shadow`, weil ein Textschatten bei durchsichtigem Text DURCH die Buchstaben scheint -- man saehe den Schatten im Buchstaben stehen. KONTRAST NACHGERECHNET, NICHT BEHAUPTET: Der dunkelste Punkt des Verlaufs (#9fb3c8) kommt gegen den Kartengrund auf 8,97:1 / 8,41:1 / 7,54:1 je nach angenommenem Untergrund. Grosse Schrift braucht 3:1, normale 4,5:1. Die Zahlen stehen im Kommentar, weil ich an genau dieser Datei schon einmal "liegt weit darueber" geschrieben hatte, ohne zu rechnen -- und beim Anmelde-Knopf damit danebenlag (4,20:1 statt der behaupteten 4,5+). Eine Behauptung ueber Kontrast ohne Zahl ist eine Vermutung. Geprueft: pruef-rollen (97 Pruefungen), pruef-css-klassen -- beide in Ordnung. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
af40b79a8c |
screen30 + screen32: Der leere Zustand wird ein Siegel, die Kennung ein Ausweis
--- Und ein Fund unterwegs: Cigdems Kennung war kaputt --- `--rollen-ton` faerbt Kennung und Rollenplakette in der Kopfleiste. Die Liste dahinter kannte admin, manager, scout und creator -- SPICY MEDIA nicht. Die Rolle kam am 07.09. dazu, diese Liste ist nicht mitgegangen. Was dabei passiert, ist schlimmer als eine falsche Farbe: Die Variable war GAR NICHT gesetzt, und `color-mix(in srgb, var(--rollen-ton) 62%, transparent)` ist mit einer leeren Variablen ungueltig -- der Browser wirft die ganze Deklaration weg. Nachgemessen im Browser: Hintergrund `none`, Rand `rgb(234,243,255)` (also currentColor, weil auch die Randfarbe fiel), Plakette grau statt rot. Cigdems Kennung war ein weisser Kasten in einer roten Leiste. DESHALB STEHT JETZT EINE VORGABE DAVOR, und die ist wichtiger als der nachgetragene Eintrag: Wer die naechste Rolle anlegt und diese Liste wieder vergisst, bekommt eine Kennung in der Hausfarbe -- nicht mehr eine kaputte. Ein fehlender Eintrag darf zu etwas Schlichterem fuehren, nie zu etwas Ungueltigem. --- screen30: der leere Zustand --- "das muss auch viel spezieller sein und auch nicht wie alle anderen kacheln da sondern wirklich krasser und geiler aber so dass es vom aussehen trotzdem noch zu seite passt." Das Gruen lief als Verlauf nach 60 Prozent ins Nichts, dahinter das Hintergrundbild -- auf Filipes Bild scheint ein Chili mitten durch die gute Nachricht. Eine Fassung, die nur auf der linken Haelfte existiert, ist keine. "Nicht wie alle anderen Kacheln" ist inhaltlich richtig: Alles andere auf dieser Seite ist eine AUFGABE, etwas, das man noch tun muss. Das hier ist die Quittung, dass nichts mehr offen ist. Es waere falsch, wenn es wie eine weitere Aufgabe aussaehe. Also die Form eines SIEGELS: die Fase sitzt rechts unten statt links oben -- spiegelverkehrt zur Kachelsprache --, links eine breite gruene Lichtschiene wie ein Stempelrand, und der Haken ist eine gepraegte Muenze statt eines Kreises mit einem Strich darin. Die Flaeche ist deckend; eine gute Nachricht, durch die man das Hintergrundbild sieht, liest sich wie ein Platzhalter. Leise bleibt es trotzdem: gedecktes Gruen, hoechstens 14 Prozent Flaeche, nichts pulsiert. Wer nichts offen hat, braucht kein Feuerwerk. Kontrast gemessen: 14,47:1 (fett) und 7,39:1 (still). --- screen32: die Kennung in der Kopfleiste --- "das sieht schon richtig gut aus aber ich will dass es noch krasser und spezieller aussieht." Sie sass als flaches, abgerundetes Quadrat zwischen vier Knoepfen und sah damit aus wie ein fuenfter Knopf, der sich nicht druecken laesst. Sie ist aber etwas anderes: Sie sagt, WER hier ist, nicht, was man tun kann. Jetzt die Fase des Hauses statt der Rundung (sie gehoert zur Seite, nicht zur Knopfreihe), ein gepraegter Ring statt eines gezeichneten Randes (Lichtkante oben, Schattenkante unten) und ein sehr leiser Schein in der Rollenfarbe. KEINE GROESSENAENDERUNG -- 28x28 bleibt. Die Kopfleiste ist am 06.09.2026 schon einmal an einem zusaetzlichen Element zerbrochen; was hier waechst, drueckt dort etwas heraus. Geprueft: pruef-workspace-seiten (18 Seiten, Ueberstand ueberall 0 px), pruef-handy, pruef-start-ansicht, pruef-css-klassen -- alle in Ordnung. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
41108d6c3c |
screen14 + screen16: Der Entscheidungsblock bekommt eine Flaeche, die Zahlen bekommen Bedeutung
--- screen14: "das soll auch bitte viel geiler und spezieller sein" ---
Zwei Dinge waren falsch, und nur eines davon sieht man im Code.
1. DIE FLAECHE WAR FAST DURCHSICHTIG -- 9 und 5 Prozent Deckkraft. Auf
einer Seite mit Hintergrundbild heisst das: Das Motiv scheint mitten
durch den Text. Auf Filipes Bildschirmfoto liest man den Satz "Ein
Review endet nicht mit einer Zusammenfassung" quer ueber einem
gespiegelten SPICY-MEDIA-Schriftzug. Ein Kasten, den man nicht
sieht, ist keine Fassung -- er ist ein Rand um nichts.
2. `border-radius` UND `border` STANDEN NOCH DA -- wirkungslos, weil
`.entscheidung` in der Modulliste von module.css steht und die
spaeter geladen wird. Zwei Angaben, die aussehen, als taeten sie
etwas, und es seit dem Umbau nicht mehr tun.
Er ist die HANDLUNG der Seite, nicht einer von vier Abschnitten: Alles
darueber ist Auskunft, hier wird entschieden und sofort eine Aufgabe
angelegt. Deshalb ein eigener `--ton` fuers Kantenlicht (die Modulliste
faerbt es darueber) statt des Seitentons, und eine kraeftigere Flaeche
als die Sammelkacheln darueber. Kein Rot: Rot heisst in diesem Haus
"ueberfaellig", und eine Entscheidung ist kein Alarm. Die Eingabefelder
sind jetzt eingelassen statt aufgesetzt -- wo man etwas hineinschreibt,
ist eine Vertiefung; und `color-scheme: dark`, sonst zeichnet Chrome
den Datumswaehler als weisses Kaestchen in die dunkle Flaeche.
--- screen16: "mit mehreren farben arbeiten, damit die wichtigsten
sachen auch auffallen" ---
Die sechs Zahlen je Creator (ueberfaellig, dringend, offen, in Arbeit,
im Review, erledigt) trugen alle dasselbe Blau -- und `data-warn`
faerbte zwei davon in DASSELBE Rot. "Ueberfaellig" ist eine versaeumte
Frist, "dringend" eine Sache, die schnell muss. Zwei verschiedene
Alarme, die gleich aussehen, sind ein Alarm.
Jetzt sechs Toene: Rot, Bernstein, Babyblau, Lila, Silber, Gruen.
DIE WICHTIGE ENTSCHEIDUNG WAR ABER NICHT WELCHE FARBE, SONDERN WANN.
Sechs dauerhaft leuchtende Felder waeren sechs gleich laute Rufe -- und
damit genau so wenig Hilfe wie sechs gleich blaue. Deshalb bleibt eine
NULL grau und still; nur was groesser als null ist, bekommt seine
Farbe. Auf einer Karte, auf der alles auf Null steht, aendert sich
nichts. Auf einer, auf der drei Sachen ueberfaellig sind, sieht man
genau die. Das ist der Unterschied zwischen Farbe als Schmuck und
Farbe als Auskunft.
Die Farbe haengt an `data-sorte` (einem Schluessel), nicht an
`:nth-child`: Wer morgen ein siebtes Feld dazwischenschiebt, soll nicht
sechs Farben verrutschen lassen. Und die Beschriftung bleibt der
eigentliche Traeger -- Farbe allein traegt in diesem Haus nie eine
Information.
KONTRAST NACHGERECHNET statt angenommen: Die Beschriftungen sind
11,2 px, also gilt 4,5:1. Gemessen gegen die Kartenflaeche liegen sie
zwischen 5,91:1 (erledigt) und 14,09:1 (im Review) -- alle sechs
deutlich darueber. pruef-barrierefrei-workspace habe ich deshalb NICHT
gestartet: Der Lauf haette 190 Sekunden gebraucht, um dasselbe zu
sagen.
Geprueft: pruef-uebersicht, pruef-uebersicht-browser, pruef-css-klassen,
pruef-buehne -- alle in Ordnung.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
8fcc9de1bb |
screen4: Die Anlass-Sammelkachel bekommt die Kachelsprache des Hauses
Wunsch Filipe: "ich will dass das alles in einer geilen kachel ist wie die kacheln in der start seite. und noch geiler." Der Umschlag um die drei Abschnitte (Als Naechstes / Im Monat / Laeuft von allein) gab es schon -- aber die Kachelform war in kalender.css NACHGEBAUT: eine Fase an einer Ecke, ein Raster, ein Innenschatten. Im Bildschirmfoto sah man den Rahmen kaum, waehrend die Karten DARIN (die seit jeher in der Modulliste stehen) Kantenlicht und Eckwinkel trugen. Die Sammelkachel war damit schwaecher gefasst als ihr eigener Inhalt -- genau andersherum, als es sein soll. "WIE DIE KACHELN AUF DER STARTSEITE" HEISST NICHT "AEHNLICH GEBAUT", SONDERN DIESELBE REGEL. `.k-anlasskachel` steht jetzt in der Modulliste von module.css -- in allen sieben Kopien, die pruef-css-klassen Zeichen fuer Zeichen vergleicht. Damit bekommt sie Fase, Kantenlicht, Eckwinkel und Schlagschatten aus derselben Quelle wie 43 andere Bauteile, und ein Nachbau daneben kann nicht mehr auseinanderlaufen. DABEI EINEN FEHLER GEMACHT UND GESEHEN: Beim Entfernen des Nachbaus ging der Hintergrund mit weg. Die Kachel war danach DURCHSICHTIG -- das Motiv der Seite schien mitten durch den Text. Die Modulliste gibt die FORM; die Flaeche bringt jede Kachel selbst mit, weil sie von Fall zu Fall verschieden ist. Eine Fassung ohne Fuellung ist kein Rahmen, sondern ein Loch. Gesehen im Bildschirmfoto, nicht in einer Zahl. Geprueft: pruef-css-klassen (sieben Kopien gleich, 44 Klassen), pruef-kalender, pruef-buehne -- alle in Ordnung. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
4e35c6f8e5 |
screen11: Der Chat hatte gar keinen Hintergrund -- seit jeher
Wunsch Filipe: "die hintergrund bilder sollen alle so strahlen und
schoen sein wie dieses. dieses ist wirklich mega und perfekt."
(Massstab ist die Scouting-Seite, Szene "wald".)
DER FUND: `chat.html` hat weder `.kopf-zeile` noch `.k-kopf` -- sie
traegt ihren Titel im eigenen `.chat__kopf`. In kopf.js stand ganz
oben:
const kopf = document.querySelector('.kopf-zeile, .k-kopf');
if (!B || !kopf) return;
Damit hing ALLES an der Frage, ob es eine Kopfzeile gibt, an die man
eine Plakette haengen kann -- auch der Farbton der Seite und ihr
Hintergrundbild, die damit nichts zu tun haben. Der Chat ist an dieser
Zeile ausgestiegen und hat WEDER Ton NOCH Buehne bekommen, obwohl in
bereiche.js seit jeher `szene: 'lounge'` fuer ihn steht. Eine
Zuordnung, die es gibt und die nie ankam.
Jetzt stehen Ton und Buehne VOR der Plakette: Sie brauchen nur den
Bereich. Die Plakette braucht zusaetzlich einen Kopf -- gibt es den
nicht, faellt eben nur sie aus.
WARUM DAS KEINE PRUEFUNG GEFUNDEN HAT, gleich zweimal:
1. `chat.html` stand nicht in der Seitenliste von
pruef-workspace-seiten. Eine Pruefung, die eine Seite nicht kennt,
kann auf ihr nichts finden. Jetzt drin, zusammen mit
leistung.html -- 18 Seiten statt 16.
2. Die Buehnenregel lautete `r.buehne ? r.buehneBild === r.buehne :
!!r.buehneBild` -- fehlt das Merkmal, reichte IRGENDEIN Bild.
Gedacht war die Ausnahme fuer die Startseite, geschrieben war sie
fuer jede Seite. Der Chat verlor sein `data-buehne`, fiel auf die
Grundszene zurueck, und die Pruefung sagte "ein Motiv ist da,
alles gut". Eine Bedingung, die bei fehlender Angabe MILDER wird
statt strenger, kann den Verlust dieser Angabe nicht melden --
sie belohnt ihn. Die Ausnahme haengt jetzt an der Startseite, nicht
am Fehlen des Merkmals.
Die Regel ist dafuer aus der Schleife herausgeloest (`buehneRichtig`)
und hat sieben Gegenproben bekommen -- darunter genau den Chat-Fall.
Ohne sie waere "alles in Ordnung" nur die Aussage, dass die Regel
nichts gemeldet hat, nicht dass sie etwas melden koennte.
DIE AUSNAHME DES CHATS STEHT JETZT MIT NAMEN in der Pruefung, statt
dass die Seite aus der Liste faellt: Plakette und Wasserzeichen
entfallen dort, weil es den Ort dafuer nicht gibt -- Ton und Buehne
gelten. Ob der Chat eine Plakette bekommen soll, ist eine
Gestaltungsfrage fuer Filipe, keine Fehlerfrage.
ZWEI FALSCHE AUSSAGEN in tools/gate-bauen.mjs richtiggestellt:
"halle: dieselbe Sammlung, GESPIEGELT" -- nachgemessen haben beide
Dateien dieselbe Pruefsumme, es gibt in diesem Werkzeug keine
Spiegelung. Und "0,42 ist gemessen" ueber `const DUNKEL = 0.26`; der
Wert wurde gesenkt, die Zeile ist nicht mitgegangen. Ein Kommentar, der
mehr behauptet als der Code tut, ist schlimmer als keiner.
ZUM EIGENTLICHEN WUNSCH, ehrlich: Ich habe die Hintergrundhelligkeit
aller 18 Seiten nachgemessen. Die Scouting-Seite ist tatsaechlich die
hellste (0,0263), alle anderen liegen 19 bis 65 Prozent darunter --
aber der Grund ist NICHT die Bildbehandlung. Schleier und Abdunklung
sind fuer alle Seiten gleich und mehrfach nachgemessen. Der Unterschied
ist, WIE VIEL vom Bild noch zu sehen ist: Die Scouting-Seite traegt
eine schmale Karte, die anderen dichte Tabellen und Kachelraster. Das
liesse sich aendern, aber es ist eine Entscheidung ueber die
Inhaltsdichte von 17 Seiten -- die gehoert Filipe, nicht mir um zwei
Uhr nachts.
(Meine erste Messung sagte das Gegenteil. Sie nahm einen Streifen bei
x 0..150 -- ausgerechnet die dunkelste Spalte jedes Motivs. Danach
schien die Scouting-Seite fast schwarz, waehrend das Bildschirmfoto
derselben Seite hell und farbig ist. Ein Messfeld, das nicht
repraesentativ ist, misst zuverlaessig das Falsche.)
Geprueft: pruef-workspace-seiten (18 Seiten, alles in Ordnung),
pruef-buehne, pruef-css-klassen -- alle in Ordnung.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
f3d5bcf198 |
screen20: Die fuenf Rollen in EINER Kachel
Wunsch Filipe: "ich will dass die rollen auch alle in einer grossen kacheln sind, die soll richtig krass sein, richtig speziell." Vorher waren es fuenf einzelne Kaesten mit je eigenem Rand, eigenen runden Ecken und 8 px Luft dazwischen -- der Hintergrund des Motivs schien ueberall durch. Das las sich als fuenf Dinge, die zufaellig untereinander stehen. Es ist aber EINE Frage mit fuenf Antworten, und genau so sieht es jetzt aus: ein Koerper mit abgeschraegten Ecken, in den fuenf Felder eingelassen sind. DIE FUGE MACHT DIE KACHEL, nicht der Rand aussen. Ein Spalt, durch den der Untergrund scheint, TRENNT; eine dunkle Fuge (#05070c) VERBINDET, weil sie zum selben Koerper gehoert. Dieselbe Entscheidung wie beim Kalender. DIE FASSUNG traegt dieselben vier Farben wie der Rand der Zentrale -- links Rot, rechts Babyblau, Silber als Treffpunkt, Schwarz als Fuge. Wer sich anmeldet, sieht damit schon hier die Handschrift der Seite dahinter. WAS BLEIBT, IST DIE SCHIENE. Sie war das Beste am alten Entwurf: Wer sich als Manager anmeldet, sieht schon hier das Lila, in dem ihm gleich seine Kacheln begegnen. Sie sitzt jetzt buendig an der Innenkante statt am Rand einer eigenen Karte -- dieselbe Wirkung, ein Koerper weniger. ZWEI SACHEN, DIE DABEI AUFFIELEN: 1. ES GAB ZWEI ENTWUERFE FUER DIESELBEN FUENF ZEILEN. Einen ab 1100 px (`.tafel .rolle`, mit Schiene und Tastenwirkung) und einen darunter (`.rolle`, schlicht). Mein erster Anlauf legte einen DRITTEN darueber -- im Bildschirmfoto standen die alten Karten unveraendert in meiner neuen Kachel. Statt der dritten Schicht sind jetzt beide vorhandenen auf Felder umgestellt: eine Aussage, zwei Groessen. 2. `transform: translateY(1px)` BEIM DRUECKEN MUSSTE WEG. Bei fuenf einzelnen Karten war das richtig -- eine Taste, die nachgibt. In einem geschlossenen Koerper schiebt sich damit ein Feld um einen Pixel aus der Kachel heraus, reisst die Fuge auf und sieht nach einem Fehler aus. Der eingelassene Schatten sagt dasselbe, ohne etwas zu verschieben. Nebenbei: Die Markierung der gewaehlten Rolle stand unter 1100 px fuer alle fuenf auf demselben Blau-Violett -- wer "Scout" waehlte, bekam Blau, obwohl Scout gruen ist. Die Rollenfarbe `--rf` war zwei Zeilen darueber definiert und wurde nicht benutzt. Jetzt kommt sie per `color-mix` aus den zentralen Hausfarben. Geprueft: pruef-rollen (97 Pruefungen, alles in Ordnung), pruef-css-klassen (alles in Ordnung), dazu 390/320/820 px nachgemessen -- nichts ragt heraus, nichts laesst sich seitlich schieben. Dabei hat meine eigene Messung erst fuenf Fehler gemeldet, die es nicht gab: Die Untertitel sind auf schmalen Geraeten ausgeblendet, ein ausgeblendetes Element hat die Masse 0/0, und 0 liegt links von jeder Kachel. Ohne den Blick aufs Bild haette ich einen Fehler gesucht, den nur die Pruefung hatte. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
f701dae53e |
screen10: Der Tagesruf -- einmal am Tag, was noch offen ist
Wunsch Filipe: "ich will das neben diesem kreis auch ein kleiner button
ist fuer den wecker von den aufgaben, oder quasi eine taetige meldung
einmal am tag zu aktivieren wenn noch aufgaben auf sind."
Ein Wecker-Knopf unter der Glocke, neben der Uhr. Eingeschaltet meldet
er sich einmal taeglich zur eingestellten Zeit -- aber nur, wenn
wirklich noch etwas offen ist. Der Satz nennt die Zahl und die
Ueberfaelligen: "3 Aufgaben sind noch offen / Davon eine ueberfaellig."
ALS EINZIGE ART MIT `vorgabe: false`, und das ist keine
Nachlaessigkeit. Alle anderen Benachrichtigungen antworten auf ein
Ereignis, das gerade passiert ist. Der Tagesruf kommt ungefragt zur
selben Zeit, ob es etwas Neues gibt oder nicht -- so etwas schaltet man
sich selbst ein, sonst ist es Werbung. Bei null offenen Aufgaben kommt
nichts: Eine taegliche Meldung "du hast nichts zu tun" ist der
schnellste Weg, dass man die naechste nicht mehr liest.
EIN FENSTER VON DREI STUNDEN. Der Takt laeuft alle fuenf Minuten; ein
einfaches "jetzt >= eingestellte Zeit" wuerde nach einem Serverausfall
den Ruf fuer neun Uhr um zwanzig Uhr zustellen. Wer eine Erinnerung an
einen vergangenen Tag bekommt, schaltet sie ab. Faellt der Tag aus, ist
das die ehrlichere Antwort.
VIER DINGE, DIE ERST DAS NACHMESSEN GEZEIGT HAT:
1. DER KNOPF VERSPRACH ETWAS, DAS ER NICHT HALTEN KONNTE. Chromium
meldet `Notification.permission === 'denied'` -- gemessen, nicht
vermutet. Der Knopf sah einladend aus ("Einmal am Tag melden…") und
sagte erst NACH dem Antippen ab. Ein Bedienelement, das den Grund
erst hinterher nennt, ist die schlechtere Haelfte einer
Fehlermeldung. Jetzt steht er im Titel, und der Knopf ist gedimmt.
2. EINE UHRZEIT IN DER RUHEZEIT WAERE EIN STILLES NICHTS. Der Server
laesst zwischen 22 und 7 Uhr nichts durch. Wer 23:00 einstellt,
bekaeme nie etwas und saehe nur einen Knopf auf "an". Jetzt steht
der Hinweis dort, wo man es einstellt -- mit den Grenzen VOM SERVER,
nicht mit hier getippten Zahlen.
3. `wert` UND `an` SIND ZWEI ENTSCHEIDUNGEN. Wer nur den Schalter
umlegt, schickt kein `wert` -- stumpf `req.body.wert` zu schreiben
haette bei jedem Aus- und Einschalten die Uhrzeit geloescht, und
beim naechsten Mal staende wieder neun Uhr da. Ein Datenverlust, den
niemand meldet, weil er wie eine Vorgabe aussieht. Genau dieser Weg
wird jetzt geprueft.
4. pruef-css-klassen HATTE ZWEIMAL RECHT. Der Stil lag in heim.css
(nur Startseite), die Zeichen entstehen aber in glocke.js (18
Seiten) -- auf 17 davon waere ein nackter Knopf gestanden. Und die
beiden neuen Schriftgroessen (10 und 11 px) haetten die Grundlinie
von 43 zu kleinen Stellen still auf 45 gehoben. Beides behoben:
Stil nach start.css, Schrift auf 12 px.
NEUE PRUEFUNG server/pruef-tagesruf.mjs, drei Schichten getrennt, weil
sie getrennt kaputtgehen: Oberflaeche im Browser, Schalten ueber die
Schnittstelle (aus der SEITE heraus, damit Sitzung und
Herkunftspruefung mitgehen), Zeitentscheidung als reine Rechnung. Die
Entscheidung wurde dafuer aus dem Rundgang herausgeloest -- dazwischen
steckend haette man zum Pruefen Datenbank und Push-Versand aufbauen
muessen, also haette man sie nicht geprueft.
Die Erwartung der ersten Schicht richtet sich nach der GEMESSENEN
Berechtigung statt sie vorauszusetzen: Erlaubt eine kuenftige
Chromium-Fassung Benachrichtigungen von sich aus, waere ein fest
verdrahtetes "muss blockiert sein" ein Fehlalarm ohne Fehler.
Gegenproben sind dabei: "99:99", "7:30" ohne fuehrende Null und ein
Wert an einer Art, die keinen kennt, muessen abgelehnt werden -- sonst
bewiese der Bereichstest nichts.
Der reservierte Platz waechst von 46 auf 104 px, damit der zweite Knopf
die Kachelreihe darunter nicht nach unten schiebt; das Zeitfeld schwebt
statt zu schieben. Beides derselbe Grund wie bei der Glocke: Ein
Sprung ist kein Schoenheitsfehler, sondern der Grund, warum man auf den
falschen Knopf drueckt.
Geprueft: pruef-tagesruf (neu, alles in Ordnung), pruef-push,
pruef-css-klassen, pruef-start-ansicht -- alle in Ordnung.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
cad3c4c4df |
screen21: Universum hinter der Zentrale, Fassung neu gewichtet
Wunsch Filipe: "ich will dass du im hintergrund dieser kachel das logo von spicy media machst ... es soll sogar paar mal zu sehen sein, es soll sich bewegen, schweben ... der ganze hintergrund soll wie ein universum aussehen. und der rand wie gesagt soll rot schwarz silber und babyblau sein, rot und babyblau soll man am meisten sehen." DER RAND HATTE ALLE VIER FARBEN -- IN DER FALSCHEN GEWICHTUNG. Jeden Stopp mit der Haelfte des Abstands zu seinen Nachbarn gewichtet: Schwarz 37,5 %, Babyblau 27,5 %, Silber 22 %, ROT 13 %. Die beiden Farben, die man am meisten sehen sollte, kamen zusammen auf 40,5 % -- Silber allein hatte mehr Platz als Rot. Im Quelltext faellt das nicht auf: Man sieht neun silberne Stopps und denkt an Spitzlichter, nicht an ein Fuenftel der Flaeche. Jetzt Babyblau 41,5 %, Rot 33 %, Schwarz 21,5 %, Silber 4 % -- zusammen 74,5 %, und die beiden nur 8,5 Punkte auseinander. Silber ist auf den Treffpunkt in der Mitte zurueckgenommen, dieselbe Stelle, an der sich im Schriftzug Chili und Husky treffen. DAS UNIVERSUM: drei Nebel (rot unten links, babyblau oben rechts, ein Hauch Lila als Uebergang), ein Sternenfeld aus acht gekachelten Verlaufsebenen und fuenf schwebende Chilis. Sechs Elemente insgesamt -- Sterne als Elemente waeren neunzig Knoten fuer eine Zierde. Bewegt werden nur `transform` und `opacity`; ein animiertes `background-position` zwingt den Browser bei jedem Bild zum Neuzeichnen einer Kachel mit vierzehn Hintergrundebenen. DIE ORTE SIND GEMESSEN, NICHT GESTREUT -- und das war die eigentliche Arbeit. Im ersten Anlauf lagen die Chilis quer ueber der Mittelspalte: einer deckte 34,5 % der Unterzeile und 45,9 % des Lagesatzes ab, der Kontrast fiel von 6,36:1 auf 5,87:1. Das war noch zulaessig, zwang die Deckkraft aber auf sechs Prozent -- und damit sah man die Chilis nicht mehr, was ausdruecklich gewuenscht war. Die bequeme Antwort waere gewesen, sie blasser zu machen. Richtig war, sie aus dem Text herauszunehmen: Sie stehen jetzt in den Zonen ohne Text, tragen 12 bis 17 statt 6 bis 10 Prozent und decken nachgemessen NULL Text ab. Der verbleibende Verlust von 0,49 kommt allein vom Nebel. AUGENSCHONEND HEISST HIER VOR ALLEM LANGSAM: Die Bahnen dauern 71 bis 118 Sekunden, die Sternendrift 240. Bei einer Kachel, die stundenlang im Bild steht, ist eine Bewegung, die man BEMERKT, eine, die stoert. Nichts blinkt, nichts pulsiert. Bei `prefers-reduced-motion` bleibt das Bild stehen statt zu verschwinden -- die Einstellung heisst "weniger Bewegung", nicht "weniger Gestaltung". Unter 700 px gehen die beiden groessten Chilis: Bei 380 px Breite naehme der grosse ein Drittel der Kachel ein und staende hinter dem Titel. Nebenbei zusammengelegt: Die Innenform der Kachel (das Fasen-Polygon) stand zweimal gleich da und steht jetzt einmal in `--k-innenform`. Genau diese Sorte Doppelung hat mich in dieser Datei heute schon zweimal Zeit gekostet. Geprueft: pruef-start-ansicht (alles in Ordnung), pruef-css-klassen (alles in Ordnung), Ueberdeckung und Kontrast im Browser nachgemessen (Foto zurueck in eine Leinwand, WCAG-Helligkeit), Bildschirmfoto bei doppelter Aufloesung. pruef-barrierefrei-workspace bewusst NICHT gestartet: Der Kontrast ist hier direkt gemessen (5,87:1 gegen 4,5 gefordert), der Lauf haette 190 Sekunden gebraucht, um dasselbe zu sagen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
12c40256f7 |
Uhr: Stunden rot, Minuten silber, Sekunden babyblau -- alle drei als Reihen
Wunsch Filipe: "stunden soll rot sein, minuten schwarz/silber und die sekunden babyblau. die punkte herum sollen eine mischung von rot schwarz und babyblau sein. ich will auch dass die stunden und minuten auch barren oder punkte sind und nicht so eine durchlaufende schleife." ALLE DREI BAHNEN SIND JETZT REIHEN. Die Stunde bekommt zwoelf Balken (ein Zifferblatt hat zwoelf), Minute und Sekunde sechzig. Die Glieder sind verschieden lang -- Punkt (0,01 + runde Kappe), kurzer Balken (1,7), langer Balken (5,5). Damit liest man die drei Bahnen auch dann auseinander, wenn jemand Farben schlecht unterscheidet; Farbe allein traegt eine Information nie. VIER FUNDE BEIM NACHMESSEN, keiner davon war vorher sichtbar: 1. ABRUNDEN STATT RUNDEN. `Math.round` liess Minute und Stunde ab der HAELFTE einen Balken zu frueh aufleuchten: um 14:30 zeigte der Stundenring vier statt drei Balken, der Minutenring ab Sekunde 30 einen zu viel. Die Uhr war damit die halbe Zeit ueber falsch -- und ausgerechnet zur vollen Stunde, wo man hinsieht, richtig. Nachgerechnet: 10:30 -> 11, 14:30 -> 3, 23:59 -> 12, 00:00 -> 1. 2. DIE PERLENKOEPFE TRUGEN DIE ALTE ZUORDNUNG. Die drei Boegen waren getauscht, die drei Koepfe nicht: ein roter Kopf sass auf der blauen Sekundenreihe, ein silberner auf den roten Stundenbalken. Das sah nach einem Winkelfehler aus, obwohl alle drei auf die Zehntelgrad genau standen (354 / 161,9 / 343,0 bei 23:26:59, gemessen). Wer eine Farbe tauscht, tauscht sie an ALLEN Stellen: Bogen, Kopf, Schein, Kranz. 3. DER SCHEIN LAG DREIFACH UEBEREINANDER. Jeder Ring liegt dreimal im SVG (Schatten, Hauptlage, Kante); `.uhr__stunde` traf alle drei. Das rote Leuchten lief dadurch bis ueber die Ziffern, obwohl in der Regel nur 1,8 px stehen -- genau das Verschwommene, das Filipe nicht will. Jetzt `.uhr__ring > …`: nur die Hauptlage leuchtet, Schatten und Kante bleiben hart. 4. ZWEI TOTE FARBSCHICHTEN in heim.css (Sekunde rot / Minute blau / Stunde bronze). Sie wurden vom spaeteren Satz ueberschrieben und waren unsichtbar -- aber wer die Datei von oben liest, haelt sie fuer die geltende Regel und aendert die falsche Stelle. Entfernt statt stehengelassen: EINE Stelle entscheidet ueber eine Farbe. Ausserdem: Der Kometenschweif ist raus (HTML und CSS, nicht ausgeblendet). Eine Reihe zeigt ihre Richtung durch das letzte Glied; ohne eigenes Muster haette er einen vollen Ring quer ueber die Punkte gezogen. Der Punktkranz aussen mischt jetzt Rot, Babyblau und ein sehr dunkles Blau im 18-Grad-Takt -- das Dunkel ist kein Loch, sonst zerfiele der Ring aus dem Augenwinkel in zwei Haelften. Gedaempft bleibt Pflicht: Die Sekunde laeuft dauernd und bekommt das ruhigste Babyblau, die Stunde bewegt sich kaum und darf die kraeftigste Farbe tragen. Die Auslieferungskennung ist auf allen 19 Seiten hochgesetzt, sonst kaeme keine der Aenderungen an. Geprueft: pruef-start-ansicht (alles in Ordnung), pruef-css-klassen (alles in Ordnung), Segmentzahlen und Perlenwinkel im Browser nachgemessen, Bildschirmfoto bei vierfacher Aufloesung. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
25f35c1290 |
Die App-Leiste wird dunkel, und der Titel sagt nicht mehr alles doppelt
Filipe, mit Bildschirmfoto der installierten App: "die barre oben wenn ich die seite als app installiere ist blau, sie soll der seite angepasst werden auch der text oben soll jetzt der seite unten angepasst werden". DIE LEISTE stand auf `theme-color: #0674b9` -- ein kraeftiges Blau. In einem Browserfenster faellt das nicht auf, weil man die Angabe dort gar nicht sieht. Als installierte App ist sie die FENSTERLEISTE, und damit sass ueber einer durchweg dunklen Seite ein leuchtend blauer Balken. Jetzt derselbe Ton wie die Kopfleiste darunter (#06090f): Leiste und Seite sind eine Flaeche statt zweier. Geaendert auf allen 19 Seiten und im Manifest -- steht die Farbe nur an einer Stelle, blitzt beim Wechsel auf eine andere Seite kurz die alte auf. DER TITEL stand doppelt in der Leiste, und beide Haelften sagten dasselbe: "Creator Workspace — Dogfather Universe" (aus dem Manifest) plus "Dogfather Universe · Creator Workspace · Anmeldung" (aus <title>). Der Markenname kam zweimal, der Anwendungsname zweimal, und was die Seite tatsaechlich zeigt, stand ganz hinten. Jetzt steht vorn, WO man ist, und hinten die Marke: Anmeldung · Spicy & Dogi Kalender · Spicy & Dogi Personen & Zugaenge · Spicy & Dogi "Creator Workspace" faellt dabei aus den Unterseiten heraus -- es steht im Manifest und damit ohnehin im Fenstertitel. Neunzehn Titel, alle nach demselben Muster; vorher folgten sie zwei verschiedenen. Das Manifest heisst jetzt "Creator Workspace — Spicy & Dogi" und der Ladehintergrund #0a121e statt #151e2a: Er ist das Erste, was beim Starten der App zu sehen ist, und war heller als die Seite, die danach kommt -- ein Aufblitzen bei jedem Start. pruef-start-ansicht EXIT=0 (140), pruef-workspace-seiten EXIT=0 (32). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
a9f3212da3 |
Startseite: die tote Mitte der Konsole bekommt drei Ablesungen
Gemessen, nicht geschaetzt: Auf 1440 px lagen zwischen dem Ende des Textes und der Uhr rund 300 px Leere. Dort stehen jetzt HEUTE (Termine), ALS NAECHSTES (Uhrzeit) und OFFEN (Punkte, Farbe nach Lage). Keine zweite Zaehlung: Die Zahlen kommen aus denselben zwei Quellen, die die Kacheln darunter fuellen. Zwei Rechenwege fuer dieselbe Zahl laufen auseinander, und dann stehen zwei Wahrheiten auf einem Bildschirm. EINE Fassung mit Stegen, nicht drei Kaestchen. Der erste Anlauf gab jedem Wert eine eigene Fraesung -- im Bild sah das aus wie aufgeklebte Plaettchen. Ein Instrumentenblock ist EIN eingelassenes Feld, in dem Stege trennen; das Licht laeuft dann einmal ueber eine Kante statt sechsmal. Auf dem Handy geht der Block auf volle Breite und richtet sich nach der Uhr, nicht nach dem Rand. EINE ANNAHME KORRIGIERT: In meiner Merkliste stand "Werktisch-Aufbau nach VanVans Business Hub, Prozentring links". Im Hub nachgesehen -- es gibt dort keinen Ring und keinen solchen Aufbau, nur eine schlichte buehne-hero. Filipes Verweis galt der UHR, und die ist laengst gebaut. Meine eigenen Notizen altern wie jede andere Bestandsliste. DREI BEFUNDE AUS EIGENEN PRUEFUNGEN, alle behoben: 1. pruef-css-klassen: Die Zahl der Schriftgroessen unter 11,5 px war um genau eine gestiegen -- .stand__schild stand auf 9,3 px. Gesperrte Grossbuchstaben in 9 px liest man nicht, man erraet sie. Jetzt 11,5 px mit etwas engerer Sperrung, damit drei Schilder bei 320 px weiterhin nebeneinander passen (nachgemessen: 287 px, nichts abgeschnitten). 2. pruef-struktur: pruef-arten.mjs bildete das Tagesdatum aus UTC. Nachts zwischen 00:00 und 02:00 waere sie rot geworden, ohne dass am Code etwas falsch ist. Derselbe Fehler war mir am selben Abend schon im Messskript passiert -- dort hatte ich "Heute=0" gemessen und den Code verdaechtigt, der richtig lag. 3. Beim Bauen fast eingebaut: margin-left:auto von der Uhrgruppe genommen, weil der neue Block sie ja schon nach rechts schiebt. Er tut das nur, solange er da ist -- bis zur ersten Antwort steht er auf hidden, und die Uhr waere sichtbar weggesprungen. Neu: server/pruef-ueberlappung.mjs. Misst auf 5 Seiten x 4 Breiten, ob ein Bedienelement ueber einem anderen liegt (am 06.09. lag der Sicht-Umschalter bei 412 px auf zwoelf Seiten ueber dem Chat-Knopf). Ueberlappungen INNERHALB eines Bedienelements zaehlen nicht -- ein durchsichtiges select ueber seinem eigenen Schild ist die uebliche Bauart, und eine Warnung, die immer kommt, ist keine Warnung mehr. Mit Gegenprobe: ein absichtlich verschobener Knopf muss erkannt werden. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
de06ce0227 |
Kalender: sechs neue Terminarten, mit zwei stillen Loechern darin
Wunsch: "kategorien wie bigmatch, turniere, Special-Live ... informier
dich was man da alles noch gebrauchen koennte und auch so dass wenn man
die sachen aussucht die ganze kachel und sachen die man eintippen muss
auch zu der jeweiligen kategorie passen."
Neu: BigMatch, Turnier, Special-Live, Collab, Raid-Train, Charity --
neben den drei internen Arten. Das Formular fragt je Art anderes:
beim BigMatch "Gegen wen?" mit 60 Minuten, beim Turnier "Welches
Turnier?" mit 120, bei Charity "Fuer wen wird gesammelt?" mit 180.
ZWEI FEHLER, DIE BEIDE NICHT ABGESTUERZT WAEREN:
1. termin_serien wurde nicht umgestellt. Die Umbauschleife laeuft ueber
zwei Tabellen, bildete den Namen der Sicherungsdatei aber ohne die
Tabelle -- und der Zeitstempel darin wird einmal pro Serverstart
gebildet. Der zweite Durchlauf wollte also dieselbe Datei anlegen,
VACUUM INTO weigerte sich, und das (richtige) "ohne Sicherung kein
Umbau" beendete die ganze Schleife. Ergebnis: termine umgestellt,
termin_serien nicht. Eine wiederkehrende BigMatch-Reihe waere ohne
erkennbaren Grund abgelehnt worden.
2. Die neuen Arten waren im Kalender UNSICHTBAR. In kalender.js standen
zwei weitere Aufzaehlungen derselben Arten: `zeigen = {call, termin,
review, frist}` und die Schalterleiste. Gefiltert wird mit
`zeigen[e.art]` -- fuer 'bigmatch' ist das undefined. Anlegen ging,
der Server meldete 201, die Zeile stand in der Datenbank, und im
Kalender war sie in keiner Ansicht zu sehen. Ohne Fehler, ohne Hinweis.
Beide Listen werden jetzt aus ARTNAME abgeleitet. Und `sichtbare()`
prueft `!== false` statt auf Wahrheit: Der Vorgabewert einer
Sichtbarkeitsfrage muss "sichtbar" sein -- ein Eintrag zu viel ist
ein Schoenheitsfehler, ein fehlender ein verpasster Termin.
Gefunden hat Nummer 2 kein Test, sondern ein Bildschirmfoto: In der
Schalterleiste standen vier Arten statt zehn. Meine eigene Pruefung war
zu dem Zeitpunkt gruen -- sie hoerte beim HTTP 201 auf.
Neu: server/pruef-arten.mjs, 28 Pruefungen. Baut eine Datenbank im ALTEN
Stand nach (samt Teilnehmer, Wecker, Serie), laesst die Anwendung
darueberlaufen und zaehlt nach; haelt CHECK und Serverliste gegeneinander;
und oeffnet zuletzt einen echten Browser, um zu sehen, ob die Eintraege
auch ankommen. Gegenprobe gefahren: mit dem alten Stand meldet sie
0 von 6 sichtbar.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
535d86d3f7 |
Die Termine im Tagesfenster sind Karten statt Werkzeugleisten
Filipe: "die sollen viel besser aussehen und viel geiler."
WAS WIRKLICH SCHIEFLIEF, WAR KEIN GESCHMACK, SONDERN DER AUFBAU
Zeit, Titel, Art und FUENF Knoepfe standen in EINER Zeile. Der Titel
bekam damit den Rest -- "BigMatch vs. Beanii" brach auf DREI Zeilen um,
waehrend rechts daneben Platz war. Die wichtigste Angabe der Zeile war
die gequetschteste, und die Knoepfe waren genauso laut wie der Termin
selbst.
Jetzt drei Ebenen, wie bei einer Karte:
OBEN Zeit und Titel, gross, ueber die ganze Breite -- der Titel
hat keinen Wettbewerb mehr
MITTE die Nebendaten (Dauer, Ort, Beschreibung)
UNTEN die Knoepfe, rechtsbuendig in einer eigenen Reihe, durch eine
Haarlinie abgesetzt
Die Zeit steht gross am Anfang und mit gleichen Zifferbreiten: Sie ist
das, wonach man in einem Tagesfenster sucht, und mehrere Zeilen stehen
dadurch in einer Flucht. Die Zeile traegt jetzt dieselbe abgeschnittene
Ecke wie alle Module -- ein Eintrag im Tagesfenster ist ein kleines
Modul, kein Listenpunkt.
ZWEI DINGE, DIE DABEI AN DIE RICHTIGE STELLE GERUECKT SIND
* DIE ART GEHOERT ZUM TITEL. Sie stand als erstes Element in der
Knopfreihe und sah damit aus wie ein Knopf, der nicht reagiert. Sie
ist aber eine ANGABE ueber den Termin, wie Uhrzeit und Titel. Jetzt
steht sie neben dem Titel, und die Knopfreihe enthaelt nur noch
Dinge, die etwas tun.
* DIE NEBENDATEN VOR DIE KNOEPFE. Im Raster bestimmt die Reihenfolge
im Dokument, welche Zeile ein Feld bekommt -- die Knopfreihe stand
davor und landete zwischen Titel und "30 Min · TikTok". Im ersten
Bildschirmfoto stand die Beschreibung UNTER den Knoepfen, als
gehoerte sie zu ihnen. Geloest ueber die Reihenfolge im Dokument und
nicht ueber `order` im Stil: Sie gilt auch fuer Vorleseprogramme und
die Tastatur, `order` verschiebt nur das Bild.
Auf dem Handy stehen Zeit und Titel untereinander -- bei 390 px laesst
eine 1,06-rem-Uhrzeit daneben keine zwei Woerter uebrig.
Zehn Pruefungen gelaufen, alle gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
e744f22fbc |
Vier Tafeln in einer Reihe -- die offene breiter als die Reiter
Filipe: "die sollen alle in einer reihe sein und nicht 3 und dann eins drunter. perfektionier das." DER GRUND WAR EINE RECHNUNG, DIE ICH NICHT KONTROLLIERT HABE Dort stand `auto-fit` mit 340 px Mindestbreite -- CSS rechnet sich dann selbst aus, wie viele nebeneinanderpassen. Bei vier Tafeln in einer 1240 px breiten Spalte reichte es fuer drei; die vierte rutschte in eine zweite Zeile. `auto-fit` ist bequem, solange die Anzahl offen ist. Sobald sie feststeht, ist es eine Rechnung, die man aus der Hand gibt. Vier sind es, vier stehen nebeneinander -- und zwar mit `flex` statt `grid`, weil damit die OFFENE Tafel breiter sein kann als die geschlossenen. Es ist immer genau eine offen, und die bekommt den anderthalbfachen Anteil: Dort wird gearbeitet, die anderen sind Reiter. Das ist der Unterschied zwischen vier gleich grossen Kaesten und einem Brett. UND EIN VERSPRECHEN, DAS ERST NACH DEM ERSTEN KLICK GALT Das Akkordeon griff nur beim Klicken. Beim Laden kamen die gemerkten Staende aus der Ablage, und die konnten drei offene Tafeln ergeben -- im Bildschirmfoto standen genau so drei offen nebeneinander. Jetzt bleibt beim Aufbau die erste Tafel offen, die etwas enthaelt; alle weiteren klappen zu, ohne den gemerkten Stand zu ueberschreiben. DREIMAL GEMESSEN STATT GESCHAETZT Nach dem Umbau standen dort "LAEUFT AUTO..." und "FESTGEHALT..." -- 252 px je Reiter, gemessen. Ich habe zweimal an den Pixeln gedreht (Anteil 2,2 -> 1,8 -> 1,5, Sperrung 0,08 -> 0,035 em) und es blieb abgeschnitten. Die richtige Antwort war nicht die dritte Zahl, sondern der Name: Ein Reiter braucht ein Wort. Aus "Laeuft automatisch" wurde "Wiederholungen" -- was es genau heisst, steht im Satz darunter, und den liest man ohnehin erst, wenn die Tafel offen ist. Gemessen am Ende: vier Tafeln, EINE Reihe, EINE offen, KEIN abgeschnittener Titel. Sechs Pruefungen gelaufen, alle gruen. OFFEN, damit es nicht untergeht: pruef-call-kategorien meldet auf Windows sporadisch Rueckgabewert 127 -- NACH "ALLES IN ORDNUNG", also beim Beenden des Prozesses (libuv-Assertion beim Schliessen des noch laufenden Servers). Das Ergebnis stimmt, der Rueckgabewert luegt. Wer nur auf den Code sieht, haelt einen gruenen Lauf fuer rot. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
1c2e196d1d |
Der Wecker: mehrere Erinnerungen je Termin, jeder fuer sich
Filipe: "wie so ein wecker, den man auch in den eintraegen aktivieren
oder ausschalten kann, den soll man sogar so einstellen koennen, dass
er einen auch mehrmals informiert, einmal eine woche vorher, einmal
drei tage vorher und einmal am tag selber. das soll man auch selbst
jeder fuer sich einstellen koennen. hol die besten skills."
NACHGELESEN, NICHT GERATEN. Google Calendar erlaubt fuenf Erinnerungen
je Termin, Outlook genau eine, Apple zwei. Die verbreitete Empfehlung
fuer Wichtiges lautet "eine Woche, ein Tag, am Tag selbst" -- also
genau die Staffel, die Filipe genannt hat. Uebernommen: sechs Stufen
zur Wahl (Woche, drei Tage, ein Tag, selber Tag, Stunde, zehn Minuten),
hoechstens fuenf gleichzeitig.
EINE ZEILE IST EIN WECKER -- kein Feld am Termin mit einer Liste darin.
Mehrere Vorlaufzeiten UND "jeder fuer sich" sind zusammen eine
n:m-Beziehung; ein Feld mit kommagetrennten Zahlen waere beim ersten
"zeig mir alle faelligen Wecker" nicht mehr abfragbar.
DER ABSTAND STEHT IN DER DATENBANK, NICHT DER ZEITPUNKT. Ein Zeitpunkt
muesste bei jeder Terminverschiebung nachgezogen werden -- und genau
das vergisst man. Ein Abstand rechnet sich beim Wecken aus dem
aktuellen Beginn und ist damit immer richtig.
ZWEI GRENZEN IM WECKLAUF, und beide sind noetig: faellig (Weckzeit
erreicht) UND der Termin liegt noch vor uns. Ohne die zweite wuerde
beim ersten Lauf nach einem Ausfall jeder alte Wecker der letzten
Wochen nachtraeglich klingeln.
DER ABSTAND GEHOERT INS MERKMAL der Doppelsperre. Ohne ihn wuerde der
erste Wecker eines Termins alle weiteren sperren -- und genau das
Mehrfach-Wecken, um das es geht, faende nie statt.
DIE PRUEFUNG HAT SICH ZWEIMAL SELBST KORRIGIERT
1. Erster Lauf um 23:42: vier Fehler, keiner echt -- der Melder
schweigt zwischen 22 und 7 Uhr. Sie hat den Kalender gemessen,
nicht die Software, und waere am Vormittag gruen gewesen. Dass die
GEGENPROBE mitgefallen ist, war die eigentliche Auskunft: Waeren
nur die Grenzen falsch, haette sie gehalten. Die Ruhezeit ist
jetzt ueber die Umgebung einstellbar (Vorgabe unveraendert 22/7),
damit eine Pruefung ihre Voraussetzung herstellen kann.
2. Danach immer noch nichts: Ich hatte angenommen, der Melder trage
den Versand nach dem VERSUCH ein. Er traegt ihn nach der
erfolgreichen ZUSTELLUNG ein -- und das ist richtig so. Meine
Annahme war falsch, nicht der Code. Die Pruefung hat jetzt einen
winzigen echten Empfaenger; damit laeuft der ganze Versandweg mit,
Verschluesselung und VAPID inbegriffen.
pruef-wecker.mjs: 20 Pruefungen. Sie stellt alle vier Fehler nach, die
bei einem Wecker moeglich sind (klingelt nicht / doppelt / nur einmal
von dreien / nachtraeglich nach einem Ausfall) -- plus die Gegenprobe,
dass ein faelliger Wecker wirklich ankommt.
Zwoelf weitere Pruefungen gelaufen, alle gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
63036fc33e |
Wiederholungen bekommen eine eigene Tafel -- und nur den laufenden Monat
Filipe: "ich will da auch noch eine kategorie fuer automatische
wiederholungen. die sollen dann auch nur fuer den monat selbst
angezeigt werden und nicht monate im voraus."
DAS PROBLEM WAR ECHT UND GROSS, UND ES STAND SEIT TAGEN AUF SEINEM
BILDSCHIRM
Der Nachfueller haelt einen Horizont von 180 Tagen gefuellt (siehe
workspace-serien.js). Ein woechentlicher Community-Talk ergibt darin
sechsundzwanzig Zeilen -- und alle standen unter "Steht an". Auf dem
Bild waren es siebenundzwanzig Karten, fast alle derselbe Termin. Die
Liste war damit unbrauchbar fuer genau das, wofuer sie da ist: zu
sehen, was WIRKLICH ansteht.
Jetzt sind es zwei getrennte Fragen:
STEHT AN was einmalig bevorsteht
LAEUFT AUTOMATISCH was von allein wiederkommt -- und davon nur der
LAUFENDE MONAT
Der Monatsschnitt ist die eigentliche Antwort auf "nicht Monate im
Voraus": Eine Wiederholung im November sagt einem heute nichts, was man
nicht schon weiss. Wer weiter schauen will, hat den Kalender -- und
genau das steht als Satz in der Gruppe.
Gerechnet wird auf dem reinen Datumstext (`beginn` beginnt mit
JJJJ-MM), nicht mit `new Date`. Kein Zeitzonenfehler, kein Nachtfehler.
Die Trennung faellt im SERVER, nicht in der Oberflaeche: Eine zweite
Regel im Browser waere die sichere Zusage, dass beide auseinanderlaufen.
DREI AUSSAGEN STATT EINER
pruef-call-kategorien saet jetzt zwei Auspraegungen derselben Serie --
eine in vier, eine in sechzig Tagen -- und misst:
1. die Wiederholung dieses Monats steht in "Laeuft automatisch"
2. die des naechsten Monats NICHT
3. und unter "Steht an" steht keine von beiden
Vorher wird geprueft, dass die beiden ueberhaupt in verschiedenen
Monaten liegen. Ohne diese Zeile waere Nummer 2 an einem 1. des Monats
trivial erfuellt -- gruen, ohne etwas gemessen zu haben.
Zwei Fehler beim Bau der Pruefung, beide von ihr selbst gemeldet:
`page.evaluate` lief in "Target page has been closed" (der Block davor
schliesst seinen Browserkontext -- diese Aussage braucht ohnehin keinen
Browser, sie betrifft die Schnittstelle), und eine Hilfsfunktion stand
nach ihrer ersten Benutzung.
pruef-call-kategorien von 17 auf 22. Neun Pruefungen gelaufen, alle
gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
fc4616bb05 |
Immer nur eine Tafel offen -- und eine zugeklappte belegt nichts mehr
Filipe: "wenn ich eine aufklicke soll auch immer nur die aufgehen und nicht alle 3." DAS IST MEHR ALS GESCHMACK. Seit die drei Tafeln nebeneinander stehen und jede ihren eigenen Lauf hat, teilen sie sich die Bildschirmhoehe: Drei offene Tafeln heissen drei kurze Ausschnitte -- eine offene heisst eine, in der man wirklich arbeiten kann. Die anderen werden ZUGEKLAPPT, nicht versteckt: Ihre Koepfe bleiben mit Namen und Anzahl stehen. Man sieht weiterhin, was es sonst gibt, und kommt mit einem Klick hin. Der gemerkte Stand wird mitgeschrieben -- sonst waere die Seite beim naechsten Aufruf in einem Zustand, den niemand hergestellt hat. UND EIN FEHLER VON MIR, DEN SEIN BILD GEZEIGT HAT Die zugeklappten Tafeln standen als LEERE KAESTEN ueber die volle Hoehe da. `align-items: stretch` am Brett gilt eben auch fuer die, die nichts zeigt. Drei gleich hohe Tafeln sind richtig, solange sie etwas enthalten -- eine geschlossene enthaelt nichts und soll dann auch nichts belegen. Vier Pruefungen gelaufen, alle gruen. NOCH OFFEN, und bewusst nicht angefangen: Erinnerungswecker, Terminarten (BigMatch/Turniere/Special-Live) und der Umbau der Begruessungskachel nach VanVans Werktisch. Jede davon ist ein eigener Bau -- angefangen und liegengelassen waeren sie schlimmer als gar nicht begonnen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
c5cdf686e3 |
Der Husky jetzt auch auf der Zugangsseite -- und fuenf Zeichen in fuenf Farben
Filipe: "bei dogfather ist immer noch die krone und da soll ja ein husky sein. und die symbole sollen doch alle viel krasser, geiler und spezieller sein." Er hat recht, und der Grund ist eine Haelfte, die ich uebersehen habe: Die Rollenzeichen gibt es ZWEIMAL im Haus -- als <use>-Bausteine in personen.html (dort war der Husky schon) und noch einmal ausgeschrieben in index.html, der Anmeldeseite. Getauscht hatte ich nur die erste. DER HUSKY, zweite Ausfertigung. Bei 21 Pixeln entscheidet die Silhouette, nicht das Detail: spitze aufrechte Ohren, breiter Kopf, der nach unten schmal zulaeuft, Gesichtsmaske. Mehr passt nicht hinein -- und mehr braucht es nicht. UND ALLE FUENF ZEICHEN TRAGEN JETZT IHRE EIGENE FARBE Sie waren feine Konturen in einer Farbe, und zwar in DERSELBEN fuer alle fuenf. Jetzt: eine gefuellte Flaeche in der Farbe ihrer Rolle, die Zeichnung hell darauf, ein leichter Schatten darunter. Chili rot, Husky gold, Stern violett, Schild gruen, Person blau -- dieselben Farben wie auf der Personenseite; wer die eine Seite kennt, erkennt die andere wieder. Die Farbe steht am ROLLENKNOPF (`--rf`), nicht im Zeichen. Die Zeichen wissen damit nichts von Rollen, und eine Farbaenderung passiert an einer Stelle statt an fuenf. Gewaehlt heisst: mehr Licht auf demselben Gegenstand -- kein anderer Gegenstand. Zehn Pruefungen gelaufen, alle gruen, darunter Kontrast und Handy fuer die Anmeldeseite. Co-Authored-By: Claude Opus 5 <[email protected]> |