8cdc31bd4617efce907573c39261596b91f7a41e
100
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
8cdc31bd46 |
Der erste Partnercode steht: DOGI10 auf einer gepraegten Muenze
Die Rabattcodeseite war ein Platzhalter -- "Codes folgen in Kuerze" und
darunter eine Vorschaukachel mit dem erfundenen Code "DOGFATHER". Jetzt
steht der erste echte drauf: DOGI10 fuer Van's DIY & Bastelbedarf,
verlinkt auf vans-diy-bastelbedarf.com.
DIE KONDITIONEN SIND ABGELESEN, NICHT GERATEN.
Aus "DOGI10" auf zehn Prozent zu schliessen, waere naheliegend gewesen,
haette zufaellig gestimmt und waere trotzdem falsch gewesen. Nachgesehen
im Shop selbst (src/content/partnercodes.json):
{ "code": "DOGI10", "prozent": 10, "bis": "2026-09-30",
"aktiv": true, "giltAufSale": false }
Zwei der drei Angaben stehen im Namen NICHT drin: dass der Code am
30.09.2026 auslaeuft und dass er auf bereits reduzierte Artikel nicht
gilt. Beides steht jetzt sichtbar auf der Karte. Eine falsche Zusage auf
einer Verkaufsseite kostet VanVan die Diskussion an der Kasse.
Gegengeprueft, dass die Datei auch wirklich gilt und kein Ueberbleibsel
ist: Sie wird an zwei Stellen ausgewertet, src/scripts/cart.ts fuer den
Warenkorb und server/lib/preis-berechnen.js fuer den Endpreis, beide mit
derselben Regel (aktiv !== false UND jetzt <= bis 23:59:59).
DAS ABLAUFDATUM IST EINE ZEITBOMBE, ALSO BEKOMMT ES EINEN ZUENDER.
Ein fest eingetippter Satz "gueltig bis 30.09.2026" stimmt, bis der
Kalender ihn ueberholt -- ab dem 01.10. verspraeche die Seite etwas, das
der Shop schon ablehnt. Genau dieselbe Falle hat am 06.09. den
Oeffnungstest im Shop umgeworfen. Das Datum steht deshalb nicht nur im
Text, sondern einmal als Zahl im Skript: Ist es vorbei, schaltet die
Karte selbsttaetig auf "abgelaufen", streicht den Code durch und sperrt
den Kopierknopf, statt weiter zu werben.
DAS LOGO: AUS EINEM SIEGEL WIRD EINE MUENZE.
Filipe hat das Logo als Bildschirmfoto aus TikTok geliefert, rundes
Siegel auf schwarzem Grund. Ungestellt waere daraus auf der dunklen
Karte ein sichtbarer schwarzer Kasten geworden -- derselbe Fehler wie
bei der Workspace-Marke, deren Zahlen damals tadellos aussahen.
Freigestellt wird per Flutfuellung vom Bildrand (tools/partner-siegel-
freistellen.mjs, 384 px WebP, 37 KB). Eine Kreismaske waere hier sogar
ausrechenbar gewesen -- Mitte 539,5/526,5, Radius 495 -- und haette
genau fuer dieses eine Bild funktioniert. Die Fuellung MISST die Form,
statt sie vorauszusetzen: Der naechste Partner ist ein Eintrag in
AUFTRAEGE und sonst nichts. Die Quelle liegt mit im Repo, sonst laesst
sich das Werkzeug genau einmal ausfuehren und ist danach Dekoration.
"Extrem speziell" fuehrt hier NICHT ueber mehr Farbe -- das Siegel ist
schwarz-weiss, jede Einfaerbung lackierte eine fremde Marke um. Es
fuehrt ueber mehr Material: sechs CSS-Lagen, kein zweites Bild.
Aura weicher Lichthof, atmet in 9 s
Raendel die geriffelte Muenzkante, 72 Zaehne. Sie steht STILL --
eine sich drehende Riffelung flimmert bei 148 px, und das
waere genau die grelle Optik, die die Hausregel ausschliesst
Glanz stattdessen wandert EIN Lichtpunkt in 22 s um die Kante.
Das ist die Bewegung, die eine Muenze im Licht macht
Schliff Praegekante nach innen, oben Licht, unten Schatten
Ablage elliptischer Schatten, damit die Muenze auf der Karte LIEGT
Bei prefers-reduced-motion steht alles davon still.
NEBENBEFUND, DER SONST NIEMANDEM AUFGEFALLEN WAERE: Der Text auf der
Sperrkachel endete auf "sobald die ersten Kooperationen live sind".
Seit heute IST die erste live -- der Satz haette jemanden dafuer zahlen
lassen, auf etwas zu warten, das schon hinter der Sperre liegt.
Ebenfalls nachgemessen statt vermutet: die Warengruppen im
Beschreibungssatz sind die echten Kategorien des Shops.
pruef-rabattcodes EXIT=0 (42 Pruefungen), darunter beide Richtungen der
Supporter-Sperre, die Bildpunkte des ausgelieferten Siegels (Ecken
durchsichtig, Mitte deckend, 69 % Flaeche), das Kopieren gegen die echte
Zwischenablage samt Gegenprobe davor, die Ablaufschaltung mit gestellter
Uhr an beiden Seiten des Stichtags und alle fuenf Sprachen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
d694e34fcb |
Die Uhr nach Filipes Vorbild: LED-Kranz, Anker, rote Anzeige
Filipe hat eine Sci-Fi-Uhr geschickt (1250 px) und gesagt "so wie die".
Unsere ist 164 px gross -- Faktor 7,6. Was uebernehmbar ist, entscheidet
damit nicht der Geschmack, sondern die Groesse:
UEBERNOMMEN der blaue LED-Punktkranz aussen (das auffaelligste
Merkmal des Vorbilds), die vier Anker bei 12/3/6/9,
der rote Grundton der Digitalanzeige.
NICHT MOEGLICH die Minutenzahlen 00/05/…/55 und die Stundenzahlen
1-12. Im Vorbild sind sie rund 30 px hoch; hier waeren
es VIER. Zahlen, die man nicht lesen kann, sind kein
Zifferblatt, sondern Rauschen -- und sie wuerden die
drei Boegen zudecken, die die eigentliche Anzeige sind.
Der Kranz ist ein `repeating-conic-gradient` mit 6-Grad-Takt, aus dem
eine Maske einen schmalen Ring schneidet: 60 Punkte, einer je Sekunde,
in EINER Ebene. Sechzig <span> waeren sechzig Elemente fuer eine Zierde.
Die vier Anker ebenso, mit 90-Grad-Takt.
EINE FALSCHE BEGRUENDUNG, VON DER EIGENEN RECHNUNG WIDERLEGT: Ich hatte
in den Kommentar geschrieben, reines Neonrot wie im Vorbild "reisse den
Kontrast" und liege bei 4,0:1. Nachgerechnet sind es 5,27:1 -- es haelt
die Grenze von 4,5. Die schoenere Begruendung war die falsche.
Die Entscheidung bleibt trotzdem, nur mit dem echten Grund: Diese Uhr
steht DAUERHAFT im Bild einer Seite, an der gearbeitet wird. Reines
gesaettigtes Rot auf Schwarz ermuedet bei stundenlangem
Nebenherschauen, auch wenn es messbar lesbar ist -- genau das meint die
Hausregel "augenschonend", und das deckt keine Kontrastzahl ab. Die
Ziffern sind deshalb ein sehr helles Rotweiss (15,9:1), das seinen
roten Charakter aus dem Schein im Textschatten bekommt. Man liest
"rote Digitalanzeige", ohne stundenlang in eine Leuchtreklame zu sehen.
Aus demselben Grund liegt das Blau der LEDs bei rund 53 % Deckkraft:
Die Anmutung kommt vom Aufbau, nicht von der Grellheit.
pruef-start-ansicht EXIT=0 (140), pruef-css-klassen EXIT=0 (28).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
e2bd6d4dc4 |
Die Uhr bekommt Kometenschweife -- und die Koepfe gleiten, statt zu springen
Filipe: "nehm diese uhr bitte und passe sie so gut wie es geht an, auch die lichter von sekunden, minuten und stunden perfekt anpassen ... überrasch mich." ZWEI DINGE, DIE EINE UHR LEBENDIG MACHEN. 1. DER KOMETENSCHWEIF. Ein Bogen in gleichmaessiger Farbe zeigt einen STAND. Ein Bogen, der zur Spitze hin heller wird, zeigt eine RICHTUNG -- man sieht ohne Nachdenken, wo "jetzt" ist und wohin es laeuft. Bei drei Ringen uebereinander ist das der Unterschied zwischen Ablesen und Erkennen. Gebaut als zweites, kuerzeres Segment ueber dem Bogen: die letzten rund 40 Grad, heller, mit runder Kappe. Ein Verlauf ENTLANG der Bahn geht in SVG nicht -- `linearGradient` folgt einer Geraden, keiner Kurve. Zwei Lagen sind der ehrliche Weg dorthin. Die Lage wird gerechnet, nicht geschaetzt: Bei Umfang U, Fortschritt a und Schweiflaenge s soll das Segment von (aU - s) bis aU liegen. Mit `dasharray: s, U-s` beginnt das sichtbare Stueck bei (U - offset), also ist offset = U*(1-a) + s. Die Laenge wird bei kurzen Boegen mitgekuerzt -- sonst haenge der Schweif am Anfang einer Minute am ENDE des Kreises, sichtbar als heller Strich bei zwoelf Uhr. 2. DIE KOEPFE GLEITEN. Bisher sprangen sie einmal je Sekunde. Jetzt uebernimmt der Browser die Bewegung dazwischen (Ueberblendung von 0,92 s) -- das Skript rechnet weiterhin nur EINMAL je Sekunde. Sechzig Bildberechnungen je Sekunde wuerden auf einer stundenlang offenen Seite den Rechner warm halten; diese Loesung kostet nichts. ZWEI FEHLER DABEI, BEIDE NUR IM BILD ZU SEHEN: Der erste Versuch rechnete die Winkel aus der vollen Unixzeit, damit sie immer weiterwachsen (sonst liefe die Ueberblendung einmal je Minute rueckwaerts durchs Zifferblatt). Ergebnis: `rotate(1.07333e+10deg)` -- Exponentialschreibweise, Nachkommastellen weg. Die Koepfe standen sichtbar neben ihren Boegen, der rote auf der anderen Seite der Uhr. Jetzt zaehlt eine eigene Uhr ab dem ersten Takt: klein genug zum Rechnen, wachsend genug fuer die Ueberblendung. Und ich hatte den Schweifen `rotate(-90deg)` gegeben, damit sie bei zwoelf beginnen -- das SVG ist aber bereits gedreht. Sie standen dadurch exakt eine Vierteldrehung daneben: oben links, waehrend die Boegen oben rechts endeten. NACHGEMESSEN, in Grad statt nach Augenmass: Kopf gegen Bogenende Abweichung 0,00° / 0,00° / 0,03° Schweifende gegen Bogen Abweichung 0,0° / 0,0° / 0,0° pruef-start-ansicht EXIT=0 (140), pruef-css-klassen EXIT=0 (28). Bei `prefers-reduced-motion` gleiten die Koepfe nicht -- sie springen dann wie vorher. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
4c0ff5caa9 |
Die vier Call-Reiter stehen bei jeder Rolle -- und die Tagesliste bekommt die Fase
Filipe mit zwei Bildschirmfotos nebeneinander: "wieso bei den scouts so und bei den manager so?" Bei Patrick stand EINE Tafel ueber die volle Breite, bei Schulle vier nebeneinander. DIE URSACHE war zweimal derselbe Satz Code an zwei Stellen in calls.js: `if (!liste.length) continue;` eine leere Gruppe wurde nicht gebaut `... return;` sind ALLE leer, gab es nur einen Satz Wer nichts Offenes hat, sah damit nicht "weniger", sondern eine anders AUFGETEILTE Seite: Bei einer Tafel zieht sich diese ueber die ganze Reihe. Genau derselbe Fehler wie bei den Aufgabenzahlen auf der Startseite heute -- und dieselbe Loesung: Die Tafel bleibt stehen, wird gedaempft und zeigt eine Null. "Protokoll fehlt: 0" ist eine Aussage, ein fehlender Reiter ist keine. Leere Tafeln starten zugeklappt -- aufklappen wuerde nur eine leere Liste zeigen. Der Hinweis "Noch keine Calls" bleibt, er ist nuetzlich, und steht jetzt UEBER den vier Tafeln statt an ihrer Stelle. DABEI EINEN ZWEITEN FEHLER GEBAUT UND GESEHEN: Der Hinweis wurde damit zum Geschwister der Tafeln, und `.call-brett` ist ein Flex-Kasten in EINER Reihe -- er nahm sich eine Spalte und quetschte die vier Tafeln daneben auf je 80 px. Im Bildschirmfoto standen vier Stummel neben einem breiten Satz. Behoben mit `flex-wrap: wrap` und voller Breite fuer den Hinweis; nachgemessen stehen die vier jetzt bei je 280 px. DAZU EIN BEFUND AUS DEM FORMVERGLEICH ueber alle fuenf Rollen: `.tagesliste__punkt` (die Terminzeilen auf der Startseite) trug noch runde Ecken -- direkt unter Kacheln mit Fase. Sie bekommt den Zuschnitt von Hand, nicht ueber die Modulliste: `::before` traegt die Farbkante links, die sagt, um welche Art Termin es geht, und die Modulliste braucht dasselbe Pseudo-Element fuer ihre Eckwinkel. NACHGEMESSEN ueber drei Rollen: scout 4 Reiter, admin 4, creator 4 -- alle mit derselben Aufteilung. pruef-abbrechen-optik EXIT=0 (27), pruef-start-ansicht EXIT=0 (140), pruef-css-klassen EXIT=0 (28). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
da274f7825 |
Die Dialoge bekommen die Fase -- und einer war ueberhaupt nicht gestaltet
Filipe: "es soll bei jedem nicht nur bei patrick sondern bei jedem die
neue stile haben wie bei mir."
Mein Durchlauf ueber 18 Seiten und fuenf Rollen hatte die DIALOGE
ausdruecklich ausgenommen -- und genau dort lag noch etwas.
1. `.dialog` trug runde Ecken (4px 20px 20px 4px). Er bekommt jetzt
dieselbe Fase wie alles andere. NICHT ueber die Modulliste: Die
belegt `::before` und `::after` fuer die Eckwinkel, und beide sind
hier schon vergeben -- an die Leuchtschiene links und den Lichtsaum.
Beides gegen zwei Winkel zu tauschen waere ein Rueckschritt, also
nur der Zuschnitt von Hand, mit derselben Groesse `--fase`.
2. DER WECKER-DIALOG WAR GAR NICHT GESTALTET. Gefunden beim Nachsehen,
welche Dialoge nicht `.dialog` heissen: Dieser traegt `.tagdialog`,
und diese Klasse stand in KEINER Stilvorlage. Gemessen bekam er vom
Browser:
Hintergrund rgb(18, 18, 18) flaches Systemschwarz
Rand 3 px Systemrahmen
Fase keine
Raster keins
Er sah aus wie ein Fenster des Betriebssystems mitten im Workspace --
auf JEDER Rolle, denn den Wecker haben alle. Aufgefallen ist es nie,
weil er nur aufgeht, wenn man die Glocke an einem Termin drueckt.
Nebenbei stand das Schliesskreuz unter der Ueberschrift statt daneben:
Auch `.tagdialog__kopf` war ohne Regel.
DAS IST DER GRUND, WARUM DER ERSTE DURCHLAUF "0 im alten Muster" ergab
und trotzdem nicht die ganze Wahrheit war: Meine Messung suchte
Elemente mit runden ECKEN. Ein Baustein ganz ohne Gestaltung hat keine
runden Ecken -- er faellt durch dasselbe Sieb. Eine Suche findet nur,
wonach sie fragt.
pruef-kalender EXIT=0 (84), pruef-wecker EXIT=0 (20),
pruef-css-klassen EXIT=0 (28), pruef-start-ansicht EXIT=0 (140).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
bd21062d29 |
Alle Seiten folgen derselben Form -- gemessen ueber 18 Seiten und fuenf Rollen
Filipe: "die seiten sollen bei jedem aussehen wie bei mir, bei patrick
zumbeispiel sieht sehr viel noch nach dem alten muster aus ... alles was
sie sehen soll dan auch nach der neuen struktur aufgebaut sein."
GEMESSEN STATT GESCHAUT. Das "alte Muster" ist praezise benennbar: runde
Ecken (border-radius 18px) statt der gefraesten Fase (clip-path polygon
mit 18px). Damit laesst es sich SUCHEN, nicht nur ahnen -- ein Durchlauf
ueber alle 18 Seiten in allen fuenf Rollen, der jedes Element ab
260x90 px meldet, das eine eigene Flaeche und runde Ecken hat.
vorher 5 Klassen im alten Muster, 90 Seitenaufrufe
jetzt 0 Klassen
DER GROESSTE EINZELPOSTEN war der Seitenkopf. `.kopf-zeile` trug runde
Ecken -- auf VIERZEHN Seiten das erste, was man sieht, direkt neben
Kacheln mit Fase. Dazu `.k-kopf` (Kalender), `.steckbrief`,
`.k-anlasskarte`, `.k-raster`, `.entscheidung` und die
Formulargruppen auf der Profilseite.
ZWEI SELEKTOREN MIT BEDACHT, weil derselbe Klassenname zweierlei meint:
`.gruppe[data-gruppe]` nur die Reiter auf der Calls-Seite. Auf der
Startseite heissen die Bereichsgruppen ebenso,
sind aber BEHAELTER fuer Kacheln und duerfen
selbst keine sein. `data-gruppe` setzt
ausschliesslich calls.js -- nachgeprueft.
`fieldset.gruppe` nur die Formularbloecke auf profil.html. Die
Startseite baut `section.gruppe`. Das Element
unterscheidet sie sauber, die Klasse nicht.
BEINAHE FALSCH GEMACHT: Ich war sicher, `.steckbrief` und
`.k-anlasskarte` staenden bereits in der Modulliste, und wollte
weitersuchen, warum die Regel bei ihnen nicht greift. Nachgesehen: Sie
standen gar nicht drin -- ich hatte sie mit `.k-listentag` und einer
Liste aus kopf.js verwechselt. Eine plausible Erinnerung ersetzt keinen
Blick in die Datei.
DIE MODULLISTE STEHT SIEBENMAL WORTGLEICH. Alle sieben ergaenzt;
pruef-css-klassen prueft "alle sieben Kopien sind Zeichen fuer Zeichen
gleich" und zaehlt jetzt 43 Klassen statt 36.
GEPRUEFT:
90 Seitenaufrufe (18 Seiten x 5 Rollen) -> 0 Bausteine im alten Muster
36 Seitenaufrufe auf 360/390/412 px -> 0 px waagerechter Ueberstand
pruef-css-klassen EXIT=0, pruef-start-ansicht EXIT=0 (140),
pruef-rollen EXIT=0 (97), pruef-abbrechen-optik EXIT=0 (27)
Die Handy-Messung gezielt selbst gefahren statt pruef-handy zu starten:
Die eine Frage, die diese Aenderung aufwirft, ist der Ueberstand -- in
40 Sekunden beantwortet statt in drei Minuten.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
cba46e79e6 |
Jede Rolle sieht dieselben Kategorien -- und die Reiter werden zu Kacheln
Filipe, mit Bildschirmfoto: "diese beiden kategorien sollen bei jedem in
jeder rolle gleich sein ... alles was kacheln ist und so soll gleich sein."
ERSTENS: DIE ZAHLENREIHE VERSCHWAND BEI EINER ROLLE.
Nachgemessen ueber alle fuenf Rollen sah Spicy Media als EINZIGE keine
Zahlenreihe, sondern einen Satz -- die anderen vier sahen sieben
Kategorien:
spicy 0 Zahlen (Leer-Hinweis statt Zahlen)
admin 7 Zahlen
manager 7 Zahlen
scout 7 Zahlen
creator 7 Zahlen
Die Ursache war eine gut gemeinte Regel: "Sechs Nullen nebeneinander
sind kein Bericht, sondern Rauschen" -- bei Summe null wurde die ganze
Reihe geloescht. Der Gedanke stimmt, die Folge nicht: Wer zwischen zwei
Rollen wechselt, findet die Seite anders aufgebaut vor und sucht, was
fehlt.
Jetzt steht die Reihe IMMER, mit denselben sieben Kategorien fuer alle.
Ist wirklich nichts offen, wird sie GEDAEMPFT (weniger Deckkraft, kein
Warnrot, Zahlen ohne Leuchten) und der Satz steht ZUSAETZLICH darunter
statt an ihrer Stelle. Gedaempft ist auch eine Antwort, nur eine leise --
und die Form der Seite bleibt ueber alle Rollen gleich.
Nachgemessen: alle fuenf zeigen jetzt dieselben sieben.
ZWEITENS: DIE REITER AUF DER CALLS-SEITE WAREN KEINE KACHELN.
Gemessen: Eine Kachel traegt `clip-path: polygon(18px 0 …)` -- die
gefraeste Fase -- plus Innenschatten. Die Reiter hatten `clip-path: none`
und nur einen feinen Lichtrand. Sie standen als einzige Bausteine
ausserhalb der gemeinsamen Sprache.
Sie sind jetzt in der Modulliste von module.css. Der Selektor ist
`.gruppe[data-gruppe]` und nicht `.gruppe`: Auf der Startseite heissen
die Bereichsgruppen genauso, sind aber BEHAELTER fuer Kacheln und
duerfen selbst keine sein. `data-gruppe` setzt ausschliesslich calls.js
-- nachgeprueft, nicht angenommen.
DIE MODULLISTE STEHT SIEBENMAL WORTGLEICH in der Datei. Alle sieben
wurden ergaenzt; `pruef-css-klassen` prueft genau das ("alle sieben
Kopien sind Zeichen fuer Zeichen gleich") und haette einen vergessenen
Eintrag gemeldet.
UND SIE HAT NOCH ETWAS GEMELDET, einen Fehler von heute Nachmittag:
".rs-funkel -- fehlt auf 1 Seite (index.html)". Beim Verdoppeln des
Rollen-Sprites auf die Anmeldeseite hatte ich die Gestaltung dazu nicht
mitgenommen; sie lag in personen.css, die index.html gar nicht laedt.
Der Manager-Stern stand dort ohne seinen Glanz. Die Regeln liegen jetzt
in gate.css -- auf allen 19 Seiten. Derselbe Fehler wie beim Sprite
selbst, nur eine Ebene hoeher: Wer etwas verdoppelt, muss alles
mitnehmen, was daran haengt.
pruef-css-klassen EXIT=0, pruef-start-ansicht EXIT=0 (140),
pruef-abbrechen-optik EXIT=0 (27).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
2872f714f3 |
Ein App-Symbol aus beiden Marken: Husky in der Mitte, Chili als Sockel
Filipe: "ich will dass du da eine geile mischung machst von diesen zwei logo ... mach was ultra krass geiles draus bitte." DIE AUFGABE IST NICHT "zwei Bilder nebeneinander". Ein App-Symbol steht bei 32 px im Browserreiter und bei 192 px auf dem Startbildschirm. Zwei vollstaendige Logos nebeneinander ergeben dort zwei unlesbare Haelften. Gebraucht wird EINE Form, in der beide vorkommen. Der Husky steht im Zentrum -- eine Silhouette traegt bei kleiner Groesse am besten. Die Chili liegt als Bogen darunter, wie ein Sockel. Der Hintergrund traegt beide Farben: Chili-Rot unten links, Dogi-Blau oben rechts, und sie treffen sich in der Mitte -- dieselbe Klammer wie im Schriftzug "Spicy & Dogi" in der Kopfleiste. Der Husky wird als MASKE eingesetzt und mit Silber gefuellt: Das Original ist schwarzweiss und waere auf dunklem Grund ein dunkler Fleck. UNTER 64 px FAELLT DIE CHILI WEG. Sie waere dort ein verwaschener Fleck und wuerde die Husky-Silhouette anfressen. Ein Symbol, das klein noch erkennbar ist, ist mehr wert als eins, das alle Bestandteile zeigt und dabei zu Matsch wird. EINMAL NACHGEBESSERT nach dem Blick aufs Bild: Die Chili sass zuerst hoeher und schnitt dem Husky die Brust ab. Jetzt liegt sie tiefer, er steht vollstaendig. GEPRUEFT WIRD NICHT DIE DATEIGROESSE, sondern die Streuung der Helligkeit. Ein Symbol, das aus einem Fehler heraus einfarbig ist, hat dieselbe Bytezahl wie eines mit Motiv -- die beweist also nichts. Ein leeres Feld hat keine Streuung; gemessen wurden 48 bis 69 bei einer Untergrenze von 12, unter der das Werkzeug abbricht. EINE FALLE MITENTSCHAERFT: `tools/app-symbole.mjs` fuehrte den Workspace noch in seiner Liste und haette die sechs Dateien beim naechsten Lauf stillschweigend ueberschrieben -- gleiche Namen, gleicher Ordner, kein Fehler, nur wieder das alte Symbol. Er steht dort nicht mehr. pruef-workspace-seiten EXIT=0 (32), pruef-assets EXIT=0. Nebenbefund, NICHT von hier: pruef-verwaltung-app scheitert an einem MODULE_NOT_FOUND -- gegen den alten Stand gegengeprueft, dort derselbe Fehler. Vorbestehend, gehoert auf die offene Liste. 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
|
469bbe9d07 |
Babyblau statt Gold, lila Stern, sichtbarer Husky -- und eine zweite Variable
Drei Ansagen von Filipe nach dem Bildschirmfoto, alle an derselben Liste. screen2: "die hauptfarbe von der kategorie dogfather soll babyblausilber sein bitte." -- DAS WAR EIN FEHLER VON MIR, und zwar derselbe wie schon zweimal heute: Beim Umstellen auf die zentralen Rollenfarben habe ich `--rf` erwischt, aber `--rton` uebersehen. Die faerbt die GEWAEHLTE Rolle in der Tafel, und dort standen `--k-gold` (admin) und `--k-mittel` (manager) unveraendert. Deshalb leuchteten beide goldbraun, obwohl die Farben laengst umgestellt waren. Zwei Variablen fuer dieselbe Sache, nur eine angefasst -- wie die doppelte Groessenangabe beim Wasserzeichen und wie die zweite Kopie der Rollenzeichen in index.html. Jetzt kommen beide aus derselben Quelle; nachgemessen traegt admin rgba(63,189,245). screen3: "die hauptfarbe von denen ist lila, der stern soll so bleiben aber was gelb ist soll lila werden." -- Die FORM bleibt, nur die Farbe wechselt. Das ist auch stimmiger: Der Manager traegt Lila als Rollenfarbe, ein goldener Stern daneben war die einzige Stelle, an der Zeichen und Rolle auseinandergingen. Die Wechsel hell/dunkel im Verlauf bleiben -- sie machen aus einer Flaeche einen Koerper. screen1: "der husky soll viel besser aussehen und zu sehen sein." Zwei Gruende, warum er unterging, und beide sind behoben: Die OHREN waren nur angedeutet und gingen in der silbernen Flaeche auf -- dabei erkennt man einen Husky zuerst daran. Sie sind jetzt dunkel ausgelegt, mit hellem Innenohr. Die GESICHTSMASKE fehlte ganz. Ohne sie ist der Umriss nur eine spitze Form mit zwei Punkten; mit ihr ist es ein Gesicht. Dazu 21 -> 27 px fuer alle fuenf Zeichen: rund 65 % mehr Flaeche, ohne dass die Zeile ihre Hoehe aendert. Bei 21 px lagen Ohren, Maske und Augen auf drei bis vier Bildpunkten -- da hilft keine Zeichnung. Beide Dateien geaendert, nicht nur eine: Das Sprite steht seit heute in personen.html UND index.html. Genau diese Doppelung hatte den letzten Fehler verursacht. pruef-rollen EXIT=0 (97), pruef-start-ansicht EXIT=0 (140). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
1d0451948a |
Die drei Bahnen der Uhr gluehen von innen -- und die Stunde wird Bronze
Filipe: "die minuten sekunden und stunden soll viel spezieller, krasser und geiler sein, noch vieeeel mehr." Die Bahnen waren flache Striche in einem Verlauf -- sauber gebaut, aber ohne Koerper. Drei Aenderungen, und alle drei arbeiten mit LICHT statt mit mehr Farbe: 1. EIGENLEUCHTEN je Bahn, in ihrer eigenen Farbe. Auf einem schwarzen Zifferblatt kann man einen Strich entweder heller machen (dann blendet er) oder leuchten lassen (dann wirkt er wie eine Anzeige, die Licht abgibt). Zwei Schatten je Bahn: der enge gibt die Kante, der weite die Aura. 2. DIE STUNDE WIRD WARM. Sie lief in Schwarzsilber und war damit dem Zifferblatt am aehnlichsten -- ausgerechnet die Bahn, die man am haeufigsten abliest. Jetzt Bronze: warm gegen das kalte Blau der Minute und das Rot der Sekunde. Damit sind alle drei auf einen Blick zu trennen. Die Wechsel hell/dunkel im Verlauf bleiben, sie sind es, die aus einem Strich Metall machen. 3. DIE PERLEN sind die Spitzen -- dort schaut man hin. Sie bekommen denselben Schein wie ihre Bahn, nur staerker, und einen weissen Kern: der Unterschied zwischen einem farbigen Punkt und einem Licht. UND EINMAL ZURUECKGENOMMEN, nach dem Blick aufs Bild: Die Sekunde bekam zuerst denselben Schein wie die anderen beiden. Sie ist aber die laengste Bahn, die hellste Farbe UND die einzige, die sich sichtbar bewegt -- im Bildschirmfoto war sie ein roter Reifen, neben dem die Uhrzeit selbst zurueckstand. Ihr Leuchten liegt jetzt eine Stufe niedriger als das von Minute und Stunde. Gesehen, nicht gerechnet. Kein Pulsieren: Die Uhr steht dauerhaft im Bild, ein animiertes Leuchten am Bildrand ist genau das, was die Hausregel verbietet. Bei `prefers-reduced-motion` entfaellt der Schein ganz -- die Bahnen bleiben in voller Farbe stehen. pruef-start-ansicht EXIT=0, 140 Pruefungen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
80dbb08eee |
Die Anmeldeseite bekommt die neuen Rollenzeichen -- sie war vergessen worden
Filipe hat es im Bildschirmfoto gesehen: Auf der Anmeldeseite standen weiter die alten, einfarbigen Zeichen -- rosa Chili, GELBER Husky, violetter Stern, Schild mit Haken, Person-Silhouette. Die neuen lagen zu dem Zeitpunkt seit Stunden im Haus, nur eben ausschliesslich in personen.html. DER GRUND ist eine Doppelung, die man dem Code nicht ansieht: index.html trug die Zeichen als EIGENE Kopien im Quelltext, nicht als Verweis auf ein gemeinsames Sprite. Wer eines von beiden aendert, aendert das andere nicht -- und merkt es nicht, weil beide Stellen fuer sich richtig aussehen. Dieselbe Sorte Fehler wie die doppelte Groessenangabe beim Wasserzeichen heute frueh, nur ueber zwei Dateien verteilt statt ueber 3600 Zeilen. Gefunden hat es kein Prueflauf, sondern Filipes Blick auf die Seite. Das ist der Grund, warum ein Bildschirmfoto mehr wert ist als eine gruene Zahl: Die Pruefungen sagten die ganze Zeit "in Ordnung" -- sie pruefen, dass Zeichen DA sind, nicht welche. Jetzt traegt index.html dasselbe Sprite (aus personen.html uebernommen, nicht abgeschrieben) und verweist mit <use> darauf. Die Zeichen gibt es damit nur noch einmal im Haus. DAS CSS MUSSTE MIT: Wie bei `.rollenwahl__symbol` setzte `.rolle__zeichen` ein `fill: none` und ein `stroke` in der Rollenfarbe. Beides wird an die Pfade vererbt -- jedes Zeichen waere von einem 1,7 px dicken Rand ueberzogen und seine Verlaeufe uebermalt worden. Die gewaehlte Rolle hebt sich jetzt ueber Groesse und Schein ab statt ueber die Farbe: Die gehoert dem Zeichen. Nachgemessen: 5 von 5 Zeichen kommen aus dem Sprite. pruef-rollen EXIT=0 (97), pruef-start-ansicht EXIT=0 (140). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
bcfe0b93f9 |
Die Fugen im Kalender werden dunkel statt hell
Filipe, screen18: "die linien zwischen den kacheln und der rand die so kras durchsichtig sind, ich will dass dass die viel dunkler sind und die kacheln vom kalender selber sollen viel krasser und geiler aussehen." WOHER DIE LINIEN KOMMEN, und das erklaert den Fehler: Sie sind gar nicht gezeichnet. Das Raster hat `gap: 1px` und darunter eine Flaeche -- in den Luecken zwischen den Tagen scheint diese Flaeche durch, DAS sind die Linien. Sie trugen `var(--rand)`, einen hellen halbdurchsichtigen Ton, der fuer Raender AUF dunklem Grund gedacht ist. Zwischen zwei ohnehin dunklen Kacheln wirkt derselbe Ton wie ein heller Schleier -- genau das, was Filipe "kras durchsichtig" nennt. Jetzt ein eigener tiefer Ton (#05070c): Die Fuge ist DUNKLER als die Kacheln daneben, nicht heller. Damit sieht sie eingefraest aus statt aufgemalt -- dieselbe Ueberlegung wie bei den Fasen auf der Startseite. Der aeussere Rand bekommt eine feine helle Innenkante, sonst verlaeuft der Kalender am Rand ins Nichts. DIE TAGE BEKOMMEN TIEFE: ein leichter Verlauf von oben nach unten und ein Lichtsaum an der Oberkante -- Licht kommt von oben, also ist die Oberkante hell und die Flaeche faellt ab. BEWUSST SCHWACH (der Verlauf umfasst rund vier Prozent Helligkeit): Ein Monatsraster hat 35 bis 42 dieser Felder nebeneinander. Was bei einer einzelnen Kachel wirkt, wird hier vierzigfach zu Unruhe. Wochenende und fremde Monate bleiben ruhiger und heben sich ueber WENIGER LICHT ab, nicht ueber eine andere Farbe. Nachgemessen am laufenden Kalender: Fugenfarbe rgb(5, 7, 12), 35 Tage im Raster. pruef-kalender EXIT=0, 84 Pruefungen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
e282ad3b44 |
Der Anmelde-Knopf traegt beide Marken -- und wurde erst durch Nachrechnen lesbar
Filipe, screen28: "dieser anmelde button soll noch viel spezieller sein bitte. und viel geiler." NUR DIESER EINE KNOPF. Er traegt die Klasse `.knopf`, die im Workspace an Dutzenden Stellen haengt -- wer sie aendert, aendert jeden Knopf im Haus. Die Regel greift deshalb ueber `#knopf` und laesst alle anderen in Ruhe. Der Verlauf laeuft vom Chili-Rot von Spicy Media in das Blau von Dogi -- dieselbe Klammer wie im Schriftzug der Kopfleiste, und hier besonders am Platz: Dieser Knopf ist die Tuer ins Haus. UND DANN HAT MICH DIE RECHNUNG WIDERLEGT. Der erste Entwurf nahm die Marken-Toene direkt (#d94a3f bis #7ec8f2). Er sah gut aus -- genau das ist die Falle. Nachgerechnet lag weisser Text darauf bei: #d94a3f 4,20:1 #6ca8d8 2,55:1 #e2664a 3,37:1 #7ec8f2 1,84:1 Auf dem hellsten Punkt also nicht einmal beim halben Mindestwert. Ich hatte im Kommentar daneben "ueber 4,5:1 an jeder Stelle" behauptet, ohne es nachzurechnen. Der Knopf waere schoen und unlesbar gewesen. Jeder Stuetzpunkt ist jetzt so weit abgedunkelt, bis weisser Text 4,6:1 erreicht -- knapp ueber der Grenze, damit Rundungen nicht darunter rutschen. Die Farben bleiben erkennbar Rot und Blau, sie sind nur tiefer. Schlechtester Wert jetzt 4,63:1. MERKSATZ, der auch fuer jeden naechsten Verlauf gilt: Ein Verlauf ist so lesbar wie sein HELLSTER Punkt, nicht wie sein Durchschnitt. Beim Textverlauf in der Kopfleiste war es dieselbe Regel mit umgekehrtem Vorzeichen -- dort zaehlt der dunkelste. Der Glanz wandert beim Ueberfahren statt zu pulsieren (wie Manager-Stern und Kalender-Knopf), bei `prefers-reduced-motion` entfaellt er. Waehrend der Anmeldung wird der Knopf ruhig gestellt, damit der Ladepunkt die Aufmerksamkeit bekommt und nicht der Glanz. pruef-start-ansicht EXIT=0 (140), pruef-css-klassen EXIT=0. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
c262537b89 |
Der eigene Name leuchtet in der eigenen Rollenfarbe
Filipe, screen35: "die begrüßungen sollen auch viel krasser und geiler sein, so richtig auffällig. so dass die leute motivation bekommen weil es so geil aussieht." NICHT UEBER DIE GROESSE, und das ist der Kern. Genau die habe ich heute frueh von 88 auf 56 px zurueckgenommen: In der Anrede-Pille steckt ein <h1> mit Titelgroesse, dadurch standen ZWEI Ueberschriften uebereinander. Sie jetzt wieder aufzublasen hiesse, denselben Fehler ein zweites Mal zu machen. "Auffaellig" heisst ohnehin nicht "gross", sondern "hebt sich ab". Der Name hebt sich ueber die FARBE ab: Er traegt einen Verlauf in `--r-haupt`, der Farbe der angemeldeten Rolle. Jeder sieht damit seinen eigenen Namen in seiner eigenen Farbe -- nachgemessen: DogFather #7ec8f2 (babyblau), Scout #5fc99a (gruen), Creator #c79a6d (bronze). Das ist der Unterschied zwischen "da steht mein Name" und "das hier ist meins". Der Gruss davor bleibt bewusst leise und farblos. Wenn beides leuchtet, leuchtet nichts -- die Betonung gehoert dem Namen, nicht der Uhrzeit. Mit derselben Sicherung wie beim Schriftzug in der Kopfleiste: `color` steht zuerst und sichtbar da, Verlauf und durchsichtige Fuellung stehen nur im @supports-Block, und bei `forced-colors: active` wird alles zurueckgenommen. Durchsichtige Schrift ohne Rueckfallwert waere ein Ausfall, kein Schoenheitsfehler. Das Leuchten liegt als `drop-shadow` HINTER der Schrift -- es gibt dem Namen Tiefe, ohne ihn zu vergroessern. pruef-start-ansicht EXIT=0, 140 Pruefungen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
8b317b23e2 |
Der Weg in den Kalender ist ein Knopf, kein Nebensatz
Filipe, screen33: "der kalender button da in der kachel oben rechts, der soll viel auffälliger sein und viel krasser und geiler." Er sah aus wie ein Verweis im Fliesstext -- kleine Schrift, kein Rahmen, keine Flaeche. Neben der fetten Ueberschrift "Heute" verschwand er, obwohl er die einzige Handlung in dieser Zeile ist. vorher Text in .78rem, ohne Fassung, rund 70x18 px jetzt 105x36 px, eigene Flaeche, farbiger Rahmen, Schimmer ER TRAEGT DEN KALENDER-TON, nicht das allgemeine Blau. Der Knopf fuehrt in den Kalender, und die Kachel dort hat genau diese Farbe (Nummer 8, #c06ad0). Wer ihn sieht, weiss ohne zu lesen, wo er landet -- das ist mehr wert als jede zusaetzliche Verzierung. Beim Ueberfahren wandert ein heller Streifen darueber. Derselbe Kniff wie beim Manager-Stern und aus demselben Grund: Glanz ist etwas, das sich BEWEGT -- ein Auf- und Abblenden waere ein Pulsieren. Der Streifen liegt in einem eigenen Element, damit er den Text nicht mitfaerbt, und bei `prefers-reduced-motion` entfaellt er. Der Knopf bleibt dann trotzdem auffaellig, er glaenzt nur nicht. `--f` wird mitgesetzt, damit der Schein beim Ueberfahren aus gate.css aus derselben Farbe kommt statt aus der Vorgabe. Nachgemessen am laufenden Browser: 105x36 px, Rahmen rgb(192,106,208) bei 48 % Deckkraft, Schrift 13,12 px / 650. pruef-start-ansicht EXIT=0, 140 Pruefungen -- diesmal GELESEN, bevor committet wurde, nicht in derselben Befehlskette daneben. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
80f410f5b8 |
Deckkraft des Wasserzeichens zurueckgenommen -- die Pruefung hatte recht
NACHTRAG ZU
|
||
|
DogFatherGitandClaude Opus 5
|
b808e072c0 |
Das Zeichen der grossen Kachel wird groesser -- und eine zweite Regel fiel auf
Filipe, screen34: "das symbol rechts in der kachel, was so ganz klein ist das soll viel größer sein bitte!!!" Nachgemessen war es gar nicht klein: 178 px gegen 133 px bei den normalen Kacheln, also GROESSER. Es wirkt nur klein, und das ist der eigentliche Punkt -- die grosse Kachel ist 769 px breit (ueber die volle Reihe rund 1160), die normale 379. Dasselbe Zeichen hat dort doppelt so viel leere Flaeche um sich und verliert sich darin. Ein Zeichen wirkt nach dem Anteil der Flaeche, den es fuellt, nicht nach seiner Pixelzahl. DABEI KAM EINE ZWEITE REGEL ANS LICHT. Fuer dasselbe Element stand die Groesse an ZWEI Stellen in start.css -- einmal bei den Kachelregeln (196 px) und 3600 Zeilen spaeter noch einmal (158 px). Gleich starke Selektoren, also gewinnt der spaetere. Meine erste Vergroesserung blieb deshalb wirkungslos: gemessen weiterhin 178 px, obwohl im Quelltext 340 stand. Im Code sieht jede der beiden Regeln fuer sich richtig aus; erst die Zahl am laufenden Browser verraet, dass eine nie zur Wirkung kommt. Dieselbe Sorte Fehler wie bei `.kopfleiste .marke`, wo `flex` den Schrumpf-Faktor still zurueckgesetzt hat. Die Groesse steht jetzt nur noch an einer Stelle. UND EINMAL ZU WEIT. Der erste Versuch koppelte die Groesse an die BREITE: `min(46%, 340px)` ergab 384 px auf einer 152 px hohen Kachel. Im Bildschirmfoto war daraufhin GAR NICHTS mehr zu sehen -- was die Kachel nicht fasst, schneidet sie ab. Groesser ist hier nicht automatisch besser. Jetzt an der Hoehe ausgerichtet: 220 px, unten und rechts angeschnitten, der Grossteil im Bild. Gemessen wird seitdem die SICHTBARE Flaeche, nicht die Elementgroesse -- das ist die Zahl, auf die es ankommt: vorher rund 158x122 = 19k jetzt 204x152 = 31k (+63 %) pruef-start-ansicht EXIT=0, 140 Pruefungen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
1f7761cb69 |
Die Kopfleiste glueht, die Knoepfe werden rot -- und DogFather sagt, was er tut
Drei Punkte aus der Nachtliste auf einmal, weil sie alle an derselben Leiste haengen. screen36: "hintergrund dieser leiste soll auch eine richtig geile mischung von rot schwarz sein, wie wenn es brennen würde." GLUT KOMMT VON UNTEN. Ein gleichmaessig roter Balken saehe aus wie eine Fehlermeldung. Feuer ist unten heiss und oben dunkel -- also liegt das Rot als flacher Schein an der Unterkante, wird nach oben schwarz und ist an den Raendern schwaecher als in der Mitte. Zwei uebereinanderliegende Verlaeufe machen das: einer fuer die Hoehe, einer fuer die Breite. Die Trennlinie nach unten glueht mit, sonst endet das Feuer an einer grauen Linie. Kein Flackern, und das ist Absicht: Diese Leiste steht auf JEDER Seite und liegt beim Lesen dauernd im Bild. Eine Animation waere ein Stroboskop am oberen Bildrand. Das Rot bleibt deshalb unter 30 % Deckkraft -- es glimmt, es leuchtet nicht. screen5: "die buttons: teilen, suchen und abmelden sollen rot, alle andere rot töne aber rot." Vier Knoepfe, vier verschiedene Rottoene -- "alle andere rot töne" heisst nicht viermal derselbe. Sie laufen von warm nach tief: Teilen im Chili-Rot der Marke, Chat ruhiger, Suchen glutorange, Abmelden am dunkelsten. Das ist auch die Reihenfolge, in der man sie braucht, und Abmelden soll am wenigsten locken. Gesetzt wird nur `--f`, die Knopffarbe aus gate.css -- sie faerbt Rahmen, Schimmer und den Schein beim Ueberfahren gleich mit. Fuenf Eigenschaften je Knopf zu setzen waere vier Gelegenheiten gewesen, eine zu vergessen. GERECHNET STATT GEMESSEN: Ein roter Text auf rotem Grund waere der naheliegende Fehler. Der Text nimmt deshalb nur 22 % der Knopffarbe an und bleibt sonst hell. Nachgerechnet gegen die HELLSTE Stelle der Glut (dort ist der Kontrast am schlechtesten): 10,45:1 im schlechtesten Fall, Grenze ist 4,5. Dafuer braucht es keinen 190-Sekunden-Lauf. screen27: Unter DogFather steht jetzt "Manager & Technik" statt "Gesamtuebersicht & Freigaben". Die alte Zeile beschrieb ein RECHT, die neue eine AUFGABE -- und danach sucht jemand, der vor der Rollenwahl steht: Er fragt sich nicht, was er duerfte, sondern was er hier tut. pruef-start-ansicht EXIT=0 (140), pruef-css-klassen EXIT=0. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
f42f9a7266 |
21 Kachelfarben neu gerechnet -- keine zwei aehneln sich mehr
Filipe, screen24/25: "viele kacheln haben noch fast die gleiche farben,
ähneln sich sehr und ich will dass du komplett eskalierst ... alle seine
eigenen farben und so dass sie sich nicht ähneln. sehr wichtig nicht
ähneln!!!!"
Er hatte recht, und es liess sich messen statt bereden:
kleinster Abstand zweier Toene 0,033 (Dateien gegen Creator-Profile)
Paare unter 0,05 (kaum trennbar) 21 von 210
Spanne der Helligkeit 0,002
DIE URSACHE WAR EINE GUTE ABSICHT. Die alte Palette lief gleichmaessig
um EINEN Farbring, mit bewusst konstanter Helligkeit und Farbstaerke --
"dadurch wirken alle gleich stark und keine draengt sich vor". Genau das
erzeugt den Fehler: Bleibt alles ausser dem Farbton gleich, ist der
Farbton der einzige Unterschied. 360 Grad auf 21 Kacheln sind 17 Grad,
und 17 Grad sieht man nicht.
Jetzt variieren Helligkeit UND Farbstaerke mit. Zwei Farben mit
aehnlichem Ton stehen trotzdem weit auseinander, weil die eine hell und
satt und die andere dunkel und ruhig ist -- der Abstand bekommt eine
zweite und dritte Dimension.
kleinster Abstand 0,097 (dreimal so gross)
Paare unter 0,05 0 von 210
Helligkeitsspanne 0,242
Gerechnet in OKLab, weil dort der Zahlenabstand dem entspricht, was das
Auge als Unterschied empfindet. Die Auswahl ist eine Suche, kein
Geschmack: erst gierig den jeweils entferntesten Ton nehmen, dann so
lange tauschen, wie der KLEINSTE Abstand dadurch waechst.
Drei Bedingungen halten dabei, und alle drei stehen im Werkzeug als
Abbruch, nicht nur im Bericht:
lesbar mindestens 4,5:1 gegen den Grund (schlechteste: 4,50)
augenschonend Farbstaerke gedeckelt bei 0,17 -- satt ja, Neon nein
trennbar gemessen ueber ALLE Paare, nicht nur ueber Nachbarn im
Raster: Auf der Uebersicht stehen dieselben Kacheln in
anderer Reihenfolge nebeneinander.
Das Werkzeug bricht ab, wenn eine neue Palette schlechter waere als der
alte Stand (0,0328) -- sonst waere ein schlechter Lauf von einem guten
nicht zu unterscheiden.
pruef-start-ansicht EXIT=0, 140 Pruefungen. Die Farben zusaetzlich am
laufenden Browser abgelesen, nicht nur aus der Datei.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
df0e74f751 |
Bearbeiten zeigt jetzt, was schon eingetragen war -- und loescht es nicht mehr
Filipe, screen19: "wenn ich auf bearbeiten drücke will ich dass mir immer
die daten angezeigt werden die schon ausgewählt wurden, damit ich auch
immer sehe okee das war alles und das änder ich."
Das war nicht nur unbequem, es war ein DATENVERLUST. Das Feld "Mit wem"
wurde beim Bearbeiten nie gefuellt und stand leer da. Beim Speichern wird
`teilnehmer_extern` aber trotzdem mitgeschickt -- der leere Wert
ueberschrieb also den vorhandenen. Wer einen Termin mit einem frei
eingetragenen Namen ("BananaStift") bearbeitete und speicherte, hatte den
Namen danach verloren, ohne ihn je gesehen zu haben. Nichts stuerzte ab,
nichts meldete sich; er war einfach weg.
DIE URSACHE lag tiefer als im Kalender: `window.personenwahl` konnte
lesen (`wert`, `extern`) und leeren (`zuruecksetzen`), aber NICHT
fuellen. Ein Bearbeiten-Formular hatte gar keine Moeglichkeit, einen
freien Namen anzuzeigen. Deshalb kommt die Reparatur in zwei Teilen:
wahl.js neue Funktion `setzen(wert, externText)`. Sie behandelt
die beiden Faelle als das, was sie sind: entweder eine
Person aus der Liste ODER ein freier Name -- nie beides.
Das eine setzt das andere zurueck.
kalender.js belegt das Gegenueber beim Bearbeiten vor, aus
creator_id / teilnehmer_id / teilnehmer_extern. Nur fuer
die Leitung, wie beim Speichern auch -- fuer die anderen
Rollen gibt es das Feld gar nicht.
Der Server lieferte die noetigen Felder die ganze Zeit mit
(t.teilnehmer_extern, t.creator_id, t.teilnehmer_id) -- es hat sie nur
niemand abgeholt.
Nachgemessen: `personenwahl('f-teilnehmer').setzen('', 'BananaStift')`
ergibt extern="BananaStift", wert="" -- der freie Name steht im Feld,
die Personennummer ist leer. pruef-kalender EXIT=0 (84),
pruef-serien EXIT=0 (69).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
29785cc2a4 |
Abgebrochene Aufgaben mahnen nicht mehr -- an zwoelf Stellen, nicht an einer
Filipe, screen12: "die abgebrochenen sollen oben nicht mehr mit zaehlen
die sollen ihre eigenen kategorie kriegen".
DIE URSACHE war eine Bedingung, die harmlos aussieht: `a.status <>
'erledigt'`. Eine abgebrochene Aufgabe ist nicht "erledigt" -- also fiel
sie durch, und zwar in JEDE Zahl, die "noch zu tun" bedeutet. Eine
Aufgabe, die niemand mehr anfassen wird, mahnte weiter als ueberfaellig.
Das ist die Kehrseite einer bewussten Entscheidung: "abgebrochen" steht
absichtlich NICHT in STATUS, damit der normale Weg es nicht setzen kann.
Genau deshalb rutscht es aber durch jede Pruefung, die nur gegen
'erledigt' vergleicht.
FILIPE HAT EINE STELLE GESEHEN. Gesucht werden musste nach dem MUSTER:
Es waren zwoelf, in sieben Dateien.
workspace-aufgaben.js 2 ueberfaellig und heute (die Zahlen "oben")
workspace-hinweise.js 2 die Hinweiszeilen der Startseite
workspace-kalender.js 1 Aufgaben mit Frist im Kalender
workspace-personen.js 1 "offene_aufgaben" je Person
workspace-profil.js 1 dieselbe Zahl im Profil
workspace-push.js 2 ERINNERUNGEN, die verschickt werden
workspace-reports.js 3 Berichte
Am schwersten wiegt workspace-push.js: Dort gingen Push-Nachrichten
hinaus -- fuer Aufgaben, die laengst abgebrochen waren.
`NOT IN ('erledigt', 'abgebrochen')` statt einer zweiten Ungleichung: Wer
spaeter einen dritten Endzustand einfuehrt, ergaenzt eine Liste, statt
eine Kette von `<>` zu verlaengern, bei der das Vergessen niemandem
auffaellt.
DIE EIGENE KATEGORIE, die Filipe verlangt hat, gibt es jetzt in der
Schnittstelle (`abgebrochen`) und auf der Startseite -- hinten bei
"Erledigt", weil beides dasselbe bedeutet: vom Tisch.
GEGENPROBE an einer abgebrochenen Aufgabe mit Frist von gestern:
alte Bedingung "<> erledigt" -> ueberfaellig = 3
neue Bedingung "NOT IN (erledigt, abg)" -> ueberfaellig = 2
Unterschied 1 = genau die abgebrochene. Die Schnittstelle liefert 2
und abgebrochen = 1.
pruef-start-ansicht hat den Umbau bemerkt und "die Aufgabenzahlen stehen
(7)" gemeldet -- sie zaehlt die Kategorien und erwartete sechs. Die Zahl
steht in der Bedingung, nicht nur im Meldetext; deshalb faellt eine
Kategorie, die still verschwindet, sofort auf. Auf 7 nachgezogen:
EXIT=0, 140 Pruefungen. pruef-aufgabenbrett EXIT=0, 44.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
5925a61dfe |
Chat, Kalender, Calls -- die Reihenfolge nach Verbindlichkeit
Filipe, screen31: "die reihenfolge von denen, links der chat, mitte den kalender und rechts calls & protokolle". Vorher stand der Chat hinter "Calls & Protokolle", begruendet damit, dass beides Gespraech sei. Die neue Ordnung liest sich von links nach rechts nach Verbindlichkeit: Der Chat laeuft nebenher, der Kalender bindet an eine Uhrzeit, das Protokoll haelt fest, was verabredet wurde. Die Farbtoene bleiben an ihren Kacheln (Chat 4, Kalender 8, Calls 15). Sie kennzeichnen die Kachel, nicht ihren Platz -- wer sie beim Umsortieren mitwandern liesse, haette zwei Kacheln in derselben Farbe. Nachgemessen am laufenden System: 0 Dashboard, 1 Aufgaben, 2 Chat, 3 Kalender, 4 Calls & Protokolle, 5 Dateien. pruef-start-ansicht EXIT=0, weiterhin 140 Pruefungen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
e3f7826ca5 |
Jede Rolle sieht ihre eigene Zahl -- Schulle zaehlte das ganze Haus
Filipe (screen22), nachdem Managerin Schulle "2 Creator" angezeigt bekam, obwohl sie einen hat: "die zahl die da angezeigt wird soll bitte immer jedem genau zutreffend sein." Und dazu (screen23), wer was sehen soll: "dogfather und cigdem haben die zahl vom insgesamten. manager sehen nur die gesamte zahl ihrer scouts und ihren creator die ihnen zugeteilt sind, die scout sehen die zahl nur von ihren creator und die creator da termine vom tag selber" DIE ZAHL WAR NICHT FALSCH GERECHNET, SIE BEANTWORTETE DIE FALSCHE FRAGE. Hier stand `SELECT ... FROM personen WHERE aktiv = 1` -- alle, fuer jeden aus der Leitung gleich. Ein Manager sah damit das ganze Haus als "sein Team", einschliesslich Leuten, mit denen er nichts zu tun hat. Jetzt je Rolle: admin/spicy alle aktiven Personen, ohne sich selbst manager seine Scouts UND die Creator (eigene wie die der Scouts) scout nur seine Creator creator unveraendert der eigene Tag SCOUTS BEKOMMEN DIESEN RING NEU. Sie zaehlen nicht zur Leitung und sahen deshalb den Stundenring des eigenen Tages -- aber ein Scout hat ein Team, naemlich seine Creator. Genau danach hat Filipe gefragt. Der Ring heisst bei ihm "Creator versorgt" statt "Team versorgt": Sonst liest ein Scout "Team" und sucht die anderen vier Rollen darin. OHNE SICH SELBST: Wer den Ring ansieht, ist die Person, die ihn liest. Sich selbst als Segment im eigenen Team mitzuzaehlen verschiebt jede Prozentangabe um einen Platz. KEINE ZWEITE RECHENVORSCHRIFT. Die Zuordnung wird nicht hier nachgebaut: `betreuteIds` kennt die Kette Manager -> Scouts -> deren Creator bereits, `scoutsVon` die Scouts. Eine eigene Fassung derselben Frage waere genau der Weg, auf dem zwei Wahrheiten entstehen. Dazu screen26: "liegt liegen, keine ahnung was das bedeuten soll aber das soll viel besser sein bitte." Gezaehlt werden Personen mit unerledigten Terminen aus der VERGANGENHEIT -- das Schild heisst jetzt "ueberfaellig". GEMESSEN an einer Lage, die den Fehler enthaelt: fuenf aktive Personen, darunter ein Creator, der zu niemandem gehoert. DogFather 4 im Team [Fremder, Tili, Schulle, Patrick] Manager Schulle 2 im Team [Tili, Patrick] <- ohne "Fremder" Scout Patrick 1 meine Creator [Tili] Creator Tili eigener Tag pruef-start-ansicht EXIT=0 (140), pruef-rollen EXIT=0 (97). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
ff8ea38595 |
Die Kopfleiste wird zur Klammer: Chili links, Husky rechts, Spicy & Dogi
Filipe (Nachtliste, screen17): "wo der husky ist soll eine geile rot gruene peperoni sein, dogfather universe ersetzen durch, Spicy & Dogi. und der husky von links soll rechts sein. die farben von der peperoni und von dem husky sollen ueber den text ziehen und sich dan in der mitte treffen." Dazu screen9: die Zierzeile der Zentrale heisst jetzt "Spicy Media" statt "Dogfather Universe". Die Chili steht als BILD (sie ist von sich aus rot mit gruenem Stiel und soll ihre Farben behalten), der Husky als MASKE (schwarzweiss gezeichnet waere er auf dunklem Grund ein dunkler Fleck; von der Maske zaehlt nur die Silhouette, gefuellt mit Silber und Babyblau). Dazwischen laeuft der Schriftzug von Chili-Rot ueber Silber nach Babyblau -- Treffpunkt in der Mitte, genau beim "&". DER VERLAUF IM TEXT IST EINE AUSNAHME MIT SICHERUNG. Direkt darueber steht seit dem 01.09. "KEIN Farbverlauf IM Text", und der Grund gilt weiter: Durchsichtige Schrift haengt an einer einzigen Technik, und faellt die aus, ist der Text WEG statt nur anders gefaerbt (gemessen damals 1,05:1). Beides geht zusammen, wenn der Verlauf nur eine Zugabe ist: `color` steht zuerst und voll sichtbar da, Verlauf und durchsichtige Fuellung stehen NUR in einem @supports-Block (wer es nicht kann, betritt ihn nicht), und bei `forced-colors: active` wird alles zurueckgenommen. Die drei Stuetzstellen sind bewusst hell -- beim Verlauf bestimmt der dunkelste Punkt den schlechtesten Kontrast. EIN SELEKTOR, DER RICHTIG AUSSAH UND FALSCH WAR. Der Husky sollte nur auf die Startseite; `body.start` davorzusetzen wirkte naheliegend. Diese Klasse tragen aber ALLE 18 Seiten -- sie kennzeichnet den Grundstil, nicht die Startseite. Folge auf den Unterseiten, wo `.marke` den Rueckweg traegt: Die 22 px des Huskys nahmen dem Text so viel Platz, dass "Creator Workspace" zu "CREAT…" wurde. Gesehen im Bildschirmfoto, nicht im Code. Jetzt steht die Regel in heim.css, das ausschliesslich von der Startseite geladen wird -- die Datei selbst ist die Bedingung. Nachgemessen dabei, damit es nicht faelschlich mir zugeschrieben wird: Der Schriftzug auf den Unterseiten ist AUCH IM ALTEN STAND abgeschnitten (151 px Inhalt auf 91 px Platz). Das ist ein vorbestehender Mangel und steht auf der offenen Liste, kein Rueckschritt aus diesem Commit. pruef-start-ansicht angepasst: Sie prueft den Namen im Schriftzug und erwartete "Dogfather Universe" -- sie hat ihre Arbeit getan und angeschlagen. EXIT=0, weiterhin 140 Pruefungen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
963ea492b1 |
Die fuenf Rollen bekommen eigene Farben und echte Zeichen
Auftrag von Filipe (Nachtliste, screen3): "die farben sollen jeden rollen angepasst werden ueber die ganze website ... diese farben sollen auch immer danach bei den rollen benutzt werden", dazu die Zeichen "viel viel viel realistischer und geiler". DIE FARBEN STEHEN JETZT AN EINER STELLE. Vorher lagen dieselben Hex-Werte ueber chat.css, personen.css, kalender.css, start.css und gate.css verstreut -- 47 Fundstellen, allein in chat.css sechzehn. Wer eine Farbe aendern wollte, musste sie ueberall finden; wer eine uebersah, hatte zwei Wahrheiten auf einem Bildschirm. Sie stehen jetzt in gate.css, der einzigen Datei, die auf allen 19 Seiten liegt, mit je drei Toenen (haupt/zweit/tief) fuer Flaeche, Verlauf und Schatten. spicy rot #ef5f57 warmes Chili-Rot, kein Signalrot admin babyblau #7ec8f2 + Lila #a78bfa als zweiter Ton manager lila #8a76ff bleibt scout gruen #5fc99a bleibt creator bronze #c79a6d + Silber #d8dee9 -- neu Zwei davon waren inhaltlich falsch: `admin` stand auf Gold und `creator` auf demselben Blau wie der allgemeine Akzent -- die Rolle war dadurch nicht von "irgendein Bedienelement" zu unterscheiden. In der Personenliste fehlten Spicy und Manager ganz, und Creator trug das Lila des Managers: zwei Rollen sahen in derselben Liste gleich aus. Umgeschaltet wird am <html> (kopf.js), nicht an einzelnen Bausteinen: Wer die Farbe an jedem Element einzeln setzt, vergisst das naechste, das dazukommt. DIE ZEICHEN TRAGEN IHRE FARBEN SELBST. Vorher hatte jedes genau eine Farbe (currentColor). "Peperoni rot UND gruen" oder "gruenes Schild mit einer roten Peperoni drin" ist damit nicht darstellbar, egal wie man mischt. Jedes Zeichen bringt jetzt eigene Verlaeufe mit: Chili rot mit gruenem Stiel, Husky in Silber mit blauen Augen (Radialverlauf plus Lichtpunkt -- ein flacher blauer Punkt sieht aus wie ein Loch), Stern in Gold mit wanderndem Glanz, Schild gruen mit Chili darin, Creator als geschliffener Kristall in Lila und Silber statt der alten Person-Silhouette, die aussah wie ein leeres Benutzerbild. Das Funkeln des Sterns laeuft ueber eine wandernde Maske, nicht ueber die Deckkraft: Auf- und Abblenden waere ein Pulsieren, kein Glitzern. 4,5 s und schwach, damit es in einer Liste aus fuenf Rollen nicht dauerhaft den Blick zieht -- und bei `prefers-reduced-motion` steht es still. ZWEI FEHLER, DIE NUR DAS HINSEHEN GEFUNDEN HAT: 1. `.rollenwahl__symbol` setzte `fill: none; stroke: var(--r)`. Beides wird an die Pfade VERERBT -- jedes neue Zeichen waere von einem 1,55 px dicken Rand in der Rollenfarbe ueberzogen worden. 2. Das Sprite stand in einem <svg style="display:none">. Solange die Zeichen einfarbig waren, war das harmlos. Ein <linearGradient> in einem `display:none`-Teilbaum wird aber NICHT ausgewertet, und ein <use> darauf bekommt gar keine Fuellung: Im Bildschirmfoto standen fuenf Bruchstuecke -- nur Striche, keine Flaechen. Die Zahlen sagten dazu nichts, das Sprite war ja vorhanden. Jetzt ein Kasten ohne Groesse: wird gerendert, nimmt keinen Platz. Gemessen: pruef-rollen 97 Pruefungen EXIT=0, pruef-personen-formular 23 EXIT=0, pruef-start-ansicht EXIT=0, pruef-css-klassen EXIT=0. Farb- umschaltung am lebenden System nachgesehen: html[data-rolle]=admin -> --r-haupt = #7ec8f2. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
863471c3df |
Die Mitte der Zentrale sitzt jetzt wirklich mittig -- zwei Ursachen, nicht eine
Filipe im Bildschirmfoto: "in der mitte der kachel soll auch alles perfekt zentriert sein und nicht wie jetzt total verschoben." Gemessen waren es zwei getrennte Fehler, die zufaellig in dieselbe Richtung zeigten. ERSTENS: .willkommen__stand trug ein `margin-left: auto` -- ein Rest aus der Zeit, als die drei Ablesungen RECHTS zwischen Text und Uhr standen. In einer Flex-Spalte gewinnt ein auto-Rand immer gegen das `align-items: center` des Elternteils. Bei 1920 px lagen Anrede, Zierzeile, Titel und Unterzeile alle exakt auf Mitte 960 -- dieser Kasten allein auf 1129, also 169 px daneben. Aufgefallen war das schon einmal: In der Media-Query fuer 412 px stand bereits `margin-left: 0`, mit dem Vermerk "im Bildschirmfoto gesehen, nicht hergeleitet". Dort wurde das Symptom geflickt und die Ursache blieb stehen -- auf dem grossen Bildschirm damit unbemerkt weiter. Jetzt ist die Ursache weg und die Gegenzeile gleich mit: Eine Zeile, die nichts mehr aufhebt, sieht aus wie Absicht und wird mitgeschleppt. ZWEITENS, und ohne Messung nicht zu sehen: `.willkommen .unterzeile` ist laut start.css ein FLEX-Kasten mit Umbruch, damit die Lage hinter der Rolle stehen und auf dem Handy umbrechen kann. In einem Flex-Kasten ordnet `text-align` die Elemente aber NICHT an -- es zentriert den Text innerhalb jedes Elements, waehrend die Elemente selbst links kleben. In der breiten alten Begruessung fiel das nie auf, weil beide in eine Zeile passten; die Spalte der Zentrale ist 397 px schmal und bricht immer um. Gemessen: Rollentext 39,7 px und Lage 58,6 px links der Achse, auf jeder Fensterbreite gleich. Behoben mit `justify-content: center` -- `align-items` waere das falsche Werkzeug, die Richtung ist row mit Umbruch, nicht column. Dazu der Punkt der Lage: Er haengt in einem `padding-left: 14px`. Steht die Lage in einer eigenen Zeile -- in dieser Spalte immer --, ist das Element dadurch 14 px breiter als sein Text und sitzt 7 px rechts der Mitte. Ein Ausgleich rechts macht es symmetrisch, nur hier und nicht in start.css: nebeneinander waere ein rechter Rand ein zu grosser Abstand. Gemessen ueber 1920/1440/1280/1100/800 px: alle sieben Elemente auf Abweichung 0,0 px. Zusaetzlich auf 360/390/412/430 px: kein waagerechter Ueberstand. pruef-start-ansicht EXIT=0, weiterhin 140 Pruefungen -- keine ist dabei still verschwunden. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
b2a0fb3a97 |
Die Zentrale bekommt die echten Marken -- und drei rote Pruefungen waren keine
Die drei Befunde in pruef-start-ansicht kamen NICHT vom Licht. Sie hingen
alle an einem boundingBox(), das einmal am Anfang ohne Vorrollen gemessen
wurde. Der Umbau zur Zentrale hatte die Begruessungskachel von 244 auf
404 px wachsen lassen, die zweite Kachel rutschte von y=971 auf y=1131,
ihre Mitte lag bei 1207 -- ausserhalb eines 1200 px hohen Fensters. Dorthin
faehrt kein Zeiger, also entstand kein Licht.
Verraten hat es die Mischung aus gruen und rot: "links" (30 % der Hoehe)
bestand, "rechts" (60 %) nicht. Eine Kachel, die nur zur Haelfte getroffen
wird, ist nicht kaputt -- sie haengt halb aus dem Bild.
Beides ist jetzt behoben, nicht nur eines:
* Die Pruefung holt die Kachel ueber scrollIntoView({block:"center"})
ins Bild und misst DANACH, vor jeder Benutzung. Passt sie trotzdem
nicht ins Fenster, ist das ein harter Fehler statt einer stillen
Fehlmessung.
* Die Kachel selbst faellt von 404 auf 344 px. Groesster Posten war die
Anrede-Pille mit 88 px: In ihr steckt <h1 class="titel">, und
.willkommen .titel ist die grosse Seitenueberschrift -- es standen
also zwei Ueberschriften in Titelgroesse uebereinander. Der Rang von
#gruss aendert sich nicht, nur die Groesse.
Nebenbefund, den die Reparatur mit aufgedeckt hat: Die Randmessung stand
auf "nah 51 gegen fern 0". Diese 0 war kein Messwert, sondern der
Bildpunkt ausserhalb des Fensters. Jetzt "nah 43 gegen fern 7" -- dieselbe
Pruefung misst zum ersten Mal wirklich.
DIE MARKEN. marke-husky.webp war nie freigestellt (0,3 % durchsichtig,
alle vier Ecken Alpha 255) -- als Maske ergab das einen Kasten mit einem
Husky darin. Ersetzt durch das echte Original, damit repariert sich die
Kopfleiste ohne eine einzige geaenderte CSS-Zeile mit.
In der Mitte des Rings steht jetzt Spicy Media, nicht der Husky: Der Ring
zeigt DAS TEAM, ein Segment je Person. Der DogFather-Kopf in seiner Mitte
haette Filipe bildlich ins Zentrum seines eigenen Teams gesetzt.
Und davon nur die Chili: Das volle Siegel war bei 44 px unlesbarer Matsch.
Beim ersten Ausschneiden meldete das Werkzeug "60,8 % deckend, Ecken
0/0/0/0" -- klang tadellos und war ein schwarzes RECHTECK mit Chili darin.
Die Flutfuellung laeuft von aussen und kommt nie hinter den weissen Ring.
Gefunden hat das kein Kennwert, sondern das Hinsehen.
Gemessen: pruef-start-ansicht EXIT=0 (137 -> 140 Pruefungen, die drei
roten sind gruen, keine ist verschwunden), pruef-css-klassen EXIT=0
(472 Groessen), pruef-handy EXIT=0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGit
|
ec55b6c8d3 |
WIP Zentrale-Kachel nach VanVans Werktisch — NOCH NICHT FERTIG
Aufbau steht (Ring links, Titel mittig, Uhr rechts), aber pruef-start-ansicht meldet 3 Befunde am MAUS-LICHT der Kacheln. Gemessen: alter Stand 0 Befunde, dieser Stand 3 — kommt also von hier. Kein JS-Fehler (pageerror/console sind still), also Zeitverhalten: Die zusaetzliche Abfrage /api/zentrale verzoegert vermutlich den Aufbau der Kacheln ueber den Zeitpunkt hinaus, an dem kopf.js lichtFolgen ruft. Ausserdem offen: 2 Schriftgroessen unter 11,5 px (pruef-css-klassen). NICHT ausliefern. |
||
|
DogFatherGitandClaude Opus 5
|
0e522181e2 |
Pruefungen: der Rueckgabewert 127, der "in Ordnung" meldete
pruef-call-kategorien gab dreimal von dreimal 127 zurueck -- NACH der Zeile "ALLES IN ORDNUNG". Ursache ist eine libuv-Assertion auf Windows: Assertion failed: !(handle->flags & UV_HANDLE_CLOSING), file src\win\async.c, line 94 `process.exit()` schlaegt zu, waehrend Playwright seinen Transportkanal noch abbaut. Das Ergebnis stimmte, der Rueckgabewert log. In einem Sammellauf zaehlt so ein Lauf als Fehlschlag, obwohl nichts fehlschlug -- und wer sich angewoehnt, den Rueckgabewert dieser einen Datei zu ignorieren, uebersieht spaeter den echten. Meine Notiz sagte "sporadisch". Es war drei von drei. Auch eigene Notizen altern. MEIN ERSTER FIX WAR DIE ELEGANTERE LOESUNG UND DIE SCHLECHTERE. Ich wollte keine feste Pause -- 400 ms sind eine Rechnung auf DIESEM Rechner, und auf einem langsameren waere der Fehler still zurueckgekommen. Also: auf das Ereignis "disconnected" warten, danach zwoelf Runden der Ereignisschleife (setImmediate). Sauber begruendet. Gemessen: ZWEI VON DREI Laeufen weiterhin 127. Die feste Pause, die ich fuer schlechter hielt, war zweimal gruen. Die Annahme war falsch: "disconnected" meldet, dass die Verbindung weg ist, nicht dass der Kanal abgebaut ist -- und setImmediate gibt der Schleife Durchlaeufe, aber keine ZEIT. Der Kindprozess braucht echte Millisekunden. Eine stimmige Herleitung ersetzt keine Messung. Jetzt beides: erst das Ereignis (richtige Ordnung), dann eine zeitliche Reserve von 600 ms gegen gemessene 400, ueber PRUEF_ABBAU_MS einstellbar. Fuenf Laeufe hintereinander gruen. Neu: server/helfer-beenden.mjs (sauberBeenden) und tools/mess-rueckgabewerte.sh -- letzteres misst alle 42 Browser- Pruefungen mit demselben Muster daraufhin, ob noch weitere "in Ordnung" melden und trotzdem einen Fehlercode zurueckgeben. Laeuft nacheinander, nicht parallel: Zwei gleichzeitige Prueflaeufe sind kein Prueflauf. 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]> |
||
|
DogFatherGitandClaude Opus 5
|
af4a00dce2 |
Die Kopfleiste war nie klebend -- und das Call-Brett hatte eine leere Haelfte
DIE LEISTE BLEIBT JETZT OBEN (screen 3)
Filipe: "diese leiste soll immer da stehen bleiben, egal ob man die
seite runterscrollt oder nicht, auf allen seiten."
In start.css steht seit jeher `.kopfleiste { position: sticky; top: 0 }`.
Zwanzig Zeilen darueber steht aber
body.start > .kopfleiste { position: relative; z-index: 1; }
und das ist (0,2,1) gegen (0,1,0) -- die staerkere Regel gewinnt,
unabhaengig von der Reihenfolge. Gemessen im Browser: `position:
relative`, und bei 600 px Scrollen wanderte die Leiste 600 px aus dem
Bild. Sie hat also nie geklebt, obwohl es im Code so dasteht.
Das ist heute die VIERTE Spielart derselben Falle: `:where()` zu
schwach, `body.start .willkommen` zu stark, die Kachel-Verschachtelung
zu stark -- und hier eine Regel, die etwas ganz anderes wollte (den
Stapelwert ueber der Buehne) und dabei die Positionierung mitgenommen
hat. Merksatz: Wer `position` setzt, nur um `z-index` zu bekommen,
greift jedes Mal daneben.
Nachgemessen: 700 px gescrollt, Leiste steht bei 0.
DAS CALL-BRETT: DREI TAFELN STATT ZWEIER SPALTEN (screen 2)
Filipe: "das bewegt sich immer noch mit, das ist so scheissen."
DAS PROBLEM WAR DIE AUFTEILUNG, nicht die Gestaltung. Zwei Spalten, und
"Steht an" hatte siebenundzwanzig Karten: Die rechte Spalte lief ueber
mehrere Bildschirmhoehen, die linke war nach zwei Koepfen zu Ende. Wer
scrollt, sieht dann eine leere halbe Seite mit einer Ueberschrift, die
scheinbar mitwandert -- sie steht bloss still, waehrend daneben alles
laeuft.
Jetzt bekommt jede Tafel DIESELBE Hoehe und einen EIGENEN Lauf. Alle
drei Gruppen sind damit immer gleichzeitig zu sehen, egal wie viel in
einer steckt, und die Seite selbst scrollt kaum noch. Das ist die
Bauart jedes Aufgabenbretts, und sie ist es aus genau diesem Grund.
Die Hoehe haengt am Fenster (`min(62vh, 620px)`) statt an einer festen
Zahl. Unter 900 px stehen die Tafeln untereinander und laufen wieder
frei -- auf dem Handy ist ein Kaestchen mit eigenem Balken eine Falle,
keine Hilfe. Der Balken ist selbst gestaltet; der Systembalken reisst
ein weisses Band in eine dunkle Flaeche.
NOCH OFFEN aus derselben Nachricht: der Erinnerungswecker fuer Termine
(ein-/ausschaltbar je Eintrag, mehrere Zeitpunkte, von jedem selbst
einstellbar) -- dazu will Filipe ausdruecklich Recherche, und der baut
sich nicht nebenbei.
Zehn Pruefungen gelaufen, alle gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
28a260fab2 |
Ein Husky statt der Krone -- und Spicy sieht DogFather, aber nur ihn
DER HUSKY (screen 1) Filipe: "die krone bei dogfather durch einen husky ersetzen, wie mein logo." Bei 24 Pixeln entscheidet die SILHOUETTE, nicht das Detail. Ein Husky erkennt man an dreierlei, und mehr passt auch nicht hinein: den spitzen aufrechten Ohren, dem breiten Kopf, der nach unten schmal zulaeuft, und der Gesichtsmaske. Fell oder Zunge waeren bei dieser Groesse Matsch -- genau deshalb hat die Krone davor funktioniert. UND ALLE ROLLENSYMBOLE SIND JETZT KOERPER Sie waren reine Konturen in einer Farbe -- daneben auf derselben Seite die Kachelzeichen mit drei Lichtern. Jetzt tragen sie eine gefuellte Flaeche in ihrer Rollenfarbe, die Zeichnung hell darauf, und Augen und Nase eigens gesetzt. Beim gewaehlten Knopf leuchtet die Flaeche staerker -- der einzige Unterschied, den es braucht: mehr Licht auf demselben Gegenstand. SPICY SIEHT DOGFATHER, ABER NICHT DEN ZWEITEN ADMIN (screen 2) Filipe: "die rolle spicy soll auch die rolle dogfather sehen, aber nur dogfather und nicht vanvan." NACHGEMESSEN AM ECHTEN SYSTEM, nicht angenommen: In der Datenbank tragen BEIDE die Rolle `admin` -- id 1 "Dogfather", id 4 "VanVan". Es gibt kein Feld, das den einen vom anderen unterscheidet. Der Unterschied, den es wirklich gibt, ist das Alter: DogFather ist der erste Zugang des Hauses. Deshalb zaehlt die kleinste Nummer unter den Admins -- eine Eigenschaft, die feststeht und nicht am Namen haengt. Die Schwachstelle steht im Code, damit sie niemand sucht: Wuerde Zugang 1 je geloescht, rueckte der naechste nach; dann gehoert ein ausdrueckliches Merkmal in die Tabelle. Die Entscheidung faellt im SERVER, nicht in der Oberflaeche. Dort stand vorher ein Filter, der den ganzen Abschnitt wegnahm -- zwei Regeln fuer dieselbe Frage laufen auseinander, und eine ausgeblendete Zeile hat noch nie etwas geschuetzt. MEINE EIGENEN PRUEFUNGEN VON HEUTE MITTAG FIELEN DABEI Richtig so: Sie pruefen "DogFather steht NICHT darin", und das gilt nicht mehr. Umgeschrieben -- und dabei kam der eigentliche Prueffall dazu: ein ZWEITER Admin-Zugang im Testbestand. Ohne ihn waere die Regel gar nicht pruefbar, bei einem einzigen Admin ist jede Antwort richtig. pruef-spicy von 57 auf 60. NOCH OFFEN aus derselben Nachricht: die Terminarten (BigMatch, Turniere, Special-Live) und der Umbau der Begruessungskachel nach dem Vorbild von VanVans Werktisch. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
09a0c17237 |
Bearbeiten geht jetzt -- und zwei Bedienelemente, die keine Kacheln sind
DER SERVER LIESS DAS AENDERN DIE GANZE ZEIT ZU. IM TAGESFENSTER FEHLTE DER KNOPF. Filipe: "ich hab die gemacht und kann sie nicht bearbeiten." Dort standen nur "erledigt" und "loeschen". Ein Recht ohne Knopf ist kein Recht. Jetzt oeffnet "bearbeiten" dasselbe Formular, gefuellt -- ein Formular, zwei Wege (POST oder PATCH), statt eines zweiten, das genauso aussieht und beim naechsten Feld auseinanderlaeuft. Die Wiederholung bleibt beim Bearbeiten aussen vor: Sie ist eine REGEL und wird unter "Laeuft von allein" geaendert, nicht an einer ihrer Auspraegungen. Wer das zulaesst, bekommt einen Termin, der aus der Reihe faellt, ohne dass jemand weiss warum. UND DIE REGEL DAZU IM SERVER Filipe: "nur diese person selber." Bis hierher durfte JEDER aendern, der den Termin ueberhaupt sah -- bei einem Termin mit mehreren Beteiligten also alle. Jetzt: die Leitung und wer ihn eingetragen hat. Dieselbe Regel wie beim Loeschen, die dort schon richtig stand. AUSNAHME "erledigt": Ein Haken, dass ein Gespraech stattgefunden hat, ist keine Aenderung am Termin, sondern eine Rueckmeldung dazu -- sonst muesste jeder Beteiligte den Anleger bitten, den eigenen Call abzuhaken. Gemessen in pruef-teilnehmer, mit allen drei Faellen. Beim Bauen der Pruefung ist mir ein Aufbaufehler unterlaufen (Bea statt Pat als zweite Teilnehmerin -- Luna darf Bea gar nicht einladen), und die Pruefung hat ihn korrekt als 404 statt 403 gemeldet. Der Fehler lag im Aufbau, nicht im Code. DER ANSICHTS-UMSCHALTER WAR VIER KACHELN `.k-ansicht` stand in der Modulliste. Jeder der vier Knoepfe bekam damit die volle Behandlung einer Kachel: Fase, Kantenlicht, Eckwinkel, Raster. Auf 90 mal 32 Pixeln ist das kein Modul, sondern Gedraenge -- vier Fasen und sechzehn Eckwinkel nebeneinander. Die Modulform ist fuer FLAECHEN gedacht, die etwas enthalten. Ein Umschalter enthaelt nichts, er waehlt aus, und die richtige Form dafuer ist die SCHIENE: eine vertiefte Bahn, in der ein erhabenes Stueck aus gebuerstetem Metall sitzt. Man sieht auf einen Blick, dass die vier zusammengehoeren und genau eines gewaehlt ist. DIE GRUPPENKOEPFE AUF DER CALLS-SEITE Vorher eine Textzeile mit Pfeil, und die Karten darunter begannen ohne Uebergang -- aufgeklappt sah man nicht, wo eine Gruppe aufhoert. Jetzt ist der Kopf ein Schalter mit Zustand, die Zahl ein gefasstes Schild, und die Karten stehen aufgeklappt in einer eigenen vertieften Bahn mit Farbschiene links. 14 Pruefungen gelaufen, alle gruen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
dd1f561f3b |
Vier Meldungen -- und dahinter zweimal derselbe alte Fehler
DIE SYMBOLE IN DER TAGESKACHEL WAREN DIESELBEN -- OHNE IHRE GESTALTUNG
Sie kommen vom selben Bauer wie alle anderen, bekamen aber nie dessen
Aussehen: Alle Lagenregeln waren auf `.kachel__svg` eingegrenzt, und
dieses Zeichen heisst `.dran__svg`. Uebrig blieb eine flache Kontur --
daneben, auf derselben Seite, dieselben Zeichen mit drei Lichtern,
Tiefe und Randlicht. Die Regeln gelten jetzt fuer beide Traeger, und
das Feld darum ist dasselbe gefasste Schild wie auf den Kacheln.
"UNDEFINED" IM CHAT -- DERSELBE FEHLER WIE HEUTE FRUEH, NUR ALS OBJEKT
Ueber Cigdems Namen stand woertlich "UNDEFINED". Die Rollennamen
standen als Objekt in FUENF Skripten (chat.js zweimal, dateien.js,
kalender.js zweimal), in keinem davon 'spicy'.
Heute Frueh war es dieselbe Sache als Menge (`new Set([...])`), und
seitdem sucht `pruef-css-klassen.mjs` danach. Ein Muster, das nur eine
Schreibweise kennt, findet auch nur eine -- die Pruefung sucht jetzt
auch nach Rollen-OBJEKTEN, mit Gegenprobe. Die Namen stehen an EINER
Stelle in bereiche.js.
DOGFATHER UND SPICY MEDIA SIND IM CHAT FUER JEDEN ERREICHBAR
DogFather kam bisher als Nebeneffekt ueber die Betreuungskette mit
hinein, Spicy Media gar nicht -- die Rolle steht in keiner Kette, sie
steht daneben. Beide werden jetzt ausdruecklich hinzugefuegt: Eine
Zustaendigkeit, die nur zufaellig aus einer anderen Regel herausfaellt,
faellt beim naechsten Umbau genauso zufaellig wieder heraus.
Gemessen aus der Sicht eines Creators -- wer bei ihm ankommt, kommt
ueberall an.
DIE PERSONENLISTE: SPICY MEDIA SIEHT ALLES AUSSER DOGFATHER
Der Abschnitt "Spicy Media" fehlte in der Liste komplett -- die Rolle
gibt es seit heute Frueh, die Personenseite kannte sie nicht. Und Spicy
Media selbst sah dort bisher nur das Anlegen-Formular; sie bekommt
jetzt die Liste, ohne DogFathers Zeile, und weiterhin ohne Codes,
Sperren, Loeschen und Protokoll. Ueberblick ist nicht Verwaltung.
ZWEI FOLGEFEHLER, BEIDE VON DEN PRUEFUNGEN GEFUNDEN
* `next("route")` TUT DAS GEGENTEIL VON DEM, WONACH ES KLINGT. Mein
erster Versuch war eine Ausnahme-Route VOR der Schranke, die mit
`next("route")` weiterreicht -- das ueberspringt aber die restlichen
Handler DIESER Route und geht zur naechsten Schicht, also genau zur
Schranke. Spicy bekam weiter 404, die Oberflaeche verstand das als
"nicht erlaubt" und sprang zur Startseite. Gemessen: Auf
personen.html standen die Kategorien der STARTSEITE.
* DAS PROTOKOLL WARF SIE VON DER SEITE. Es bleibt bei DogFather und
antwortet ihr mit 404 -- und `hole()` versteht ein 404 unter
`/verwaltung/` als "nicht erlaubt". Die Seite baute sich auf und
sprang im naechsten Atemzug weg. Eine Abfrage, von der man weiss,
dass sie 404 gibt, stellt man nicht.
UND EINE MEINER EIGENEN NEUEN PRUEFUNGEN WAR WERTLOS
"bei ihr fehlt der Abschnitt DogFather" -- gruen, mit dem Zusatz
"(keine Abschnitte)". Sie war gruen, weil die Liste bei ihr GAR NICHT
DA war. Genau der Haken, der nichts beweist. Er steht jetzt neben einem
Ergebnis, das etwas enthaelt: "Spicy Media | Manager | ...".
18 Pruefungen gelaufen, alle gruen. pruef-spicy von 49 auf 57.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
0ea8b27aca |
Aus drei Strichen werden drei Ringe aus Material
Filipe: "ich will dass der rand mit den sekunden minuten und stunden
viel krasser und geiler ist ... ultra modern, ultra speziell, ultra
profissionell, ultra phaenomenal."
EIN STRICH IST EINE LINIE. EIN RING IST EIN KOERPER.
Und ein Koerper hat drei Merkmale, die man zeichnen MUSS, sonst bleibt
es ein Strich. Jeder der drei Ringe besteht deshalb jetzt aus drei
Lagen:
SCHATTEN Er liegt ueber dem Zifferblatt, also wirft er einen.
Dieselbe Bahn, schwarz, ein halbes Rastermass nach UNTEN.
KOERPER Der Bogen selbst in seiner Farbe.
OBERKANTE Duenner, hell, ein Drittel nach OBEN. Weil er versetzt
ist, schaut er oben hervor und verschwindet unten -- genau
das tut eine gewoelbte Kante bei Licht von oben.
Kein Weichzeichner, nirgends: Die Tiefe kommt aus dem Versatz, nicht
aus Unschaerfe.
DIE BAHNEN SIND GEFRAESTE RILLEN
Ein Zeiger laeuft bei einem guten Instrument IN einer Vertiefung. Eine
Rille erkennt man an zweierlei: dunkler als ihre Umgebung, und an ihrer
unteren Wand steht eine helle Kante. Beides steht jetzt da, und die
Breite folgt dem Ring, der darin laeuft -- eine Rille, die schmaler ist
als ihr Zeiger, ist keine.
DREI KOEPFE STATT EINEM
Minute und Stunde bekommen dieselbe polierte Kappe wie die Sekunde, auf
ihren eigenen Bahnen und in ihrer eigenen Farbe. Erst dadurch liest man
die drei Ringe als drei ZEIGER und nicht als drei Fortschrittsbalken.
Sie laufen mit ihrem Ring: die Minute nimmt die Sekunden anteilig mit,
die Stunde die Minuten -- sonst staende der Kopf neben dem Ende seines
Bogens.
ALLE LAGEN WERDEN GEMEINSAM GESETZT. Sie tragen `data-ring`; einzeln
gepflegte Verweise waeren drei Stellen, an denen man eine vergessen
kann, und ein Schatten, der stehen bleibt, sieht sofort kaputt aus.
UND EIN FUND, DEN DIE PRUEFUNG SOFORT GEMELDET HAT
Die neue helle Oberkante des Stundenrings laeuft hinter den Ziffern
durch: schlechtester Kontrast 2,98:1 -- knapp unter der Grenze, und
ausgerechnet bei der Uhrzeit selbst. Die Antwort war nicht "Kante
weg", sondern der fehlende Untergrund: Auf einer echten Uhr steht eine
Anzeige, die ueber Zeigern liegt, auf einer eigenen vertieften INSEL im
Zifferblatt. Jetzt 5,42:1, und dabei 29 statt 14 gemessene Stellen.
Merksatz: Wenn eine neue Schicht einen Text unlesbar macht, ist die
Antwort selten "Schicht weg" -- meistens fehlt dem Text sein Grund.
Zehn Pruefungen gelaufen, alle gruen. Rechner und Handy angesehen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
9c7952b5a3 |
Drei Lichter statt einem: die Symbole bekommen Koerper
Filipe: "die symbole und der text dadrin sollen groesser und noch
spezieller sein, und die symbole sollen auch 2-3 farben haben ... sollen
mehr leben haben, auch viel realistischere effekte."
NICHT DREI AUSGEDACHTE FARBEN, SONDERN DIE DREI EINES ECHTEN AUFBAUS
So wird jedes Produktfoto ausgeleuchtet, und aus demselben Grund sieht
es plastisch aus:
1 FUEHRUNGSLICHT, kalt, von oben links. Ein Spitzlicht ist nie
reinweiss -- es traegt die Farbe der Lampe, und die ist kuehl.
2 EIGENFARBE des Gegenstands: der Ton seiner Kachel.
3 STREULICHT, warm, von unten. Licht, das vom Untergrund
zurueckkommt, ist waermer als das Hauptlicht. Genau dieser warme
Saum ist der Grund, warum ein Gegenstand im Bild STEHT statt zu
schweben.
Dazu die aelteste Regel der Malerei: warmes Licht, KUEHLE Schatten. Die
Seitenwaende der Zeichen kippen jetzt ins Blaue statt nur dunkler zu
werden. Und ein RANDLICHT auf der Lichtseite -- der schmale Streifen,
in dem das Fuehrungslicht die Kante streift. Ein Gegenstand ohne diese
Kante sieht immer ein wenig flach aus, und man kann meist nicht sagen,
warum.
ZWEI FEHLER DABEI, BEIDE ERST BEI FUENFFACHER VERGROESSERUNG SICHTBAR
* DAS WARME LICHT LAG UNTER DER FORM. Die Verlaeufe spannten ueber das
ganze 24er-Raster (y 2 bis 22); die Sprechblase des Chats reicht
aber nur von 5,5 bis 20,5. Der warme Stopp bei y 22 war damit
ausserhalb -- von den drei Lichtern kam genau eines an.
`objectBoundingBox` spannt den Verlauf jetzt ueber JEDES Teil
einzeln: Der Kalenderkorpus bekommt sein volles Licht, seine Fuesse
ebenfalls. So verhaelt sich ein echter Aufbau -- jedes Teil liegt im
selben Licht, nicht im selben Ausschnitt.
* DAS RANDLICHT WAR SCHMALER ALS DIE KONTUR DARUEBER und lag deshalb
vollstaendig darunter: gebaut, gezeichnet, unsichtbar. Jetzt 2,7
gegen 1,9 -- so schaut es oben links hervor.
GROESSER, WIE GEWUENSCHT
Plakette 58 -> 64 px (grosse Kachel 62 -> 70), Zeichen 29 -> 35 px
(gross 32 -> 39), Wasserzeichen 132 -> 156 px (gross 168 -> 196),
Name 1,06 -> 1,15 rem (gross 1,24 -> 1,38), Unterzeile 0,78 -> 0,845.
Auf dem Dashboard entsprechend.
UND DAS SCHILD WIRFT LICHT AUF SEINE KACHEL
Ein beleuchteter Gegenstand faerbt seine Umgebung. Ohne diesen Abfall
sieht selbst ein gut gebautes Schild aufgeklebt aus. Weit gestreut und
weit unter der Blendschwelle: Man soll ihn nicht sehen, man soll ihn
vermissen, wenn er fehlt.
Zehn Pruefungen gelaufen, alle gruen -- darunter Handy und Breiten,
weil groesserer Text der schnellste Weg zu einem Ueberlauf ist.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
5b6f9cef98 |
Rot, Schwarz, Babyblau -- und ein Glas, das entspiegelt ist
Filipe: "der rand soll auch eine mischung von rot schwarz und babyblau
haben und die kachel selbst soll einen uebertrieben krank geilen
hintergrund haben ... die einzige kachel, die komplett aus dem rudel
faellt. die uhr soll auch VIEL VIEL VIEL KRASSER sein. informier dich,
hol die besten skills von den besten skills."
NACHGELESEN STATT GERATEN -- UND DAS HAT DIE UHR VERAENDERT
Zur Frage, woran man ein hochwertiges Uhrenglas erkennt: Eine
Entspiegelung wird im Vakuum aufgedampft und senkt die Spiegelung auf
unter ein Prozent -- das Zifferblatt wirkt dadurch SCHAERFER, nicht
milchiger. Und ihr Erkennungszeichen ist kein weisser Schleier, sondern
ein TOPASBLAUER SCHIMMER, der je nach Lichteinfall ueber das Glas
laeuft.
Hier lag genau das Gegenteil: ein breiter weisser Verlauf ueber ein
Fuenftel der Scheibe -- also die Spiegelung eines UNBESCHICHTETEN
Glases, das Merkmal des billigeren Materials. Jetzt: ein schmaler,
harter Reflexbogen an der Woelbung, der topasblaue Schimmer diagonal
darueber, und die haarfeine Schnittkante oben.
DAZU ZWEI WEITERE MITTEL AUS DEM UHRENBAU
* AUFGESETZTE INDIZES bei 3, 6 und 9. Auf einer guten Luenette sind
die Viertelstunden keine Striche wie die anderen: Sie sind eigene
Marken, breiter und HELL statt graviert -- weil sie aufgesetzt sind
und deshalb Licht fangen statt Schatten zu halten. Die 12 bleibt
die rote.
* DAS SEKUNDENFELD IST EIN EINGELASSENES FENSTER. Eine Zusatzanzeige
sitzt in einer Aussparung des Blatts; man erkennt das daran, dass
der Schatten oben hineinfaellt und unten eine helle Kante steht.
Genau diese beiden Schatten stehen jetzt darin.
DIE FASSUNG: DREI FARBEN STATT STAHL MIT TUPFERN
Links die rote Haelfte, rechts die babyblaue, dazwischen und an den
Raendern Schwarz -- und ueberall dort, wo Metall das Licht bricht, die
hellen Spitzlichter. Es sind dieselben zwei Farben wie im Motiv und auf
der Anmeldekarte.
DER HINTERGRUND: SECHS SCHICHTEN
Lichtkante, KOHLEFASERGEWEBE (zwei gegenlaeufige Schraegen, die sich
kreuzen -- bei drei Prozent sieht man kein Muster, man sieht ein
MATERIAL), das Messraster, ein HORIZONT im unteren Drittel mit Schein
darueber, die beiden Farbbecken kraeftiger als bisher, und ein fast
schwarzer Grund mit Blauschimmer oben.
Alles weit unter der Blendschwelle -- die Hausregel gilt auch fuer
"krank geil": Es darf beeindrucken, es darf nicht blenden.
Sieben Pruefungen gelaufen, alle gruen. Rechner und Handy angesehen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
6e09c55002 |
Die Symbole hatten nie ihre Farbe -- ein Jahr lang, auf jeder Seite
Filipe: "ich will dass die symbole viel krasser, realistischer, farbiger und spezieller sind ... ich meine wirklich alle alle alle symbole auf der ganzen website." DER GRUND WAR KEIN GESCHMACK, SONDERN EIN BAUFEHLER Die Verlaeufe der Zeichen arbeiten mit `currentColor`, damit jedes Zeichen die Farbe SEINER Kachel annimmt. Sie lagen aber alle zusammen in EINEM versteckten SVG am Ende der Seite, und jedes Zeichen verwies nur darauf. `currentColor` in einem Verlaufsstopp wird an dem Element aufgeloest, das den STOPP enthaelt -- also dort, im versteckten SVG, wo die Textfarbe das helle Grau der Seite ist. Jedes Zeichen im ganzen Haus war deshalb grau. Der Farbton kam sauber an der Kachel an (gemessen: rgb(62,149,231) auf der Dashboard-Kachel) und wurde nie benutzt. GEMESSEN, NICHT VERMUTET: Faerbt man das versteckte SVG rot, werden die Zeichen rot (hellster Bildpunkt 43/49/61 -> 46/29/40). Faerbt man das ZEICHEN rot, passiert nichts. Damit war die Frage entschieden. Das Tueckische daran: Es sah nie kaputt aus. Graue Zeichen auf dunklem Grund wirken sauber und zurueckhaltend -- man haelt es fuer eine Entscheidung. Ein Fehler, der wie Gestaltung aussieht, ueberlebt jede Pruefung, die auf Fehlermeldungen achtet. DIE REPARATUR Jedes Zeichen traegt seine Verlaeufe jetzt SELBST, in seinem eigenen SVG und mit eigener Kennung. Damit steht `currentColor` dort, wo es hingehoert. Die Verweise setzt das Skript als Inline-Stil, weil eine Klassenregel die je Zeichen andere Kennung nicht kennen kann -- das Wasserzeichen bekommt keinen, dort setzt das CSS die Farbe ausdruecklich. UND DAS LICHT WURDE UMGEDREHT Weiss stand vorher ueberall: die Deckflaeche begann mit 92 % Weiss, die Kontur war bis 38 % weiss und bei 100 % wieder. Selbst mit richtiger Farbe waere davon wenig uebrig geblieben. Jetzt ist Weiss nur noch da, wo bei einem echten Gegenstand das SPITZLICHT sitzt -- ein schmaler Streifen ganz oben. Darunter traegt die Eigenfarbe, unten kommt Streulicht in einer helleren Tonung statt in Weiss: Licht, das vom Untergrund zurueckkommt, nimmt die Farbe des Gegenstands mit, es bleicht ihn nicht aus. Das Spitzlicht selbst wurde schmal und hart -- ein Schleier ueber zwei Drittel der Flaeche ist kein Spitzlicht, sondern der sicherste Weg, jede Farbe blass zu machen. DAS WASSERZEICHEN Seine Deckkraft von sieben Prozent war ein Wert aus der Zeit, als das Zeichen grau war -- mehr ging nicht, ohne dass es schmutzig aussah. Eine Farbe darf lauter sein als ein Grau, weil sie zur Kachel GEHOERT. Auf 14 Prozent verdoppelt, kraeftigere Linie, und ein leichter Schein darunter fuer Tiefe. 15 Pruefungen gelaufen, alle gruen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
dbb19f69e9 |
Uhrmacherei statt Lack: guillochiertes Blatt, laufende Perle, Spiegelung auf Metall
Filipe: "ich will dass diese kachel komplett speziell ist, das
hochwertigste und geilste auf der ganzen website ... auch das gleiche
prinzip fuer die uhr, noch vieeeel spezieller. hol die besten skills
von den besten skills dafuer."
Also keine weitere Schicht Lack, sondern die Mittel, an denen man ein
teures Instrument WIRKLICH erkennt.
DIE UHR -- VIER MITTEL AUS DER UHRMACHEREI
1. GUILLOCHIERTES ZIFFERBLATT. Guillochieren ist das Verfahren, mit
dem seit zweihundert Jahren hochwertige Blaetter gemacht werden:
Eine Maschine schneidet ein feines regelmaessiges Muster ins
Metall, und weil jede Rille das Licht anders zurueckwirft, LEBT
die Flaeche. Hier aus Strahlen vom Mittelpunkt und Ringen darum,
beide bei vier Prozent Deckkraft -- wer das Muster einzeln
erkennt, hat es zu laut gemacht.
2. EIN AUFGESETZTER ZWOELF-INDEX. Auf einem echten Blatt ist die
Zwoelf nie nur ein Strich wie die anderen: Sie ist das, woran das
Auge sich ausrichtet. Ein Keil in Hausrot mit heller Kante.
3. DIE PERLE AM KOPF DES SEKUNDENBOGENS. Sie laeuft einmal je Minute
herum und ist das Einzige an der Uhr, das sich BEWEGT statt zu
wachsen. Ein Bogen zeigt einen Stand, eine laufende Perle zeigt
Leben. Sie springt im Sekundentakt statt zu gleiten -- ehrlicher
(die Anzeige ist digital) und eine Bildberechnung je Sekunde statt
sechzig.
4. GRAVIERTE ZIFFERN. Ein dunkler Saum oben, ein heller unten -- das
Lichtverhalten einer Vertiefung. Die Ziffern stehen damit IM Blatt
statt darauf.
DIE KONSOLE -- DAS METALL FAENGT DAS LICHT
Auf den Kacheln leuchtet das Licht in der Farbe der Kategorie; dort ist
es ein Hinweis. Auf der Konsole waere das falsch -- ein farbiger
Schleier auf gebuerstetem Metall sieht aus wie eine Folie darauf.
Metall zeigt seine Form ueber die SPIEGELUNG: weiss, schmal, hart an
der Kante, und sie wandert mit dem Zeiger ueber die Fassung wie ein
Fenster, an dem man vorbeigeht. Erst dadurch sieht man, dass die
Fassung gewoelbt ist. Ein Standbild kann das nicht.
Dieselbe Falle wie heute Frueh dabei vermieden, diesmal vorher
bedacht: `.willkommen > *` haette dem Lichtelement wieder sein
`position: absolute` genommen -- jetzt `:not(.licht)`.
UND EIN FEHLER, DEN NUR DAS HANDY GEZEIGT HAT
Die Mulde der Uhr hing am Kasten daneben und war an dessen rechtem Rand
ausgerichtet. Am Rechner passte das; bei 412 px steht die Uhr mittig,
und die Mulde lag als dunkle Scheibe neben ihr. Sie entsteht jetzt aus
zwei Schattenringen der Uhr SELBST und ist damit konzentrisch bei jeder
Groesse -- die bessere Bauart, nicht nur die reparierte: Eine Fassung,
die man ausrichten muss, richtet irgendwann jemand falsch aus.
Zehn Pruefungen gelaufen, alle gruen. Rechner und Handy angesehen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
532daa3edf |
Alles fertig: Konsole montiert, Tageskachel als Instrument, zwei Seiten repariert
DIE KONSOLE -- DREI STUFEN DRAUF
1. VIER NIETEN in den vier Fasen. Das Einzige, was eine Flaeche
endgueltig zu einem GEGENSTAND macht, ist die Frage, wie sie
befestigt ist. Ein Gehaeuse haengt nicht in der Luft.
2. EINE GEFRAESTE NUT trennt Text von Instrumenten -- dunkel auf der
Lichtseite, hell auf der Schattenseite. Genau umgekehrt zu einer
aufgemalten Linie, und deshalb sieht sie nach Material aus.
3. DIE UHR SITZT IN EINER MULDE statt auf der Platte.
Drei Fehler dabei, alle im Bildschirmfoto gesehen: Die Nieten waren
QUADRATE (eine Hintergrundebene laesst sich nicht runden -- jetzt aus
Radialverlaeufen, die selbst rund sind). Die Mulde lag UEBER der Uhr
und hat die polierte Luenette zu mattem Grau gedaempft (`::after` wird
nach allen Kindern gezeichnet). Und das Raster musste von der
Nieten-Ebene herunter: Eine Ebene hat nur EINE Deckkraft.
DIE TAGESKACHEL "WAS IST DRAN"
Die drei Zeilen sind jetzt MODULE -- Fase, Kantenlicht in der Farbe
ihres Bereichs, Eckwinkel. Sie sind damit kleine Ausgaben derselben
Bauteile, zu denen sie fuehren, was sie ja auch sind. Die ZAHL wurde
zum gefassten Schild wie das Zeichen auf den Kacheln, und zwischen den
Haelften laeuft dieselbe gefraeste Nut wie auf der Konsole.
Ein Rueckschritt dabei, von der Pruefung sofort gemeldet: Ich hatte
die Ziffer weiss gemacht, weil das auf Metall gut aussieht -- damit
war ihre Aussage weg. Die Zahl traegt die Farbe ihres Bereichs und bei
etwas Ueberfaelligem die Warnfarbe; das ist die schnellste Auskunft der
ganzen Kachel. Die Farbe gehoert in die Ziffer, nicht ins Schild.
SPICY MEDIA SIEHT DIE ZAHLEN JETZT NIRGENDS
Vorher nur Kachel und Seite -- die Creator-Zahlen standen weiterhin im
Dashboard, weil das sie ueber eine eigene Schnittstelle holt. Die ist
jetzt zu (404 am Server, nicht in der Oberflaeche). Das Dashboard
bleibt fuer sie stehen: Es faengt den Fehlschlag ausdruecklich ab.
Mit Pruefung und Gegenprobe.
UND ZWEI SEITEN, DIE BEIM ANSEHEN AUFFIELEN
Das ist der Ertrag der Durchsicht jener zwoelf Seiten, die bisher nur
GEPRUEFT und nie ANGESEHEN worden waren:
* chat.html und uebersicht.html luden kopf.js OHNE wahl.js. Der
Umschalter "Meine Sicht" fiel dort auf das nackte Systemfeld
zurueck: 92 x 19 px, grauer Kasten, Systemschrift -- auf allen
anderen Seiten ist es ein selbst gebautes Bedienelement, hinter dem
dasselbe Feld unsichtbar bei 2 x 2 px liegt. Kaputt war nichts. Es
sah nur aus wie aus einem anderen Programm, und genau das findet
keine Pruefung, die auf Fehlermeldungen achtet.
Neue Pruefung: Wer kopf.js laedt, muss wahl.js laden -- und vorher.
* Der Chat-Rahmen gehoerte als einzige grosse Flaeche noch nicht zum
Modulsystem. Jetzt schon.
18 Pruefungen gelaufen, alle gruen. Rechner und Handy angesehen,
dazu Kalender, Chat, Automationen, Uebersicht, Start-Check,
Steckbrief, Bereiche, Profil, Content, Scouting und Report.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
90d5898640 |
Drei Stufen auf die Kacheln -- Fase, Rahmung, gefasstes Schild
Filipe: "perfektionier alle kacheln die du vorhin gewechselt hast auf
der ganzen website, mach sie alle noch geiler und geiler und noch
spezieller. sie gehen aber in eine gute richtung schon."
Alle drei Stufen sind FORM, keine neue Farbe -- das war die Lehre der
letzten Runden. Sie gelten fuer alle 35 Bauteile auf allen 18 Seiten,
weil sie in module.css stehen.
STUFE 1 -- DIE SCHRAEGE WIRD EINE ECHTE FASE
Bisher war die abgeschnittene Ecke ein Loch: Material, das fehlt. Eine
gefraeste Fase hat eine FLAECHE, und auf der liegt Schatten, weil sie
schraeg zum Licht steht. Ein Innenschatten aus der Richtung der
Schraege macht daraus ein bearbeitetes Werkstueck.
STUFE 2 -- ECKWINKEL AN DREI ECKEN STATT AN EINER
Eine einzelne Ecke liest sich als Verzierung, drei lesen sich als
RAHMUNG: Das Auge schliesst sie zu einem Ausschnitt. Die vierte bleibt
frei, dort sitzt die Fase -- ein Winkel auf einer abgeschnittenen Ecke
zeigte ins Leere.
STUFE 3 -- DAS ZEICHEN BEKOMMT EINE METALLFASSUNG
Die Plakette war ein abgerundetes Quadrat mit Farbschleier, also
dieselbe Form wie ueberall sonst im Netz. Jetzt ist sie ein gefasstes
Schild: dieselbe abgeschnittene Ecke wie ihre Karte, ein 2 px breiter
Ring aus gebuerstetem Metall, und die Kategoriefarbe INNEN. Damit
spricht die Anwendung EINE Materialsprache -- Konsole, Luenette der
Uhr und Schild sind dasselbe Metall.
ZWEI FEHLER DABEI, BEIDE GEMESSEN STATT VERMUTET
* DIE RUNDUNG BLIEB. `.kachel[data-gross="ja"] .kachel__zeichen`
setzt in start.css zweimal einen Radius (21 px, 18 px) und ist
staerker als eine einzelne Klasse. Gemessen: 18 px, obwohl
module.css 0 setzt und zuletzt geladen wird. Heraus kam ein Schild
mit abgeschnittener Ecke UND runden Ecken. Das ist heute die
dritte Spielart derselben Falle -- `:where()` war zu schwach,
`body.start .willkommen` zu stark, hier ist es die
Verschachtelung.
* DIE FASSUNG WAR ZU GRELL. Fast weiss auf 2 px Breite las sich als
Rahmen, der lauter ist als das Zeichen darin. Eine Fassung soll
das Schild halten, nicht mit ihm konkurrieren -- dieselben Stopps,
eine Blende dunkler.
18 Pruefungen gelaufen, alle gruen, keine mit gesunkener Anzahl.
Rechner und Handy (412 px) angesehen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
2acb6bc020 |
Das Maus-Licht ist zurueck, und die Begruessung ist keine Kachel mehr
DAS LICHT, DAS DEM ZEIGER FOLGT -- MEIN EIGENER FEHLER VON HEUTE FRUEH
Es war nicht geloescht. In module.css stand seit heute
.kachel > * { position: relative; z-index: 1; }
damit der Inhalt ueber Raster und Kantenlicht liegt. Das Lichtelement
ist aber ein direktes KIND jeder Karte -- ihm wurde damit sein
`position: absolute` genommen. Aus einer Flaeche ueber der ganzen Karte
wurde ein leerer Inline-Span ohne Ausdehnung. Im Browser gemessen:
`display: inline`, obwohl in start.css `absolute` steht.
Merksatz dazu im Code: Eine Regel auf `> *` trifft auch das, was gar
kein Inhalt ist.
Zweiter, aelterer Fehler beim selben Thema, den erst die Pruefung
gefunden hat: Beim Wechsel von einer Kachel direkt auf die naechste
ging das Licht GANZ aus. `pointermove` der neuen Karte meldet einen
Bildaufbau an, `pointerout` der alten kommt danach und hat ihn
geloescht -- obwohl er gar nicht ihr gehoerte. Jetzt wird nur noch der
EIGENE Bildaufbau entwertet.
DIE BEGRUESSUNG FLIEGT AUS DER REIHE
Filipe: "diese hauptkachel muss komplett aus der rolle fliegen im
gegenzug zu den anderen ... AUCH MIT DER UHR RECHTS; WIE IN DER
BUISNESS HUB SEITE VON VANVAN."
Nachgesehen statt geraten: Auf VanVans Business-Hub gibt es keine Uhr.
Gemeint ist das `gate-medaillon` der Anmeldeseite -- ein runder
Kegelverlauf, der wie gebuerstetes Metall aussieht, gefasst in zwei
eingelassenen Ringen. Diese Bauart steht jetzt hier, weitergetrieben.
Die Begruessung ist keine Kachel mehr, sondern eine KONSOLE, und sie
unterscheidet sich in der FORM, nicht im Lack:
* Sie ist BREITER ALS DIE SEITE -- sie tritt links und rechts ueber
die Spalte hinaus, in der alle Kacheln stehen.
* Sie ist ein ACHTECK. Die Module haben EINE abgeschnittene Ecke,
sie hat VIER.
* Sie hat eine METALLFASSUNG, laengs gebuerstet, mit je einer warmen
und einer kuehlen Spiegelung.
Die Uhr ist von 124 auf 164 px gewachsen und hat eine echte Luenette:
10 px deckendes Metall, zwoelf eingravierte Stundenmarken, sechzig
feine Minutenstriche, Glaskuppe.
VIER FEHLER AUF DEM WEG DAHIN, ALLE IM BILDSCHIRMFOTO GESEHEN
1. HALBDURCHSICHTIGES METALL ist kein Metall, sondern graues Glas.
Stand gleichzeitig an Konsole und Uhr.
2. KEGELVERLAUF AUF EINEM BREITEN BALKEN bewirkt nichts: Die ganze
Oberkante liegt in wenigen Grad. Rund -> conic, lang -> linear.
Die Verlaufsart muss zur FORM passen, nicht zum Material.
3. DIE SKALA DER UHR WAR NIE SICHTBAR, seit es sie gibt. Ihre Maske
rechnete Prozente auf die weiteste ECKE (116 px) statt auf den
Radius (82 px) -- der Ring lag komplett ausserhalb der Uhr.
`closest-side` behebt es. Eine unsichtbare Verzierung sieht aus
wie gar keine, nicht wie ein Fehler.
4. `body.start .willkommen` in start.css hat die neue Konsole
ueberschrieben -- nicht ueber die Ladereihenfolge, sondern ueber
die SPEZIFITAET (0,2,1 gegen 0,1,0). Derselbe Fehler wie mit
`:where()` heute Frueh, nur andersherum: damals zu schwach
geschrieben, hier zu stark stehen gelassen.
Der Ueberstand haengt an der Polsterung der Inhaltsspalte
(`min(34px, 3.6vw)`) statt an einer festen Zahl -- eine feste haette
auf dem Handy 17 px aus dem Bildschirm geragt.
UND EINE PRUEFUNG, DIE UNTER DEN BILDRAND GEZIELT HAT
pruef-start-ansicht meldete zwei Fehler am Licht. Das Licht war in
Ordnung: Die hoehere Konsole hatte Kachel 3 auf y = 1134 geschoben,
bei einem 1200 px hohen Fenster lag ihre Mitte unter dem Rand. Sie
rollt jetzt hin, misst danach neu -- und die Zahl der wirklich
gemessenen Kacheln steht in der Bedingung. 140 statt 137 Pruefungen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
ac432d85e1 |
Spicy Media: sieben stille Luecken -- und der Kalender zeigt wirklich nur noch Eigenes
Filipe hat drei Sachen gemeldet. Zwei davon waren nicht das, wonach sie
aussahen.
1. "BEI DER SPICY ROLLE IST DA EIN PROBLEM" (Creator-Profil laedt nicht)
Nicht diese Seite war kaputt. In NEUN Skripten stand dieselbe Zeile
const LEITUNG = new Set(['admin', 'manager']);
und in keinem davon 'spicy'. profil.js nahm deshalb den Creator-Zweig
und lud das EIGENE Profil -- ein Spicy-Zugang ist kein Creator, also
404. Acht der neun sind nicht kaputtgegangen; sie haben sich still
falsch verhalten.
Die Liste steht jetzt EINMAL in bereiche.js. Beim Aufraeumen kamen mit
derselben Suche sechs weitere Luecken heraus, alle vom selben Typ:
* Aufgaben abbrechen -- Server UND Knopf ohne 'spicy'
* Teilen-Knopf in der Kopfleiste -- ohne 'spicy'
* Chat: die Gespraechsliste laeuft ueber eine feste Rollenfolge.
Wer nicht darin steht, taucht gar nicht auf -- eine Person, die es
fuer die anderen nicht gibt.
* Kalender: dieselbe Rollenfolge, dort landete Spicy Media durch
indexOf() === -1 ganz oben statt an ihrem Platz.
* Dashboard: "Creator anlegen" nur fuer admin/manager -- der Server
haette sie gelassen, den Knopf hat sie nie gesehen.
* Personenliste: ROLLENNAME ohne 'spicy'. Der Auffangwert
`|| p.rolle` schrieb "spicy" statt "Spicy Media" -- plausibel
genug, um jahrelang zu bleiben.
`pruef-css-klassen.mjs` verlangt jetzt, dass kein Workspace-Skript sich
wieder eine eigene Rollenliste baut. Mit Gegenprobe, dass der Sucher so
eine Liste auch wirklich findet.
2. "DIE ZAHLEN DIESE KATEGORIE NICHT SEHEN"
Kachel und Seite waren beim Anlegen der Rolle auf ["spicy","admin"]
gesetzt worden -- "dieselben Rechte ausser Automationen". Beides jetzt
auf DogFather allein.
3. "IN CIGDEMS KALENDER STEHT IMMER NOCH MEIN MANAGER MEETING"
Das war MEIN Denkfehler von heute Frueh, nicht ein vergessener Fall.
Ich hatte "geht alle an" als "kein Teilnehmer eingetragen" definiert --
also entschied der Server, was alle angeht, und nicht der, der den
Termin anlegt. Wer niemanden eintraegt, meint aber meistens nicht
"alle", sondern "mich".
Der Fall ist entfallen. Sichtbar ist ein Termin jetzt nur noch fuer
den, der ihn angelegt hat, dem er zugeordnet ist, der das Gegenueber
ist -- oder der in der Teilnehmerliste steht. Damit ist das Markieren
im Termin die einzige Antwort auf "wen geht das an": eine sichtbare
Entscheidung im Formular statt einer unsichtbaren Regel im Server.
Calls & Protokolle rufen dieselbe Funktion auf und koennen deshalb gar
nicht auseinanderlaufen -- das war Filipes vierter Wunsch, und er ist
mit derselben Zeile erledigt.
Am laufenden System als Cigdem nachgemessen: Profil laedt ("Profil:
Luna"), Zahlen-Kachel weg und Seite gesperrt, im Kalender NUR der
Termin, bei dem sie markiert ist, Calls zeigt genau denselben.
Fuenf Pruefungen auf die endgueltige Regel umgeschrieben statt
geloescht (sicht, spicy, teilnehmer, scout-zuteilung, css-klassen).
Die dritte Drehung bei scout-zuteilung steht mit allen drei Staenden
in der Akte -- eine geloeschte Pruefung hinterlaesst keine Spur davon,
dass hier einmal etwas anderes galt.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
4eab64bd20 |
Eine neue Form fuer jedes Modul -- und der Kalender zeigt nur noch, was einen angeht
Filipe: "DU HAST WIEDER EINE KLEINE AENDERUNG UEBERALL GEMACHT ANSTATT
EINE RIESEN AENDERUNG." Er hatte recht, und der Grund war jedes Mal
derselbe: Ich habe das MATERIAL getauscht (Mattglas, Leuchtschiene,
Verlauf) und die FORM gelassen. Ein abgerundetes Rechteck bleibt ein
abgerundetes Rechteck -- und die Silhouette ist das Einzige, was man aus
fuenf Metern erkennt.
Jetzt ist die Form eine andere: abgeschnittene Ecke oben links
(clip-path, echte Silhouette), ein Kantenlicht in der Kategoriefarbe
darauf, Eckwinkel unten rechts, ein feines Raster statt Koernung.
35 Bauteile auf allen 18 Seiten, in einer eigenen Datei (module.css).
DREI DINGE, DIE DABEI SCHIEFGINGEN UND JETZT ABGESICHERT SIND
1. Die Regeln standen in :where() -- Spezifitaet null, also gewann jede
aeltere .kachel::before-Regel. Jetzt :is().
2. module.css stand an DRITTER Stelle im Ladeweg. Auf Calls,
Automationen, Bereich und Dateien hat sie damit gar nichts bewirkt:
Die Seitendateien setzen dort selbst border-radius und box-shadow und
kommen spaeter. Genau das ergab wieder "ueberall ein bisschen". Sie
wird jetzt als LETZTE geladen, geprueft auf allen 18 Seiten.
3. Die Klassenliste steht siebenmal in der Datei (CSS kennt keine
Variable fuer Selektoren). Eine vergessene Kopie faellt niemandem
auf -- pruef-css-klassen vergleicht sie deshalb alle, mit Gegenprobe.
DER KALENDER: NUR NOCH, WAS EINEN ANGEHT
Filipe: "calls oder termine soll jeder nur sehen die er selber macht
oder jeden betrifft." Das gilt auch fuer DogFather, und das ist die
eigentliche Aenderung -- er bekam bisher 1=1. "Jeden betrifft" heisst:
ohne Gegenueber und ohne Teilnehmerliste. Wer niemanden eintraegt, meint
alle. Die Rollenfrage entfaellt im Kalender damit vollstaendig.
SECHS PRUEFUNGEN, DIE EINE WELT GEMESSEN HABEN, DIE ES NICHT MEHR GIBT
Alle sechs wurden auf die neue Regel umgeschrieben, keine geloescht --
loeschen haette die Zahl gesenkt und den neuen Weg ungeprueft gelassen:
ics, serien, sicht, spicy, teilnehmer, tagesblick, team.
UND VIER ECHTE FUNDE, DIE DABEI HERAUSFIELEN
* pruef-workspace-seiten war seit dem Bildumbau von heute Frueh auf
ALLEN 32 Seiten rot: Sie verlangte noch das eine Motiv. Die neue
Bedingung ist schaerfer als beide alten -- das geladene Bild muss zu
dem Merkmal passen, das die Seite selbst traegt. Und die Meldung sagt
jetzt, WELCHE Bedingung gefallen ist.
* pruef-leistung-optik hat sich selbst ausgesperrt (meldete sich als
Manager an, der die Zahlen seit Filipes Anweisung nicht mehr sehen
darf) und stuerzte danach ab: 2 Pruefungen statt 56. Der Absturz hat
verdeckt, dass sie sieben Fingerziele als "zu klein" meldete -- es
waren die unsichtbaren Knoepfe der zugeklappten Woche, 0x0.
* personen.html beim Manager: Der Erklaersatz ("Codes, Sperren und das
Protokoll bleiben bei DogFather") kam nie an -- das Element gab es
nicht, und das && davor hat den Fehlgriff verschluckt. Die Liste stand
ausserdem dauerhaft auf aria-busy="true": fuer einen Screenreader lud
die Seite fuer immer.
* pruef-schranke hielt personen.html noch fuer DogFather-only. Die Seite
wechselt jetzt die Erwartung, statt aus der Pruefung zu verschwinden:
Seite auf fuer die Leitung, Verwaltungsdaten dahinter weiterhin zu.
Die Anmeldeseite wurde nicht angefasst (nur ihr Versionsstempel).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
e8478c9cae |
Spicy sieht DogFathers Sachen nicht mehr -- und sechs Fehler dazu
VIER DINGE AUS DEN BILDSCHIRMFOTOS, jedes ein echter Fehler:
1. SPICY MEDIA SAH DOGFATHERS DATEN. Beim ersten Anlauf bekam die Rolle
dieselbe Regel wie DogFather (`1=1`) -- damit stimmte der Ueberblick
ueber Manager, Scouts und Creator, und nebenbei standen seine eigenen
Termine, Aufgaben, Dateien und Eintraege mit drin. Jetzt gibt es
ohneDogFather() als EINE Stelle dafuer: Zwei Spalten werden geprueft,
`creator_id` (um wen geht es) und `erstellt_von` (wer hat es
geschrieben) -- ein Termin, den er sich selbst anlegt, haengt nur an
der zweiten. `IS NULL OR NOT IN` und nicht bloss `NOT IN`: In SQL ist
`NULL NOT IN (...)` weder wahr noch falsch, die Zeile fiele
stillschweigend heraus.
2. "PERSOENLICHER ZUGANGSCODE · undefined" auf der Anmeldeseite. Eine
zweite Namensliste im Browser, die beim Hinzufuegen der Rolle
niemand gepflegt hat. Ein unbekannter Schluessel faellt jetzt auf
sich selbst zurueck statt auf `undefined` -- haesslich, aber
sichtbar.
3. SPICY KAM NICHT IN DIE PERSONENVERWALTUNG. Der Server liess sie
herein, das Skript warf sie wieder hinaus: zwei Listen fuer dieselbe
Frage, gepflegt wurde nur die erste.
4. DIE ANMELDEKARTE WAR ZU KLEIN FUER FUENF ROLLEN. Der Kommentar an
genau dieser Stelle warnt woertlich davor -- und ich habe getan,
wovor er warnt: eine Rolle eingefuegt und die Zahl daneben nicht
angefasst. Gemessen: Inhalt 573 px in einer 526 px hohen Tafel, die
Fusszeile stand unter dem Rahmen. Schrift kleiner half nicht (sie lag
schon auf dem Anschlag), also sind die Abstaende an neun Stellen
enger. Nachgemessen auf fuenf Groessen: passt ueberall.
DIE ZEIT WAR WIRKLICH FALSCH. Nicht nur in meinem Satz: `datum()` in
personen.js schnitt die ISO-Zeichenkette ab -- und die ist UTC. Im
Protokoll stand 03:00, wo 05:00 war. Das Tueckische daran ist, dass es
nie kaputt aussieht: Eine Uhrzeit ist immer plausibel.
PROFILBILDER WERDEN JETZT GEZEICHNET. Der Server lieferte sie seit
gestern mit, gezeichnet wurden sie nirgends -- deshalb aenderte sich
nichts. Jetzt in der Personenauswahl (Aufgaben, Termine, Dateien,
Bereiche), in der Gespraechsliste und an jeder Nachricht. Der
Anfangsbuchstabe bleibt als Unterlage LIEGEN: Faellt das Bild aus, steht
dort weiter etwas Sinnvolles.
DER CHAT: Gesichter mit Rollenfarbe, Blasen mit Richtung (die erste
einer Folge eckig, die naechsten rund -- so sieht man, wo ein Gedanke
anfaengt), das offene Gespraech mit Schiene, Ungelesenes hervorgehoben,
und das Eingabefeld in einer eigenen Leiste, die sich beim Schreiben
hebt.
ZWEI EIGENE PATZER, beide von Pruefungen gefunden:
- `o is not defined`: Mein Suchmuster hat die zwei Zeilen fuer das
Bild ans DATEIENDE gesetzt statt in die Schleife -- und in
kalender.js an einen <span> statt ans <option>. Gemeldet von
pruef-sicht, das die Browserkonsole mitliest.
- Ein Kommentar mit `bild` in schraegen Anfuehrungszeichen stand INNEN
in einer Vorlagenzeichenkette und hat sie geschlossen. Die halbe SQL
wurde zu Programmtext.
Dazu: `.chat-neu` gibt es nicht (heisst `.chat__eingabe`), und der
Rollenknopf hatte fuer den Manager keinen sichtbaren Fokus -- ein
box-shadow wird von `overflow: hidden` abgeschnitten, ein outline nicht.
Gruen: spicy (43), creator-anlegen (29), personen-liste (33), sicht (48),
chat (48), chat-optik (24), buehne (38), struktur (32), css-klassen (15),
handy (59), breiten (23), formulare (19), start-ansicht (136),
lesbarkeit (14), barrierefrei (18), tempo (8), kopf-messen (3),
glocke (26), haerte (20), manager-sicht (43), alle-wege (19),
aufgabenbrett (44), kalender (84).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
3b356d6eef |
Ein Material fuer die ganze Website -- und die Uhr wird zum Chronographen
DIE UHR: Sekunde nach AUSSEN, Minute in die Mitte, Stunde nach innen (Wunsch Filipe). Das ist die Anordnung eines Chronographen und nicht die eines Fortschrittsbalkens: Der schnellste Zeiger laeuft auf der laengsten Bahn, weil man Bewegung dort am besten sieht -- der langsamste innen, wo eine kleine Drehung viel bedeutet. Die drei Umfaenge sind mitgewandert; ein vertauschter Ring ohne vertauschte Zahlen endet nie dort, wo er soll. EIN MATERIAL FUER ALLE SEITEN. Die Startseite hatte seit heute beleuchtete Platten, die anderen sechzehn Seiten flache Rechtecke -- man wechselte die Seite und fiel aus einer Oberflaeche in eine andere. Ich habe das bisher Seite fuer Seite nachgezogen, und genau deshalb war es nie fertig: Es sind FUENFUNDVIERZIG Stellen. Jetzt EINE Regel. Die Klassenliste ist nicht erfunden, sondern gemessen -- es sind genau die, die `var(--flaeche)` als Kartenflaeche benutzen. `:where()` ist der Kniff dabei: Spezifitaet null, also ueberschreibt die Regel nichts, was eine Seite selbst festlegt. Eine Warnkarte bleibt rot, eine Spalte behaelt ihre Statusfarbe. Ohne das haette ich an dreissig Stellen `!important` gebraucht. DREI FUNDE DER PRUEFUNGEN, alle berechtigt: 1. `.profil-gruppe` gibt es nicht -- ich hatte den Namen aus dem Kopf geschrieben statt aus der Datei. pruef-struktur meldete totes CSS. Die Karten auf profil.html heissen `.gruppe`, und genau der Name darf NICHT in die Liste: Auf der Startseite heissen die Kachelgruppen ebenso und haetten ploetzlich eine Kartenflaeche. 2. Der erste Verlauf war HELLER als das, was er ersetzt. Ein Material, das die ganze Website aufhellt, hellt auch jeden Text darauf auf -- und das faellt an der leisesten Schrift zuerst auf. 3. `.gruppe__unter` stand auf 4,21:1. Und das ist der interessante Fall: Die Farbe war nicht schuld, eine VERSCHIEBUNG war es. Mit der fuenften Rolle rutschte auf personen.html alles eine Zeile nach unten, und die Zeile landete auf einer helleren Stelle des Buehnenbilds. Sie ist die einzige Beschriftung ohne Karte -- ein Text, dessen Untergrund ein FOTO ist, bekommt nicht den leisesten Ton. Jetzt 5,51:1. Der zweite Fund fiel nur auf, weil die Zahl sich nach meiner ersten Korrektur KEIN Stueck bewegte (zweimal exakt 4,21) -- dasselbe Zeichen wie schon zweimal heute: falsche Stelle, nicht zu wenig. Gruen: buehne (38), css-klassen (15), struktur (32), handy (59), breiten (23), start-ansicht (136), lesbarkeit (14), tempo (8), personen-liste (33). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
68bc116c36 |
Die Rolle "Spicy Media" -- und drei Fehler, die nur ihre Pruefung fand
DIE PERSONENTABELLE WURDE NEU GEBAUT. Eine Rolle ist ein erlaubter Wert in einer Spalte, und der steckt in einem CHECK -- den kann SQLite nicht aendern. Auf `personen` zeigen ZWEIUNDFUENFZIG Fremdschluessel. Deshalb wird der Bauplan NICHT abgeschrieben, sondern gelesen: Der CREATE-Text kommt aus sqlite_master, darin wird ausschliesslich die Rollenliste ersetzt, und die Kopierliste kommt aus PRAGMA table_info. Die beiden aelteren Umstellungen schreiben ihre Spalten von Hand ab -- `personen` hat seit damals SIEBEN dazubekommen (bild, ueber_mich, tiktok ...). Wer hier abschreibt, verliert alle Profilbilder. ZWEI FRAGEN, DIE MAN AUSEINANDERHALTEN MUSS: siehtAlles() = DogFather ODER Spicy Media -> Listen, Uebersichten istDogFather() = nur DogFather -> loeschen, Rollen, Codes Es waere weniger Arbeit gewesen, istDogFather() um "spicy" zu erweitern -- und genau das waere der Fehler: Spicy Media koennte dann DogFather loeschen. DER CHAT BRAUCHTE NICHTS. Er haengt allein an der Teilnehmerliste und kennt kein "das Management sieht alles". Spicy Media sieht fremde Gespraeche nicht, weil es dafuer keinen Weg gibt -- nicht, weil eine Abfrage es verbietet. DREI ECHTE FEHLER, alle von pruef-spicy gefunden, keiner vorher sichtbar: 1. MEIN EIGENER KOMMENTAR STAND IM BAUPLAN. SQLite hebt den CREATE-Text woertlich auf, samt Kommentaren. Ich hatte "'spicy' steht HIER mit drin" hineingeschrieben -- und die Erkennung suchte genau dieses Wort im ganzen Text. Ergebnis: Die Umstellung hielt die Tabelle fuer erledigt, obwohl die CHECK-Regel noch die alte war. Jetzt wird die Regel herausgeschnitten und NUR darin gesucht; der Kommentar steht ausserhalb des SQL. 2. DER SICHERUNGSNAME HATTE NUR MINUTEN. `VACUUM INTO` weigert sich, eine vorhandene Datei zu ueberschreiben -- zu Recht. Zwei Umstellungen in derselben Minute wollten in dieselbe Datei, die zweite scheiterte, und weil ohne Sicherung nicht umgestellt wird, blieb sie aus. Es sah nach "lief" aus (die Datei lag ja da) und war keine. Jetzt mit Sekunden. 3. EINE FRISCHE DATENBANK LEGTE DIE ALTE ROLLENLISTE AN und stellte beim allerersten Start sofort um -- Tabelle neu bauen, Sicherung schreiben, fuer nichts. Ein Bauplan, der sofort umgebaut werden muss, ist der falsche. Und ein vierter in der Pruefung selbst: Der Chat-Aufbau benutzte einen falschen Weg, das Gespraech entstand gar nicht -- "Spicy Media sieht 0 Gespraeche" war trotzdem gruen, weil es keine gab. Jetzt ist das Anlegen selbst eine Pruefung, und eine Gegenprobe zeigt, dass Max es sehr wohl sieht. DAZU: Manager sehen die Kachel "Personen & Zugaenge" -- die SEITE geht auf, die Schnittstellen nicht. Alles unter /verwaltung haengt weiter an `nurAdmin` und antwortet 404; sie sehen genau den Teil, fuer den es einen Weg gibt. Spicy Media legt Creator UND Manager an (zweite enge Tuer, Rolle steht auch dort nicht im Aufruf; ein Manager kommt durch sie nicht). Der Rollentext des Managers stimmte nicht mehr -- er legt jetzt Creator an. pruef-spicy: 36 Pruefungen, alle gruen. Ausserdem gruen: personen-liste (33), creator-anlegen (29), sicht (48), css-klassen (15), alle-wege (19), haerte (20), manager-sicht (43). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
4bb5afc942 |
Drei Ringe, klappbare Gruppen -- und die Calls-Seite endlich wirklich umgebaut
DU HATTEST RECHT (Bildschirmfoto 3). Beim letzten Mal habe ich an der Calls-Seite nur das MATERIAL der Karten getauscht und die Aufstellung gelassen. Drei Gruppen untereinander, und weil "Steht an" 27 Eintraege hat, lagen die beiden anderen ausserhalb des Bildes -- man SAH die Aenderung gar nicht, weil man nie so weit kam. Das war Lackieren, kein Umbauen. JETZT EIN BRETT AUS ZWEI SPALTEN. Die Gruppen sind eigenstaendige Tafeln in einem Raster; "Protokoll fehlt" (kurz, dringend) und "Festgehalten" (Archiv) liegen NEBEN der langen Liste statt darunter. `align-items: start` ist dabei der Punkt: Ohne ihn waeren alle Tafeln so hoch wie die hoechste, und neben der langen Liste stuenden zwei fast leere Kaesten. Welche Tafel wo landet, entscheidet die Breite und nicht das Skript -- eine festgeschriebene Spalte waere eine Zahl, die beim naechsten Fenster falsch ist. Jede Tafel klappt zu, und der Zustand wird gemerkt. Vorgabe: "Festgehalten" ist zu -- es ist das Archiv; wer die Seite oeffnet, will wissen, was ansteht. DIE GRUPPEN AUF DER STARTSEITE genauso. Der Kopf IST der Schalter, nicht ein Dreieck daneben: Die ganze Zeile ist ein Ziel von 40 Pixeln statt eines von vierzehn. <button> statt <div>, damit Tastaturbedienung und Ansage nicht mit tabindex und role nachgebaut werden muessen. Gemerkt wird je Gruppe UND je angesehener Rolle -- DogFather, der sich einen Creator ansieht, hat dort eine andere Aufteilung im Kopf. DIE UHR: drei Ringe statt zwei. Aussen die Stunde in Schwarzsilber, in der Mitte die Minute in Blau, innen die Sekunde in Rot -- von aussen nach innen immer schneller, so liest man eine Uhr ohne nachzudenken. UND SIE IST SCHARF. Kein blur(), kein drop-shadow mehr auf den Boegen -- an der alten lag beides drauf, und der Vorwurf stimmte. Der Glanz kommt jetzt aus dem VERLAUF: Echtes Metall glaenzt nicht, weil es leuchtet, sondern weil es das Licht abwechselnd hell und dunkel zurueckwirft. Fuenf Stopps statt zwei -- ein zweifarbiger Verlauf waere ein Farbverlauf, erst der Wechsel ist Metall. Dazu `shape-rendering="geometricPrecision"` (sonst rastert der Browser duenne Boegen grober) und Kappen auf `butt` statt `round`: Eine runde Kappe steht ueber das Ende hinaus, bei null Sekunden saehe man trotzdem einen Punkt. Minute und Stunde laufen WEICH mit: die Minute bekommt die Sekunden anteilig, die Stunde die Minuten. Ein Minutenring, der einmal pro Minute springt, sieht aus wie eine haengende Anzeige. Gruen: css-klassen (15), call-kategorien (17), start-ansicht (136), handy (59), breiten (23), buehne (38), struktur (32). NOCH OFFEN: der neue Kachelstil fuer die ganze Website und die Rolle "Spicy Media". Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
49bd4a7cec |
Manager legen Creator an -- eine neue Tuer statt eines Schluessels fuer die alte
Filipe: "wieso greift das in die rechte rein? ist doch ok, die sollen einfach paar leute selber hinzufuegen koennen." Er hat recht, und ich hatte zwei Dinge in einen Topf geworfen: Das hier braucht KEINE Datenbankaenderung -- nur die Rolle "Spicy Media" braucht eine. WARUM EIN EIGENER WEG UND NICHT DIE ALTE TUER Alles unter /workspace/api/verwaltung haengt an EINER Schranke (nurAdmin). Dahinter liegen acht Wege: Rollen aendern, Codes neu setzen, sperren, loeschen, Protokoll lesen. Einen Manager dort hineinzulassen und danach in jedem der acht einzeln zu pruefen, was er darf, ist genau die Bauweise, durch die am 31.08.2026 ein Loch entstanden ist -- zwei von drei Stellen abgesichert, die dritte vergessen. Deshalb bleibt die Tuer zu, und daneben steht eine neue mit genau einem Zweck: POST /workspace/api/creator-anlegen. Sie kann nichts anderes, als einen Creator anzulegen -- nicht weil eine Abfrage es verbietet, sondern weil es hier keinen anderen Weg gibt. Unterschied zwischen "darf nicht" und "kann nicht". DIE ROLLE STEHT NICHT IM AUFRUF, sie wird im Server gesetzt. Ein Feld `rolle` im Koerper waere die naheliegende Loesung und die falsche: Dann muesste eine Abfrage sie pruefen, und eine vergessene Abfrage ist ein zweiter Zugang mit vollen Rechten. Geprueft wird deshalb nicht, dass ein mitgeschicktes `rolle: "admin"` abgelehnt wird, sondern dass es WIRKUNGSLOS ist. DIE ZUTEILUNG PASSIERT SOFORT. Ein Creator ohne Betreuung ist fuer alle ausser DogFather unsichtbar -- der Manager haette ihn angelegt und danach nicht mehr gesehen. Wer anlegt, betreut; ein eigener Scout kann mitgegeben werden. Eine FREMDE Scout-Nummer wird abgelehnt (403) und nicht stillschweigend auf den Anleger zurueckgesetzt: Sonst glaubte der Manager, er haette zugeteilt. Der Knopf sitzt auf dem Dashboard, nicht in der Personenverwaltung -- dort kommt ein Manager gar nicht hinein, und hier sieht er seine Creator ohnehin. Der Zugangscode steht einmal im Dialog und wird nie nachgeladen; deshalb schliesst sich das Fenster NICHT von selbst. pruef-creator-anlegen.mjs, 29 Pruefungen, alle gruen -- und die Haelfte davon prueft, was NICHT geht: Personenverwaltung 404 fuer Manager, Scout und Creator kommen gar nicht erst durch, fremder Scout 403 (und der Creator wird dabei gar nicht erst angelegt), erfundene Nummer 403. Zwei Manager mit je einem eigenen Scout, weil sich "nur die eigenen" mit nur einem Manager gar nicht pruefen laesst. Nebenbei: .feld-hinweis ist von bereich.css nach aufgaben.css gewandert (zu den uebrigen Formularstilen) -- ein Formularbaustein in der Bereichsdatei ist nur so lange richtig, wie ihn keine zweite Seite braucht. Gruen: creator-anlegen (29), personen-liste (33), css-klassen (15), struktur (32), formulare (19). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
4447a653e7 |
Die Uhr wird ein Gegenstand -- Rot x Babyblau, und start.css wird geteilt
DIE UHR. Filipe: "viel viel viel viel viel viel viel spezieller ... eine
mischung von rot und babyblau". Was eine Uhr teuer aussehen laesst, ist
nicht die Farbe, sondern das GEHAEUSE -- bei einer echten sieht man drei
Schichten uebereinander: einen Metallrand, der das Licht von oben faengt,
eine VERTIEFTE Scheibe darin, und ein Glas darueber, das spiegelt. Genau
die drei sind jetzt gebaut.
Die beiden Farben sind nicht aus dem Farbkasten: Rot ist Spicy Media,
Babyblau ist DogFather -- dieselben zwei, die im Kopf der Anmeldekarte
nebeneinanderstehen und im Motiv den Neonrahmen bilden. Zwei Verlaeufe,
absichtlich GEGENLAEUFIG (Stundenring rot->blau, Sekundenring blau->rot):
Wo der eine warm ist, ist der andere kuehl, so bleiben sie
auseinanderzuhalten, wo sie sich ueberlagern.
Dazu: eine Skala aus sechzig Strichen, jeder fuenfte kraeftiger (aus
einem Kegelverlauf, nicht aus sechzig Elementen); ein leuchtender Kopf,
der am Ende des Sekundenbogens mitlaeuft -- die einzige Stelle, an der
sich sichtbar etwas bewegt; und die Mischung IM Text als zwei Schatten
statt als Verlaufsschrift (background-clip: text waere im Windows-
Kontrastmodus unsichtbar). Die Glocke bekommt dasselbe Gehaeuse, nur
kleiner -- zwei runde Dinge aus verschiedenem Material sehen
zusammengesucht aus.
PROFILBILDER: /api/personen lieferte nur id, name, rolle. Deshalb konnte
KEINE Oberflaeche ein Gesicht zeigen, auch wenn eines hochgeladen war --
der Fehler lag nicht in der Anzeige, sondern in der Schnittstelle.
Jetzt kommt die fertige Bildadresse mit (nicht der Dateiname: sonst
setzt jede Stelle im Browser denselben Pfad zusammen). Und DogFather ist
fuer alle sichtbar -- Name, Rolle, Bild, sonst nichts; seine Eintraege,
Chats und Zahlen haengen weiter an den eigenen Regeln der Module.
start.css GETEILT statt gekuerzt. Sie lief mit 202 KB wieder in die
200-KB-Grenze, und diesmal war Kuerzen die falsche Antwort: Dreizehn
Seiten laden diese Datei, Uhr und Begruessungskachel braucht genau EINE.
Also heim.css -- 184 KB statt 202, und zwoelf Seiten laden 14 KB
weniger. Vorher mit grep nachgesehen, dass `uhr`, `willkommen` und
`glocke-platz` in keiner anderen HTML-Datei vorkommen.
ZWEI FUNDE DER PRUEFUNGEN, beide berechtigt:
- `.glocke--kachel` musste zurueck nach start.css. glocke.js laeuft auf
ALLEN siebzehn Seiten und kann die Klasse ueberall setzen; die Regel
gehoert dorthin, wo das Skript sie brauchen KANN, nicht dorthin, wo
es sie heute zufaellig braucht.
- Die Sekundenanzeige stand auf 10,88 px (Grenze 11,5). Gesperrte
Ziffern in Versalhoehe wirken kleiner als die Zahl sagt -- auf
11,84 px.
Gruen: css-klassen (15), struktur (32), sicht (48), buehne (38),
start-ansicht (136), handy (59), aufgabenbrett (44).
NOCH OFFEN aus derselben Nachricht: die Calls-Seite komplett umbauen mit
Auf-/Zuklappen ueberall, die Profilbilder auch WIRKLICH ueberall
zeichnen (die Daten sind jetzt da), die Rolle "Spicy Media" und
Manager-legt-Creator-an.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
8f8c283a1a |
Kacheln werden ein Raster -- dritter Anlauf, diesmal die FORM
Filipe zweimal davor: "das ist genau das gleiche" und "sorry aber ich glaub du verstehst nicht was ich meine". Er hatte beide Male recht, und ich weiss jetzt warum: Ich habe zweimal die OBERFLAECHE geaendert (Mattglas, dann Leuchtschiene) und beide Male die FORM gelassen -- eine breite Zeile, Zeichen links, Text daneben. Wer eine Zeile umlackiert, bekommt eine lackierte Zeile. AUS DREI BREITEN ZEILEN WIRD EIN RASTER AUS SECHS KARTEN. Hochformat, Zeichen oben, Name unten, Schiene von links nach OBEN gewandert (an einer hochkanten Karte wuerde ein Lichtbalken links sie optisch halbieren). Die Zahl steht als Marke oben rechts statt in der Namenszeile, der Pfeil unten rechts. `data-gross="ja"` behaelt das Querformat -- so hebt sich die Kachel WIRKLICH ab, statt nur breiter zu sein. Bei 1380 px passen jetzt sechs Karten nebeneinander statt drei. BILDER: Kontrast 1,08 -> 1,14, Saettigung 1,10 -> 1,26, Glanz 0,34 -> 0,46, dazu ein neuer Durchgang "Tiefe" -- eine S-Kurve auf der Helligkeit. Das ist NICHT mehr Kontrast: Kontrast dehnt alles gleich und frisst Zeichnung in den Lichtern; die S-Kurve laesst die Mitte in Ruhe (dort sitzt das Motiv) und arbeitet nur an den Enden. Gerechnet auf dem Maximum der drei Kanaele, nicht je Kanal -- sonst wandert der Farbton (ein dunkles Rot wuerde braun). ANMELDESEITE: "Dogfather Universe" -> "SpicyMedia x DogFather" (das Kreuz kleiner und leiser, sonst liest man drei Namen statt zwei), und der Satz darunter nennt jetzt Manager, Scouts und Creator von Spicy Media -- ohne DogFather. ZAHLEN nur noch fuer DogFather. Beides zusammen, nicht nur die Kachel: Eine Kachel ist ein Weg, keine Schranke -- wer die Adresse kennt, waere weiterhin hineingekommen. Also auch in der Rechteliste auf ["admin"]. AUFGERAEUMT, weil pruef-struktur zu Recht rot wurde: start.css lief mit 202 KB in die 200-KB-Grenze. Der Grund war echter Ballast -- die Datei trug DREI Generationen Kacheldesign uebereinander. Die ueberholten Regeln sind weg (nur was der neue Entwurf nicht selbst setzt, bleibt), der Entwurfstext dazu auf seine Lehre gekuerzt. 198,7 KB, und wichtiger: nur noch EINE Stelle, an der eine Kachel beschrieben wird. Gruen: buehne (38), css-klassen (15), leistung (50), start-ansicht (136), handy (59), breiten (23), struktur (32). NOCH OFFEN aus derselben Nachricht: die neue Rolle "Spicy Media" und die Aenderung, dass Manager Creator anlegen duerfen. Beides greift in die Rechte und in die CHECK-Regel der Personentabelle ein -- das kommt als eigener Schritt mit Sicherung und eigener Pruefung, nicht nebenbei. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
1b2874299e |
Uhr und Glocke in die Begruessung, Teilen in die Leiste, ein echter Fehler weg
Neun Punkte aus Filipes Bildschirmfotos. Der wichtigste war kein
Aussehen, sondern ein Fehler:
UEBEREINANDERLIEGENDE TEXTE IN DER SICHERUNGSLISTE. Das Datum entstand
aus `name.split('-').slice(1).reverse().join('.')`. Bei
"woechentlich-2026-09-06.db" ging das gut; die Sicherungen vor einem
Umbau heissen aber "vorher-2026-09-02-160012438.db" -- mit Zeitstempel.
Heraus kam "160012438.02.09.2026", dreimal so lang wie die 96-px-Spalte,
und es lief ueber den Nachbartext. Ein Muster, das Bestandteile ZAEHLT
statt sie zu SUCHEN, bricht beim ersten Namen mit einem Teil mehr. Jetzt
ein Suchmuster nach vier-zwei-zwei Ziffern -- und in der CSS eine
Kuerzung, damit der NAECHSTE zu lange Text nur abgeschnitten wird. Eine
Spalte mit fester Breite ohne Kuerzung ist immer eine Zeitbombe.
DIE BEGRUESSUNGSKACHEL. Runde Digitaluhr rechts: zwei Ringe um dieselbe
Mitte -- innen die Sekunde, aussen der Stand der Stunde. Kein
setInterval(1000): Ein fester Takt laeuft mit der Zeit aus dem Tritt und
ueberspringt Sekunden; gewartet wird bis zur naechsten VOLLEN Sekunde.
Die Glocke ist aus der Kopfleiste hierhergezogen -- mit Rueckfall, denn
zwoelf andere Seiten haben diesen Platz nicht. Nebenbei ist die Leiste
damit um ein Element leichter; sie ist am 06.09. schon einmal an einem
sechsten zerbrochen.
TEILEN-KNOPF in der Leiste, nur fuer Scout, Manager und DogFather.
Geteilt wird der EINGANG, nicht die aktuelle Seite: Ein Link auf
bereich.html?b=schutz schickt jemanden auf eine Seite, die er nicht
sehen darf. Wo es navigator.share gibt, wird es benutzt; sonst
Zwischenablage; wo beides fehlt, erscheint der Knopf gar nicht -- ein
dritter Ausgang statt einer Schaltflaeche, die nichts tut.
WEITER: Kachelreihenfolge Steckbrief -> Profile -> Zahlen. Die
Tagesliste laesst sich zuklappen und zeigt dann SIEBEN Tage (die Woche,
nicht die vier von ueberall sonst). Dialoge, Automationen-Karten,
Sicherungsblock, KI-Kasten und Call-Karten bekommen dasselbe Material
wie die Kacheln -- Leuchtschiene, Materialstaerke, Glanz.
Profilbilder brauchten nichts: Der Weg gibt es fuer jede Rolle bereits
(steckbrief.html fuer die Betreuung, derselbe Block auf profil.html fuer
Creator, Hochladen schreibt immer auf req.person.id).
ZWEI EIGENE FEHLER, beide gemessen statt vermutet:
- Die Koernung lag in vier neuen Bloecken auf DERSELBEN Ebene wie die
Spiegelung und erbte deren 50 % Deckkraft. Gemessen rgb(56,44,58)
statt rgb(20,26,38) -- die Karten sahen durchsichtig aus, obwohl sie
zu 95 % decken. Derselbe Fehler wie heute Nachmittag an der
Anmeldekarte. Koernung gehoert auf eine eigene Ebene mit overlay.
- `.glocke-platz:empty { display: none }` liess die Kachel wachsen,
sobald die Glocke geladen war. Layout-Sprung von start.html: 0,708.
Platz wird jetzt reserviert -> 0,473.
pruef-struktur: `-breit` gehoert in die Stufen-Ausnahme. Schaerfe kostet
Bytes (hohe Frequenzen lassen sich nicht wegrechnen), die mittlere Stufe
wuchs auf 230-300 KB. Die Regel bleibt inhaltlich: gross nur, WENN eine
kleinere Stufe daneben steht. Die Verkettung der beiden replace() waere
ein stiller Fehler gewesen -- fuer uhd haette sie nach `-schmal` gesucht.
Gruen: kopf-messen (3), breiten (23), glocke (26), css-klassen (15),
struktur (32), buehne (38), start-ansicht (136), handy (59),
formulare (19), barrierefrei (18), lesbarkeit (14), tempo (8).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
8efdb39ce9 |
Kein Weichzeichner mehr -- die Bilder werden scharf, die Kacheln Lampen
Filipe: "gerade sehen die sogar leicht verschwommen aus ... die sollen
nicht durch die kacheln gehen ... ich wollte eine krasse aenderung."
Drei Ursachen, alle drei von mir eingebaut, alle drei gemessen:
1. ICH HABE 1647-PIXEL-BILDER ALS "uhd" MIT 2400 PIXELN AUSGELIEFERT.
Am Morgen stand in derselben Datei, sein Schirm sei 2550 px breit und
das groesste Bild 1600 -- meine "Loesung" war, die Ausgabe
hochzurechnen. Es gab nie mehr Bildpunkte. Dazu fehlte der Schritt,
den der Kommentar daneben selbst verlangt ("Verkleinern MITTELT
Bildpunkte ... deshalb schaerft man danach nach"): Es wurde nie
nachgeschaerft. Jetzt Unscharfmaske auf der ENDgroesse
(Ausgabeschaerfung) und ein Glanz-Durchgang: die hellsten Stellen
weich gezeichnet und additiv dazu -- Licht, das ueber seine Kante
strahlt. Guete 0,80 -> 0,88, am Gate 0,93.
2. backdrop-filter: blur() UNTER JEDER FLAECHE. 16 px unter siebzehn
Kacheln, 13 px unter sieben weiteren Flaechen, 26 px unter der
Anmeldekarte. Ein Weichzeichner mittelt nicht nur, was hinter dem
Element liegt -- er zieht seinen Radius weit darueber hinaus. Hinter
der Anmeldetafel ist Schwarz, direkt daneben aber die hellste Stelle
des Motivs: Die Karte wurde deshalb GRAU, gemessen rgb(46,57,64)
statt rgb(15,22,34). Je schoener der Rahmen, desto grauer die Karte.
Alle Weichzeichner raus, --flaeche 0,78 -> 0,89: Durchsicht bleibt,
aber scharf.
3. DIE TAFELMESSUNG WAR FALSCH, UND ICH HABE SIE VON HAND "KORRIGIERT".
Sie lief vom Inneren nach aussen und hielt beim ersten farbigen Punkt
an -- links glueht der Rahmen breiter als rechts, also hielt sie dort
frueher an (58,59 statt 55,37). Statt den Messfehler zu beheben, habe
ich in der CSS "um 1,1 % nach links" geschaetzt. Ergebnis: 32 px
schwarze Tafel blieben links offen. Jetzt wird die einzige
Eigenschaft gesucht, die nur der Rahmen hat -- kraeftig UND farbig --,
mit Gegenprobe auf der linken Bildhaelfte (dort muessen es 0 sein).
KACHELN: keine Politur mehr, ein anderes Ding. Jede steckt in einer
LEUCHTSCHIENE ihrer Kategoriefarbe, die Licht in die Platte wirft --
links scharfe Kante, rechts rund. Steiler Abfall (52 % statt 68 %):
beleuchtet, nicht eingefaerbt. Der Glanz wandert beim Ueberfahren
einmal durch. Dieselbe Sprache auf der Anmeldeseite: die vier Rollen
sind Tasten in Schienen (Gold/Bernstein/Gruen/Blau).
Zwei eigene Fehler nebenbei, beide durch das Unveraenderlichkeits-
Zeichen gefunden -- eine Zahl, die sich nach einer Aenderung KEIN Stueck
bewegt, sagt "falsche Stelle", nicht "zu wenig":
- Dreimal exakt 4,16:1 an "Ueberfaellig". Der Pruefpunkt lag nicht auf
dem Knopf, sondern in der Luecke daneben auf dem Bild. Ursache war
das hellere Hochkant-Bild, nicht das Bedienelement -> mehr Schleier
und weniger Glanz NUR fuer die Handy-Fassung. 4,16 -> 5,10.
- Die Koernung der Anmeldekarte lag mit 90 % Deckkraft ohne Mischmodus
ueber allem und hob jeden Bildpunkt um 30 Stufen. Jetzt 4 % mit
overlay, auf eigener Ebene.
- --flaeche anzuheben machte die WICHTIGE Anleitung duenner als eine
gewoehnliche (88 gegen 89) -- feste Zahl neben beweglicher Groesse.
Gefunden von pruef-lesbarkeit, jetzt an --flaeche gebunden.
Gruen: buehne (38), start-ansicht (136), handy (59), breiten (23),
lesbarkeit (14), css-klassen (15), barrierefrei (18), tempo (8).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
947c9d8a26 |
Agentur: Eintraege gehoeren allen -- und Events bekommen ein eigenes Formular
Gemessen am 07.09.2026, bevor irgendetwas geaendert wurde: Von drei Agentur-Eintraegen sah eine Creatorin genau EINEN -- den, der ihr zugeordnet war. Ein Event fuer alle traf weder `creator_id = ich` noch `erstellt_von = ich`; die Agentur-Seite war fuer jeden Creator leer. Nicht kaputt, nicht fehlerhaft: leer, so wie eine Seite aussieht, auf der noch nichts steht. Die Pruefung dazu war gruen. Sie legte ihre Testeintraege mit `creator_id: idLuna` an und pruefte damit einen Fall, den es im Alltag nicht gibt. - Bereichseinstellung `fuerAlle` + `ohneCreatorBezug`, daraus abgeleitet sichtbarEintrag(). BEWUSST neben sichtbar() statt darin: an derselben Funktion haengen Aufgaben, Dateien, Termine und Calls -- wer dort "1=1" einschleust, gibt nebenbei fremde Akten frei. Eine Gegenprobe mit einer zweiten Creatorin haelt das fest. - Die Zuordnung bietet nur noch "Agentur" an. Der Server verwirft eine Zuordnung ausserdem selbst -- inklusive des frei getippten Namens, und zwar NACH externPruefen: davor haette der Name den Riegel wieder aufgemacht. - "Event & Kampagne" heisst jetzt "Agentur-Events" und hat ein eigenes Formular: Von/Bis, Titel, Beschreibung, Aufgaben (Punkte und Preise), Regeln. Die Karte zeigt den Zustand als WORT (laeuft bis / startet / vorbei seit), nicht nur als Farbe. - Drei neue Spalten -- und sie stehen auch im Tabellenneubau vom 06.09. Der laeuft NACH dem Spaltennachtrag und haette sie samt Inhalt weggeworfen, ohne Fehler und mit stimmender Zeilenzahl. - Creator sehen weiterhin alles und tragen weiterhin nichts ein (403). Die Unterzeile sagt jetzt "alles, was hier steht" statt "alles, was zu dir gehoert" -- eine vollstaendige Liste soll sich nicht wie ein Ausschnitt lesen. pruef-agentur: 61 Pruefungen (vorher 40), alle gruen. Zwei eigene Fehler nebenbei gefunden und behoben: eine Beschriftung mit 11,2 px (Grenze 11,5) und ein Testdatum aus UTC statt Ortszeit. Zusaetzlich gruen: css-klassen, struktur, formulare, barrierefrei-workspace, handy. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
3914adf46c |
Material statt Farbe -- Kacheln werden Gegenstaende, die Karte ein Bildschirm
Filipe: "ich will dass alle kacheln viel geiler und spezieller aussehen,
viel realistischer" und "so dass der komplette von der kachel vom
hintergrund bild komplett bedeckt ist. ueberrasch mich."
DIE BILDER: BEARBEITET STATT ABGEDUNKELT.
Bis hierher tat der Bildbauer zwei Dinge -- kleiner rechnen und einen
schwarzen Schleier darueberlegen. Abdunkeln macht ein Bild aber nicht
ruhiger, sondern TOT: Es zieht jede Farbe zur Mitte, und uebrig bleibt
ein grauer Schleier mit einer Ahnung von Motiv.
Drei Dinge, die ein Fotograf zuerst anfasst, und keines davon ist
"dunkler":
* KONTRAST -- Verkleinern MITTELT Bildpunkte; deshalb wirkt jedes
verkleinerte Bild flauer als das Original, und deshalb schaerft man
danach nach.
* SAETTIGUNG -- holt das Rot der Chili und das Gruen der Blaetter
zurueck, die der Schleier herausgewaschen hatte.
* VIGNETTE -- der eigentliche Unterschied zwischen "Screenshot" und
"Aufnahme". Ein Objektiv verliert zu den Ecken hin Licht; das Auge
liest das als Tiefe. Sie ersetzt ausserdem einen Teil des flachen
Schleiers: Dunkel wird, wo ohnehin nichts steht.
Der flache Schleier sinkt dadurch von 0,42 auf 0,26 -- heller UND
lesbar, weil die Vignette genau dort arbeitet, wo die Kacheln liegen.
DIE KACHELN: VIER DINGE, DIE EIN DING VON EINEM RECHTECK TRENNEN.
Sie hatten Farbverlauf, Lichtkante und ein Licht, das dem Zeiger folgt --
und blieben Rechtecke mit Farbe darin. Es fehlten:
1. GEWICHT. Ein Ding, das auf etwas liegt, wirft einen Schatten, auch
wenn es niemand anfasst. Den gab es nur beim Ueberfahren.
2. MATERIALSTAERKE. Ein Blech hat oben eine Licht- UND unten eine
Schattenkante. Nur die obere ergibt einen aufgeklebten Strich.
3. KOERNUNG. Perfekt glatte Verlaeufe kommen in der Natur nicht vor,
und das Auge merkt das, ohne es benennen zu koennen. Drei Prozent
Rauschen genuegen -- aus einem SVG-Filter als Adresse, also ohne
Datei und ohne zusaetzliche Anfrage.
4. DURCHSICHT. Hinter den Kacheln liegt jetzt ein aufwendiges Bild.
Eine deckende Flaeche verdeckt es, eine mattierte nimmt seine Farbe
auf -- erst dadurch gehoeren beide zusammen.
Beim Ueberfahren wird die Kachel nicht heller, sondern kommt NAEHER:
Sie steigt, ihr Schatten wird groesser und weicher (der Abstand zum
Untergrund waechst). So verhaelt sich ein angehobener Gegenstand.
DIE ANMELDEKARTE: EIN GERAET STATT EINES BILDES AN DER WAND.
Sie sass mit Abstand in der gemalten Tafel -- zwei Rahmen ineinander,
dazwischen schwarze Leere. Jetzt geht sie bis unter das Gluehen des
Neonrahmens: Der Rahmen ist das Gehaeuse, die Karte der eingeschaltete
Bildschirm. Sie leuchtet von den Kanten herein in den Farben des Rahmens
(rot oben links, blau unten rechts), traegt eine Glasscheibe als sehr
schwache Spiegelung und dieselbe Koernung. Die Rollen sind Tasten
geworden: Materialstaerke oben hell, unten dunkel, beim Druecken sinken
sie ein, und die gewaehlte ist beleuchtet statt eingefaerbt.
Alle Angaben bleiben -- vier Rollen mit Beschreibung, Codefeld, Auge,
Rollenhinweis, Fusszeile. "Hochwertiger" heisst nicht "weniger drin".
EIN ECHTER FUND DABEI: --text-still lag ploetzlich bei genau 4,50:1
statt der noetigen 4,5. Der Ton war am 01.09. gegen die DAMALIGE,
dunklere Buehne gemessen. Wer den Hintergrund heller macht, muss die
leiseste Schrift nachziehen -- sonst haette man den Aufwand auch lassen
koennen. Erkannt daran, dass die Zahl sich bei zwei Schleier-Aenderungen
NICHT bewegte: Die Pruefung rechnet mit der CSS-Farbe.
Gemessen statt angesehen: Kontrast an echten Bildpunkten (pruef-buehne),
neun Bildschirmbreiten, drei Handygroessen, Ladezeit und Datenvolumen,
Klassen, Struktur, Startseite -- alles gruen. Die Seiten ueber dem
CLS-Zielwert sind nebenbei von sieben auf vier gesunken.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
8107b97379 |
Die Kopfleiste wuchs beim Laden um vier Pixel -- und schob die Seite
Beim Messen des Datenvolumens nach dem Bildumbau fiel etwas anderes auf: Der Layout-Sprung auf der Startseite lag bei 0,99. Die Bilder waren es nicht -- ein Hintergrundbild liegt `position: fixed` und bewegt gar nichts. Die Meldung sagte es selbst, man musste nur hinsehen: ALLES sprang um denselben Betrag (295->301, 144->150, 685->692, 605->611). Wenn die ganze Seite gleichmaessig nach unten rutscht, waechst etwas ueber ihr. Gemessen: Leiste vor dem Skript 67 px, danach 71. Der Sicht-Umschalter kommt erst, wenn die Personenliste geladen ist, und ist mit 42 px das hoechste Teil in der Reihe. Vier Pixel -- man sieht sie kaum und merkt sie doch: Wer beim Laden schon zielt, klickt daneben. Die Loesung ist keine reservierte Hoehe auf Verdacht, sondern die Hoehe, die die Zeile ohnehin haben muss: `min-height: 44px`. Das ist das Mindestmass fuer ein Fingerziel (WCAG 2.5.8) und gilt hier sowieso fuer jedes Teil. Damit ist die Zeile immer so hoch wie ihr groesstes zulaessiges Element -- unabhaengig davon, ob dieses gerade schon da ist oder erst kommt. Ergebnis: 0,99 auf 0,60, und die Zahl der Seiten ueber dem Zielwert von zwoelf auf sechs. Datenvolumen unveraendert in Ordnung trotz der groesseren Bilder -- der Browser holt je Seite nur eine Stufe. Und der offene Punkt von vorhin ist geklaert: pruef-browser laeuft gruen durch, alle vier Maschinen (Chromium, Firefox, WebKit, WebKit auf dem iPhone), 64 Seitenaufrufe, 15898 Elemente. Der eine rote Punkt im Gesamtlauf war eine Zeitueberschreitung unter Dauerlast -- erkennbar daran, dass ZWEI Pruefungen gar nicht gelaufen waren und die Datei die doppelte Zeit brauchte. Eine gesunkene Anzahl ist ein eigener Befund. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
accf01b5d6 |
Sieben Motive statt einem -- und Bilder, die nicht mehr hochgerechnet werden
Filipe: "die grafik soll viieeeel besser aussehen bitte. die hintergrund
bilder sollen viel hochwertiger und spezieller aussehen."
DIE URSACHE WAR NICHT DIE BILDGUETE, SONDERN DIE GROESSE.
Sein Bildschirm ist 2550 px breit, das groesste ausgelieferte Bild war
1600 -- der Browser rechnet es also um das 1,6-fache hoch. Jede Kante
wird dabei weich, gleichmaessig ueber das ganze Bild. Genau das sieht
man als "billig", ohne benennen zu koennen, warum. Eine hoehere
WebP-Guete haette daran nichts geaendert: Man kann keine Bildpunkte
zurueckholen, die nie ausgeliefert wurden.
Anmeldeseite: jetzt 960 / 1280 / 1600 / 1920 / 2560, Guete 0,88.
Buehnen: jetzt 2400 (uhd) / 1600 (breit) / 900 (schmal).
Ueber srcset bzw. eine Fenstergroesse laedt trotzdem jeder nur die
Stufe, die er braucht -- ein Handy weiterhin 32 KB.
UND NEUN BUEHNEN ZEIGTEN DASSELBE BILD.
In start.css standen neun Regeln, eine je Szene -- alle zeigten auf
dieselbe Datei. Die Zuordnung war seit dem 01.09. richtig gedacht und
seit dem 03.09. wirkungslos. Aufgefallen ist es niemandem, weil jede
Seite fuer sich stimmig aussah; man merkt es erst, wenn man zwei
nebeneinander haelt. Jetzt hat jede Gruppe ihr eigenes Motiv, und die
Zuordnung folgt dem, was auf der Seite passiert:
studio Startseite Chili-Wasserfall, "More Than Media"
showbuehne Dashboard, Reports Spiegelkabinett -- viele auf einmal
portal LIVE, Content Splash mit IDEAS / BRAND / CONTENT
garage Aufgaben, Technik Kohle und Glut, Werkstatt
arena Dateien, Wissen Medaillon-Sammlung, ein Archiv
halle Profile, Schutz dieselbe Sammlung -- Personen, nicht
Betrieb
wald Start-Check, Scout roter Ahorn, etwas das waechst
skyline Kalender Podest unter dem Mond
lounge Calls, Chat dieselbe Nachtbuehne, ruhig
Sieben Motive auf neun Plaetze; die zwei Paare sind inhaltlich
benachbart und liegen nie nebeneinander auf einer Seite.
ABDUNKLUNG 0,42 -- gemessen, nicht uebernommen. Beim Tresorbild hatte
ich 0,62 aus den alten Szenen uebernommen, und uebrig blieb ein Schemen.
pruef-buehne rechnet den Kontrast an echten Bildpunkten nach: 4,69 bis
7,14 gegen die noetigen 4,5, an bis zu 28 Stellen je Seite.
Die Groessenpruefung in pruef-struktur bekommt eine begruendete Ausnahme
fuer GESTUFTE Bilder: Bei einer Datei, von der der Browser immer nur
eine von drei Stufen holt, misst eine feste 200-KB-Grenze das Falsche.
Sie gilt unveraendert fuer alles andere -- und die Ausnahme prueft
zusaetzlich, dass die kleineren Stufen wirklich existieren, damit sie
niemand als Schlupfloch benutzt.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
44b3290bc5 |
Die Kopfleiste: nicht die dritte Zahl, sondern gar keine
BEFUND. Der Gesamtlauf war nach dem Bildumbau bei SIEBZEHN Dateien rot,
pruef-handy allein mit 37 Fehlern. Alle mit derselben Meldung:
"ueber=126px". Eine Ursache, siebzehnfach gezaehlt.
Sie war meine. Um den Layout-Sprung bei 1280 px zu beheben, hatte ich
den Umbruch der aeusseren Leiste wieder auf "nur unter 380 px" gestellt
-- und damit bei 390 und 412 px genau das Loch aufgerissen, das ich
Stunden vorher geschlossen hatte. Dieselbe feste Schwelle von 380, ueber
die zwei Commits vorher eine Regel in CLAUDE.md gewandert ist.
DREI ANLAEUFE, und die ersten beiden waren Symptomkur:
1. `flex: 0 0 auto` fuer die Bedienelemente -> 126 px Ueberstand bei
412 px (sie koennen weder schrumpfen noch umbrechen).
2. Hoher Schrumpf-Faktor am Schriftzug (220 gegen 1) -> besser, aber
von 19 fehlenden Pixeln nahmen die Knoepfe 0,19, und die runden auf
1 auf. Ein Pixel, und die Gruppe brach um. Ich habe daraufhin die
Abstaende verkleinert; danach war es wieder genau ein Pixel. Wer an
einem Rundungsfehler schraubt, hat die falsche Stellschraube.
3. RICHTIG: dem Schriftzug gar keine Wunschbreite geben.
`flex: 1 1 0` heisst "ich beanspruche nichts und nehme, was uebrig
bleibt". Damit entsteht ueberhaupt kein Fehlbetrag, der verteilt
werden muesste. Kein Schrumpf-Faktor, keine Schwelle, nichts zu
runden. Dazu `max-width: max-content`, sonst zieht `flex-grow` die
Marken-Pille ueber die ganze Leiste (990 statt 375 px) -- wovor der
Kommentar zwei Zeilen darueber ausdruecklich warnt und was ich beim
Umbau uebergangen habe.
Gemessen ueber neun Breiten: 1920 bis 768 einzeilig (71 px), 412 und 390
zweizeilig (127), 320 dreizeilig (167). Ueberstand ueberall null. Und der
Layout-Sprung von 0,94 ist damit auch weg -- er kam aus derselben Ecke.
Dabei drei weitere echte Fehler gefunden, alle in Neuem von heute:
* Der Namenslink in der Fruehwarnung war 22x25 px -- unter dem
Mindestmass von 24x24 (WCAG 2.5.8). Bei kurzen Namen trifft man
daneben. Jetzt ein echtes Fingerziel mit negativem Aussenabstand, der
die Polsterung optisch wieder aufhebt.
* Die Warnkarten standen bei 320 px 9 px aus dem Bild:
`minmax(320px, 1fr)` begrenzt die Spalte, nicht ihren Inhalt. Erst
`min(320px, 100%)` PLUS `min-width: 0` PLUS umbrechender Kopf loesen
es -- einzeln keines davon. Die Schreibweise stand zwei Abschnitte
weiter oben laengst richtig da.
* Der Zurueck-Link im Schriftzug ragte aus seinem Kasten:
`overflow: hidden` schneidet nur die ANZEIGE ab, der Link behaelt
seine Layoutbreite. Bei 768 px lag sein Mittelpunkt unter den
Bedienelementen -- ein Klick dorthin traf das Falsche, auf 17 von 18
Seiten, und zu sehen war davon nichts.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
aa1d05a5c0 |
Neues Anmeldebild -- die Karte sitzt IN der gemalten Tafel
Filipe: "integriere die zugangskachel links nach rechts und passe sie
perfekt an damit sie in dem neuen bild rechts perfekt und die
vorgemachte kachel passt."
Das neue Motiv (Spicy Media x DogFather) hat rechts eine leere Tafel mit
Neonrahmen. Die Anmeldekarte sitzt jetzt DARIN -- und zwar wirklich
darin, nicht ungefaehr in der Gegend.
DAS PROBLEM, DAS MAN LEICHT UEBERSIEHT: Das Bild liegt mit
`object-fit: cover` unter der Seite; je nach Fensterform schneidet der
Browser oben/unten oder links/rechts etwas ab. Ein `left: 58%` bezieht
sich aber auf das FENSTER. Auf genau einer Bildschirmgroesse saehe es
richtig aus und ueberall sonst falsch. Deshalb rechnet `.tafel-anker`
dieselbe Cover-Formel noch einmal nach und ist damit deckungsgleich mit
dem Bild -- Prozentwerte darin sind Prozent DES BILDES.
Die vier Zahlen sind GEMESSEN (tools/gate-bauen.mjs), nicht geschaetzt.
Zwei Anlaeufe standen daneben und haben sich selbst verraten:
1. "Suche den leuchtenden Rahmen" fand den Mond, die roten Blueten und
jede Spiegelung -- Ergebnis: die ganze rechte Bildhaelfte. Eine
Messung, die das Offensichtliche zurueckgibt, hat nichts gemessen.
2. "Suche die groesste dunkle Flaeche" fand die Breite richtig, aber
94 % Hoehe: Ueber und unter der Tafel ist die Szene genauso
schwarz.
Richtig ist der dritte Weg: vom Mittelpunkt der Tafel nach aussen
laufen, bis es hell ODER farbig wird -- auf diesem Weg liegt nichts
anderes, denn die Tafel ist leer. Danach eine Plausibilitaetspruefung,
die abbricht statt vier geratene Zahlen auszugeben.
DREI FEHLER IM EIGENEN ENTWURF, alle gemessen statt angesehen:
* Die Karte hing 300 px unter dem Bildschirmrand. Auf `.tafel` liegt
die Einblend-Animation, deren Endbild `transform: none` ist -- mein
`translateY(-50%)` war damit wirkungslos. Zwei Wege, dasselbe
Element zu verschieben, vertragen sich nicht.
* Der Anker lag 3 % neben dem Bild: Das Bild traegt `scale(1.03)` als
Reserve fuer die Parallaxe. Jetzt tragen beide dieselbe Verwandlung,
und die Parallaxe laeuft ueber zwei CSS-Groessen am <body> -- so
wandert die Karte mit, statt dass der Rahmen unter ihr wegrutscht.
* Der Hochkant-Ausschnitt zeigte die LEERE Tafel: ein schwarzes
Rechteck mit ein paar Saeulen. Auf dem Handy liegt die Karte ohnehin
davor; dort gehoert das Logo hin. Jetzt faellt der Schriftzug
SPICY MEDIA in den sichtbaren Streifen -- nachgerechnet, nicht
probiert.
STARTSEITE: das Tresorbild als neuer Hintergrund. Die uebernommene
Abdunklung von 0,62 war zu viel (der Tresor ist von Haus aus dunkel) --
uebrig blieb ein Schemen. Und der "Leseweg" verdunkelte ausgerechnet die
MITTE: Bei den alten Szenen stand dort nichts, beim Tresor steht dort
die Tuer. Beides korrigiert und mit pruef-buehne an echten Bildpunkten
nachgemessen.
DABEI GEFUNDEN, ohne Zusammenhang mit dem Bild: Der abgeschaltete
"Ueberfaellig"-Filter kam auf 4,05:1 statt 4,5:1. Die Deckkraft zu
erhoehen half nichts -- die Pruefung rechnet mit der CSS-FARBE und dem
gemessenen Bildpunkt dahinter, und ein `opacity` am Elternknopf aendert
die Farbe nicht. Die Zahl blieb dreimal exakt gleich; genau das war der
Hinweis. Jetzt ein eigener, hellerer Ton. Der Kommentar daneben sagte
ohnehin, was gewollt ist: Man SOLL sehen, dass es null sind.
Und die vier Regeln von heute stehen in CLAUDE.md.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
70039714c5 |
Die Sicherung war zwei Loecher gross -- gefunden, weil sie zum ersten Mal wirklich zurueckgespielt wurde
"Wir haben eine Sicherung" war bis heute ein Satz, kein Nachweis. Die
taegliche Kopie ausserhalb des Servers prueft `PRAGMA integrity_check`
und meldet seit dem 31.08. jeden Tag "in Ordnung". Das heisst: die Datei
ist nicht zerschossen. Es heisst NICHT, dass man damit weiterarbeiten
kann.
tools/wiederherstellung-proben.mjs geht den Weg jetzt wirklich: juengste
Sicherung in ein Wegwerf-Verzeichnis kopieren, die echte Anwendung
dagegen starten (damit laufen alle Schemawanderungen durch), vorher und
nachher zaehlen, anmelden, jede Seite aufrufen. Drei Ausgaenge, nicht
zwei -- "konnte nicht nachsehen" ist weder Erfolg noch Fehler.
BEIM ERSTEN LAUF BLIEB GENAU EINE VON ACHTZEHN SEITEN ROT: der
Steckbrief, mit einem 404 fuer ein Bild. Daran hingen zwei echte Luecken:
1. PROFILBILDER WAREN NIE GESICHERT. sicherung-holen.sh holte
dateien/ und wissen/ -- die Bilder liegen aber in einem dritten
Ordner (profilbilder/, siehe workspace-steckbrief.js). Nach einem
Plattenausfall waeren alle Profilbilder weg gewesen, waehrend die
taegliche Meldung weiter "in Ordnung" sagte. Sie hat ja nie
behauptet, vollstaendig zu sein.
2. DIE RUECKMELDUNG AN DEN SERVER LIEF INS LEERE. Das Skript meldete
sich bei dogfather-universe.com/workspace/... -- seit dem Umzug am
06.09. antwortet diese Adresse mit 410 "Gone". Der Server erfuhr
also seit dem Umzug nicht mehr, dass die Kopie laeuft; auf der
Automationen-Seite waere sie mit jedem Tag aelter erschienen,
obwohl sie taeglich lief. Ein 410 wird jetzt eigens gemeldet -- es
heisst etwas anderes als "Netz kaputt", naemlich "die Adresse
stimmt nicht mehr".
Beides behoben. Und damit es kein drittes Mal passiert, vergleicht die
Probe die Ordnerliste des Sicherungsskripts gegen die Ordner, die der
Server im Quelltext wirklich benutzt (`join(DATEN_ORDNER, "...")`). Wer
morgen einen vierten Datenordner anlegt und ihn nicht sichert, bekommt
hier einen Fehler statt eines stillen Lochs -- mit Gegenprobe, dass der
Vergleich einen fehlenden Ordner auch wirklich erkennt.
Ergebnis nach den Reparaturen: 18 Pruefungen, alle gruen,
"DIE SICHERUNG LAESST SICH ZURUECKSPIELEN." Der Lauf traegt sich mit
Datum in die Sicherungsablage ein -- sonst weiss beim naechsten Mal
niemand, wann zuletzt wirklich zurueckgespielt wurde.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
233cd76d78 |
Der Handy-Durchgang: drei echte Bedienfehler, alle vom selben Ursprung
Filipe: "ich will dass du die komplette seite auf dem handy abcheckst.
ich will dass alles perfekt aussieht und bedienbar ist."
DER SCHWERSTE FUND: Auf ZWOELF Seiten war der "Meine Sicht"-Umschalter
nicht bedienbar -- wer darauf tippte, landete im Chat.
Bei 412 px (der haeufigsten Android-Breite ueberhaupt) brach die
Kopfleiste nicht um, der Umschalter wurde auf 50 px zusammengedrueckt,
sein Knopf behielt aber seine 104 px Mindestbreite und lag damit quer
ueber dem Chat-Knopf. Sichtbar war davon nichts.
Und die Ursache steht seit dem 05.09. woertlich im Kommentar daneben:
"Die Rechnung ging genau auf, solange rechts VIER Dinge standen. Mit der
Glocke sind es FUENF, und bei 320 px passte es nicht mehr." Am 06.09.
habe ich den Chat-Knopf dazugesetzt -- SECHS -- und die Schwelle bei 380
gelassen. Derselbe Fehler, eine Position weiter.
Die Lehre ist nicht "380 auf 430 erhoehen"; das waere er ein drittes
Mal, nur mit einer anderen Zahl. Eine feste Schwelle ist eine Rechnung,
die jemand einmal aufgestellt hat und die beim naechsten Knopf still
falsch wird. `flex-wrap: wrap` OHNE Schwelle rechnet nicht, sondern
misst -- es bricht genau dann um, wenn der Platz nicht reicht.
DASSELBE NOCH EINMAL, am anderen Ende: Bei 1280 px brauchte die Leiste
1235 px (Marke 375 + Bedienelemente 844 + Abstand 16) und hatte 1200.
Auch hier war der Chat-Knopf der Tropfen. Sie brach um, sobald das
Skript die Bedienelemente eingehaengt hatte, und schob die ganze Seite
52 px nach unten -- CLS 0,94. Jetzt gibt die MARKE nach (sie darf
gekuerzt werden, ein Knopf nicht), und umgebrochen wird nur noch auf
sehr schmalen Geraeten.
WEITERE ECHTE FUNDE:
* /workspace/api/chat/ungelesen wurde auf JEDER Seite ZWEIMAL geholt:
einmal beim Laden, einmal Millisekunden spaeter beim Aufgehen des
Ereignisstroms. Der 'open'-Zuhoerer war fuer Wiederverbindungen
gedacht und feuerte auch beim ersten Mal.
* Drei Kacheln teilten sich einen Farbton mit einer anderen (18 Farben
auf 21 Kacheln). Filipe wollte ausdruecklich, dass jede ihre eigene
hat. Nicht eine Farbe dazuerfunden -- der ganze Farbkreis ist mit
tools/kachel-farben.mjs neu in 21 geteilt; kleinster Abstand zweier
Nachbarn jetzt 120 Grad (vorher 106). Dabei fiel eine feste 16 in
der Mischschleife auf: Bei 18 Kacheln wurden die letzten beiden nie
mitgemischt.
* Der Agentur-Untertitel wurde auf dem Handy abgeschnitten.
* Ein zugeklappter <details>-Kasten (Kalender-Abo) verdeckte einen
Filter-Chip: Chromium versteckt dessen Inhalt ueber
`content-visibility`, nicht ueber `display` -- die Kaesten behalten
eine Groesse. Dieselbe Falle wie bei den Zeitbloecken, dieselbe
Loesung.
UND DREI PRUEFUNGEN, DIE SELBST FALSCH LAGEN:
* "achtzehn Kacheln" stand als feste Zahl im Test. Eine Pruefung, die
bei jeder neuen Kachel rot wird, erzieht dazu, ihr Rotwerden zu
ignorieren. Sie zaehlt jetzt aus bereiche.js.
* "das Licht der Kalender-Kachel (tuerkis) muss mehr Blau als Rot
haben" -- Wissen von aussen, und nach dem Neurechnen war der
Kalender rosa. Gemessen wird jetzt gegen den Ton der Kachel selbst.
* pruef-workspace-umzug meldete sein Ergebnis in eigenen Worten. Der
Gesamtlauf las daraus NULL Pruefungen und schrieb bei JEDEM Lauf ein
FEHL, obwohl alle 31 Punkte bestanden. Ein Fehlalarm, der immer
kommt, macht den einen echten unsichtbar.
Und weil "BUTTON 'Meine Sicht' verdeckt" mich eine Stunde gekostet hat,
sagen pruef-handy und pruef-tempo jetzt DAZU, was verdeckt und was
springt -- mit Elternkette und Koordinaten. Ein Befund, den man nicht
verorten kann, ist ein halber.
NEU: der Kalender zum Abonnieren (Stufe 3.2). Persoenlicher, jederzeit
widerrufbarer Link fuer Google, Apple und Outlook. 36 Pruefungen, die
das ICS ZURUECKLESEN statt es anzusehen -- entfaltet, entschluesselt,
verglichen. Wichtigster Punkt: Der Weg ohne Anmeldung darf nichts
zeigen, was der Weg mit Anmeldung nicht zeigt.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
bede91921d |
Der sechste Bereich, und zwei Pruefungen, die den Lauf lahmgelegt haben
DER AGENTUR-BEREICH (Stufe 4 des Plans)
Kernprinzip 04 des Konzepts lautet woertlich "Die Agentur bleibt
angebunden" -- und dafuer gab es bis heute nichts. Fuenf Bereiche
standen, der sechste fehlte vollstaendig. Damit stand nirgends, welche
Kampagne laeuft, welche Schulung ansteht und wie ein Anliegen an die
Agentur ausgegangen ist. Das lief ueber private Nachrichten: nicht
auffindbar, nicht nachvollziehbar, beim naechsten Mal von vorn.
Vier Arten, und die vierte ist der Punkt: kampagne, schulung, anliegen
und ZUSTAENDIGKEIT. Die letzte ist keine Verlegenheit, sondern das, was
das Konzept ausdruecklich fordert -- Betreuung und Umsetzung sind unsere
Seite, offizielle Wege sind Agenturseite. Solange das nur im Kopf steht,
wird es bei jedem Streitfall neu verhandelt.
Der Umbau war das eigentliche Risiko, nicht der Bereich: Ein CHECK
laesst sich in SQLite nicht aendern, die Tabelle muss neu gebaut werden
-- und dabei werden ALLE vorhandenen Eintraege umgeschrieben. Deshalb
geht pruef-agentur.mjs (31 Pruefungen) den Weg wirklich: Sie baut eine
Datenbank im ALTEN Stand nach, fuellt sie mit allen fuenf Bereichen,
laesst die echte Anwendung darueberlaufen und zaehlt danach jede Zeile
UND jedes Feld nach -- auch die seltenen Spalten (hook, creator_extern),
die man beim Abschreiben des Bauplans vergisst. Wichtigste Gegenprobe:
Der CHECK muss danach noch BEISSEN. Eine Umstellung, die nebenbei die
Schranke entfernt, sieht aus wie ein Erfolg und ist der schlimmere
Ausgang.
Nebenbei drei abgeschriebene Bereichslisten beseitigt (Wochenbericht,
Suche, Report-Ziele). Im Wochenbericht waere der neue Bereich sonst
schlicht nicht vorgekommen -- ohne Fehler, ohne Luecke, einfach nicht da.
ZWEI PRUEFUNGEN, DIE DEN GESAMTLAUF ZUM STILLSTAND BRACHTEN
pruef-call-kategorien.mjs hing DREI STUNDEN. Ursache war ein Zeitzuender
in ihr selbst: Sie legte Calls auf "heute 18:00" und erwartete zwei
davon unter "Heute". Ab 18 Uhr sind die vorbei, der Server schiebt sie
nach "Protokoll fehlt", und die Oberflaeche unterteilt erst ab FUENF
anstehenden. Uebrig blieben vier, die Bloecke verschwanden, und die
Pruefung wartete auf einen Klick auf einen Block, den es nicht gab.
Genau die Sorte Fehler, vor der die Projektnotiz vom 06.09. warnt: Sie
war um 17:59 gruen und um 18:01 rot, ohne dass sich am Code etwas
geaendert hatte. Jetzt liegen alle Zeiten RELATIV zu jetzt, und die
Erwartung wird mit derselben Vorschrift gerechnet, die calls.js benutzt
-- statt Zahlen, die nur zu einer bestimmten Tageszeit stimmen.
Und der Grund, warum daraus ein Stillstand statt eines Fehlers wurde:
index.js setzt bewusst zwei Auffangnetze (uncaughtException,
unhandledRejection). Fuer den Betrieb richtig -- ein Fehler darf die
Website nicht offline nehmen. Fuer eine Pruefung fatal: Sie importiert
index.js in denselben Prozess und erbt die Netze. Ihr eigener Absturz
wird dann nur protokolliert, und der Express-Server haelt den Prozess
danach ewig am Leben. Kein Fehler, kein Ergebnis, kein Ende.
Deshalb zwei Abhilfen, die zusammengehoeren:
* server/helfer-notbremse.mjs -- haengt eigene Zuhoerer DANEBEN
(process.on ergaenzt, es ersetzt nicht) und beendet den Lauf mit
Fehler; dazu ein Wecker. In alle 42 Browserpruefungen eingebaut.
Der Betrieb bleibt unveraendert.
* tools/alles-pruefen.mjs gibt jeder Datei eine Frist von 600 s. Wer
sie reisst, wird abgebrochen und ZAEHLT ALS FEHLGESCHLAGEN, mit der
letzten Ausgabe davor als Beleg. Einzelne Dateien nachzuruesten hilft
nur bis zur naechsten ohne Notbremse -- deshalb sitzt sie dort, wo
sie fuer alle gilt, auch fuer die, die es noch nicht gibt.
AUSSERDEM: pruef-breiten.mjs pruefte 16 Seiten aus einer Liste von Hand,
chat.html und leistung.html fehlten darin. Der Chat war bei keiner
einzigen der neun Breiten je gemessen worden. Wie bei pruef-handy kommt
die Liste jetzt aus dem Verzeichnis.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
80a8aac774 |
Der ganze Prueflauf blieb am Chat-Strom stehen -- behoben
BEFUND. Seit der Chat am 06.09. dazukam, LIEF DER GESAMTE
REGRESSIONSLAUF NICHT MEHR DURCH. Nicht "er wurde rot" -- er blieb
einfach stehen, bei Datei 3 von 62, ohne Fehlermeldung, ohne FEHL, ohne
Absturz. Nach zwoelf Minuten stand er immer noch dort. Von aussen sieht
"noch nicht fertig" genauso aus wie "haengt fuer immer"; deshalb ist
mir das gestern nicht aufgefallen, sondern erst, als ich den Lauf
gezielt beobachtet habe.
DIE URSACHE. pruef-alle-wege.mjs geht stumpf ueber ALLE 134
Schnittstellen und liest jede Antwort mit `await a.text()` aus. Der
Chat haelt seine Verbindung aber absichtlich offen und schickt neue
Nachrichten hinein, solange jemand zusieht (SSE). `text()` wartet, bis
der Server fertig ist -- und der wird nie fertig. Angemeldet als
DogFather trat der Lauf dort ein und kam nicht wieder heraus.
DIE ABHILFE, zwei Teile, die zusammengehoeren:
* Jeder Ruf hat jetzt eine Frist von 8 s. Laeuft sie ab, ist das ein
ERGEBNIS ("hing") und kein Absturz. Ein neuer Abschnitt meldet am
Ende, WELCHER Weg nicht geantwortet hat -- statt dass der Lauf
wortlos stehenbleibt.
* Bekannte Stroeme stehen in einer Liste MIT BEGRUENDUNG und werden
nicht uebersprungen, sondern anders geprueft: verbinden, Status
ablesen, abbrechen. Die Schranke wird damit genauso gemessen wie
ueberall. Zusaetzlich wird nachgemessen, dass ein eingetragener
Strom auch wirklich offen bleibt -- sonst verdeckte die Ausnahme
nur seine Inhaltspruefung.
Der "hing"-Zustand musste eigens gesammelt werden: In Abschnitt 1 haette
er ausgesehen wie "ohne Anmeldung erreichbar", in Abschnitt 2 waere er
ganz durchgefallen (`"hing" >= 500` ist false, Zeichenkette gegen Zahl).
Genau so verschwinden Befunde.
Ergebnis: 134 Schnittstellen, 532 Aufrufe, alles gruen, kein Haenger.
AUSSERDEM, gefunden beim Nachsehen:
* pruef-handy.mjs pruefte 15 Seiten -- aus einer Liste von Hand, die
veraltet war. chat.html, leistung.html und steckbrief.html standen
nicht darin: DREI von neunzehn Seiten waren nie auf einem Handy
gemessen worden, ausgerechnet der Chat. Die Liste kommt jetzt aus
dem Verzeichnis, die naechste neue Seite ist von selbst dabei.
* chat.html und leistung.html fehlte <link rel="manifest">. Auf dem
Handy heisst das: Wer die App installiert hat und ueber eine
Benachrichtigung dort landet, verlaesst den App-Rahmen -- die Seite
oeffnet im Browser, mit falscher Leistenfarbe. Ihre theme-color war
ausserdem eine andere als auf allen uebrigen Seiten. Beides behoben
UND als Pruefung in pruef-struktur nachgetragen, damit es beim
naechsten Mal nicht am Gedaechtnis haengt.
NEU: tools/wiederherstellung-proben.mjs — die Probe aufs Exempel.
Die Sicherung ausserhalb des Servers laeuft taeglich und prueft
`integrity_check`. Das sagt: die Datei ist nicht zerschossen. Es sagt
NICHT, ob die Anwendung damit startet, ob man sich anmelden kann und ob
die Daten vollstaendig sind. Eine Sicherung, die man nie zurueckgespielt
hat, ist eine Hoffnung. Das Werkzeug kopiert die juengste Sicherung in
ein Wegwerf-Verzeichnis, startet die echte Anwendung dagegen (damit
laufen alle Schemawanderungen wirklich durch), zaehlt vorher und
nachher, meldet sich an und ruft jede Seite auf. Drei Ausgaenge, nicht
zwei -- "konnte nicht nachsehen" ist weder Erfolg noch Fehler.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
953c3f5721 |
Zahlen bekommen eine Oberflaeche, das Dashboard bekommt Zahlen
Der Server konnte seit gestern rechnen -- und niemand konnte etwas
eintragen. Ein Rechenwerk ohne Oberflaeche ist kein Modul, sondern ein
Versprechen. Das ist jetzt eingeloest:
* leistung.html: Wochenkarten (Wert, Vergleich zur Vorwoche,
Verlaufslinie), Ziele als Fortschrittsbalken, die letzten 14 Tage
zum Eintragen -- auch die LEEREN, denn eine Luecke ist selbst die
Auskunft. Import aus dem TikTok-Export mit Vorschau VOR dem
Schreiben.
* Kachel "Zahlen" als erste der Gruppe "Rund um den Creator", eigenes
Zeichen (steigende Linie, kein zweites Balkendiagramm).
* Dashboard: jede Creator-Karte traegt jetzt Diamanten, LIVE-Tage und
Verweildauer. Bis heute zeigte sie ausschliesslich ARBEIT -- ein
Creator konnte null ueberfaellige Aufgaben haben und gleichzeitig
seit drei Wochen einbrechen, und die Karte sah tadellos aus.
* Die Fruehwarnung steht oben im Dashboard. Sechs benannte Signale im
Klartext mit Beleg, bewusst OHNE Punktzahl -- ein Wert wie
"Abwanderungsrisiko 73" klingt nach Wissenschaft und ist eine
Behauptung, der man nicht widersprechen kann.
* chat.html?mit=<person>: der Weg von der Warnung ins Gespraech. Gab
es vorher nicht; ein Hinweis ohne Weg dahin ist nur ein schlechtes
Gewissen.
GEFUNDEN VON DEN PRUEFUNGEN, nicht von der Theorie:
1. Die Verlaufslinie zeichnete fuer vier der sieben Groessen NICHTS.
Der Server liefert im Verlauf nur drei Reihen; fuer den Rest kam
undefined an. `=== null` faengt das nicht, Number(undefined) ist
NaN, und ein <polyline points="NaN,NaN"> ist im DOM vorhanden und
auf dem Bildschirm unsichtbar -- ohne Fehlermeldung. Die Pruefung
misst deshalb die PUNKTE, nicht die Anwesenheit des Elements.
2. Fuenf Schriftgroessen im CHAT lagen unter 11,5 px (.68/.7 rem) und
waren seit vorgestern drin. Die Grundlinie der Groessenpruefung
stand auf 43, gemessen wurden 48. Nicht die Grundlinie angehoben,
sondern die fuenf Stellen behoben: Eine Grundlinie, die mitwaechst,
ist keine mehr.
pruef-leistung-optik.mjs: 57 Pruefungen, zwei echte Browser, Gegenprobe
zu jeder Aussage -- auch dazu, dass die Vorschau vor dem Bestaetigen
wirklich noch nichts geschrieben hat und dass ein Creator seine Zahlen
zwar SIEHT, sie aber weder eintragen noch die Fruehwarnung ueber sich
lesen kann (auch nicht ueber eine von Hand gebaute Anfrage).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
c8a4e7628c |
Stufe 1+2: Zahlen ueber das Geschaeft, und eine Fruehwarnung
Der grosse Befund aus dem Plan vom 31.08.2026: Der Workspace organisiert ARBEIT hervorragend, wusste ueber das GESCHAEFT aber nichts. Keine Diamanten, keine LIVE-Tage, keine Verweildauer. Damit hing die ganze Betreuung in der Luft -- der Start-Check bewertete ohne zu messen, der Report fragte "was hat funktioniert" ohne Beleg, das 90-Tage-Ziel war ein Satz statt eines Fortschritts. STUFE 1 -- LEISTUNG Eine Zeile je Creator und TAG (nicht Woche: Feineres laesst sich immer zusammenfassen, Groeberes nie aufteilen). Diamanten, LIVE-Dauer, gueltiger Tag, Zuschauer im Schnitt und in der Spitze, Verweildauer, Schenker, neue Follower -- und eine NOTIZ. Ohne sie sieht man in drei Monaten einen Einbruch und weiss nicht mehr, dass die Person Grippe hatte. DIE VERWEILDAUER IST DIE LEITZAHL (Recherche 06.09.2026): 2026 haengt der Algorithmus alles an der Completion Rate, und sie gehoert als BETRIEBSkennzahl behandelt -- sie soll die naechste Runde steuern, nicht die letzte erklaeren. Jede Zahl kommt mit Vergleich, Verlauf und Einordnung. Eine Zahl ohne diese drei ist eine Eitelkeitszahl: Sie sieht nach Auskunft aus und ist keine, weil man nichts entscheiden kann. Zwei Wege hinein: Schnelleingabe und CSV-Import aus dem offiziellen Export, mit Vorschau vor dem Uebernehmen. STUFE 2 -- FRUEHWARNUNG Sechs benannte Signale (Zahlen fallen, LIVE-Tage brechen weg, lange nicht angemeldet, kein Gespraech, Aufgabenstau, Start-Check haengt) und daraus EIN ruhiger Satz: "Bei Nora wuerde ich diese Woche nachfassen." BEWUSST KEIN SCORE. Eine Note von 1 bis 100 wirkt objektiv und ist es nicht; sie verfuehrt dazu, Menschen nach einer Zahl zu behandeln. Am Score kann man nichts tun, am Signal schon. Deshalb Saetze statt Punkte, und jedes Signal einzeln nachvollziehbar. Ein CREATOR sieht die Fruehwarnung nicht: Das ist eine Arbeitsgrundlage fuer die Betreuung, keine Mitteilung an die betroffene Person. ZWEI ECHTE FEHLER, VON DER PRUEFUNG GEFUNDEN 1. ZAHLENFORMAT, Faktor tausend daneben. "1.250" wurde als 1,25 gelesen und "1,234" als 1,234. Die Regel "das letzte Trennzeichen ist das Dezimalzeichen" liefert bei nur EINEM Trennzeichen fuer beide Faelle das Falsche -- und die Zahl sieht danach trotzdem plausibel aus. Jetzt entscheidet, wie viele Ziffern dahinter stehen: genau drei heisst Tausendertrenner. 2. DIE ZIELE-ROUTE WURDE VERSCHLUCKT. Express nimmt die erste passende Route, und `:tag` passt auch auf "ziele" -- ein PUT auf .../ziele landete in der Tages-Route und scheiterte am Datumsmuster. Die Meldung sagte "ungueltig", was auf die Zahlen deutet, nicht auf den Weg. Reihenfolge getauscht. Beides waere still gewesen: falsche Zahlen sehen richtig aus, und ein Ziel, das sich nicht setzen laesst, probiert man zweimal und laesst es dann. pruef-leistung.mjs: 47 Punkte, darunter jede Rechnung einzeln nachgerechnet (Durchschnitte ohne Tage ohne Wert, Prozent von null, Wochengrenzen), Import zweimal eingelesen, deutsche und englische Zahlenformate, Rechte, und die Gegenprobe, dass die Fruehwarnung bei Unauffaelligkeit SCHWEIGT. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
17157b4f18 |
Sicht-Umschalter: ein Auge statt des Wortes "SICHT"
Filipe zu dem Feld in der Kopfleiste: "das soll viel besser aussehen
viel geiler aber nicht so eine scheisse."
Er hatte recht. Da stand ein Etikett mit dem Wort SICHT und daneben ein
Auswahlfeld -- ein Formular, das in die Kopfleiste gerutscht war. Drei
Aenderungen:
* DAS AUGE ersetzt das Wort. Es sagt dasselbe in einem Zeichen und
laesst dem NAMEN den Platz, um den es eigentlich geht. Fuer
Vorleseprogramme bleibt die Beschriftung erhalten, nur unsichtbar --
sie ersatzlos zu loeschen haette das Feld unbeschriftet gelassen.
* "Meine Sicht" statt "Alles (meine Sicht)". Der Zusatz erklaerte
nichts und machte den Knopf so breit, dass am Handy nichts anderes
mehr danebenpasste.
* EIN KREUZ statt "zurueck zu mir". Der Satz brauchte mehr Platz als
der Name daneben, und was ein Kreuz an einer aktiven Auswahl tut,
weiss jeder. Die Worte bleiben im aria-label und im Titel.
DIE EIGENTLICHE VERBESSERUNG ist aber die Hierarchie: Im Normalfall
ist der Umschalter still (graues Auge, ruhiger Rand). Sobald eine
FREMDE Sicht laeuft, traegt er ganz Farbe -- nicht nur ein
Zusatzknopf am Rand.
Das ist der gefaehrlichste Zustand dieser Funktion: Wer sie vergisst,
sieht am naechsten Tag drei Aufgaben statt dreissig und haelt das fuer
den Bestand. Ein Zustand, der Schaden anrichtet, muss lauter sein als
einer, der nichts tut.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
9dc35f5da6 |
Chat wieder einhaengen -- die Datei ist jetzt da
Nachtrag zu |
||
|
DogFatherGitandClaude Opus 5
|
686249e36c |
Und die restlichen 40 Pruefbilder
Der erste Durchgang hat nur 62 von 102 erwischt. Grund: Die Liste kam
aus `path: "..."` -- Bilder, deren Name aus einem Template-Literal oder
einer Variablen entsteht, standen nicht darin:
path: breite === 1440 ? "pruef-kalender-computer.png" : "…-handy.png"
path: `pruef-rollen-${r.rolle}.png`
Danach war die Kontrolle entscheidend, nicht die Erfolgsmeldung: "0
Pruefbilder versioniert" -- es waren noch 40. Wer nach einem
Aufraeumen nicht nachzaehlt, glaubt der Absicht statt dem Ergebnis.
Vor dem Entfernen noch einmal im GANZEN Repo geprueft (nicht nur in
server/ und tools/, wie beim ersten Mal): Kein readFileSync, kein
existsSync, kein readFile auf eine .png-Datei. Sie werden ueberall nur
geschrieben.
Kontrolliert danach: 0 Pruefbilder versioniert, QR-Codes weiterhin 3.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
1f4717d683 |
Bilder der Pruefungen aus der Versionierung nehmen
62 Bildschirmfotos, 54 MB, die bei JEDEM Prueflauf neu geschrieben
werden. Sie standen im Repo und tauchten dadurch bei jedem Commit als
Aenderung auf -- man haette sie mitcommittet oder jedes Mal von Hand
aussortiert. Beides ist Ballast, und beides passiert irgendwann falsch.
Sie bleiben auf der Platte und werden weiter erzeugt. Nur versioniert
sind sie nicht mehr.
GEPRUEFT VOR DEM ENTFERNEN: Keine einzige Pruefung LIEST je ein Bild --
kein readFileSync, kein existsSync auf .png; sie werden ausschliesslich
geschrieben. Es sind also Ansichtsbilder, keine Vergleichsvorlagen,
deren Verlust eine Pruefung blind machen wuerde. Waeren es welche,
duerften sie nicht weg.
UND EIN BEINAHE-FEHLER, der hier festgehalten gehoert: Der erste Anlauf
nahm "alle .png ausser workspace/assets und assets/img". In dieser
Liste standen assets/qr/qr-instagram.png und zwei weitere QR-Codes der
Website -- echte Dateien, die niemand neu erzeugt. Ein zu grobes Muster
haette sie mitgeloescht.
Die Liste kommt deshalb jetzt aus der Quelle statt aus einem Muster:
Was in einem `screenshot({ path: ... })` einer Pruefdatei steht, kann
weg. Alles andere nicht. Kontrolliert danach: QR-Codes (3) und
Website-Bilder (105) sind unveraendert versioniert.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
3bab6d9fbf |
Der Knopf auf der Umzugsseite ist jetzt ein echter Verweis
Hinweis von Filipe: Wenn etwas wie ein Knopf aussieht, muss man auch
draufdruecken koennen. Er hatte recht.
Meine urspruengliche Begruendung - die Adresse solle nur zum Lesen
dastehen, damit niemand versehentlich ein Lesezeichen auf den alten Weg
setzt - traegt nicht: Wer klickt, landet auf der NEUEN Adresse und setzt
sein Lesezeichen genau dort. Ein Element, das wie ein Knopf aussieht und
sich nicht wie einer verhaelt, ist eine Falle.
Der Knopf hat jetzt einen Hover- und einen Tastatur-Fokuszustand, und
beide Bewegungen entfallen bei prefers-reduced-motion.
Die Pruefung geht dabei einen Schritt weiter als vorher: Sie prueft nicht
mehr nur, WELCHE Anfragen zugeordnet werden, sondern ruft die Middleware
wirklich auf und sieht sich die ANTWORT an. Denn die Zuordnung kann
stimmen und die Seite trotzdem kaputt sein:
- ein Platzhalter, der woertlich in der Seite steht statt eingesetzt zu
werden
- ein Knopf ohne Verweis (genau der Fall, den Filipe gemeldet hat)
- HTML statt JSON fuer /workspace/api/ - ein noch offener Tab wuerde
sonst die Hinweisseite als Daten zu lesen versuchen
- und die wichtigste: dass die NEUE Adresse durchgelassen wird
31 Pruefungen, alle gruen. Gegenprobe gemacht: Dreht man den Knopf zurueck
zu einem div ohne Verweis, meldet die Pruefung 2 Fehler - sie haette den
gemeldeten Mangel also selbst gefunden.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
8e3eccc7a8 |
Alte Workspace-Adresse abgeschaltet statt weitergeleitet
Auf Filipes Wunsch: dogfather-universe.com/workspace/ soll nicht mehr existieren, er gibt den neuen Link selbst an Creator und Scouts weiter. Vorher stand dort eine Weiterleitung - die haette die alte Adresse auf unbestimmte Zeit am Leben gehalten. Der Server antwortet dort jetzt mit 410 Gone. Beides - 404 und 410 - heisst "gibt es hier nicht"; 410 sagt zusaetzlich "gab es, ist absichtlich weg, kommt nicht wieder". Genau der Sachverhalt. Suchmaschinen nehmen die Adresse dadurch schneller heraus, und in einem Protokoll ist ein 410 sofort als gewollt erkennbar, waehrend ein 404 immer nach Versehen aussieht. Statt einer nackten Fehlermeldung kommt eine kurze Hinweisseite mit der neuen Adresse. Wer hier landet, hat einen alten Link oder eine alte Verknuepfung und soll erfahren, wohin der Workspace gezogen ist, statt vor einem leeren Fenster zu sitzen. Bewusst OHNE Verweis zum Anklicken, damit niemand aus Versehen ein neues Lesezeichen auf den alten Weg setzt. Schnittstellen-Aufrufe unter /workspace/api/ bekommen JSON statt HTML - ein alter, noch offener Browser-Tab wuerde sonst die Hinweisseite als Daten zu lesen versuchen und einen unverstaendlichen Fehler zeigen. Die Pruefung deckt weiterhin 21 Faelle ab und ist mitgezogen: Der gefaehrlichste Fall heisst jetzt nicht mehr "Endlosschleife", sondern "die neue Adresse mit abschalten" - wer nicht auf den Hostnamen prueft, sperrt den Workspace fuer alle aus. Alle gruen, Gegenprobe schlaegt an. Diesmal vor dem Commit den Diff Datei fuer Datei kontrolliert - beim letzten Mal hatte ich hier eine fremde uncommittete Zeile mitgenommen und damit die Website fuer zwei Minuten abgeschossen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
09a4cfdeab |
AUSFALL BEHOBEN: versehentlich mitcommitteten Import zurueckgenommen
Die Website war ab 16:27 unerreichbar (HTTP 502, 29 Neustartversuche).
Ursache war mein Commit
|
||
|
DogFatherGitandClaude Opus 5
|
4637aa24e7 |
Chat zwischen Creator, Scouts und Managern
Wunsch Filipe, 06.09.2026: *"eine kategorie chat, wo die creator mit
ihren manager nachrichten austauschen koennen, wie erinnerungen, fragen
und noch vieles mehr."* Auf Nachfrage entschieden: Zweier-Gespraeche UND
Gruppen; Manager und Scouts duerfen sich auch ohne gemeinsamen Creator
schreiben.
WER MIT WEM steht an EINER Stelle: schreibbareIds() in workspace.js.
Bewusst getrennt von einladbareIds() (Terminwahl): Dort geht es darum,
wen man zu einem Kalendereintrag dazustellen darf -- harmlos. Ein Chat
legt ein dauerhaftes Gespraech an, schickt eine Benachrichtigung und
macht den eigenen Namen sichtbar. Zwei Fragen, zwei Funktionen.
Ein Creator erreicht seine Betreuer und DogFather, KEINEN fremden
Creator. Eine Gruppe ist kein Schlupfloch: Jede Nummer wird einzeln
gegen dieselbe Regel geprueft.
SOFORT STATT NACHFRAGEN IM TAKT (SSE). Ein Chat, der alle fuenf
Sekunden fragt, ist fuenf Sekunden langsam und stellt bei zehn
Angemeldeten 7200 Anfragen in der Stunde fuer Nachrichten, die es
meistens nicht gibt. Kein WebSocket: Hier fliesst alles in eine
Richtung, und SSE uebersteht einen Verbindungsabriss von selbst.
DIE ZAHL STEHT AUF JEDER SEITE, nicht nur im Chat. Eine Nachricht, die
man erst sieht, wenn man den Chat aufmacht, ist keine Nachricht --
sie ist ein Fundstueck.
Push aufs Handy nur an die, die NICHT gerade zusehen. Wer die Seite
offen hat, sieht es ohnehin; ihm zusaetzlich etwas aufs Handy zu
schicken ist der schnellste Weg, dass er Benachrichtigungen abschaltet.
WAS BEWUSST NICHT GEHT:
* Niemand liest fremde Gespraeche mit -- auch DogFather nicht. Ein
Chat, in dem der Chef stillschweigend mitliest, ist kein Chat.
Er kann jederzeit jedem schreiben, aber sichtbar.
* Eine abgeschickte Nachricht laesst sich nicht aendern, nur
zuruecknehmen. Wer Absprachen nachtraeglich umschreiben kann, macht
den Verlauf wertlos. Zurueckgenommenes hinterlaesst einen Hinweis
statt eines Lochs.
DAZU: CALL-LISTE NACH ZEIT GEGLIEDERT
Wunsch mit Bild von "STEHT AN 27": *"die liste soll kategorisiert sein
und werden mit einem button zum auf und zu machen."* Jetzt Heute /
Diese Woche / Naechste Woche / Spaeter, offen nur der erste gefuellte
Block. Nach ZEIT und nicht nach Titel: Auf dem Bild waren fast alle
"Community-Talk" -- nach Titel gruppiert haette man zwei Ueberschriften
und darunter dieselbe lange Liste.
DER FUND, DER DIE FUNKTION GERETTET HAT: Ein zugeklappter Block zeigte
seinen Inhalt trotzdem -- 367 Pixel Hoehe bei open=false. <details>
versteckt seinen Inhalt naemlich nur, solange niemand dem Inhalt eine
eigene display-Angabe gibt, und .gruppe__karten traegt display:grid.
Der Knopf haette sich bewegt und sonst nichts getan. Im Bildschirmfoto
fiel es nicht auf, weil der Ausschnitt genau darueber endete.
Ausserdem gefunden und behoben:
* Ein Wettlauf beim Abschicken: War der Ereignisstrom schneller als
die Antwort auf das POST, stand die eigene Nachricht zweimal im
Verlauf.
* Die Chatseite war zu hoch -- die Kopfleistenhoehe stand als fester
Wert (62 px) im CSS, am Handy ist sie doppelt so hoch. Das
Eingabefeld stand halb unter dem Bildschirmrand. Jetzt gemessen.
* Der Platzhalter "Enter schickt ..." brach am Handy um UND stimmte
dort nicht: Ohne Tastatur schickt Enter absichtlich nicht.
* Der Dialog benutzte Klassen aus aufgaben.css, das chat.html nicht
lud -- gemeldet von pruef-css-klassen, bevor jemand einen
ungestylten Dialog zu sehen bekam.
Pruefungen: pruef-chat (44 Punkte, Rechte und Sichtbarkeit),
pruef-chat-optik (24, zwei echte Browser schreiben sich),
pruef-call-kategorien (16).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
58b8ef233a |
Creator Workspace zieht auf eine eigene Adresse um
Der Workspace laeuft ab sofort auf workspace.dogfather-universe.com. Die
alte Adresse dogfather-universe.com/workspace/ leitet dorthin weiter.
Grund: Chrome laesst neben der Hauptseite, deren Bereich "/" die ganze
Domain umfasst, keine zweite App auf derselben Adresse zu. Unter dem alten
Pfad liess sich der Workspace nur als Verknuepfung ablegen, nie als
richtige App installieren - im Menue stand "Oeffnen in DOGFATHER
UNIVERSE" statt "Seite als App installieren". Das ist kein Fehler,
sondern Absicht (w3c/manifest Nr. 1180: verschachtelte Bereiche auf einem
Ursprung sind "strongly not recommended"). Auf der neuen Adresse hat
Filipe die App erfolgreich installiert.
Der PFAD /workspace/ bleibt erhalten. An ihm haengen 150 Server-Routen,
107 API-Aufrufe und 26 Server-Dateien - ihn wegzuschneiden waere ein
grosser Umbau ohne Gewinn, denn der Konflikt entsteht durch die
gemeinsame ADRESSE, nicht durch den Pfad. Dadurch musste am Code nichts
weiter geaendert werden.
Die Entscheidung steht in einer eigenen Datei (workspace-umzug.js), weil
sie zwei Stellen hat, an denen ein Denkfehler teuer waere und die man
einer Bedingung nicht ansieht:
1. ENDLOSSCHLEIFE - derselbe Dienst bedient beide Adressen. Ohne
Hostpruefung leitet die neue Adresse auf sich selbst, und der
Workspace waere sofort nach dem Neustart fuer alle unerreichbar.
2. PRAEFIX-IRRTUM - "faengt an mit /workspace" trifft auch
/workspaceXYZ und /workspace-alt.
Als eigene Funktion ist beides pruefbar, ohne den Server zu starten:
pruef-workspace-umzug.mjs deckt 21 Faelle ab (alte/neue Adresse, mit und
ohne www, Gross-/Kleinschreibung, Portangabe, lokale Testadressen, beide
Praefix-Fallen). Alle gruen. Gegenprobe gemacht: Baut man die
Endlosschleife absichtlich ein, meldet die Pruefung 3 Fehler; baut man den
Praefix-Irrtum ein, meldet sie 2. Sie kann also auch "nein" sagen.
Bewusst 302 und nicht 301: Ein 301 wird vom Browser dauerhaft gemerkt und
laesst sich praktisch nicht zurueckholen - waere an der Umleitung etwas
falsch, waere die alte Adresse fuer jeden, der sie einmal aufgerufen hat,
dauerhaft unbrauchbar.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
e0d8e6d55d |
Tagesblick: Termine als Karten, und vier Fehler, die dabei auffielen
Filipe zu der Liste mit einem einzigen Termin darin: "das soll viel
geiler und krasser aussehen bitte."
Er hatte recht, und der Grund war der Einzelfall. Ein Zeitstrahl lebt
davon, dass er etwas VERBINDET -- bei einem Eintrag verbindet er nichts.
Uebrig blieben eine magere Zeile, ein Strich ins Leere und Weissraum bis
zur Plakette am rechten Rand.
Jetzt traegt jede Karte fuer sich: eigene Flaeche mit farbiger Kante,
die Uhrzeit gross und in der Farbe der Terminart (vorher war sie
kleiner als der Titel -- dabei ist sie das, was man sucht), ein Balken
fuer die Dauer, und "JETZT" am naechsten Termin statt eines etwas
helleren Hintergrunds. Erledigtes bekommt einen Haken und verliert die
Farbe, bleibt aber voll lesbar; vorher wurde alles blasser, was auch
den Text traf.
Kein Neon dazu. Die Wirkung kommt aus Kontrast und Hierarchie.
VIER FEHLER, DIE DIE PRUEFUNGEN GEFUNDEN HABEN
1. ZEITZONE, in NEUN Pruefungen. Um 00:10 meldete pruef-teilnehmer
ploetzlich 13 Fehlschlaege an einer Datei, die seit Stunden niemand
angefasst hatte:
Ortszeit: 06.09.2026, 00:10
UTC: 05.09.2026, 22:10
Sie bildeten ihr Tagesdatum mit toISOString() -- also UTC -- legten
ihre Termine auf gestern und suchten heute. ZWEI STUNDEN AM TAG waren
sie damit rot, im Winter eine. Wer nur tagsueber laeuft, sieht das
nie. Jetzt gibt es helfer-zeit.mjs mit derselben Rechenweise wie die
Anwendung, und pruef-struktur sucht das Muster kuenftig automatisch.
2. MEIN UMSTELL-SKRIPT VERSAGTE STILL. Es pruefte
`if "helfer-zeit.mjs" not in s` -- und mein eigener Kommentar
enthielt den Dateinamen. Ergebnis: keine einzige der neun Dateien
bekam den Import, alle waeren zur Laufzeit abgestuerzt. `node --check`
findet das nicht. Aufgefallen, weil danach nachgezaehlt wurde statt
der Erfolgsmeldung zu glauben.
3. DIE KACHEL LIESS DIE SEITE SPRINGEN. Der Layout-Sprung auf
start.html stieg von 0 auf 0,96 -- zweimal bestaetigt. Sie erschien
erst nach dem Laden und schob alles darunter weg. Das ist kein
Schoenheitsfehler, sondern der Grund, warum man auf den falschen
Knopf drueckt.
Gemessen wurden die echten Hoehen (1 Termin 169 px, 3 → 327, 5 →
486). Daraus zwei Konsequenzen: Platz vorher reservieren, und
hoechstens DREI Termine zeigen -- das halbiert die Spanne und ist
die klarere Aussage. Der Rest steht als "1 weiterer Termin heute"
darunter, nicht stillschweigend abgeschnitten. Von 0,96 auf 0,163.
4. SCHRIFTGROESSE, zweimal am selben Tag: erst die Art-Plaketten mit
10,56 px, dann -- nach der Korrektur -- die neue Jetzt-Marke mit
10,88. Beide Male gemeldet von pruef-handy und pruef-grosscheck,
beide Male erst nach einem mehrminuetigen Browserlauf.
ZWEI PRUEFUNGEN, DIE SICH SELBST IM WEG STANDEN
pruef-tempo-workspace meldete "NEUE Doppelabfrage: start.html 2x
/workspace/api/termine". Nachgemessen an einem einzelnen Seitenaufruf:
genau eine Anfrage. Die Pruefung startete ihren Zaehler, bevor die
Anmeldung zur Ruhe gekommen war, und schrieb der Seite an, was die
vorherige noch offen hatte.
pruef-tagesblick fiel zum zweiten Mal auf dieselbe Falle herein: Sie
mass die Artfarbe an einem vorbeigezogenen Termin, der absichtlich grau
ist. Diesmal an der Wurzel geloest -- die Daempfung wird fuer die
Messung kurz abgeschaltet und sofort zurueckgesetzt. Damit ist die
Zuordnung fuer JEDEN Termin geprueft, unabhaengig von der Uhrzeit des
Laufs, und zusaetzlich beweist die Pruefung, dass die Daempfung greift.
NEU: Schriftgroessen werden jetzt AN DER QUELLE geprueft, in Sekunden
statt Minuten. Im Bestand stehen 43 solche Stellen; sie alle rot zu
melden haette die Pruefung ab Tag eins wertlos gemacht. Deshalb eine
Grundlinie wie beim Layout-Sprung: Sie haelt den Stand fest und
schlaegt an, sobald es MEHR werden. Heute haette das zweimal gegriffen.
Die Browserpruefung bleibt daneben -- sie sieht, was am Ende auf dem
Schirm steht, die CSS-Pruefung nur, was gemeint war.
Gesamtlauf: 56 von 56 Dateien, 2002 von 2002 Punkten.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
6541ecbfa7 |
Alte Symboldateien tragen jetzt auch das neue Bild
Filipe hat die Verknuepfungen dreimal neu angelegt und sah trotzdem das alte Symbol. Die Ursache lag nicht an den neuen Dateien - die werden nachweislich korrekt ausgeliefert (36 von 36 live byteweise geprueft), sondern an vier Altlasten: /assets/img/favicon.png 256x256 /assets/img/apple-touch-icon.png 180x180 /assets/img/icon-192.png 192x192 /assets/img/icon-512.png 512x512 Die stammen aus der Zeit vor dem Umbau auf app-symbole/ und werden von KEINER Seite mehr verlinkt - geprueft mit einer Suche ueber alle html, js, json und webmanifest: nur noch sw.js und main.js nennen sie. Aber Chrome hat sich das Favicon dieser Domain gemerkt, als favicon.png noch verlinkt war, und gibt es nicht mehr her: Beim Anlegen einer Verknuepfung nimmt Windows dieses alte Bild, egal was im HTML steht. Auf Filipes Bildschirm trugen deshalb ZWEI verschiedene Verknuepfungen dasselbe Symbol - das war der entscheidende Hinweis, denn zwei Apps mit verschiedenen Manifesten koennen unmoeglich dasselbe Symbol haben. Statt zu hoffen, dass ein Zwischenspeicher irgendwann aufgibt, tragen die alten Adressen jetzt einfach dasselbe Bild wie die neuen. Damit ist es egal, welche ein Programm nimmt. Dazu im Service Worker: CACHE_NAME auf v2 hochgezaehlt - activate() loescht dadurch den alten Zwischenspeicher samt altem Symbol. Und SHELL_ASSETS zeigt nicht mehr auf die verwaisten icon-192/-512, sondern auf die Adressen aus dem Manifest. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
ed12d75404 |
App-Symbole: Kennzeichen-Plakette, damit man sie klein unterscheiden kann
Die Symbole waren farblich schon verschieden, zeigten aber alle dasselbe Motiv. Gemessen in echter Groesse: Bei 24px (Startmenue) und 32px (Taskleiste) ist der Husky nur noch ein Fleck - es unterscheidet sie einzig die Farbe, und Webdesign, Kundenportal und WD-Verwaltung liegen im Lila-Rosa-Bereich dicht beieinander. Jedes Symbol traegt jetzt unten rechts eine Plakette mit einem Kennzeichen in der Farbe der App: Hauptseite * DogiCrew-Verwaltung C Webdesign W Kundenportal K WD-Verwaltung V Creator Workspace A Der Husky bleibt gross und dominant - die Marke wird nicht angetastet, die Plakette traegt nur die Unterscheidung. Die maskable-Fassungen haben eine EIGENE Plakettenlage, und die ist gerechnet, nicht geschaetzt: Android behaelt nur den Kreis mit 80% Durchmesser (Radius 0.40 ab Mitte). Der aeusserste Punkt der Plakette liegt bei sqrt(2)*(0.5-rand-groesse/2)+groesse/2. Der erste Entwurf kam damit auf 0.417 - die Plakette waere auf dem Handy angeschnitten worden. Mit rand 0.190 und groesse 0.280 sind es 0.380, also mit Reserve drin. Erzeugt aus den vorhandenen Symbolen (nicht neu gezeichnet), 36 Dateien: je App 32, 180, 192, 512 und die beiden maskable. Jede Datei danach einzeln aus dem PNG-Kopf vermessen - 36 von 36 haben die richtige Groesse und Inhalt. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
de60df5637 |
Creator Workspace ist jetzt wirklich installierbar
Der Workspace liess sich nicht als App installieren: Windows und Android legten nur eine Browser-Verknuepfung an, mit dem globalen Favicon der Domain statt dem eigenen Symbol. Grund: workspace/app.webmanifest lag fertig da und wurde sogar ausgeliefert (HTTP 200), war aber in KEINER der 17 Seiten verlinkt. Ohne rel=manifest gibt es fuer den Browser nichts zu installieren. Jede der 17 Seiten bekommt deshalb den Manifest-Verweis und die eigene Fensterfarbe #0674b9 (Blau, passend zum nachtblauen Symbol). Zur Entstehung: Diese 17 Dateien tragen auch Versionsnummern einer parallel laufenden zweiten Sitzung (?v=202609052252), deren zugehoerige start.css und start.js noch nicht committet sind. Die gehoeren nicht in diesen Commit. Sie wurden fuer das Bereitstellen kurz auf den committeten Stand zurueckgesetzt und in der Arbeitskopie sofort wiederhergestellt - im Index liegt dadurch nur die eigene Aenderung, ihre Arbeit bleibt unangetastet uncommittet. Vorher gesichert, hinterher Datei fuer Datei verglichen: kein Unterschied. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
5ef3a13615 |
Jede App der Domain bekommt eine eigene Fensterfarbe
Beim Installieren als App sahen alle Dienste gleich aus. Nicht wegen der Symbole - die sind seit heute Mittag gut unterscheidbar - sondern wegen der Farbe: zwoelf von vierzehn trugen dasselbe Fast-Schwarz (#05070b, #05070d, #0a0910, #0b0d10, #0d0817, #0e0a16). Das ist die theme_color, also am PC die Titelleiste des App-Fensters und am Handy die Statusleiste. Neu, je App eine Farbe, abgeleitet vom eigenen Symbol: Hauptseite #065f76 Petrol (Symbol stahlblau) DogiCrew-Verwaltung #8d4125 Kupfer (Symbol orange) Webdesign #564e95 Violett (Symbol lila) Kundenportal #924985 Magenta (Symbol pink) WD-Verwaltung #b44f5e Rose (Symbol rot) Creator Workspace #0674b9 Blau (Symbol nachtblau) Nextcloud (#17a5a6) bleibt unveraendert - als einzige hob sie sich schon ab. WICHTIG war, beide Stellen zu aendern: Die meta-Angabe im HTML ueberschreibt die theme_color aus dem Manifest. Nur das Manifest zu aendern haette gar nichts bewirkt. Der background_color (Startbildschirm beim Oeffnen) bleibt bewusst sehr dunkel, nur leicht in Richtung der App-Farbe getoent - kraeftig ist nur die schmale Leiste, damit nichts grossflaechig aufblitzt (Vorgabe augenschonend). Wie die Farben entstanden sind: Zwei Entwuerfe fielen bei der eigenen Pruefung durch. In HSL gerechnet lagen Workspace und Webdesign bei einem Farbabstand von 12.6 statt der noetigen 25 - auf dem Papier 30 Grad auseinander, fuers Auge dasselbe Blauviolett. Auch der zweite Versuch scheiterte (Hauptseite zu nah an Nextclouds Tuerkis, 19.1). Neun Farben bei gleicher Helligkeit passen schlicht nicht mit genug Abstand auf den Farbkreis. Erst mit der Helligkeit als dritter Dimension und einem Optimierer, der den KLEINSTEN Abstand im Satz maximiert, kam ein Satz heraus, der haelt: kleinster Abstand 25.5. Geprueft: 68 Farbpruefungen (weisse Schrift ueberall lesbar 5.0-7.2:1, keine blendet, jede hebt sich vom bisherigen Schwarz ab, alle Paare >= 25 Delta E) und 101 Browserpruefungen ueber 16 Seiten (Manifest und meta stimmen ueberein, genau eine theme-color je Seite, Symbole vorhanden) - alle gruen, Gegenprobe schlaegt an. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
c3b156dbad |
Tagesblick: eine Kachel fuer offene Punkte und die Termine des Tages
Wunsch Filipe, 05.09.2026, mit Bildschirmfoto der Hinweisliste: "eine
ganze kachel wo links die sachen sind die du da schon siehst und rechts
in der kachel die termine vom tag. in der mitte gesplittet. mach das
richtig geil und hochwertig."
WARUM DIE BEIDEN ZUSAMMENGEHOEREN
Links steht, was zu TUN ist, rechts, was schon FESTSTEHT. Zusammen
ergeben sie die einzige Frage, die man morgens hat -- wie sieht mein Tag
aus. Untereinander musste man scrollen, um sie zu beantworten.
Eine Kachel und nicht zwei nebeneinander: Zwei Rahmen lesen sich als
zwei Themen. Der Trenner laeuft oben und unten aus, statt von Kante zu
Kante durchzuschneiden -- eine harte Linie macht aus einer Kachel wieder
zwei.
Die rechte Haelfte ist ein Zeitstrahl, kein Kalenderauszug:
* Was als NAECHSTES dran ist, wird hervorgehoben. Beim Ueberfliegen
ist das die Auskunft, die man sucht -- nicht "der erste des Tages".
* Vorbei heisst nicht weg. Erledigtes tritt zurueck, bleibt aber
sichtbar; man will sehen, was man schon hinter sich hat.
* Dieselben vier Farben wie im Kalender. Eine Farbe, die hier etwas
anderes bedeutete, muesste man zweimal lernen.
Die Daten kommen aus der Kalender-Schnittstelle mit tage=1 -- keine
zweite Abfrage, keine zweite Sichtbarkeitsregel. Was jemand im Kalender
nicht sehen darf, kommt hier gar nicht erst an.
DREI FEHLER, DIE DABEI AUFFIELEN
1. Die rechte Haelfte war 38 statt 579 Pixel breit. Die versteckte
Ueberschrift fuer Vorleseprogramme zaehlt als Kind im Raster und hat
alles um eine Spalte verschoben, sodass "Heute" in der Ein-Pixel-
Spalte des Trenners landete. Die Spalten sind jetzt ausdruecklich
zugewiesen -- damit verschiebt auch ein spaeteres viertes Element
nichts mehr.
2. Die Plaketten (CALL, TERMIN, REVIEW) hatten 10,56 px. Die Hausgrenze
liegt bei 11,5 -- darunter liest auf einem Handy niemand mehr.
Gemeldet von pruef-handy auf allen drei Geraeteklassen UND von
pruef-grosscheck bei allen vier Rollen. Ein Fix, zwei Pruefungen.
3. Am Handy stand die Uhrzeit mittig zur Zeile, waehrend der Titel oben
begann -- sie fluchteten nicht, sobald die Plakette unter den Text
rutschte.
Die Kachel bleibt ganz weg, wenn BEIDE Haelften leer sind, und zeigt
sonst auf der leeren Seite einen Satz. Vorher haette jemand ohne offene
Punkte, aber mit drei Calls seinen Tagesplan nicht gesehen: Das
Verstecken hing an der linken Haelfte allein.
ZWEI PRUEFUNGEN, DIE SICH SELBST IM WEG STANDEN
pruef-tempo-workspace meldete "Layout springt: bereich.html 0,703".
Nachgemessen: derselbe Wert schwankt zwischen den Laeufen um den Faktor
zwei (aufgaben.html 0,478 / 0,262 / 0,262; bereich.html 0,703 dann
0,347). Er haengt davon ab, ob die Daten ankommen, waehrend das Geruest
noch aufgebaut wird. Eine Pruefung, die zufaellig rot wird, ist so
wertlos wie eine, die nie anschlaegt -- man klickt sie weg, und mit ihr
die echte Warnung. Statt die Grenze anzuheben (das haette sie stumpf
gemacht) wird ein Ausschlag jetzt durch WIEDERHOLUNG bestaetigt, und
gemeldet wird der zweite Wert, nicht der kleinere. Ein echter Sprung
kommt bei jedem Lauf und uebersteht das muehelos. Die neue Kachel selbst
springt uebrigens gar nicht: start.html steht bei 0.
pruef-push-weg meldete "ALLES IN ORDNUNG" und stuerzte danach ab
(libuv: UV_HANDLE_CLOSING, Rueckgabewert 3221226505). Ursache war
process.exit() mitten im Schliessen der fetch-Verbindungen. Jetzt
process.exitCode -- Node raeumt zu Ende. Fuenf Laeufe hintereinander
sauber. Eine Pruefung, die inhaltlich besteht und trotzdem rot ist, ist
das Schlimmste von beidem.
Gesamtlauf: 1994 von 1994 Punkten (1973 vorher + 21 der neuen Pruefung).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
5119e0139d |
vanvan.html: Coming-soon-Knopf wird Link zu VAN'S DIY
Der silberne Knopf trug 'Coming soon...' und war gesperrt (aria-disabled, kein href). Er heisst jetzt 'VAN`S DIY' und fuehrt zu https://vans-diy-bastelbedarf.com/ - in neuem Tab, mit rel=noopener, wie der TikTok-Knopf darueber und die uebrigen Shop-Verweise im Projekt. aria-disabled musste weg: sonst meldet ein Bildschirmleser 'nicht bedienbar', obwohl der Knopf jetzt bedienbar ist. Dabei aufgefallen und mitbehoben: Die Beschriftung brach auf schmalen Geraeten mitten im Wort um ('VAN / `S / DIY' bei 390px, Knopf 117px statt 89px hoch), weil die Sektion auf vanvan.html auch auf dem Handy zweispaltig bleibt - ein Inline-Style ueberschreibt dort die Regel aus @media(max-width:620px). .btn-silver bekommt deshalb white-space:nowrap. Das behebt zugleich den gleichen Umbruch von 'Coming soon...' auf abonnieren.html bei 320px. Geprueft im echten Browser: 52 Pruefungen (5 Sprachen x Text, href, kein aria-disabled, target, rel, sichtbar, bedienbar) plus echter Klick, der auf vans-diy-bastelbedarf.com landet - alle gruen, Gegenprobe schlaegt an. Zusaetzlich 180 Messungen ueber 4 Seiten x 9 Breiten x 5 Sprachen (270 Knoepfe angesehen): kein Umbruch, kein Ueberlauf. Ohne den nowrap-Fix meldet dieselbe Messung 30 Befunde. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
627f710d71 |
Aufgaben abbrechen, Teilnehmerwahl fuer alle, Benachrichtigungen
Zwei Wuensche vom 05.09.2026, dazu drei Fehler, die dabei ans Licht kamen.
ABBRECHEN (Wunsch: "in jedem status die aufgaben auch abbrechen koennen,
nur ich die manager und scouts")
Neuer Status mit Pflicht-Grund, aus jedem der vier Status heraus.
Festgehalten wird auch, WO die Aufgabe stand -- "im Review abgebrochen"
ist eine andere Aussage als "nie angefangen", und das Wiederaufnehmen
geht dorthin zurueck statt nach "offen".
Eigener Weg statt "abgebrochen" in der Statusliste: Dort entscheidet
darfAendern(), und das laesst auch den zustaendigen Creator aendern.
Der gewoehnliche PATCH kann diesen Zustand deshalb gar nicht erreichen
-- auch nicht fuer DogFather, sonst waere die Grund-Pflicht umgehbar.
Abgebrochenes steht in einem zugeklappten Bereich unter dem Brett, nicht
als fuenfte Spalte: Am Handy waeren dann alle fuenf unlesbar schmal.
Verschwinden darf es nicht, sonst waere der Abbruch ein Loeschen mit
Zwischenschritt.
Die Tabelle musste dafuer getauscht werden (SQLite kann CHECK nicht
aendern). Vorher auf einer Kopie durchgespielt: 40 von 40 Aufgaben,
Inhalte, Verweise und Indizes geprueft, Gegenprobe zeigt, dass der CHECK
noch lebt.
TEILNEHMERWAHL (Wunsch: "das soll viel besser aussehen und fuer jeden
verfuegbar sein")
Auf dem Bildschirm klebten die Namen aneinander: "DogfatherDogFather".
Ursache war, dass kalender.html das Stylesheet mit diesen Klassen nie
eingebunden hat -- sie standen in dateien.css. Vierzig gruene Pruefungen
zur Teilnehmerwahl hatten das nicht gemerkt, weil keine je gefragt hat,
ob es AUSSIEHT wie gedacht.
Jetzt eigene Klassen im eigenen Stylesheet, nach Rollen gruppiert: Die
Rolle steht einmal als Ueberschrift statt neunmal am Namen. Damit ist
das Kleben an der Wurzel weg, nicht zugepflastert.
"Fuer jeden" war mehr als ein hidden zu entfernen: darfEintragen() haette
einem Creator nur sich selbst erlaubt. Er haette seinen Scout gesehen,
angeklickt, und der Server haette ihn still weggelassen -- ein Knopf, der
nichts tut. einladbareIds() schaut jetzt in beide Richtungen, bewusst
getrennt von /api/personen: Wer die erweitert, gibt einem Creator
nebenbei die Moeglichkeit, seinem Scout Aufgaben zuzuweisen.
BENACHRICHTIGUNGEN (Wunsch: "sowas, und dass es perfekt funktioniert
fuer jeden")
Web Push nach RFC 8291/8292, ohne fremde Abhaengigkeit. Der Knopf sagt
in jeder Lage die Wahrheit, auch die unbequemen: abgelehnt (mit dem
Hinweis, wo man es zuruecknimmt), iPhone im Reiter (mit Anleitung),
Browser ohne Push. Ein Knopf, der bei abgelehnter Berechtigung nur
nichts tut, ist der sichere Weg zu "das funktioniert nicht".
DREI FEHLER, DIE DABEI AUFFIELEN
1. Ein defekter Zugangsdatensatz sperrte ALLE einer Rolle aus. Wirft
hashe() bei einer Person, flog die ganze Anmeldung in den catch: 503
"nicht verfuegbar" fuer jeden mit dieser Rolle. Aufgefallen durch
einen eigenen Testfehler. Jetzt wird die defekte Person uebersprungen
und laut protokolliert; die Gegenprobe zeigt, dass ein falscher Code
weiterhin abgelehnt wird.
2. Die Glocke sprengte die Kopfleiste -- zweimal. Bei 320 px lag die
Lupe des Suchknopfes auf dem Sicht-Umschalter (ein Knopf, der auf 12
Seiten ins Leere tippt), bei 768 px wurde der Abmelden-Knopf bis zu
15 px aus dem Bild geschoben, weil die Textgrenze auf 760 stand und
ein Tablet 768 hat. Nachgewiesen durch Messen mit und ohne Glocke,
nicht durch Vermuten.
3. .block__frage war viermal gestaltet und stand auf einer Seite, die
keine dieser Dateien laedt -- derselbe Fehler wie bei der
Teilnehmerwahl. Gefunden von der neuen Klassenpruefung beim ersten
Lauf.
NEUE PRUEFUNGEN
pruef-css-klassen jede gestaltete Klasse muss auf ihrer Seite ankommen
(unterscheidet Struktur-Anker von echtem Verlust)
pruef-dabei-optik die Wahl im Browser, an den echten Pixeln
pruef-abbrechen Umstellung auf einer Kopie, Rechte, Rueckweg
pruef-abbrechen-optik Knopf, Dialog, Bereich, Handy
pruef-glocke Zustaende, An/Abmelden, jede Rolle
pruef-push(-weg) Rechnung gegen die RFC-Vektoren, Zustellung
pruef-struktur prueft jetzt zusaetzlich, ob sich jedes Server-Modul als
ESM laden laesst. node --check auf einer .js-Datei prueft als CommonJS
und meldete "ok", waehrend der Import scheiterte.
Gesamtlauf: 55 von 55 Dateien, 1973 von 1973 Punkten.
Was NICHT geprueft werden konnte und deshalb dasteht: Der Schritt
"Browser holt eine Adresse beim Push-Dienst" braucht eine Verbindung zu
Googles FCM, die ein Pruef-Browser nicht hat. Die Pruefung misst das
zuerst und meldet es als dritten Ausgang, statt gruen zu sein.
Verschluesselung und Zustellung sind getrennt geprueft; diese eine
Strecke beweist sich erst auf dem Server.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
529c814389 |
Kalender: mehrere Teilnehmer je Termin und Serie
Wunsch Filipe: "wenn ich im kalender was eintrage will ich dass ich
auch 2 leute markieren kann mit denen der call ist." -- und auf
Rueckfrage: beliebig viele, und auch fuer wiederkehrende Termine.
Bis hierher hatte ein Termin GENAU EIN Gegenueber. Fuer ein Gespraech
zu dritt musste man zwei Termine anlegen und hatte zwei Wahrheiten
ueber dieselbe halbe Stunde.
DAS IST KEINE ANZEIGE, SONDERN EINE RECHTEREGEL. An der
Teilnehmerliste haengt die Sichtbarkeit: Wer eingetragen ist, sieht den
Termin. Deshalb zwei Grenzen, beide serverseitig:
* Eintragen darf man nur, wen man ohnehin sehen darf (Leitung jeden,
ein Scout seine betreuten Creator, ein Creator sich selbst).
* Zuordnungen verschiebt nur die Leitung -- sonst koennte sich jemand
selbst in fremde Termine eintragen und sie sich damit sichtbar
machen.
Gebaut nach dem Muster von datei_personen: eigene Tabellen
termin_teilnehmer und serie_teilnehmer statt weiterer Spalten.
teilnehmer_id bleibt das Haupt-Gegenueber und wird beim Speichern immer
in die Liste mit aufgenommen.
Vorhandene Termine werden beim Start uebernommen. Zusaetzlich liest die
Abfrage das Haupt-Gegenueber IMMER mit dazu -- die Liste stimmt damit
auch dann, wenn die Uebernahme nicht gelaufen ist (Sicherung
zurueckgespielt, Neustart ausgeblieben). Genau das ist beim Bauen
aufgefallen: Ein alter Termin zeigte "niemand dabei", obwohl ein
Gegenueber eingetragen war.
Serien vererben ihre Teilnehmer an jede erzeugte Auspraegung -- sonst
saehe der zweite Mensch den woechentlichen Call einmal und danach nie
wieder.
Neue Pruefung pruef-teilnehmer.mjs mit 40 Punkten: beide sehen ihn,
Fremde nicht, kein Selbsteintragen, Hinzufuegen und Entfernen, Serien,
Unsinn in der Liste. Mit Gegenprobe, die nachweist, dass die Messung
"nicht sichtbar" ueberhaupt erkennt. Im echten Browser gegengeprueft:
Schalter da, zwei angehakt, gespeichert, beide zurueck, keine
Konsolenfehler.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
8759a46e5b |
iPhone-Symbole: quadratisch und deckend statt abgerundet
Gemeldet: "auf dem pc und auf dem handy soll alles funktionieren, auf
dem einen klappt es und auf dem anderen nicht."
Der Grund ist, dass PC und Handy ihr Symbol an drei verschiedenen
Stellen holen -- und jede stellt andere Anforderungen:
Browser-Reiter das normale Symbol, runde Ecken erlaubt
Android die maskable-Fassung, aussen wird beschnitten
iPhone <link rel=apple-touch-icon> -- und iOS rundet SELBST
ab und fuellt alles Durchsichtige mit SCHWARZ
Unser 180er brachte seine eigene Rundung mit, also durchsichtige Ecken.
Auf dem iPhone wurden daraus schwarze Zipfel, die dann ein zweites Mal
beschnitten wurden. Auf dem PC sieht dieselbe Datei tadellos aus --
genau daher der Unterschied zwischen den Geraeten.
Jetzt wird die 180er-Fassung randvoll und deckend gebaut. Nachgemessen
an allen zehn: 0,00 Prozent durchsichtig, Ecken voll deckend. Die
normale Fassung bleibt abgerundet (4,75 Prozent) -- auch das gemessen,
damit der Fix nicht die andere Seite kaputtmacht.
Dazu eine Pruefung in pruef-struktur.mjs: alle sechs Groessen je App
vorhanden, und jede Seite nennt beide Symbolarten. Fehlt das
iPhone-Symbol, nimmt iOS einen Bildschirmausschnitt der Seite.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
e9709a5aa8 |
Maskable-Symbole: das ganze Symbol verkleinern, nicht nur das Logo
Gemeldet von Filipe: "die symbole sehen aber auf meinem pc nicht aus wie auf dem browser mit diesen geilen farben." Er hatte recht -- die maskable-Fassungen sahen aus wie eine schlechte Kopie: blass, das Medaillon riesig, der Doppelring ueber den Rand hinaus. Und genau die nimmt das Betriebssystem fuer installierte Apps. Der erste Entwurf verkleinerte nur das LOGO (52 statt 68 Prozent) und liess den Hintergrund unveraendert. Das geht bei einer glatten Flaeche gut und bei allem anderen schief: Medaillon, Doppelring, Raster und Eckband rechnen ihre Kreise in Prozent der FLAECHE. Wird aussen ein Fuenftel weggeschnitten, sitzt der Ring nicht mehr, wo er hingehoert. Jetzt wird das fertige Symbol als Ganzes auf 78 Prozent verkleinert und in eine Huelle aus dem dunkelsten Ton der App gesetzt. Damit bleibt jedes Verhaeltnis erhalten -- Ring zu Flaeche, Logo zu Ring, Verlauf zu Kante. Weggeschnitten wird nur ruhige Randfarbe. Nachgeprueft mit einer Vorschau, die den Zuschnitt nachstellt: rund (Android) und abgerundetes Quadrat (Windows/iOS). Beide sehen jetzt praktisch aus wie die Fassung im Browser. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
37c2930af0 |
Kundenportal war nicht installierbar: Manifest hinter der Zugangswand
Live gemessen nach dem Deploy: Symbole 200, portal.webmanifest 302 auf zugang.html. Der Browser bekam HTML statt JSON und bot "App installieren" gar nicht erst an -- die ganze Arbeit am Symbol waere fuer das Portal wirkungslos geblieben, ohne dass irgendwo etwas rot geworden waere. Das ist zum DRITTEN Mal derselbe Fehler an derselben Stelle (app.webmanifest, verwaltung.webmanifest, jetzt portal.webmanifest). Zweimal stand die Begruendung danach im Code -- beim dritten Mal wurde sie trotzdem uebersehen. Ein Kommentar verhindert nichts. Deshalb zusaetzlich eine Pruefung in pruef-struktur.mjs: Jedes Manifest unter /webdesign/ MUSS in der Ausnahmeliste von webdesign-gate.js stehen. Gegengeprobt -- Eintrag entfernt, Pruefung schlaegt an. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
7fe6a51233 |
ZockerAnstalt und Analyse: Symbole unter den richtigen Namen
Der erste Entwurf legte sie unter eigenen Namen daneben (dogfather-zocker-192.png). Die Dateien lagen da, die Manifeste zeigten weiter auf icon-192.png -- das neue Symbol waere nie angekommen. Der Kopiervorgang meldete trotzdem 6 Symbole kopiert. Jetzt werden die vorhandenen Namen ueberschrieben. Damit greifen Manifest und HTML ohne weitere Aenderung, und es gibt keine zweite Stelle, an der ein Verweis uebersehen werden kann. Fehlt ein erwarteter Name, wird das gemeldet statt still uebergangen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
3decdab2f2 |
Laufprotokoll der Browserpruefung gehoert nicht ins Repo
Es entsteht bei jedem Lauf neu und ist ein Ergebnis, kein Quelltext. Beim vorigen Commit versehentlich mitgenommen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
51c3d4402b |
Audit des Creator Workspace, App-Symbole fuer alle Apps der Domain
AUDIT (Auftrag: vollstaendiger Durchgang, Fehler direkt beheben)
Ausgangslage waren 40 Pruefungen mit 1616 Einzelpunkten, alle gruen.
Acht neue Pruefungen kamen dazu; sie haben gefunden, was die alten nicht
sehen konnten.
Der schwerste Fund: Die Zugangsschranke verglich req.path EXAKT gegen
eine Liste. Express raeumt Punkt-Segmente selbst weg, mehrfache
Schraegstriche aber nicht. Damit kam //workspace/start.html OHNE
Anmeldung mit HTTP 200, und ein Creator bekam ueber
/workspace//personen.html die Verwaltungsseite. Die DATEN waren nie
betroffen (nachgemessen: 404 bzw. 401). Behoben durch Normalisierung
UND eine Umkehr der Logik -- jetzt ist jede .html geschuetzt ausser der
Anmeldeseite, statt nur die in der Liste. Eine vergessene neue Seite
steht damit nicht mehr versehentlich offen.
Weiter behoben:
* Kaputter/abgebrochener Rumpf ergab 500 in HTML statt 400 in JSON --
die Oberflaeche ruft ueberall a.json() und lief in einen zweiten
Fehler; der Knopf hing ohne Meldung.
* POST /zustand/sichern war der einzige von 60 schreibenden Wegen
ohne Herkunftspruefung.
* workspace-sicherung.js gab interne Pfade in Fehlermeldungen nach
aussen; alle 23 anderen Module antworten neutral.
* admin_notiz war als einziges von 14 Feldern ohne <label>.
* Der aktive Filter hatte keinen sichtbaren Fokus (CSS-Spezifitaet
0,3,0 schlug 0,2,0) -- genau der Knopf, auf dem man steht.
* h1 -> h3 ohne Zwischenstufe auf zwei Seiten.
* HSTS ging auch ueber http mit (RFC 6797, 7.2 verbietet das).
* upgrade-insecure-requests galt auch auf 127.0.0.1 -- dadurch war
WebKit/Safari ueberhaupt nicht pruefbar, also der Browser, den
jedes iPhone benutzt.
* pruef-grosscheck las readdirSync(".") und pruefte aus server/
gestartet NULL oeffentliche Seiten -- meldete aber "ok".
Neue Pruefungen: struktur, schranke, haerte, alle-wege,
barrierefrei-workspace, breiten, tempo-workspace, browser.
Jede mit Gegenprobe und mit der geprueften Anzahl in der Bedingung.
Vier davon sind beim Bauen durch die eigene Gegenprobe aufgeflogen und
haetten sonst dauerhaft gruen gemeldet, ohne etwas zu messen.
APP-SYMBOLE (Wunsch: alle Apps der Domain, jede anders, ausser
safeaddress)
Zehn Apps, zehn Stile, zehn in OKLCH gerechnete Farben. Zusammen haelt
sie dasselbe Logo, dieselbe Eckenrundung und eine gemeinsame gedeckte
Farbreihe. Beim Bauen wird gemessen, ob sich das Logo vom Grund abhebt
(19 bis 58 Helligkeitsstufen).
Dabei aufgefallen: Das Kundenportal hatte kein eigenes Manifest und
trug Namen und Symbol der Webdesign-Seite. Der Workspace hatte gar
keins und war als App nicht installierbar. Beide haben jetzt eins.
Geaendert wurde AUSSCHLIESSLICH das Symbol. Ein Zwischenstand hatte
auch die Themenfarben gesetzt; das war mehr als bestellt und wurde
zurueckgenommen.
Werkzeuge: tools/logo-freistellen.mjs, tools/app-symbole.mjs,
tools/app-symbole-einbinden.mjs -- alles im Browser gerechnet, kein
Bildprogramm, keine neue Abhaengigkeit.
Gitea und Nextcloud sind bereits live und nachgeprueft.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
15fe9bb197 |
Zwei Pruefungen an die getroffenen Entscheidungen angepasst
Der komplette Pruefstand vor der Vorstellung (38 Laeufe im Workspace) lief bis auf zwei durch. Beide Fehlschlaege waren KEINE Fehler in der Anwendung, sondern Pruefungen mit veraltetem Weltbild -- Folgen von Entscheidungen, die Filipe selbst getroffen hat: 1. pruef-workspace-seiten (32 von 32 rot) pruefte, dass JEDE Seite ihre EIGENE Buehne hat (Aufgaben = Werkstatt, Kalender = Nachtstadt, ...). Am 03.09.2026 hat Filipe die neun Szenen durch EIN Bild ersetzt. Jetzt wird geprueft, was weiterhin wichtig ist: dass ueberhaupt ein Hintergrundbild ANKOMMT (ein data-buehne ohne CSS-Regel waere still wirkungslos) -- und dass es auf JEDER Seite dasselbe ist. Ohne die zweite Bedingung waere sie auch gruen, wenn irgendwo eine alte Szene zurueckkaeme. 2. pruef-zustand-ansicht erwartete, dass ein Manager den Systemzustand sieht. Seit dem 02.09.2026 gilt "die manager sollen diese kategorien garnicht sehen"; der Zustand gehoert zur Automationen-Seite. Beide UMGEDREHT statt geloescht. Eine geloeschte Pruefung hinterlaesst keine Spur davon, dass hier einmal etwas anderes galt -- und niemand merkt, wenn eine Sperre spaeter versehentlich wieder faellt. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
80639d0bab |
Abnahme vor der Vorstellung: eine tote Kachel gefunden und geschlossen
Morgen wird die Seite als Produkt vorgestellt. Deshalb eine Pruefung,
die es bisher nicht gab: server/pruef-live-abnahme.mjs geht gegen die
ECHTE Domain statt gegen einen Server auf diesem Rechner.
Der Unterschied ist nicht theoretisch. Zwischen "laeuft bei mir" und
"laeuft im Netz" liegen Caddy, Cloudflare, der Cache-Stempel, das
Zertifikat und der Dienst-Neustart -- genau dort ist am 18.08. und am
22.08.2026 schon zweimal etwas haengengeblieben, das lokal tadellos war.
Sie geht 26 Seiten in DREI Gestalten durch:
RECHNER 1440 px
HANDY 390 px, mit Fingerbedienung
INSTALLIERT als App vom Startbildschirm -- ohne Adresszeile und ohne
Zurueck-Knopf des Browsers. Dort faellt auf, was man mit
Browserleiste nie merkt.
Gemessen je Seite: Konsolenfehler, fehlgeschlagene Anfragen, seitlicher
Ueberlauf, tote Verweise, fehlende Bilder, ueberhaupt Inhalt, Titel.
Dazu die App selbst: Manifest, Name, Start ohne Browserleiste, alle vier
Startbildschirm-Symbole einzeln abgefragt, Hintergrunddienst angemeldet
und aktiv.
DER EINE ECHTE FUND: Auf links.html war die Kachel "Merchandise / Shop"
ein <a href="#"> -- sie sah aus wie ein Verweis, liess sich anklicken
und tat nichts. Auf der Kachel steht "Folgt in Kuerze"; genau dann darf
sie nicht klickbar sein. Ein Knopf, der nichts tut, ist schlimmer als
gar keiner: Man drueckt ihn zweimal und haelt die Seite fuer kaputt.
Jetzt ein <div> mit denselben Klassen -- gleiches Aussehen, kein
Versprechen mehr, das die Seite nicht halten kann.
ZWEI FEHLALARME, beide in MEINER Pruefung, beide aufgeschrieben:
* Sie meldete "fehlende Bilder" auf zwei Seiten. Es waren versteckte
Platzhalter (<img hidden> ohne src), die JavaScript erst fuellt --
der Normalzustand. Jetzt zaehlen nur sichtbare Bilder mit Quelle.
* Sie meldete "manifest.json nicht ladbar", waehrend curl gleichzeitig
200 lieferte. Die Probe stand noch auf about:blank und holte von
dort -- fremde Herkunft, der Browser lehnt ab. Sie hat also nicht
die Seite geprueft, sondern sich selbst. Erst navigieren, dann
messen.
Die beiden anderen href="#" auf der Seite (index.html, streamplan.html)
bleiben: Sie sind versteckt und werden von JavaScript gefuellt, sobald
es etwas zu verlinken gibt. Geprueft wird nur, was man auch sieht.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
95f54fd211 |
Die ganze Oberflaeche spricht jetzt dieselbe Sprache wie die Zeichen
"bring alles auf dieses niveau -- texte, kacheln, hinweise, titel,
buttons, einfach alles."
Berechtigt, und der Fehler war meiner: Die Kachelzeichen sind Koerper
geworden, alles andere blieb flach. Ein plastisches Zeichen neben einem
gemalten Knopf sieht nicht nach "teilweise gut" aus, sondern nach
Versehen.
Ab jetzt gelten fuer JEDES Bauteil dieselben drei Regeln -- dieselben,
nach denen auch die Zeichen gebaut sind:
1. LICHT VON OBEN. Eine helle Kante an der Oberkante, in der Mitte am
staerksten, nach aussen auslaufend. Echtes Licht auf einer Kante
sieht so aus; eine durchgehend gleich helle Linie ist ein Strich.
2. TIEFE NACH UNTEN. Ein versetzter Schatten -- wie bei jedem
Gegenstand, der auf etwas liegt. Ohne ihn klebt ein Element auf der
Seite, statt darauf zu liegen.
3. VERLAUF STATT FLAECHE. Oben eine Spur heller als unten. Kaum zu
sehen, aber ohne ihn bleibt jede Flaeche tot.
Und eine vierte, nur fuer Bedienbares:
4. WAS MAN DRUECKT, GEHT HINEIN. Beim Klick kehrt sich die Woelbung um:
Licht nach unten, Schatten nach oben. Das ist der Unterschied
zwischen "es passiert etwas" und "ich habe etwas gedrueckt".
ANGEFASST -- beide Seiten, nicht nur eine:
Workspace (gate.css, gilt auf jeder Seite)
Knoepfe, Schritte, Abmelden, Stufenknoepfe, Suchknopf
Eingabefelder, Auswahlfelder, Suchfeld -- die bekommen die Woelbung
ABSICHTLICH ANDERSHERUM: Ein Feld, in das man schreibt, ist eine
Mulde, kein Knopf. Licht unten, Schatten oben.
Marken, Rollenabzeichen, Zaehler, Filterchips
Hinweisflaechen, Notizen, Call-Raum, Codekasten
Ueberschriften und Schilder
Oeffentliche Seite (main.css)
Knoepfe (btn, btn-primary, btn-outline) samt geschliffener Kante
Marken und Abzeichen
Ueberschriften
Der Textschatten aendert die FARBE nicht -- die Kontrastpruefung misst
weiter denselben Wert --, legt den Text aber auf die Seite, statt ihn in
den Hintergrund zu mischen.
Alles gedeckt. Diese Bauteile stehen zu Dutzenden auf einer Seite, und
was einzeln beeindruckt, blendet im Dutzend.
GEPRUEFT, zehn Laeufe, alle gruen: Buehne 38 (Textkontrast an echten
Bildpunkten), Rollen 97, Handy 50, Formulare 19, Grosscheck 15,
Lesbarkeit 14 -- dazu die vier Laeufe der oeffentlichen Seite
(Startseite, Design, Barrierefreiheit, Tastaturbedienung).
Co-Authored-By: Claude Opus 5 <[email protected]>
|