main
85
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
1ad22b55c4 |
Ring so gross wie die Uhr, Stunden geschaerft, Report-Karten gerade, Schutz wird Magenta
--- screen1: Glocke nach rechts, Ring so gross wie die Uhr ---
"dieser button links vom kreis soll rechts davon sein und der kreis
soll die gleiche groesse wie die uhr haben."
Die KAESTEN waren schon exakt gleich gross (248 x 248, seit gestern aus
einer Variablen). Der gezeichnete Ring aber nicht: Sein aeusserer Bogen
lag bei Radius 128 von 150, plus halbe Strichbreite also bei 132,5 --
88 Prozent des Kastens, gerendert 219 statt 248 px. Die Uhr daneben
fuellt ihren Kasten ganz aus, ihr Leuchtkranz ragt sogar 7 px darueber
hinaus. Zwei gleich grosse Kaesten mit ungleich grossem Inhalt sehen
ungleich gross aus.
Jetzt 145 statt 128 (aussen) und 120 statt 106 (die Segmente) --
dasselbe Verhaeltnis zueinander, nur bis an den Rand. 145 + 4,5 =
149,5 von 150: ein halber Pixel Luft, damit die runde Kappe nicht
abgeschnitten wird.
Die Glocke steht jetzt rechts vom Ring. Damit liegen beide Knoepfe
INNEN, zwischen den Instrumenten und dem Text -- vorher sassen sie an
den beiden Aussenkanten, so weit voneinander entfernt wie moeglich,
obwohl sie dasselbe tun: einstellen, was einen erreicht.
--- screen2: die Stunden ---
"die stunden muss noch perfektionnieren."
DIE LICHTKANTE WAR EIN KRATZER. Sie stand auf 50 Prozent Weiss bei 0,9
Breite. Auf den schmalen Sekunden- und Minutenbahnen ist das eine
Kante; auf dem 5,8 px breiten Stundenbalken war es ein zweiter,
weisser Balken auf dem roten. Der Grund ist Verhaeltnis UND Farbe:
0,9 von 3,2 sind 28 Prozent, 0,9 von 5,8 nur 16 -- aber die Stunde ist
die einzige deckende, kraeftig gefaerbte Bahn, und auf Rot faellt
dasselbe Weiss doppelt so stark auf wie auf Silber. Jetzt 22 Prozent
bei 0,6 Breite.
DER KOPF BLEIBT ROT. Er stand auf #ffd9dd, also fast weiss -- das
aktuelle Glied war zwar das hellste, hatte aber die Farbe seiner Bahn
verloren und sah aus wie ein Fremdkoerper zwischen den roten Balken.
Jetzt ein helles, deutliches Rot: Es hebt sich durch Helligkeit ab,
nicht durch eine andere Farbe.
--- screen3: die Report-Karten stehen gerade ---
"ich will dass alles passt, nicht bedeckt ist, schief steht oder zu
tief oder zu hoch."
NACHGEMESSEN, ALLE 17 KARTEN -- der Befund deckt sich genau mit dem,
was er beschreibt: Name und Zahl lagen 12 bis 28 px auf VERSCHIEDENEN
Hoehen, sie ueberlappten sich waagerecht (gemessener Abstand -183 bis
-524 px), und Karten in derselben Reihe waren verschieden hoch.
DIE URSACHE IST EINE ZEILE: `.kachel__zahl` steht `position: absolute`
bei top 13 / right 13. Auf der Startseite ist das richtig -- gleich
grosse Kacheln, einzeiliger Name. Hier bricht der Name um ("Community:
neue Eintraege"), die Karte waechst nach unten, die Zahl bleibt oben
kleben. Sie war ausserdem fuer die Hoehenrechnung unsichtbar, weshalb
es vorher schon eine `min-height` als Pflaster brauchte.
Jetzt ein echtes Raster: Name links (Zeile 1), Trend darunter, Zahl
rechts ueber beide Zeilen und mittig. `display: contents` auf dem
Wrapper -- so werden seine Kinder selbst zu Rasterfeldern, ohne dass am
HTML etwas geaendert werden muss und ohne dass die Startseite, die
dieselben Klassen benutzt, etwas davon mitbekommt.
Nachgemessen danach: 17 von 17 sauber -- nichts ragt heraus, nichts
ueberlappt, nichts abgeschnitten, kein Versatz ueber 5 px, und keine
Reihe mit ungleichen Hoehen.
--- screen4: Schutz & Regeln wird Magenta ---
"ich will dass die kategorie eine farbe bekommt die extrem krass
auffaellt. diese kategorie ist naemlich seeeehr wichtig."
MAGENTA, WEIL ES DAS EINZIGE IST, DAS ES SONST NICHT GIBT. Rot ist fuer
"ueberfaellig" und Spicy Media vergeben, Babyblau fuer DogFather, Lila
fuer Manager, Gruen fuer Scout, Bronze fuer Creator, Bernstein fuer
"dringend". #ff2fd0 stoesst mit keinem davon zusammen -- es faellt
nicht auf, weil es HELLER ist, sondern weil es einzigartig ist. Das
ist verlaesslicher: Helligkeit konkurriert mit den Nachbarn,
Einzigartigkeit nicht.
Gerechnet wie bei Ton 21: Abstand zum naechsten Nachbarn 0,1305 (die
Grenze im Satz liegt bei 0,0973), Buntheit 0,276 -- die hoechste im
ganzen Satz, das alte Gold lag bei 0,170 --, Kontrast 6,00:1. Von
sieben Kandidaten sind drei an der Abstandsgrenze gescheitert. Das
Saeuregelb #e0ff00 waere lauter gewesen (16,86:1), haette sich aber
mit dem Bernstein von "dringend" und dem Gold der Nachbarkacheln um
dieselbe Wirkung gestritten. Die Kachel bleibt gebaut wie alle
anderen; was sie heraushebt, ist die Farbe, keine Sonderform.
--- Eine Rueckwirkung, die pruef-buehne gefunden hat ---
Die Typenschilder von gestern nutzen `background-clip: text` -- dafuer
MUSS `color: transparent` sein. pruef-buehne las genau dieses `color`,
machte daraus Schwarz und meldete 1,07:1 fuer Text, der hell und gut
lesbar ist. Fuenf Fehlalarme auf drei Seiten.
Eine Warnung, die bei richtiger Arbeit anschlaegt, wird abgeschaltet.
Sie ist deshalb nicht weichgemacht, sondern GENAUER geworden: Bei
Verlaufsschrift zaehlt jetzt der DUNKELSTE Farbstopp der ersten
Hintergrundebene -- der schlechteste Punkt, den es auf dieser Schrift
wirklich gibt. Damit meldet start.html 4,74:1 (noetig 4,5), die
Pruefung findet also weiter die engste Stelle.
UND DIE GEGENPROBE HAT SOFORT EINEN FEHLER IN MEINEM EIGENEN CODE
GEFUNDEN: Ich suchte das Ende der ersten Ebene mit `"),"` -- diese
Zeichenfolge steht aber schon am Ende des ERSTEN `rgb(...)`. Die
Messung las damit immer nur den ersten Stopp und haette einen dunklen
Verlauf fuer hell gehalten. Jetzt wird ueber Klammern gezaehlt. Der
Helfer steht einmal und wird als Quelltext in beide Seiten-Aufrufe
gereicht -- zwei Kopien waeren zwei Gelegenheiten auseinanderzulaufen.
Geprueft: pruef-buehne (mit neuer Gegenprobe), pruef-start-ansicht,
pruef-css-klassen, pruef-handy, pruef-workspace-seiten -- alle in
Ordnung.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
cccafd2c31 |
Sechs Wuensche: Hintergruende, Knopfverteilung, Universum, Uhrkoepfe, Knallrot
--- screen3 + screen1: die Hintergruende draengeln nicht mehr --- "die hintergrunde sollen ueberall so sein dass die sich nicht in den vordergrund draengeln." / "mach den hintergrund von dieser kachel dunkler, so dass die die kacheln drin viel mehr auffallen." `--raster` stand auf .26 Deckkraft -- auf dunkler Flaeche kein Hauch mehr, sondern ein gezeichnetes Gitter. Im Tagdialog lief es sichtbar durch die Ueberschrift, in den Sammelkacheln stand es VOR den Karten darin. Jetzt .09: Man sieht eine Struktur, man zaehlt keine Linien. Eine Zahl fuer das ganze Haus -- sie steht einmal in module.css und wird an fuenf Stellen benutzt. Die Anlasskachel im Kalender lag mit rgba(19,26,38,.88) auf demselben Helligkeitsniveau wie die Karten darin: keine Vitrine, sondern eine dritte Flaeche gleicher Lautstaerke. Jetzt fast schwarz. An den Karten musste dafuer nichts geaendert werden -- der Abstand entsteht von selbst. --- screen2: ein Knopf wandert nach links --- "eins von diesen buttons soll links bei dem anderen kreis sein." Die GLOCKE geht nach links zum Ring, der WECKER bleibt rechts bei der Uhr. Das ist nicht ausgewuerfelt: Der Wecker ist eine Uhrzeit. Die Glocke entscheidet, ob man ueberhaupt etwas ueber sein Team erfaehrt -- und der Ring links zeigt genau das. Die Kachel ist damit spiegelsymmetrisch belegt: 48 px Knopf + 14 px Abstand + 248 px Instrument auf beiden Seiten. Genau das rechnet `--spalte`. Die Zentrierung des Rings ist weggefallen -- sie war noetig, solange er allein in einer fuer Instrument PLUS Knopf bemessenen Spalte stand. Der reservierte Platz schrumpft von 104 auf 48 px je Seite; die Begruendung fuer das Reservieren bleibt: Ein Platz, der erst mit der Antwort entsteht, laesst die Zeile springen. --- screen4: zwei Chilis und zwei Huskys dazu --- "setz in den hintergrund noch 1-2 peperonis und dan das logo von dogfather, also nur den husky." DER HUSKY IST EINE MASKE, KEIN BILD. Die Datei ist schwarz-weiss und freigestellt (nachgemessen: 49 % durchsichtig). Als Hintergrundbild bei 15 % verschwaenden die schwarzen Flaechen im dunklen Grund und uebrig blieben die hellen -- ein zerrissener Umriss, kein Hund. Als Maske ueber einer Farbflaeche wird daraus eine geschlossene Silhouette in DogFathers Babyblau. Im Universum schweben jetzt beide Marken in ihren beiden Farben: sieben Chilis rot, zwei Huskys blau. --- screen5: die Punkte sind ersetzt, das letzte Glied leuchtet --- "ich will dass du die punkte ersetzt und immer der letzte soll mehr strahlen oder so." / "alles ist mega ausser die stunden muss du noch perfektionnieren." DIE DREI UMLAUFENDEN PERLEN SIND WEG -- samt 60 Zeilen Rechnung. Sie waren ein zweites Ding an einer zweiten Stelle: eigene Uhr ab dem ersten Takt (weil die volle Unixzeit `rotate(1.07333e+10deg)` ergab), eigener Startwinkel je Bahn, drei Winkel, die die kleineren Einheiten anteilig mittragen mussten. All das war noetig, WEIL der Kopf neben der Reihe herlief statt Teil von ihr zu sein. Genau deshalb trugen sie am 08.09. noch die alten Farben, als die Bahnen getauscht wurden. Jetzt zeichnet eine zweite SVG-Lage genau EIN Glied heller -- dasselbe, das die Reihe darunter zuletzt gesetzt hat, aus denselben Zahlen. Sie kann gar nicht danebenstehen. Heller statt groesser: Waere der Kopf groesser, waere er ein Fremdkoerper in der Reihe. DIE STUNDEN WAREN BREITER ALS LANG -- 5,5 lang bei 7 breit, also 0,79:1. Ein Segment, das breiter ist als lang, liest sich als Klotz quer auf der Bahn statt als Balken entlang. Und weil die Kantenlage nur 0,4 versetzt ist, lief der 0,9 breite Lichtstrich MITTEN DURCH jeden Balken statt an seiner Kante. Jetzt 10 lang bei 5,8 breit (1,7:1), und der Kantenversatz ist nach Bandbreite gestaffelt: (Breite - 0,9) / 2, also 0,75 / 1,65 / 2,05 zusaetzlich zur Gruppe. --- screen6: die Scout-Pipeline wird knallrot --- "die farbe von dieser kategorie soll knall rot sein." Die anderen zwanzig Kachelfarben sind gerechnet (OKLab, groesstmoeglicher Abstand). Diese eine ist gewuenscht -- und wurde deshalb GEGEN den Satz geprueft statt eingetragen: Der engste vorhandene Abstand liegt bei 0,0973. #ff1f2e kommt seinem naechsten Nachbarn auf 0,1228 nahe, ist also weiter entfernt als das engste vorhandene Paar. Kontrast 5,01:1 (noetig 4,5). Von sechs geprueften Rottoenen der mit dem groessten Abstand UND genug Kontrast. tools/kachel-farben.mjs weiss jetzt davon: Ein kuenftiger Lauf wuerde wieder Rosa vorschlagen, und das waere eine stille Ruecknahme einer ausdruecklichen Entscheidung. --- Ein Messfehler, der festgehalten gehoert --- Beim Pruefen von screen4 meldete meine Foto-Methode vier Beschriftungen unter 4,5:1 -- bei einem Verlust von 0,00 bis 0,15 durch das Universum. Dass die Ursache nicht das Universum sein konnte, stand damit schon in den Zahlen. Exakt gerechnet (Vordergrundfarbe gegen die tatsaechliche Flaeche darunter) liegen dieselben Texte bei 9,13:1 bis 10,76:1. Die Foto-Methode mittelt ueber alle helleren Bildpunkte, und bei duenner Grossbuchstabenschrift ist die Haelfte davon halb ausgeleuchtete Kantenpunkte. Fuer grosse Schrift taugt sie, fuer kleine Versalien meldet sie systematisch zu wenig. Haette ich ihr geglaubt, haette ich vier Farben "repariert", die in Ordnung sind. Geprueft: pruef-start-ansicht, pruef-css-klassen, pruef-kalender, pruef-buehne, pruef-handy, pruef-workspace-seiten, pruef-tagesruf -- alle in Ordnung. Dazu Ring und Uhr auf 248/248 nachgemessen, die Kopf-Muster gegen die Uhrzeit nachgerechnet (01:24:59 -> Sekunde bei 281,115, Minute bei 96,76, Stunde bei 16,493) und die Kachelfarbe gegen alle zwanzig anderen in OKLab geprueft. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
4e35c6f8e5 |
screen11: Der Chat hatte gar keinen Hintergrund -- seit jeher
Wunsch Filipe: "die hintergrund bilder sollen alle so strahlen und
schoen sein wie dieses. dieses ist wirklich mega und perfekt."
(Massstab ist die Scouting-Seite, Szene "wald".)
DER FUND: `chat.html` hat weder `.kopf-zeile` noch `.k-kopf` -- sie
traegt ihren Titel im eigenen `.chat__kopf`. In kopf.js stand ganz
oben:
const kopf = document.querySelector('.kopf-zeile, .k-kopf');
if (!B || !kopf) return;
Damit hing ALLES an der Frage, ob es eine Kopfzeile gibt, an die man
eine Plakette haengen kann -- auch der Farbton der Seite und ihr
Hintergrundbild, die damit nichts zu tun haben. Der Chat ist an dieser
Zeile ausgestiegen und hat WEDER Ton NOCH Buehne bekommen, obwohl in
bereiche.js seit jeher `szene: 'lounge'` fuer ihn steht. Eine
Zuordnung, die es gibt und die nie ankam.
Jetzt stehen Ton und Buehne VOR der Plakette: Sie brauchen nur den
Bereich. Die Plakette braucht zusaetzlich einen Kopf -- gibt es den
nicht, faellt eben nur sie aus.
WARUM DAS KEINE PRUEFUNG GEFUNDEN HAT, gleich zweimal:
1. `chat.html` stand nicht in der Seitenliste von
pruef-workspace-seiten. Eine Pruefung, die eine Seite nicht kennt,
kann auf ihr nichts finden. Jetzt drin, zusammen mit
leistung.html -- 18 Seiten statt 16.
2. Die Buehnenregel lautete `r.buehne ? r.buehneBild === r.buehne :
!!r.buehneBild` -- fehlt das Merkmal, reichte IRGENDEIN Bild.
Gedacht war die Ausnahme fuer die Startseite, geschrieben war sie
fuer jede Seite. Der Chat verlor sein `data-buehne`, fiel auf die
Grundszene zurueck, und die Pruefung sagte "ein Motiv ist da,
alles gut". Eine Bedingung, die bei fehlender Angabe MILDER wird
statt strenger, kann den Verlust dieser Angabe nicht melden --
sie belohnt ihn. Die Ausnahme haengt jetzt an der Startseite, nicht
am Fehlen des Merkmals.
Die Regel ist dafuer aus der Schleife herausgeloest (`buehneRichtig`)
und hat sieben Gegenproben bekommen -- darunter genau den Chat-Fall.
Ohne sie waere "alles in Ordnung" nur die Aussage, dass die Regel
nichts gemeldet hat, nicht dass sie etwas melden koennte.
DIE AUSNAHME DES CHATS STEHT JETZT MIT NAMEN in der Pruefung, statt
dass die Seite aus der Liste faellt: Plakette und Wasserzeichen
entfallen dort, weil es den Ort dafuer nicht gibt -- Ton und Buehne
gelten. Ob der Chat eine Plakette bekommen soll, ist eine
Gestaltungsfrage fuer Filipe, keine Fehlerfrage.
ZWEI FALSCHE AUSSAGEN in tools/gate-bauen.mjs richtiggestellt:
"halle: dieselbe Sammlung, GESPIEGELT" -- nachgemessen haben beide
Dateien dieselbe Pruefsumme, es gibt in diesem Werkzeug keine
Spiegelung. Und "0,42 ist gemessen" ueber `const DUNKEL = 0.26`; der
Wert wurde gesenkt, die Zeile ist nicht mitgegangen. Ein Kommentar, der
mehr behauptet als der Code tut, ist schlimmer als keiner.
ZUM EIGENTLICHEN WUNSCH, ehrlich: Ich habe die Hintergrundhelligkeit
aller 18 Seiten nachgemessen. Die Scouting-Seite ist tatsaechlich die
hellste (0,0263), alle anderen liegen 19 bis 65 Prozent darunter --
aber der Grund ist NICHT die Bildbehandlung. Schleier und Abdunklung
sind fuer alle Seiten gleich und mehrfach nachgemessen. Der Unterschied
ist, WIE VIEL vom Bild noch zu sehen ist: Die Scouting-Seite traegt
eine schmale Karte, die anderen dichte Tabellen und Kachelraster. Das
liesse sich aendern, aber es ist eine Entscheidung ueber die
Inhaltsdichte von 17 Seiten -- die gehoert Filipe, nicht mir um zwei
Uhr nachts.
(Meine erste Messung sagte das Gegenteil. Sie nahm einen Streifen bei
x 0..150 -- ausgerechnet die dunkelste Spalte jedes Motivs. Danach
schien die Scouting-Seite fast schwarz, waehrend das Bildschirmfoto
derselben Seite hell und farbig ist. Ein Messfeld, das nicht
repraesentativ ist, misst zuverlaessig das Falsche.)
Geprueft: pruef-workspace-seiten (18 Seiten, alles in Ordnung),
pruef-buehne, pruef-css-klassen -- alle in Ordnung.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
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
|
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
|
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
|
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]>
|
||
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
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
|
fc26597083 |
Wer sich einen neuen Code gibt, sperrt sich nicht mehr selbst aus
Gemeldet: "ich hab einen neuen code fuer mich gemacht aber ich wurde raus
gekickt bevor ich den neuen code kopieren konnte jetzt komm ich nicht mehr
rein."
DER FEHLER
Ein neuer Code beendete ALLE Sitzungen der Person -- auch die, in der der
Code gerade auf dem Bildschirm stand. Der naechste Aufruf der Seite lief in
ein "nicht angemeldet", die Umleitung zur Anmeldung nahm den Kasten samt
Code mit, und der Code ist nirgends noch einmal abrufbar (in der Datenbank
steht nur seine Pruefsumme). Ergebnis: ausgesperrt, Rueckweg nur ueber
einen Eingriff auf dem Server.
Bitter daran: Die Rueckfrage sagte das sogar an ("Deine aktuelle Sitzung
wird sofort beendet") -- als Warnung formuliert, nicht als Fehler erkannt.
Ein Ablauf, den man nur mit gutem Timing ueberlebt, ist keiner.
DREI RIEGEL, NICHT EINER
1. DIE EIGENE SITZUNG BLEIBT. codeNeu() beendet weiterhin alle Sitzungen
der Person -- ausser der einen, aus der heraus der Code gerade erneuert
wird. Sicherheitlich kostet das nichts: Wer den Code tauscht, hat sich
mit genau dieser Sitzung soeben ausgewiesen und haelt sie in Haenden.
Alle ANDEREN Geraete fliegen weiterhin hinaus -- das ist der Sinn der
Uebung und wird eigens geprueft.
2. DER KASTEN BLEIBT STEHEN. Solange ein frischer Code angezeigt wird,
springt die Personenseite nicht mehr von selbst zur Anmeldung. Selbst
wenn eine Sitzung aus einem anderen Grund endet (Zeitablauf, Neustart),
bleibt der Code lesbar, bis er weggeklickt ist -- mit einem Hinweis,
ihn jetzt abzuschreiben. Ein Code, den man nicht mehr lesen kann, ist
schlimmer als gar keiner.
3. EINE TUER VON AUSSEN: tools/notfall-code.sh. Setzt auf dem Server einen
neuen Code, zeigt ihn an und loescht die Sperre nach acht Fehlversuchen
gleich mit. Weigert sich, als root zu laufen (sonst gehoerten die
Hilfsdateien der Datenbank danach root und der Dienst koennte nicht
mehr schreiben). Dokumentiert als "Fall 0" in WIEDERHERSTELLUNG.md --
dem ersten Fall, den man aufschlaegt, wenn nichts kaputt ist ausser
dem Zugang.
KEIN fest hinterlegter Notfall-Code in der Anwendung: Der waere eine
Hintertuer, die dauerhaft offensteht, fuer jeden der sie findet, ohne
dass es auffiele. Dieser Weg verlangt Zugang zum Server, hinterlaesst
einen Protokolleintrag, und es gibt nichts zu erraten.
Die Rueckfrage sagt jetzt, was wirklich passiert, statt vor etwas zu
warnen, das nicht mehr eintritt.
GEPRUEFT: server/pruef-code.mjs, 17 Pruefungen -- darunter die Gegenprobe,
dass das ZWEITE Geraet derselben Person sehr wohl abgemeldet wird (ohne sie
waere die Reparatur auf dem Weg, einen neuen Code zur Formalie zu machen),
dass der alte Code nicht mehr gilt, dass beim Erneuern eines FREMDEN Codes
weiterhin alles hinausfliegt, und dass die Seite nach dem Erzeugen nicht
zur Anmeldung springt. Das Notfall-Skript ist mit beiden Wegen getestet
(Treffer und unbekannter Name). Bestehende Laeufe gruen: Rollen 97,
Personen-Liste 33, Sicht 48.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
15cfee1078 |
Gesamtlauf aller Pruefungen -- und eine Pruefung, die nichts geprueft hat
Auf "CHECK MAL AB, DASS ALLES PERFEKT LAEUFT. ALLES."
Ergebnis: 29 von 29 Pruefdateien in Ordnung, 1178 von 1178 Einzelpunkten
bestanden. Der Server laeuft ohne Neustart, alle 33 oeffentlichen Seiten
antworten, keine Schnittstelle gibt ohne Anmeldung etwas heraus.
DER EIGENTLICHE FUND WAR EINE PRUEFUNG, DIE NICHTS GEPRUEFT HAT.
tools/alles-pruefen.mjs zaehlt nicht nur gruen/rot, sondern die ANZAHL
der Einzelpruefungen je Datei -- und pruef-kopf-messen.mjs kam auf NULL.
Sie war nie eine Pruefung, sondern ein reines Messwerkzeug: Sie druckte
Zahlen und endete IMMER mit Exitcode 0. Weil sie "pruef-..." heisst, lief
sie bei jedem Gesamtlauf mit und meldete brav "bestanden". Sie konnte
gar nicht fehlschlagen.
Mit blossem Auge war das nicht zu sehen: Der Lauf war gruen, die Datei
stand unauffaellig zwischen den anderen. Aufgefallen ist es nur, weil
die Zahl mitgezaehlt wurde -- ein gruener Lauf ist eben kein Beweis,
solange nicht auch die Anzahl stimmt.
ZWEI KONSEQUENZEN:
1. Die Datei prueft jetzt wirklich. Die beiden Zahlen, um die es geht,
wurden laengst gemessen und werden nun auch beurteilt:
UEBERSTAND muss 0 sein
ABMELDEN ERREICHBAR muss wahr sein -- es ist der einzige Weg wieder
heraus; liegt er ausserhalb des Bildes, sitzt
man fest.
Die Messwerte bleiben in der Ausgabe: Sie sagen bei einem Fehlschlag
sofort, WELCHES Teil zu breit ist.
Gegenprobe gemacht: Mit einer unerfuellbaren Bedingung meldet sie
"3 Breiten gemessen, 3 beanstandet" und endet mit 1. Sie kann also
anschlagen -- vorher nicht.
2. Der Laeufer wertet "0 Pruefungen" ab jetzt als FEHLER, nicht als
Erfolg. Sonst haette dieselbe Falle beim naechsten Mal wieder
jemanden getaeuscht.
Der Laeufer selbst bleibt im Ordner tools/: Er faengt einen Fehlschlag
je Datei ab (statt beim ersten abzubrechen), zeigt die Dauer mit -- eine
Pruefung, die ploetzlich dreimal so lange braucht, wartet meist auf
etwas, das es nicht mehr gibt -- und druckt am Ende die Gesamtzahl.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
2bebab156b |
Profilbild gebaendigt, Steckbrief von der Creator-Akte getrennt
ZWEI FEHLER, DIE FILIPE GESEHEN HAT.
1. DAS PROFILBILD LAG UEBER DER HALBEN SEITE. Als Patrick sein Bild
hochlud, zog sich ein roter Balken quer ueber die Startseite.
Ursache: Die CSS-Regel .wer__bild hat GEFEHLT. Das Element wurde in
kopf.js erzeugt, die Regel dazu nie geschrieben -- und ein <img> ohne
Groessenangabe nimmt seine natuerliche Groesse an, bei einem Handyfoto
also mehrere tausend Pixel. Dazu fehlte overflow: hidden am Traeger.
WARUM KEINE PRUEFUNG DAS GEFUNDEN HAT: Sie lud ein 1x1-Pixel-PNG hoch.
Klein, schnell, von Hand gebaut -- und voellig unfaehig, irgendetwas
zu ueberdecken. Die Pruefung war gruen, der Fehler war da, und gesehen
hat ihn der Nutzer. Sie arbeitet jetzt mit einem 1200x1200-Bild, also
in der Groesse, die wirklich hochgeladen wird, und misst danach: Bleibt
das Bild in seinem 28-px-Feld, ragt es irgendwo heraus, laeuft die
Seite ueber. Gegenprobe gemacht -- ohne die Regel meldet sie
1200x1200 in 28x28 und 918 px Ueberlauf.
2. ZWEI PERSONEN AUF EINEM BILDSCHIRM. Auf der Profilseite stand oben
"Profil: SpongBobSchwammKopf" und mittendrin "MEIN PROFIL: Dogfather".
Niemand konnte sagen, welche Angabe zu wem gehoert.
Es sind auch wirklich zwei verschiedene Dinge:
MEIN STECKBRIEF gehoert MIR -- Bild, ein Satz ueber mich, meine
Kanaele. Fuehre ich selbst.
CREATOR-PROFILE die BETREUUNGSAKTE eines anderen Menschen --
Ziele, 90-Tage-Plan, interne Notizen. Fuehren die
Betreuer.
Scouts, Manager und DogFather haben jetzt zwei getrennte Kacheln und
eine eigene Seite (steckbrief.html, serverseitig geschuetzt). Ein
Creator behaelt beides zusammen -- er hat nur eine Seite und sieht
dort ausschliesslich sich selbst. Die Logik liegt in einer eigenen
Datei statt hinten an profil.js: Sie gehoert der angemeldeten Person,
nicht der Akte.
ACHTZEHN KACHELN, ACHTZEHN FARBEN. Die neue Kachel haette sich ihren
Farbton mit den Creator-Profilen geteilt -- zwei Nachbarn in derselben
Farbe. Statt eine Farbe dazuzuerfinden, wurde tools/kachel-farben.mjs
fuer 18 Winkel neu gerechnet, samt der neuen Nachbarschaft im Raster.
Der kleinste Abstand zweier Nachbarn liegt weiterhin bei 100 Grad.
Gefunden hat das die Startseitenpruefung ("17 Farben auf 18 Kacheln").
Die Trennung wird jetzt fuer JEDE Rolle geprueft: welche Kacheln sie
sieht, dass auf der Akte kein fremder Steckbrief steht, und dass die
eigene Seite die richtige Person zeigt. Eine alte Pruefung, die das
Gegenteil verlangte, wurde ersetzt statt stehen gelassen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
766c75b51d |
Die Buehnen richtig: nicht mehr beschnitten, hell, mit Lesespur
Drei handfeste Fehler, alle im Screenshot zu sehen gewesen. 1. ABGESCHNITTEN. background-size stand auf "138% auto". Auf einem 2540 px breiten Schirm wurde das Bild damit 3500 px breit und knapp 2000 px hoch -- in einem 1300 px hohen Fenster fehlten 700 px, und zwar oben. Genau deshalb waren die Figuren riesig und ihre Koepfe weg. Jetzt cover mit Verankerung auf 50% 42%: Die Flaeche wird immer gefuellt, so wenig wie noetig skaliert, und wenn etwas beschnitten werden muss, dann Fussboden und Decke -- nicht die Gesichter. 2. DIE VIGNETTE LAG FALSCH HERUM. Abgedunkelt wurde die MITTE, also genau der Teil, in dem die Szene steht. Man sah die Raender des Bildes und in der Mitte einen grauen Fleck. Jetzt laufen die RAENDER ins Dunkle und die Mitte bleibt klar -- so wie in der Fotografie. 3. ZWEI SCHICHTEN DUNKELHEIT. Zusaetzlich zur Vignette legte der Schleier .86/.58/.44 Schwarz ueber dasselbe Bild. Jetzt nur noch oben (Kopfleiste) und unten (Seitenende) ein Streifen. Dazu die Bilder selbst: Helligkeit 0.66 -> 0.88, mehr Kontrast und Farbe. Sie sind ein BILD, kein Nebel. DIE LESESPUR ist der eigentliche Kniff. In allen neun Szenen stehen HasiDog und DogFather AUSSEN, die Mitte ist frei -- danach wurden sie ausgesucht. Diese Aufteilung wird jetzt benutzt statt bekaempft: aussen bleibt das Bild hell und scharf, in der Mitte (wo der Text steht) wird gedaempft. Der klare Rand ist in jedem Fenster mindestens 400 px breit. Auf dem Handy gibt es daneben keinen Platz, dort deckt die Spur alles. Was frei stand und keine Karte hatte, bekommt eine Lesezone mit backdrop-filter: Der Hintergrund bleibt in Farbe und Form sichtbar, wird an dieser Stelle aber weichgezeichnet. Die billige Loesung waere gewesen, das Bild wieder abzudunkeln -- damit waere man dort, wo man angefangen hat. ZWEITER FUND AN DER EIGENEN KONTRASTMESSUNG. Sie tastete ausschliesslich NEBEN dem Element ab. Traegt ein Text seine Flaeche aber selbst (eine Beschriftung mit Hintergrund und Polsterung), liegt jeder Punkt daneben schon auf dem Bild -- gemeldet wurden 1,89:1, obwohl der Text auf deckender Flaeche steht und tadellos lesbar ist. Jetzt wird zuerst in der eigenen Polsterung gemessen, also auf dem, worauf der Text WIRKLICH liegt. (Der erste Fund an derselben Stelle war gestern: Sie mass Text gegen Nachbartext.) Nach dem Aufhellen einmal komplett durchgemessen: von sieben roten Stellen auf null. Schlechtester Wert jetzt 4,70:1 bei 4,5:1 Norm. Die Bilder sind groesser geworden (580 KB -> 1,8 MB fuer alle achtzehn), weil weniger Dunkelheit weniger komprimierbar ist. Geladen wird pro Seite genau eine: 42 bis 132 KB. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
fc4fde0f02 |
Buehnen hell, Flaechen dicht - und die Kopfleiste wieder kurz
DIE BUEHNEN WAREN ZU DUNKEL. Bei 0.42 Helligkeit sah man Schemen, nicht die Szene -- "zu dunkel und sieht ganz komisch aus" traf es genau. Jetzt 0.66 mit etwas mehr Farbe (1.08), die Vignette schwaecher (0.52 statt 0.72). Die Bilder kommen durch. MOEGLICH IST DAS NUR MIT DEM GEGENZUG: Alle Kacheln, Karten und Spalten lagen bei 2 bis 3 Prozent WEISS -- also praktisch durchsichtig. Solange der Hintergrund fast schwarz war, fiel das nicht auf; sobald er hell wurde, lief das Bild mitten durch den Text. Jetzt gibt es --flaeche (rgba(9,13,22,.78)), eine deckende dunkle Flaeche, und 44 Stellen in 16 Dateien holen sich ihre Farbe von dort. Der Unterschied ist genau der, den Filipe beschrieben hat: Der Hintergrund bleibt sichtbar, aber ZWISCHEN den Kacheln -- nicht hinter der Schrift. Wer die Flaechen kuenftig dichter oder durchlaessiger will, aendert eine einzige Zeile statt 44. Die Kacheln selbst tragen ihren Farbton jetzt AUF der Flaeche (color-mix mit --flaeche statt mit transparent) -- dadurch bleibt die Farbe erkennbar, ohne dass die Kachel durchsichtig wird. DIE KOPFLEISTE war so breit wie das ganze Fenster, obwohl der Text kurz ist: .marke__text stand auf flex: 1 1 auto. Das war unsichtbar, solange der Schriftzug nur Text war -- seit er einen Rahmen traegt, lief die Pille quer durchs Bild. Jetzt flex: 0 1 auto (schrumpfen ja, wachsen nein). Gemessen: 375 px statt 1280. Kontrast an echten Bildpunkten auf allen sechs Seiten nachgemessen -- haelt trotz des viel helleren Bildes (schlechtester Wert 4,69:1). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
0391a91d14 |
Neun Buehnen statt einer - jede Seite hat ihre eigene Szene
Filipe hat neun Bilder geschickt, damit es VERSCHIEDENE Hintergruende gibt. Benutzt wurde davon genau eines (das Studio), die uebrigen acht lagen unbenutzt im Ordner -- lounge.png und skyline.png sogar schon fertig kopiert. Zu Recht beanstandet. Jetzt wird aus jeder Szene eine Buehne, breit und schmal, und jede Seite bekommt die, die zu ihr passt: studio Startseite der neutrale Ort, alles beginnt hier showbuehne Dashboard, Review die grosse Buehne, alles im Blick garage Aufgaben, Technik Werkstatt, hier wird gearbeitet skyline Kalender Nacht ueber der Stadt, Zeit lounge Calls, Community Sitzecke, hier wird geredet arena Dateien, Wissen Archiv hinter dem Portal halle Profil, Personen die Halle, in der jemand steht wald Start-Check, Scouting der Weg, den man erst sucht portal Content, LIVE Durchgang, hier entsteht etwas Die Zuordnung steht in bereiche.js -- derselben Liste, aus der schon Zeichen und Farbton kommen. Eine Seite traegt damit dreierlei aus einer einzigen Quelle: Farbe, Zeichen und Buehne. Sie koennen nicht auseinanderlaufen. Alle neun bekommen dieselbe Behandlung (abgedunkelt auf 0.42, Vignette in der Mitte, wo der Text steht, oben ausgeblendet, wo die Kopfleiste sitzt). Sie sehen verschieden aus und verhalten sich gleich -- eine Buehne, die je Seite anders hell waere, waere Unruhe statt Vielfalt. Der schmale Ausschnitt ist je Szene ein anderer, weil ein auf 9:16 gequetschtes Breitbild nur noch Wand zeigt; genommen wird der Bereich, in dem die Figuren stehen. 18 Dateien, zusammen 580 KB -- pro Seite werden davon zwei geladen (breit ODER schmal), also 16 bis 48 KB. Die Rohbilder waren 2,4 MB je Stueck. Kontrast auf allen sechs geprueften Seiten an echten Bildpunkten nachgemessen: haelt (schlechtester Wert 4,59:1). FUND: Die Buehnenpruefung suchte nach "buehne-breit" und fand die neuen Namen nicht mehr -- sie meldete "die Buehne liegt im Hintergrund: FEHL", obwohl sie da war. Die Seitenpruefung sieht jetzt nach, dass jede Seite ihre Szene hat UND dass das Bild wirklich ankommt: Ein data-buehne ohne passende CSS-Regel waere still wirkungslos. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
e74254263f |
Buehne aus den echten Marken-Bildern, Kopfleiste und Begruessung neu
Filipe hatte recht, und zwar zweifach: Der Husky war der FALSCHE (ein fremder Neon-Husky aus dem alten Bilderordner statt DogFather), und zwei in die Ecken geklebte Bilder ergeben noch kein Bild. DIE BUEHNE, zweiter Anlauf. Aus den zehn geschickten Bildern das Studio gewaehlt, in dem HasiDog und DogFather stehen -- nicht aus Geschmack, sondern wegen der ANORDNUNG: Die beiden stehen weit aussen, die Mitte ist dunkel. Genau dort steht der Inhalt. Bei den Bildern mit den Figuren in der Mitte waeren sie hinter dem Text gelandet. Ueber die ganze Flaeche, fest an der Scheibe, 138 % breit: Bei 100 % staenden die beiden bei 20 % und 78 % der Breite -- mitten unter der Textspalte. Vergroessert man das Bild ueber die Scheibe hinaus, wandern sie nach aussen (rund 9 % und 88 %) und der leere Hallenboden liegt dort, wo gelesen wird. Ein Bild groesser zu machen, damit WENIGER davon im Weg ist, klingt verkehrt und ist genau richtig. Fuer schmale Schirme ein eigener Hochkant-Ausschnitt derselben Szene -- ein auf 9:16 gequetschtes Breitbild zeigt nur noch Wand. 1,9 MB PNG -> 28 KB WebP. DIE VIER STELLEN aus den Bildschirmfotos: * Kopfleiste: der DogFather-Kopf davor. Als MASKE aus dem Logo gerechnet (Dunkelheit wird Deckkraft), nicht als Bild -- so laesst er sich im Stil einfaerben; ein fertig eingefaerbtes Bild muesste man fuer jede Farbe neu bauen. 114 KB -> 3 KB. * "Dogfather · DogFather" war der peinlichste Punkt: Name und Rolle lasen sich gleich, es sah nach einem Fehler aus. Jetzt drei unterscheidbare Dinge -- Zeichen mit dem Anfangsbuchstaben, Name, Rolle als Marke in ihrer Farbe. Gebaut in kopf.js, EINMAL statt vierzehnmal: Jede Seitendatei setzte diese Zeile bisher selbst zusammen. * Begruessung: leuchtender Strich, groesserer Gruss, auslaufende Trennlinie. Dieselben Striche vor "WAS IST DRAN" und "DEINE AUFGABEN" -- so gehoert sichtbar zusammen, was zusammengehoert. ZWEI EIGENE FEHLER, die die Pruefungen gefunden haben: 1. Ich hatte Verlaeufe IM TEXT gebaut (background-clip mit durchsichtiger Schrift). Sah gut aus, und der Kontrasttest meldete 1,05:1 -- zu Recht. Durchsichtige Schrift haengt an einer einzigen Technik; faellt sie aus (Kontrastmodus, Druck, aeltere Browser), ist der Text UNSICHTBAR statt nur anders gefaerbt. Das ist kein Schoenheitsfehler, das ist ein Ausfall. Jetzt feste Farbe mit einem Hauch Leuchten. 2. Auf dem Handy stand der Abmelden-Knopf 9 px aus dem Bild. Die Suche nach der Ursache ging zuerst in die Irre -- der Test nannte das Wasserzeichen, das aber von seiner Kachel sauber abgeschnitten wird und nur seine Masse meldet. Gemessen war es die Marke: 209 px + 139 px rechte Gruppe passten nicht in 390 px. Auf dem Handy bleibt jetzt nur der Kopf stehen; der Markenzug steht zwei Zeilen tiefer ohnehin als Ueberschrift. Fuer Vorleseprogramme bleibt er im Dokument. Und einmal habe ich mir beim Ersetzen eines CSS-Blocks das halbe Stylesheet geloescht (die Kachel-Regeln lagen zwischen den beiden Suchmarken). Aufgefallen sofort am Bildschirmfoto, zurueckgeholt aus Git, danach zeilengenau ersetzt. 118 Pruefungen, alle gruen. Der Kontrast wird weiterhin an echten Bildpunkten gemessen, jetzt an bis zu 35 Stellen je Seite. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
fcebbd18bb |
Workspace: Casper und HasiDog als Buehne im Hintergrund
Filipe: "der hintergrund soll genau so krass und speziell sein, benutz
den hasen und husky."
Gefunden in assets/img: hero-husky.png (Casper, neonblau auf dunkel --
farblich genau die Oberflaeche) und char-hasidog.jpg (HasiDog). Der
Sticker "HasiDog & Casper" hat bestaetigt, dass die beiden zusammen
gehoeren.
Beide sitzen FEST an der Scheibe in den unteren Ecken -- sie scrollen
nicht mit, sondern stehen da wie ein Buehnenbild, vor dem gearbeitet
wird. Die Mitte bleibt frei, dort steht der Inhalt. HasiDog ist weiter
nach aussen geschoben und schwaecher als Casper: Er ist heller, sein
Gesicht zieht den Blick staerker, und direkt neben einer Kachel wuerde
man ihn ansehen statt der Kachel.
AUFBEREITET STATT EINGEBUNDEN (tools/buehne-bauen.mjs):
* stark abgedunkelt und leicht entsaettigt -- Stimmung, kein Motiv
* weiche Raender ins Bild EINGERECHNET. Ein hartes Rechteck saehe nach
aufgeklebtem Foto aus; und eine Maske ueber ein 900-Pixel-Bild kostet
bei jedem Bildaufbau Rechenzeit.
* 290 KB PNG -> 41 KB WebP, 110 KB -> 32 KB
Gerechnet mit dem Browser, der ohnehin fuer die Pruefungen da ist -- kein
Bildprogramm, keine neue Abhaengigkeit, 0 EUR.
GEPRUEFT WIRD NICHT, OB ES HUEBSCH IST, sondern ob der Text noch lesbar
ist -- an echten BILDPUNKTEN aus dem fertigen Bildschirmfoto, nicht an
der Farbangabe im Stil. Die weiss naemlich nichts davon, was
dahinterliegt. Gemessen wird der Untergrund direkt NEBEN jedem sichtbaren
Text, auf fuenf Seiten, auf Computer und Handy: bis zu 34 Stellen je
Seite gegen den WCAG-Massstab (4,5:1, bei grosser Schrift 3:1).
UND DAS HAT SOFORT EINEN ALTEN FEHLER GEFUNDEN: Der leiseste Grauton
(--text-still) lag bei 4,43:1 -- knapp UNTER der Norm. Das war schon
lange so, nur hatte es nie jemand nachgerechnet, weil bisher niemand an
echten Bildpunkten gemessen hat. Von #6d7d92 auf #75859a angehoben; jetzt
4,95:1 auf dem hellsten Untergrund. Das gilt fuer JEDE Seite, nicht nur
fuer die mit dem Hintergrundbild.
Schlechtester Wert jetzt: 4,97:1. Alle 30 Messungen bestanden.
Nebenbei eine Falle in den Pruefungen selbst: Ein haengengebliebener
Testserver auf demselben Port fing die Anfragen ab -- der Test sprach mit
einem ALTEN Prozess und dessen anderer Datenbank, und meldete "no such
table". Der Port ist jetzt ein anderer; die Lehre steht hier, weil das
Bild "Server laeuft" trotzdem erscheint und alles richtig aussieht.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
7673c12136 |
Startseite: 17 eigene Farben -- gerechnet, nicht gewaehlt
Filipe: "jede kiste soll seine eigene farbe haben. und die kacheln sollen viel spezieller, viel spezieller sein." BEIM ERSTEN MAL HATTE ICH ABGELEHNT, und das war zu bequem. Mein Einwand stimmte zwar -- ein Versuch mit frei gewaehlten Farben ergab Paare mit 1,4 Grad Abstand, also praktisch dieselbe Farbe -- aber daraus "geht nicht" zu machen, war falsch. Es geht, man muss nur rechnen. Der Denkfehler war die Annahme, alle 17 muessten sich voneinander unterscheiden. Das Auge vergleicht aber nur, was NEBENEINANDER liegt. Also: 1. 17 Toene, gleichmaessig um den Farbkreis (je 21 Grad), gerechnet in OKLCH -- dort sind gleiche Abstaende auch fuer das Auge gleich. Helligkeit und Farbstaerke konstant, damit keine sich vordraengt. Wo die Farbstaerke den darstellbaren Bereich verliesse (Gelb und Gruen frueher als der Rest), wird sie gesenkt, bis sie hineinpasst. 2. Die ZUORDNUNG ist eine Suche ueber die tatsaechlichen Nachbarschaften im Raster (nebeneinander UND untereinander). Gesucht: die Anordnung mit dem groesstmoeglichen kleinsten Nachbarabstand. Ergebnis: mindestens 105,9 Grad zwischen allen Nachbarn. 3. Unter allen Anordnungen, die eine harte Untergrenze schaffen, gewinnt die passendste: LIVE rot, Technik gelb, Reports gruen, Personen rot-gold, Schutz stahlblau. Steht als tools/kachel-farben.mjs im Repo, mit festem Zufallsstartwert -- derselbe Lauf ergibt dieselben Farben. Wer Kacheln umsortiert, aendert die Nachbarschaften und muss es neu laufen lassen; das steht auch in start.js. Geprueft: Helligkeitsband, Farbstaerke und Kontrast bestehen fuer alle siebzehn gegen genau diesen Hintergrund. VIEL SPEZIELLER -- das WASSERZEICHEN: Jede Kachel traegt ihr eigenes Zeichen noch einmal, riesig, angeschnitten und fast unsichtbar (7 % Deckung) in der Ecke. Das ist der Grund, warum siebzehn Kacheln nicht mehr wie siebzehn Kaesten aussehen: Jede bekommt eine eigene grosse Form, ohne dass ein einziges zusaetzliches Bild geladen wird -- es ist derselbe Pfad, nur groesser. Bewusst so schwach, dass man es nicht liest, sondern nur spuert. Beim Ueberfahren wird es etwas deutlicher und wandert zwei Pixel. Dazu: Zeichenfeld 46 auf 52 px mit farbigem Schein darunter, Name auf 1,06 rem, mehr Polsterung. Alles mit prefers-reduced-motion abgesichert. 44 Pruefungen. Neu: dass jede Kachel eine EIGENE Farbe hat (17 Farben auf 17 Kacheln, gemessen an der berechneten Strichfarbe) und dass das Wasserzeichen da und schwach genug ist. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
17c605b93d |
Sicherung: laeuft von allein, und ein stiller Ausfall faellt auf
Filipe zu Recht: "wieso soll ich diesen Befehl einmal die Woche eingeben,
ich will einmal und dass es dann alleine laeuft". Ein Befehl, den man
selbst eintippen muss, wird irgendwann vergessen -- und zwar genau dann,
wenn er zaehlt.
tools/sicherung-einrichten.ps1 legt eine Windows-Aufgabe an: taeglich
statt woechentlich (der Lauf dauert Sekunden, bei woechentlich waere die
Kopie im schlimmsten Fall sechs Tage alt), 13:30 statt nachts (der
Rechner laeuft nicht durch), und mit StartWhenAvailable -- war der
Rechner aus, holt Windows den Lauf beim naechsten Hochfahren nach. Ohne
diesen Schalter fiele jeder verpasste Termin ersatzlos aus. Braucht keine
Administratorrechte und macht am Ende gleich einen Probelauf: eine
Einrichtung, die man nicht ausprobiert, ist eine Vermutung.
Damit entsteht aber ein neues, schlimmeres Problem: Wenn die Aufgabe
still klemmt oder der Rechner wochenlang aus ist, merkt es NIEMAND. Man
glaubt, man haette eine Kopie ausser Haus, und hat sie nicht. Deshalb
meldet sich das Abholskript nach jedem Lauf beim Server zurueck, und die
Automationen-Seite zeigt, wie alt die Kopie ist -- nach zehn Tagen wird
sie auffaellig.
Die Rueckmeldung laeuft ueber einen eigenen langen Schluessel, nicht ueber
einen Zugangscode: Das Skript laeuft unbeaufsichtigt und muesste einen
Code sonst dauerhaft auf der Platte halten. Der Schluessel kann NUR einen
Zeitstempel setzen -- nichts lesen, nichts aendern. Verglichen wird
zeitunabhaengig.
Dabei eine unauffaellige Falle gefunden: In workspace-aufgaben.js steht
`aufgabenRouter.use("/workspace/api", angemeldet)` -- eine Schranke ueber
JEDEN Pfad unter /workspace/api, nicht nur die eigenen. Alle spaeter
eingehaengten Module leben stillschweigend davon. Die Rueckmeldung wurde
dort mit 401 abgewiesen, bevor ihr Schluessel ueberhaupt geprueft wurde;
der richtige Schluessel sah dadurch aus wie ein Fehler in der Pruefung.
Das Sicherungsmodul haengt jetzt VOR dem Aufgabenmodul und bringt seine
eigene Schranke mit -- damit haengt es an keinem anderen Modul mehr.
Ausserdem: Die Ueberschrift im Kasten nennt jetzt den GRUND, aus dem er
gelb ist. Vorher stand dort "Zuletzt gesichert vor 2 Minuten", waehrend
die Farbe wegen der fehlenden Kopie warnte -- die Anzeige widersprach
sich selbst und man sucht den Fehler an der falschen Stelle.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
3f18e1bd69 |
Sicherung: Kopie auf den PC, Dateien mit dabei, Wiederherstellungs-Anleitung
Eine Sicherung, die auf derselben Platte liegt wie das Original, ist keine -- sie hilft gegen versehentliches Loeschen, nicht gegen einen Plattenausfall. tools/sicherung-holen.sh holt sie deshalb auf den Arbeitsrechner. Dabei ist gleich eine zweite Luecke aufgefallen und mitgeschlossen: Die Datenbank kennt hochgeladene Dateien und die PDFs der Bibliothek nur ueber ihren Namen -- die Dateien selbst liegen daneben im Dateisystem und stecken NICHT in der Datenbanksicherung. Nach einem Plattenausfall haette man eine Bibliothek voller Verweise auf PDFs, die es nicht mehr gibt. Werden jetzt mitgeholt. Bewusst nur auf dem PC und nicht zusaetzlich auf dem Server: Eine zweite Kopie auf derselben Platte haette gegen nichts geholfen, was die erste nicht schon ueberlebt haette. Und weil scp nie loescht, bleibt ein einmal geholtes PDF hier erhalten, auch wenn es auf dem Server verschwindet. Geprueft wird mit Node statt mit dem sqlite3-Programm: Node bringt SQLite selbst mit, auf diesem Windows-Rechner ist sqlite3 gar nicht da -- die erste Fassung gab nur Fragezeichen aus und meldete trotzdem "fertig". WIEDERHERSTELLUNG.md beschreibt drei Faelle (aus Versehen geloescht / Datenbank zurueckspielen / Server ganz weg), jeweils als EIN Block zum Kopieren. Der Ruecklauf legt den kaputten Stand mit mv zur Seite statt ihn zu loeschen -- falls die Sicherung aelter war als gedacht. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
c0ac041122 |
Workspace: Versionsstempel gegen Cloudflares 4-Stunden-Cache
Filipe sah die neue Kachel nicht, obwohl sie live war. Ursache gemessen, nicht vermutet: Node liefert : Cache-Control: no-cache (richtig) Cloudflare macht: Cache-Control: max-age=14400 (ueberschreibt es) cf-cache-status: REVALIDATED, Server: cloudflare Cloudflares voreingestellte Browser-Cache-Zeit von vier Stunden setzt sich ueber das no-cache des Servers hinweg -- aber NUR bei JS und CSS. HTML kommt mit DYNAMIC und no-cache immer frisch durch (geprueft an /creator.html und /workspace/). Genau deshalb genuegt ein Stempel in der HTML: neue Seite -> neue Adresse -> Cloudflare kennt sie nicht -> frische Datei. Keine Cloudflare-Einstellung noetig, nichts, worauf ich warten muss. tools/workspace-stempel.mjs setzt den Stempel auf alle 71 Verweise in 13 Dateien. Der Lauf ist wiederholbar: ein vorhandener Stempel wird ersetzt, nicht angehaengt (geprueft). Gehoert ab jetzt vor jeden Deploy, der JS oder CSS im Workspace anfasst. Ich verlasse mich damit nicht mehr aufs Erinnern -- das war der eigentliche Fehler. Co-Authored-By: Claude Opus 5 <[email protected]> |