018d02c3b8f3e93825f2187cf30734ce00f2d491
317
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  DogFatherGitandClaude Opus 5
|
603319a145 |
Arbeitsschloss: zwei Sitzungen sehen sich jetzt
HEUTE ZWEIMAL NUR GUTGEGANGEN. Zwei Claude-Sitzungen arbeiteten
gleichzeitig in diesem Verzeichnis, ohne voneinander zu wissen.
Keine hat etwas falsch gemacht — sie konnten es nicht wissen.
* Beide haben `git add -A` benutzt. Haette die eine
unfestgeschriebene Arbeit der anderen im Baum gehabt, waere sie
mitcommittet worden — unter fremdem Namen, in einer fremden
Begruendung, und niemandem waere es aufgefallen. Nachgesehen:
diesmal war nichts dabei.
* Beide haben den Stempellauf gestartet. Der schreibt 45 Dateien
um. Wer dort eine offen hatte, bekam sie unter den Haenden weg
geaendert.
Dasselbe hat in RunOne am 03.09.2026 sieben Minuten Ausfall
gekostet. Dort gibt es seitdem `arbeitsschloss.sh`; diese Fassung
uebernimmt seine Lehren.
WAS ES IST UND WAS NICHT. Es ist kein Riegel — wer wirklich muss,
kommt vorbei. Es beantwortet die eine Frage, die heute niemand
beantworten konnte: „arbeitet hier gerade sonst jemand?"
Die teuren Fehler liegen bei einem Schloss alle in derselben
Richtung: Es blockiert zu viel und wird deshalb abgeschafft. Also:
* Es blockiert NICHT, wenn das Schloss DEINES ist. RunOnes erste
Fassung fragte „ist abgeschlossen" statt „haelt es jemand
anders" — damit haette, wer ordentlich abschliesst, nie mehr
ausliefern koennen. Dafuer gibt es `fremd`.
* Es VERFAELLT nach zwei Stunden, und dass da jemand war, steht
beim Uebernehmen dabei.
* Es blockiert NICHT, wenn es selbst unlesbar ist — dritter
Ausgang, kein Stillstand.
* Notausgang: SCHLOSS_ZWANG=ja git commit …
DAS PROBLEM, AN DEM RUNONE HAENGT, IST HIER GELOEST. Dort faellt die
Kennung im Zweifel auf den Systembenutzer zurueck, und zwei
Claudian-Sitzungen laufen BEIDE als `claudian` — die Sicherung griff
ausgerechnet zwischen den zwei Faellen nicht, fuer die sie gebaut
wurde. Deshalb ist dort `export ARBEITER=…` Pflicht, und Pflicht
heisst: man vergisst es.
Hier steht `CLAUDE_CODE_SESSION_ID` in jeder Sitzung und ist je
Sitzung verschieden (nachgesehen, 36 Zeichen UUID). Zwei Sitzungen
auf demselben Windows-Benutzer unterscheiden sich damit von selbst,
ohne dass jemand etwas tun muss. Reihenfolge: ARBEITER, dann
Sitzungskennung, dann Benutzername MIT Warnung.
NIEMAND MUSS DARAN DENKEN:
* die beiden Stempelwerkzeuge nehmen es selbst und geben es selbst
frei — auch nach einem Absturz und bei Strg+C (wie `bauen.sh` im
Shop; eines, an das man denken muss, wird vergessen und ab da
umgangen)
* `tools/git-haken/pre-commit` bricht jeden Commit ab, solange
jemand ANDERS das Schloss haelt. Das ist die Stelle, die heute
gefehlt hat: `git add -A` ist der Griff, den man ohne Nachdenken
macht, und gegen einen Reflex hilft keine Regel auf Papier.
* `core.hooksPath` statt `.git/hooks` — letzteres ist nicht
versioniert und waere nach einem Klon genau dann leer, wenn es
gebraucht wird.
GEPRUEFT, server/pruef-arbeitsschloss.mjs: 33 Pruefungen, 0 Fehler —
in einem WEGWERF-Verzeichnis mit eigenem git, damit kein echtes
Schloss angefasst wird. Darunter am echten git:
ohne Schloss committen -> geht (0)
mit dem EIGENEN Schloss -> geht (0)
mit einem FREMDEN Schloss -> bricht ab (1), nennt wer und warum
und es stehen genau ZWEI Commits da, nicht drei
SCHLOSS_ZWANG=ja -> kommt vorbei
ohne das Schloss-Werkzeug -> laesst durch
Dazu: verfallenes Schloss laesst durch, mit laengerer Frist blockt
dasselbe Schloss wieder (Gegenprobe), unlesbarer Inhalt und
unlesbarer Zeitstempel blockieren nicht.
Portnummern nach der neuen Pruefdatei nachgemessen: Pruefbereich bis
5415, 462 Nummern, 0 Kollisionen. pruef-struktur 75/0,
pruef-fingermass 5/0, pruef-ports 10/0.
In DEPLOY.md steht es jetzt an erster Stelle — eine Sicherung, von
der nur der weiss, der sie gebaut hat, ist die erste, die umgangen
wird.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
1afb38258c |
Anfuehrungszeichen: drei Loecher in meiner eigenen Wache
Die zweite Sitzung hat in den Praesentationen des Vaults 83 Stellen
gefunden — und damit auf Loecher in MEINER Wache gezeigt. Ich habe
sie nachgemessen, alle drei waren echt.
LOCH 1 — SIE SAH NUR `server/workspace-*.js`
Also ausgerechnet nicht `workspace.js`, die groesste Datei des
Hauses. Der weitere Filter fand dort sofort drei Stellen:
workspace.js:3404 Kanal „Chat-Moderation" (Protokoll)
workspace.js:3422 „${titel}" -> ${haus} (Protokoll)
workspace.js:3304 „${… || "ohne Titel"}" (siehe Loch 3)
Das ist heute der DRITTE Fall von „die Wache kennt nur die halbe
Menge" — nach pruef-struktur (sah nur die Pruefdateien, nicht die
Anwendung) und pruef-fingermass (sah keine variable Breite).
LOCH 2 — IHR AUSDRUCK GILT JE ZEILE
Ein `„`, das erst in der naechsten Zeile mit einem geraden `"`
schliesst, fiel durch. Gemessen: drei echte Faelle, zwei davon
sichtbarer Seitentext.
workspace/leistung.html „nicht / zugeordnet"
workspace/leistung.html „Backstage-Tabelle / einfuegen"
workspace/assets/js/ampel.js „noch ' + 'verbessern"
Beim letzten laeuft das Zitat ueber eine Zeichenketten-Verkettung.
Neue Regel ohne Fehlalarme: erst alle RICHTIG geschlossenen Paare
entfernen (auch mehrzeilig), dann die einzeilig falschen (die meldet
die alte Regel). Was danach noch ein `„` hat und binnen drei Zeilen
ein gerades `"`, ist ein Fund. Ausgenommen bleibt das Zeichen ALS
WERT — in `content: "„";` und in den Sprachtabellen ist das `„` der
Inhalt und das `"` die Begrenzung.
LOCH 3 — EINE AUSNAHME, DIE EINEN FUND VERSCHLUCKT HAT
Gefunden durch die ZAHL, nicht durch den Blick: Der weitere Filter
liess die Ausnahmen von 12 auf 13 steigen. Die dreizehnte war
`… „${zeile[titelSpalte] || "ohne Titel"}"`
Der Ausdruck blieb am `"` von `"ohne Titel"` haengen; als Inhalt kam
`${zeile[titelSpalte] || ` heraus, das endet auf ein Leerzeichen,
und damit galt „der Satz geht in der naechsten Zeile weiter". Das
echte Schlusszeichen stand hinter dem `}` und war gerade.
Dass die Ausnahmen gezaehlt UND genannt werden, hat ihn gefunden.
Genau dafuer steht die Zeile dort.
Behoben an der Wurzel: Anfuehrungszeichen innerhalb einer Einsetzung
`${…}` werden vorher durch X ersetzt, bei gleicher Laenge und
gleichen Zeilenumbruechen. Das nimmt einer ganzen Sorte
Fehlklassifizierung die Grundlage — die Ausnahmen fielen danach von
13 auf 11.
UND EIN VIERTES, BEIM MESSEN AUFGEFALLEN
`„Van-Van”` in assets/js/data-modis.js schliesst mit U+201D, dem
ENGLISCHEN Zeichen. Zweimal, beide Male in einer DEUTSCHEN Zeile
(`de:` und `"de-CH":`) — nicht einmal eine Uebersetzung, in der es
richtig waere. Eigene Regel dafuer, die keine Ausnahme braucht: Wer
mit `„` oeffnet, schliesst deutsch; in fremdsprachigen Zeilen steht
gar kein `„` am Anfang.
DIE AUSNAHMEZAHL IST JETZT STRENG. Sie stand auf „hoechstens 12" —
damit waere der Anstieg auf 13 nicht aufgefallen. Jetzt genau 11,
wie bei den Grundlinien in pruef-fingermass.
GEPRUEFT: pruef-struktur 68 -> 75 Pruefungen, 0 Fehler. Dazu
leistung-optik 59/0, ampel 47/0, treff 85/0, modi-verborgen 87/0 —
die Seiten, deren Text ich angefasst habe. Steuerzeichen: 830
Dateien, keines. Beide Stempel gesetzt.
Sechs echte Stellen berichtigt, vier neue Gegenproben.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
95c4599baa |
Anfuehrungszeichen: 199 falsche Schlusszeichen im sichtbaren Text
Deutsch oeffnet mit „ und schliesst mit “. An 199 Stellen, die ein
Mensch liest, stand als Schlusszeichen ein GERADES " -- „Nächstes"
statt „Nächstes“. Auf sechzehn oeffentlichen Seiten, in vierzig
Dateien des Workspace und in zwoelf Servermodulen, die Texte
verschicken.
Auf dem Bildschirm sieht man den Unterschied sofort. Beim Schreiben
nicht: Das gerade " liegt auf der Tastatur, die anderen nicht.
WARUM EIN ERSTER ANLAUF ZURUECKGENOMMEN WURDE
Ein gerades " ist an vielen Stellen SYNTAX und kein Schriftzeichen --
Grenze einer Zeichenkette, Grenze eines HTML-Attributs, Zeichen in
einem regulaeren Ausdruck. Wer stumpf ersetzt, macht aus
„<a href="https://… ein kaputtes Attribut
/^["'„»\s]+|["'“«.\s]+$/ einen kaputten Ausdruck
"… nichts „mal " + "eben …" eine kaputte Zeichenkette
DIE UNTERSCHEIDUNG LAEUFT AN MERKMALEN, NICHT AN EINER LISTE
< > = dazwischen -> HTML-Marke oder Attribut
endet auf Leerzeichen -> die Zeichenkette hoert hier auf, der
Satz geht in der naechsten Zeile weiter.
Ein deutsches Schlusszeichen steht NIE
hinter einem Leerzeichen.
Rueckstrich mittendrin -> regulaerer Ausdruck
${ ohne } -> mitten in einem Ausdruck
Eine Liste erlaubter Ausnahmen waere die naechste, die niemand
pflegt. Zwoelf Stellen bleiben dadurch stehen, alle zwoelf einzeln
angesehen und alle zwoelf zu Recht -- dort steht das richtige
Schlusszeichen ohnehin weiter unten im Satz.
Fuenf davon waren allerdings ECHTE Fehler HINTER dem Link
(`…>HasiDog</a>".`) -- die erste Regel hatte nur das Attribut
gesehen, nicht den Satz danach. Gezielt nachgezogen.
Ein maskiertes `\"` in workspace-vorlagen.js (28 Hooks) wird zu “ --
ohne Rueckstrich, denn “ begrenzt nichts.
KOMMENTARE BLEIBEN, WIE SIE SIND. Dort liest es niemand ausser mir;
eine Wache, die auch Kosmetik anmahnt, wird weggeklickt. Beim ersten
Messen fielen ausserdem acht Stellen aus buehne.html faelschlich an,
weil `/* */` in HTML (in <style> und <script>) nicht ausgeblendet
war -- jetzt schon.
DIE WACHE DAZU
pruef-struktur prueft es ab sofort mit derselben Regel: 322 Dateien
mit sichtbarem Text, 0 Funde, und die zwoelf bewussten Ausnahmen
werden GEZAEHLT und genannt (erlaubt: 12). Eine Ausnahme, die niemand
sieht, waechst -- und irgendwann steht der echte Fall darin.
GEPRUEFT
pruef-struktur 59 -> 68 Pruefungen, 0 Fehler
node --check auf allen geaenderten JS-Dateien
nachgemessen: 199 geaendert, 12 mit Grund stehen geblieben
gruen geblieben: bewerbung-aufgaben 163, nachwuchs 262,
reaktion 421, support 63, content 45, terminregel 35, treff 85
Und nachgesehen, ob eine Pruefung noch die alte Schreibweise
ERWARTET: 13 Fundstellen, alle dreizehn nur Text in ihrer eigenen
Ausgabe, keine einzige ein Vergleich mit dem Seitentext.
GEGENPROBE: In reaktion.html ein Schlusszeichen zurueckgedreht ->
„workspace/reaktion.html:546 „Nächstes"", mit Datei und Zeile. Und
die Erkennung einzeln gegen HTML-Attribut, fortgesetzte
Zeichenkette, regulaeren Ausdruck und eingesetzten Wert geprueft.
Stempel gesetzt: workspace 670 Verweise in 45 Dateien, oeffentlich
554 in 48 Seiten.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
2c12b8706e |
Highlights des Teams sind sofort zu sehen -- ohne zweiten Klick
Filipe, 30.09.2026: „wenn wir bei highlights videos rein setzen will
ich nicht mehr dass wir sie freigeben muessen, sobald die reingesetzt
wurden sollen die sofort zu sehen sein."
=====================================================================
WAS ICH NICHT GETAN HABE, UND WARUM NICHT
=====================================================================
Die naheliegende Loesung waere gewesen, `highlight` aus
`TREFF_FREIGABE_BRETTER` zu streichen. Das waere falsch: Auf diesem
Brett laedt auch die COMMUNITY hoch -- Clips, Bilder, Fanart. Im
Quelltext steht woertlich daneben:
„Zwei Schloesser, weil hier fremde Inhalte hochgeladen werden --
Urheberrecht und Anstand sind nichts, was man nachtraeglich
klaert."
Filipe meint nicht das. Er meint: „wenn WIR videos rein setzen".
=====================================================================
DIE UNTERSCHEIDUNG STAND SCHON IM HAUS -- nur nicht im Code
=====================================================================
Derselbe Quelltext sagt ueber die zwei Freigabe-Bretter
Verschiedenes:
ansteht -> der SCHALTER „Im Treff zeigen". Das Team entscheidet
JE TERMIN, ob die Community ihn sieht.
highlight -> der Urheberrechts- und Anstandsfilter.
Ein Filter fragt „hat das jemand angesehen?". Wenn der, der ihn
bedienen darf, den Eintrag SELBST anlegt, ist die Antwort ja. Genau
diese Begruendung steht seit dem Uebernehmen aus dem Katalog im
Haus: „Eine zweite daneben waere keine Sicherheit, sondern ein
Klick."
Ein Schalter dagegen ist eine Entscheidung je Fall. Termine bleiben
deshalb unberuehrt -- sonst stuende jeder interne Termin sofort im
Treff, und danach hat niemand gefragt.
Neu: `FREIGABE_IST_FILTER` und `sofortFreigeben()` in
workspace-treff.js. DIE BEDINGUNG FRAGT DIE ROLLE, NICHT DEN WEG --
waere der Weg gefragt, waere aus dem Filter ein Loch geworden, sobald
jemand einen zweiten Weg baut. Ein Community-Mitglied ab „Stamm"
darf weiterhin einstellen; sein Eintrag wartet auf das Team.
Gerufen an ZWEI Stellen: beim Videoweg und beim Anlegen von Hand.
Beide hatten es bisher nicht.
=====================================================================
DIE VORHANDENE FREIGABEPRUEFUNG BEWEIST DAS NICHT
=====================================================================
Sie blieb nach der Aenderung gruen -- und das zu Recht: Sie legt ihre
Eintraege unmittelbar in der Datenbank an und prueft damit den
Mechanismus, nicht den Weg. Haette ich mich darauf verlassen, waere
eine Aenderung ausgeliefert worden, fuer die keine Zeile spricht.
pruef-treff (+5): DogFather legt ueber den echten Weg an -> die
Community sieht es SOFORT. Ein TERMIN bleibt verborgen. Die Regel
gibt fuer eine Rolle von aussen NICHT frei und fuer Termine
ueberhaupt nicht.
pruef-video (+3): Der Videoweg hat seinen eigenen Aufruf -- genau
dort wird einer vergessen. Geprueft wird die Freigabezeile selbst,
samt Gegenprobe „freigegeben ist nur, was auch angelegt wurde".
Meinen Abschnitt hatte ich erst HINTER das Abschalten des
nachgebauten TikTok-Dienstes gehaengt -- der Kopf der Datei warnt
woertlich davor („das Abschalten steht ganz hinten"). Gelesen habe
ich ihn, als es rot wurde.
UND `pruef-struktur` HAT MEINE EIGENE NEUE ZEILE GEFANGEN: Sie bildete
das Datum aus UTC statt Ortszeit -- zwischen Mitternacht und zwei Uhr
waere es der falsche Tag gewesen. Behoben mit `tagLokal()`, Minuten
nach dem Schreiben.
Gemessen: pruef-treff 85/0 (war 80), pruef-video 74/0 (war 71),
pruef-highlights 31/0, pruef-bereiche-lesend 37/0,
pruef-treff-werkzeuge 73/0, pruef-alle-sehen-es 43/0,
pruef-community-sicht 10/0, pruef-wege-nach-draussen 67/0,
pruef-struktur 44/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
f53791cefd |
Dritte Schicht: auch die Webdesign-Seiten trugen Stempel vom August
Nach den 35 oeffentlichen Seiten und den zwei Zahlen des Service
Workers lag dieselbe Faeulnis noch eine Ebene tiefer:
webdesign/*.html 49x ?v=20260823wd20 (23. August)
1x ?v=20260825wd51 (25. August)
Zwei VERSCHIEDENE Stempel in 13 Seiten, und beide aus dem August. Sie
verweisen auf dieselben Dateien wie die Startseite -- darunter
`main.css` --, und der Server schickt dazu ein Jahr `immutable`. Wer
den Bereich seit August besucht hatte, hatte sie eingefroren, ganz
unabhaengig vom Service Worker.
Dritte Schicht desselben Fehlers an einem Vormittag. Alle drei hatten
dieselbe Ursache: eine Zahl, die ein Mensch pflegen sollte.
Der Stempler nimmt die 13 Seiten jetzt mit -- 554 Verweise in 48
Seiten, EIN Stempel. `workspace/` bleibt ausgenommen: Dort arbeitet
`workspace-stempel.mjs`, und zwei Werkzeuge auf demselben Ordner
waeren zwei Antworten auf dieselbe Frage.
Und die Wache liest sie mit. Haette sie nur die Wurzel gelesen, waere
sie gruen gewesen und haette die Haelfte geprueft -- genau die Sorte
gruener Haken, die nichts bedeutet.
Viermal heute ist mir beim Schreiben ein Backslash durch die Shell
verlorengegangen (`\1` wurde zum Steuerzeichen, `\\` zu nichts).
Die Hausnotiz sagt das seit Langem; ich habe es viermal trotzdem
gemacht. Ab jetzt: alles mit Backslash geht durch das Werkzeug, nicht
durch die Befehlszeile.
Gemessen: pruef-zwischenspeicher 34/0, pruef-bewegung 9/0,
pruef-css-klassen 37/0, pruef-struktur 44/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
12fa0e45ba |
Der Webdesign-Bereich lieferte seit dem 27.08. ein veraltetes main.css aus
Der Stempel-Fund von eben hatte eine Fortsetzung: DEPLOY.md verlangte
seit dem 26.08. „ZWEI Zahlen hochzaehlen", mit Begruendung und
Messwerten daneben.
webdesign/sw.js const CACHE_NAME = "dogfather-webdesign-v64"
assets/js/wd-core.js .register("/webdesign/sw.js?v=64", …)
Gemessen am 30.09.2026 standen beide seit dem 27.08. auf v64 --
waehrend SIEBEN Commits die Dateien geaendert hatten, die der Service
Worker vorhaelt. Er haelt sechs vor, und `/assets/css/main.css` ist
eine davon.
Wer den Webdesign-Bereich einmal geoeffnet hatte, bekam sie seither
aus seinem Zwischenspeicher. Auch die Behebung von heute Vormittag
waere dort nicht angekommen.
EIN KOMMENTAR, DER VOR EINEM FEHLER WARNT, VERHINDERT IHN NICHT. Die
Anleitung war richtig, ausfuehrlich und begruendet. Getan hat es
trotzdem niemand -- fuenf Wochen lang. Das ist dieselbe Lehre wie am
11.09., als ein Warnhinweis neben einer abgeschriebenen Spaltenliste
stand und drei Spalten mit Inhalt trotzdem verlorengingen.
DESHALB MACHT ES JETZT DAS WERKZEUG. `tools/seiten-stempel.mjs`
setzt beide Zahlen auf denselben Stempel wie die Seiten. Passt eines
der zwei Muster nicht mehr, bricht es ab, statt stillschweigend
weiterzulaufen -- sonst waere die Zahl ab da wieder von Hand
gepflegt, und das merkt niemand.
Dass der Vorrat bei jedem Stempeln neu aufgebaut wird, ist Absicht:
sechs kleine Dateien kosten nichts, ein unbemerkt alter Stand fuenf
Wochen.
UND EINE WACHE DAZU. `pruef-zwischenspeicher` prueft jetzt:
· beide Zahlen stehen da
· sie sind GLEICH -- sonst wird der Vorrat geleert, aber der
Service Worker gar nicht erst neu geladen (Cloudflare ersetzt
sein `no-cache` durch vier Stunden)
· die Zahl ist nicht aelter als die vorgehaltenen Dateien
Die Liste der vorgehaltenen Dateien wird AUS DEM SERVICE WORKER
gelesen, nicht abgeschrieben -- eine zweite hier waere die, die beim
naechsten Eintrag auseinanderlaeuft.
Gegenprobe gemacht: die zwei Zahlen um eine Minute auseinander ->
rot, zurueck -> gruen.
DEPLOY.md sagt jetzt, dass es automatisch geht, und nennt den Befund
im Wortlaut daneben.
Gemessen: pruef-zwischenspeicher 34/0 (war 30/0), pruef-bewegung 9/0,
pruef-css-klassen 37/0, pruef-struktur 44/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
d087d02a63 |
Seit fuenf Wochen kam keine Aenderung der Website bei einem wiederkehrenden Besucher an
Gefunden beim Nachgehen des letzten roten Pruefstand-Eintrags. Eine
Kette aus drei Funden, und der dritte wiegt am schwersten.
=====================================================================
1. EINE ENDLOSE BEWEGUNG AUF ETWAS UNSICHTBAREM
=====================================================================
`pruef-browser` scheiterte in WebKit daran, dass der Anmeldeknopf nie
ruhig wurde. Eine der zwei laufenden Bewegungen war:
.knopf__laden { opacity: 0; animation: dreh .8s linear infinite; }
Dieselbe Suche, ueber ALLE 42 Stilvorlagen beider Haeuser und der
Website, fand einen zweiten: An jedem Navigationspunkt der
oeffentlichen Seite lief eine elf Sekunden lange Aurora -- unsichtbar
bis zum Ueberfahren, auf jeder Seite, fuer immer.
Beides faellt niemandem auf: Nichts stuerzt ab, nichts sieht falsch
aus. Es kostet nur Rechenzeit und Akku.
NEU: `server/pruef-bewegung.mjs` mit sechs Gegenproben -- darunter
die wichtigste, dass ein Beispiel IM KOMMENTAR nicht zaehlt (genau
diese Falle hat am 29.09. eine andere Pruefung dreimal getroffen).
Der Gesamtlauf findet sie von selbst, sie laeuft ab heute Nacht mit.
=====================================================================
2. DIE WEBSITE HATTE KEINEN STEMPLER
=====================================================================
Fuer den Workspace gibt es `workspace-stempel.mjs` seit Langem. Die
oeffentliche Website hatte nichts -- dort stand ein VON HAND
gepflegter Stempel, und der ist gealtert wie jede von Hand gepflegte
Liste.
NEU: `tools/seiten-stempel.mjs`, 447 Verweise in 35 Seiten. Er kennt
beide Schreibweisen (mit und ohne fuehrenden Schraegstrich) UND die,
die in einem `style="…url(…)"` stehen -- zwei Hintergrundbilder auf
streamplan.html waeren sonst ein Jahr lang die alten geblieben.
Dieselbe Luecke gab es im Workspace-Stempler schon einmal, dort bei
den App-Symbolen.
=====================================================================
3. UND DESHALB KAM SEIT DEM 27.08. NICHTS MEHR AN
=====================================================================
Stempel in allen 35 Seiten: ?v=20260828e (zuletzt 27.08.)
Aenderungen an assets/ seither: 6 Commits
Der Server dazu: Cache-Control: max-age=31536000, immutable
`immutable` heisst: Der Browser fragt nicht einmal nach. Wer die
Seite einmal geladen hatte, behielt Stilvorlagen und Skripte bis zu
EINEM JAHR.
Darunter der Partnercode DOGI10 auf der gepraegten Muenze und der
komplette Sprachumbau der Oberflaeche. Sie lagen auf dem Server, sie
waren ausgeliefert, und niemand sah sie.
Dieselbe Sorte Fehler wie am 09.09. im Workspace („eine Aenderung ist
nicht gemacht" -- sie war es, nur unsichtbar) und dieselbe wie bei
VanVans Shop: Eine Aenderung ist erst fertig, wenn sie auf der
Adresse ankommt, die der Nutzer benutzt.
`pruef-zwischenspeicher` fragt jetzt nicht mehr nur, OB ein Stempel
dasteht, sondern ob er NEUER ist als die Dateien, auf die er zeigt.
Gegenprobe gemacht: eine Datei zwei Stunden in die Zukunft gesetzt ->
rot, Zeit zurueck -> gruen. Eine Stunde Nachsicht, damit die Wache
nicht bei zwei Minuten anschlaegt und weggeklickt wird.
DEPLOY.md hat jetzt einen Schritt 0 mit beiden Stemplern und dem
Grund dafuer -- der Befund steht im Wortlaut daneben.
Gemessen: pruef-bewegung 9/0, pruef-zwischenspeicher 30/0,
pruef-browser 17/0, pruef-css-klassen 37/0, pruef-struktur 44/0,
pruef-workspace-umzug 3/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
2c3b90d75c |
Benachrichtigungen: die Reaction laedt ein, jedes Haus bekommt sein Gesicht -- und die Videos haengen nicht mehr
Filipe, 29.09.2026: „ich will dass du die benarichtigungen
perfektionierst. dogfather und alle anderen sollen die
benachrichtigungen perfekt von dieser seite hier bekommen."
Und dazu, mit einer Bildschirmaufnahme: „wieso haengen die videos
immer."
=====================================================================
1. WARUM DIE VIDEOS HAENGEN -- zwei Zeilen, eine Rueckkopplung
=====================================================================
Die Aufnahme zeigt den YouTube-Zaehler bei 0:13 von 31:34, vier
Bilder lang unbewegt, in der Mitte der Ladering.
a) `hostMelden()` rechnete `laeuft = getPlayerState() === 1`.
Zustand 3 heisst PUFFERN -- „ich will spielen, mir fehlen
gerade Daten". Der Host meldete in diesem Moment „laeuft
nicht", und zwar sofort, weil `onStateChange` bei jedem
Zustandswechsel meldet.
b) `empfaenger()` fuegt den Host ausdruecklich hinzu, und
`folgen(d)` lief im Ereignisstrom fuer alle -- auch fuer ihn.
Seine eigene Meldung kam zurueck und traf dort auf
if (!stand.laeuft && getPlayerState() === 1) pauseVideo();
Der Host puffert eine halbe Sekunde, laeuft weiter -- und wird vom
Echo seines eigenen Pufferers angehalten. Bei einem 31-Minuten-Video
passiert das in den ersten Sekunden zuverlaessig.
Und alle Zuschauer bekamen bei JEDEM Pufferer des Hosts ein
Pause-Play-Paar. Das ist das Ruckeln, das man fuer die eigene
Leitung haelt.
GEMESSEN, NICHT HERGELEITET (mess-reaktion):
vorher Host=laeuft -> Pufferer gemeldet -> Host=pause
nachher Host=laeuft -> Pufferer gemeldet -> Host=laeuft
Drei neue Messungen, jede mit Gegenprobe:
· ein gemeldeter Pufferer haelt den Host nicht an
· ein ECHTES Anhalten (Knopf gedrueckt) haelt alle an -- sonst
waere das Erste mit kaputtem Gleichlauf bezahlt
· beim Puffern meldet der Server `laeuft=true`; ist der Pufferer
nicht herzustellen, sagt die Messung das (dritter Ausgang)
Beide Behebungen einzeln zurueckgenommen: beide Male rot.
Die erste Fassung der Gegenprobe war selbst falsch -- sie hielt das
Selbstheilen des Systems (der Host meldet alle fuenf Sekunden die
Wahrheit) fuer einen Fehler. Deshalb drueckt sie jetzt den Knopf,
statt eine Meldung zu faelschen.
=====================================================================
2. DIE REACTION LAEDT EIN
=====================================================================
Nachgemessen war `workspace-reaktion.js` STUMM: kein einziges
`benachrichtige`. Beim Einschalten lief `melden("reaktion", ...)`
ueber den Ereignisstrom -- also nur an Leute, die die Seite ohnehin
offen haben. Das Kino machte auf, und die Einladung verliess das Haus
nie. Dasselbe Muster wie bei den Bewerbungen am 23.09.
Neue Art `reaktion_live`, eigene neben `dogfather_live`: Das eine ist
sein Stream auf TikTok, das andere das Kino hier im Haus.
Eingeladen wird, wer ein Geraet hat und NICHT der Agentur gehoert
(`AGENTUR_ROLLEN` -- keine neue Liste). Nicht der, der eingeschaltet
hat. Und nicht zweimal: Eine Bremse von zwei Stunden faengt den
Neustart ab, denn das Merkmal haengt an `gestartet_am` und das wird
bei jedem Wechsel nach live neu gesetzt.
Geprueft Ende zu Ende in pruef-reaktion (+10): Sendung geht auf
Sendung, danach stehen genau fuenf Einladungen in `push_verschickt` --
rechte Hand, linke Hand, Modi, zweimal Community. Nicht der Host,
nicht die Creatorin. Einladung abgeschaltet: sechs Fehlschlaege.
=====================================================================
3. DARF DAS NACHTS KOMMEN? -- drei Antworten statt zwei
=====================================================================
Hier stand `art === "test" || art === "anruf"`, 230 Zeilen von der
Artenliste entfernt. Am 18.09. hat das eine Nacht lang alle Anrufe
verschluckt; behoben wurde damals dieser eine Fall.
GEMESSEN AM LIVE-BESTAND: `dogfather_live` ging an allen sieben
Abenden vom 22. bis 28.09. zwischen 20:28 und 21:06 raus -- jedes Mal
knapp vor der Sperre um 22 Uhr. Geht Filipe einmal um 22:05 live,
bekommt niemand etwas, und niemand erfaehrt warum.
`ruhe` steht jetzt an der ART:
"immer" (Vorgabe) 22-7 gesperrt -- Erinnerungen
"spaet" nur 1-7 -- etwas laeuft GERADE
"nie" nie -- ein Mensch wartet am Hoerer
=====================================================================
4. JEDES HAUS BEKOMMT SEIN GESICHT
=====================================================================
Im Service Worker stand fest `workspace-192.png`. Von acht Menschen
mit angemeldetem Geraet gehoeren fuenf ins Crew-Haus -- die sahen auf
jeder Benachrichtigung das Symbol des Hauses, in dem sie nicht
arbeiten.
Entschieden wird es auf dem SERVER: Im Browser stuende sonst die
verborgene Crew-Adresse in einer Datei ohne Anmeldung (der Befund vom
21.09. bei crew-haus.css) -- und es waere eine zweite Fassung der
Hausteilung. Zweistufig, beide Stufen gibt es schon: die Zielseite,
wenn sie in genau ein Haus gehoert (GEHOERT_ZU_ADRESSE), sonst
`AGENTUR_ROLLEN`.
=====================================================================
5. DAS ABZEICHEN WAR EIN KLOTZ
=====================================================================
`badge` ist das winzige Zeichen in der Statusleiste; Android benutzt
davon NUR den Alphakanal. Dort stand dasselbe `workspace-192.png` --
ein vollflaechiges Quadrat ohne Transparenz, also ein ausgefuellter
Klotz. Es stuerzt nichts ab, deshalb faellt es niemandem auf.
`assets/img/abzeichen-96.png`: der gefuellte Umriss des Huskys, weiss
auf durchsichtig, 3,5 KB. Drei Fassungen gebaut und bei ECHTER Groesse
(24 px) verglichen -- Strichbild zerfaellt, Flaeche traegt.
`server/helfer-png-alpha.mjs` liest den Alphakanal wirklich (PNG
auspacken, Zeilenfilter zuruecknehmen). Eine Pruefung auf „die Datei
gibt es" haette den Klotz nie gefunden -- die Datei gab es ja. Die
Gegenprobe ist der alte Zustand selbst: dieselbe Rechnung meldet auf
`workspace-192.png` „kein Alphakanal, Deckung 100 %".
Das Abzeichen liegt NICHT bei den App-Symbolen -- `pruef-struktur`
verlangt dort zu jedem Namen den vollen Satz und hielt es fuer eine
neue App. Der Waechter hat recht: Ein Abzeichen ist kein App-Symbol.
=====================================================================
Gemessen: mess-reaktion 0, pruef-reaktion 393/0 (+10),
pruef-push-ziel 38/0 (+27), pruef-push 24/0, pruef-push-weg 20/0,
pruef-glocke 36/0, pruef-struktur 44/0, pruef-haus-trennung 100/0.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
a43bc565ec |
Werbeeinblendung fuer die Reaction: Laufband, Wechsel und zwei Bilder in sechs Ecken
Filipe: „ich will dass du auch perfektionierst dass ich einen banner durchlaufen kann, oder erscheinen lassen kann mit werbung drauf ... und ich will auch das dogfather logo oben rechts links unten rechts links genau wie oben unten mittig, so dass ich es wegmachen und hinzufuegen kann." DAS BAND Zwei Arten: „Laufband" zieht die Botschaften von rechts nach links, „Wechsel" blendet sie nacheinander ein. Ein Rabattcode gehoert in den Wechsel -- wer „DOGI10" lesen will, waehrend es wandert, hat es gesehen und nicht behalten. Die Dauer ist einstellbar (8-40 s). Das Band ist Glas, kein Balken: ein Verlauf, unten dicht genug, dass jede Schrift traegt, oben offen. Man sieht das Video weiter. Das Laufband traegt die Folge ZWEIMAL. Wandert es um 50 % seiner Breite, steht die zweite dort, wo die erste war, und der Sprung zurueck ist unsichtbar. Ohne sie entstuende am Ende jedes Durchlaufs eine leere Flaeche -- das sieht aus, als sei die Einblendung abgestuerzt. Wer weniger Bewegung eingestellt hat, bekommt den Wechsel statt des Laufbands -- nicht „aus". Die Werbung soll auch dann wirken. DER RABATTCODE Ein Wort in Grossbuchstaben mit einer Ziffer darin bekommt eine eigene Flaeche in Bernstein: „DOGI10" ja, „VANVAN" nicht. Er ist der einzige Teil der Botschaft, den jemand ABSCHREIBEN soll. Der Text wird NIE als HTML eingesetzt -- die Kennzeichnung baut echte Elemente. Sonst waere ein Eingabefeld im Regiepult ein Weg, fremdes Markup in den Stream zu bringen. DIE ZWEI BILDER Der Husky und der Haekelhase aus der Zusammenarbeit mit VanVan, jeweils an einem von sechs Plaetzen: oben und unten, je links, mittig, rechts -- oder aus. Links und rechts mittig gibt es mit Absicht nicht: dort liegen bei jedem Videodienst die Bedienelemente. Zwei Bilder auf denselben Platz werden abgelehnt (400 ecke_belegt) -- sie laegen uebereinander, und man saehe von beiden nichts. Wer unten steht, weicht dem Band aus, und die Spendentafel rueckt hoch. Beides im Stilblatt ueber `:has`, nicht im Programm: Das Band kennt die Tafel nicht und die Tafel kennt das Band nicht. Der Husky ist schwarz und laege auf dunklem Videobild als Silhouette in der Nacht. Zwei weiche helle Schatten legen eine Kontur darum -- dieselbe Loesung, die jeder Sender fuer sein Wasserzeichen nimmt. IM STREAM, NICHT NUR IM SAAL Beides laeuft in der Buehnenquelle mit, die OBS abfilmt, mit groesserer Schrift (24 statt 18 px) -- ein Stream wird auf einem Handy gesehen, oft in einem Viertel des Bildes. Gemessen: die OFFENE Quelle zieht eine Umschaltung nach, ohne dass die Szene neu geladen werden muss. EINE QUELLE, NICHT DREI `werbungStand()` steht in `reaktion-tabellen.js` und wird von Saal, Regie und Buehne aufgerufen. Erst standen dort drei Abschriften derselben Abfrage; beim Entfernen der Datenbank-Kennung habe ich eine davon geaendert, und die anderen lieferten sie weiter. WAS DIE PRUEFUNGEN DABEI GEFUNDEN HABEN - pruef-buehne: Die Botschaften trugen ihre Datenbank-Kennung in die OBS-Auskunft, die nur mit einem Schluessel geschuetzt ist. Die Feldliste geht jetzt zwei Ebenen tief -- eine abschliessende Liste, die nur die oberste kennt, laesst sich umgehen, indem man ein Feld in ein vorhandenes Objekt legt. - pruef-reaktion: Acht Fehlerwoerter ohne deutschen Satz. Nachgetragen im Hausstil: was nicht geht UND was stattdessen. - pruef-struktur: Die Suche nach totem CSS las `buehne.html` und `tafel.html` nicht -- eine Ausnahme, die fuer eine ganz andere Frage gemacht war (Startbildschirm-Symbol). Sie haette verlangt, `.obs-buehne` zu loeschen, also die Regel, die den Stream traegt. - pruef-tippziele: Erkannte als Anhebung nur `min-height`/`min-width`. Ein `height: 44px` im Fingerblock hebt genauso -- Fehlalarm, und ein Fehlalarm an einer Pruefung, die nach jeder Aenderung laeuft, wird weggeklickt. Zwei Gegenproben dazu. - mess-reaktion: Die Regieleiste am Handy wurde gegen die feste Zahl SIEBEN geprueft und meldete „zeigt nur 8 von 7". Sie zaehlt jetzt selbst. - mess-buehne: Die Konsolenmeldung zeigte dauerhaft vier Fehlschlaege, alle von den Pruefungen selbst bestellt. Jetzt eng gefiltert, benannt, mit Gegenprobe -- und ein UNERWARTETER Fehlschlag in der Quelle, die in den Stream geht, faellt ab sofort durch. Gemessen: mess-reaktion 0, mess-buehne 0, pruef-reaktion 383/0, pruef-buehne 38/0, pruef-tippziele 13/0, pruef-struktur 44/0, pruef-css-klassen 0, pruef-haus-trennung 100/0, pruef-haus-seiten 38/0. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
790b77a73d |
Bei dir klingelt nichts -- und 49 Pruefungen, die blind waren
1. SIEBEN VON ELF HATTEN KEIN GERAET ANGEMELDET.
Gemessen am echten Server, nicht geschaetzt (die Notiz von heute Nacht
sagte acht -- Tamy hat inzwischen eins). Bei ihnen kommt nichts an,
solange die Seite zu ist: keine Aufgabe, kein Termin, kein Anruf.
Die Glocke sagt das seit jeher korrekt und kennt sogar den
iPhone-Sonderfall ("erst zum Home-Bildschirm"). Nur tippt sie niemand
an -- sie ist ein stiller Schalter in einer Leiste.
Jetzt steht es dort, wo man hinsieht: als Hinweis in "Was ist dran?",
mit Weg auf anruf-probe.html. Als OFFENER PUNKT, nicht als Warnung --
eine Warnung, die bei sieben von elf Leuten dauerhaft oben steht, ist
nach einer Woche unsichtbar, und mit ihr die echten daneben. Er
verschwindet von selbst, sobald ein Geraet da ist (Gegenprobe in
pruef-glocke).
Und ohne die "1" davor: Er zaehlt nichts, er beschreibt einen Zustand.
FUENF DER SIEBEN DURFTEN DIE SEITE GAR NICHT OEFFNEN. anruf-probe.html
stand nur Leitung und Modis offen. Das war die falsche Einschraenkung:
Die Seite prueft die ganze Kette bis zur Geraete-Kennung, und die
traegt auch jede Aufgaben- und Terminerinnerung. Jetzt alle Team-Rollen,
ohne "gast" (die Community bekommt keine Erinnerungen).
2. 49 PRUEFUNGEN KONNTEN "BELEGT" NICHT VON "KAPUTT" UNTERSCHEIDEN.
Aufgefallen beim Nachsehen, warum ein Lauf rot war: Es war mein eigener,
haengengebliebener Lauf, der den Port hielt. Kein Befund.
Dabei gemessen: Von 130 Pruefungen hatten 49 keinen Portwaechter, und
SIEBEN Portnummern sind doppelt vergeben (4186, 4188, 4189, 4193, 4198,
4321, 4345). Bei belegtem Port startet der eigene Server STILL nicht --
und alles Weitere misst gegen einen fremden Stand. Das hat in diesem
Haus schon zweimal Stunden gekostet (27.08. und 05.09.).
Der Waechter existierte seit dem 05.09., er war nur nie ausgerollt.
Jetzt haben ihn alle 130. Gegenprobe gemacht: Port belegt ->
Rueckgabewert 3 mit Begruendung statt stillem Messen.
pruef-content bekommt BEIDE Ports -- sie startet zwei Server, und der
zweite gehoert zur Gegenprobe. Nur den ersten zu schuetzen hiesse,
ausgerechnet den Teil ungeschuetzt zu lassen, dem man glaubt.
Die sieben doppelten Nummern bleiben vorerst. Mit dem Waechter ist eine
Kollision jetzt laut statt still; Umnummerieren ist ein eigener Schritt.
3. pruef-rollen IST ABGESTUERZT, SEIT WANN WEISS NIEMAND.
"Target crashed" bei der fuenften Rolle, nach 234 gruenen Pruefungen.
Kein Fehlschlag -- ein toter Browser.
NACHGEMESSEN GEGEN DEN STAND VOR HEUTE (
|
||
|
DogFatherGitandClaude Opus 5
|
f62ade3573 |
Vertraulicher Meldeweg, klappbare Abschnitte, lila Stunden, Logos
Eine Nacht voller Auftraege von Filipe. Der Reihe nach: 1. VERTRAULICH MELDEN -- der groesste neue Teil. "es soll auch eine kategorie also eine hauptkachel geben wo die community leute sich anonym melden koennen wenn sie probleme haben ... rechte hand und dogfather sollen zugriff auf diese anonyme nachrichten haben. also anonym fuer die anderen." WICHTIG, UND ES STEHT SO AUF DER SEITE: "anonym" heisst hier VERTRAULICH. DogFather und die rechte Hand sehen den Namen -- so bestellt und auch richtig, ohne Namen kann man niemandem helfen. Anonym ist es gegenueber allen anderen: kein Modi, kein anderes Mitglied. Wer glaubt, er schreibe unerkannt, schreibt anders und fuehlt sich hinterher getaeuscht -- deshalb steht der Satz im Formular, bevor jemand tippt. Der strikte Wechsel (melden -> warten -> antworten -> warten) ist im SERVER erzwungen, nicht nur im Knopf. Ein ausgegrauter Knopf ist keine Regel. Geschlossen wird nur von der Leitung; abgeschlossene Faelle werden nach 90 Tagen samt Nachrichten geloescht -- hier stehen die empfindlichsten Texte des Hauses. Modis sind ausdruecklich AUSSEN VOR: Sehr oft geht es in diesen Meldungen um eine Moderationsentscheidung. 2. JEDE KATEGORIE LAESST SICH ZUKLAPPEN. "man soll auf dieser seite jede kategorie auf und zu klappen koennen mit einem button ... ueberall wo so eine liste entstehen kann." Das Muster gab es auf der Startseite schon; es steht jetzt als `abschnittKlappbar` in kopf.js und wird von den Brettern und dem Zeitstrahl benutzt. Die Koepfe sind echte <button> (fuer die Tastatur), der Zustand haelt in localStorage, und er haengt je Brett UND Art -- sonst waere "Regel zugeklappt" ueberall gleichzeitig zu. 3. DIE SPRUNGLEISTE SIEHT AUS WIE ETWAS ZUM ANFASSEN. Vorher unterstrichene Woerter, die aussahen wie eine Fusszeile. Jetzt Marken mit Rahmen in einem eigenen Block. 4. DIE STUNDEN SIND LILA. UMGERECHNET, NICHT NEU GEWAEHLT: Jeder der fuenf Verlaufsstopps wurde nach OKLCH zerlegt, der Farbton auf 303 Grad gedreht, zurueckgerechnet. Helligkeit und Buntheit blieben gleich -- eine frei gegriffene Palette waere heller oder bunter geworden, und die Uhr damit unruhiger. 5. DIE KARTEN "UNSERE SEITEN": babyblau und lila, mit schwebenden Logos. Beide Logos wurden zu MASKEN gerechnet (tools/logo-maske.mjs): Die PNG tragen nur Alpha, die Farbe kommt aus dem CSS. Dadurch passt dasselbe Logo in jede Kachel, egal welchen Ton sie hat -- und VanVans 378-KB- Logo wurde dabei zu 109 KB. Vier Stueck je Karte, verschieden gross, zwei Bahnen, 26 bis 41 Sekunden Umlauf. Der erste Versuch war mit 5-9 % Deckkraft praktisch unsichtbar; jetzt 10-16 %. 6. "ENTWICKLUNG" HEISST JETZT "EURE AUFGABEN". Filipe hat recht: Die Kachel fuehrt seit dem 11.09. auf den Katalog -- eine Aufgabenliste. Der Name blieb stehen, weil beim Umhaengen des Ziels niemand ihn angefasst hat. Der Name "Entwicklung" ist damit frei fuer das, was er darunter versteht (Auswertung je Person mit Verlauf und Text) -- das ist noch NICHT gebaut. DREI PRUEFUNGEN, DIE ZUFAELLIG GRUEN WAREN, sind nebenbei aufgefallen: - pruef-kachelraster wartete feste 500 ms auf eine gestaffelte Einblendung und mass vier Reihen, wo drei sind. Jetzt reducedMotion. - pruef-start-ansicht scrollte 600 px und nahm an, danach liege keine Kachel mehr unter dem Zeiger. - pruef-wege-nach-draussen zaehlte das Kachelraster ueber ALLE Gruppen statt je Gruppe. GEMESSEN: pruef-hilfe (neu) 55/0, pruef-wege-nach-draussen 64/0, pruef-jeder-hat-eine-seite 65/0, pruef-community-sicht 10/0, pruef-bereiche-lesend, pruef-steckbrief, pruef-start-ansicht, pruef-kachelraster alle gruen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
3cda64568d |
Die Modi-App bekommt ihre eigene Adresse: crew.dogfather-universe.com
Filipe: "ich will dass es eine eigene app wird" -- und dann "subdomain
machen jetzt sofort". Name von ihm gewaehlt: crew. (unauffaellig).
Auf einem Ursprung laesst sich genau EINE App installieren (w3c/manifest
Nr. 1180). Derselbe Grund, aus dem der Workspace am 06.09. umgezogen ist.
Getrennt wird ueber den HOSTNAMEN: ein Dienst, eine Datenbank, ein
Verzeichnis wie bisher.
DIE REGEL STEHT AN EINER STELLE
crew-adresse.js beantwortet: Darf diese Rolle auf dieser Adresse
angemeldet sein? Eingehaengt in sitzungLesen() -- durch die Funktion geht
jedes der 26 Fachmodule und jede Seitenschranke. Eine Middleware daneben
kann man in einem neuen Modul vergessen, und ein vergessener Rechteschutz
faellt nicht auf, weil dann alles geht.
crew. nur Modis; jeder andere bekommt 401 wie bei einem Tippfehler
workspace. keine Modis mehr; sie bekommen den Weg zur neuen Adresse
localhost UNVERAENDERT
Die dritte Zeile ist der Kern: Die Regel ist eine AUFZAEHLUNG der drei
echten Adressen, nicht "alles ausser crew". Sonst wuerden sieben andere
Pruefdateien ab sofort messen, dass ein Modi nirgends hereinkommt -- gruen,
weil sie nichts mehr finden.
ZWEI APPS, ZWEI NAMEN
Beide Adressen liefern dieselben HTML-Dateien. Auf crew. wird
/workspace/app.webmanifest serverseitig auf crew.webmanifest umgebogen --
so braucht keine der 30 Seiten eine zweite Zeile, die man bei der 31.
vergisst. "Team Dogi" statt "Creator Workspace", eigenes Zeichen:
derselbe Husky, aber ohne Chili (die gehoert zu Spicy Media, nicht zu
ihnen) und im Modi-Ton #5f8a9f.
tools/crew-symbol.mjs erzeugt die sechs Symbole und bricht ab, wenn sie
sich zu weniger als 10 % vom Workspace-Symbol unterscheiden. Gemessen:
43 bis 53 %.
GEMESSEN
pruef-crew-adresse 74 Pruefungen, 0 Fehler -- mit Gegenprobe: der Modi
bekommt in der Datenbank die Rolle 'manager', danach
MUSS dieselbe Sitzung auf crew. ins Leere laufen
pruef-rollen 245, unveraendert (die Regel ist lokal wirkungslos)
pruef-workspace-umzug 31 Faelle
pruef-zwischenspeicher 21 -- ein Stempel im Haus, jetzt ueber 23 Dateien
Der Server kennt die Adresse damit. DNS und Caddy bleiben Filipes Schritt.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
d0ac8ee8d1 |
Das Logo: aus dem Fleck wird wieder ein Hund
Filipe: "kannst du bitte das logo wenn man es installiert auf pc oder handy und oben rechts in der leiste noch perfektionnieren." Beide Stellen hatten denselben Fehler, und er war derselbe wie an mehreren Stellen davor: Der Husky lag als MASKE auf einer Farbflaeche. Von einer Maske zaehlt nur der Alphakanal, und die Vorlage ist rundum freigestellt -- uebrig blieb eine geschlossene Flaeche in Hundeform. Kein Auge, keine Schnauze, kein Ohrinneres. Ein Fleck. Jetzt liegt an beiden Stellen dieselbe Zeichnung im Mischmodus "screen" ueber einer stahlblauen Silhouette: Schwarz laesst das Fell dunkel, Weiss hebt Gesicht, Ohren und Auge heraus. Gleiche Farben, gleicher Daempfer (.88) -- ein Zeichen, zwei Orte. App-Symbol ausserdem: - Die Chili lief mit ihrem Stiel quer ueber den Fang. Sie ist jetzt gespiegelt, kleiner und liegt hinter dem Hals. - Der Hals endete in einer geraden Kante (die Vorlage ist unten angeschnitten). Eine zweite Maske blendet ihn aus, statt ihn abzuschneiden. - Der Grund war matschig: Rot und Blau trafen sich diagonal genau dort, wo der Kopf steht. Jetzt kaltes Licht oben, warmes unten. - Unter 64 px faellt die Gesichtszeichnung weg, die Chili aber NICHT -- klein erkennt man ein Zeichen zuerst an der Farbe. - Alle Masse haengen an einer Zahl (Groesse der Gruppe), nicht an sechs. Kopfleiste ausserdem: - Die Chili links hatte einen BLAUEN Schein -- aus der Zeit, als dort der Husky stand. Der Schein ist nie mitgewandert. Jetzt warm. - `filter` ersetzt, es ergaenzt nicht: Beim Ueberfahren wurde der Schein geloescht und das Zeichen dabei flacher statt heller. Behoben. Damit die Aenderung auch ankommt: - Der Stempel gilt jetzt auch fuer die App-Symbole und fuer das Manifest. Bilder werden einen Tag zwischengespeichert, das Symbol der INSTALLIERTEN App gar nicht neu geholt -- ohne Stempel haette niemand das neue Zeichen gesehen. - pruef-zwischenspeicher prueft das (18 -> 21 Pruefungen). Werkzeuge: - tools/ausschnitt.mjs (neu): schneidet aus einem Bildschirmfoto ein Stueck heraus und vergroessert die PNG-Datei. Noetig, weil eine Vergroesserung per CSS-transform den Browser NEU rechnen laesst -- ich habe damit 264 px beurteilt und geglaubt, es seien 22, und daraus den falschen Schluss gezogen, ein Gesicht trage bei 22 px nicht. - tools/ansicht.mjs: AUSSCHNITT=<selektor> nimmt nur ein Element auf. - workspace-symbol.mjs: SYMBOL_ZIEL lenkt die Ausgabe um (Entwuerfe ansehen, ohne die sechs echten Dateien zu ueberschreiben), und zwei Gegenproben pruefen jetzt, dass Gesicht und Chili wirklich zu sehen sind -- die alte Pruefung sagte nur "es steht etwas drauf" und haette den Fleck anstandslos durchgewunken. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
5a67ef2948 |
Die Rabattcodes haengen am Konto, nicht mehr am Abo
Filipe: "die partner codes sollen auch schon fuer die leute sichtbar sein die angemeldet sind." Umgestellt, und auf Nachfrage dauerhaft: Rabattcodes sind ab jetzt ein Konto-Vorteil, kein Abo-Vorteil. WARUM DAS MEHR IST ALS EINE BEQUEMLICHKEIT Der alte Riegel verlangte einen Abo-Status. Nachgesehen, statt vermutet: Die Bezahlung auf abonnieren.html steht auf "Coming soon", bis Dogis PayPal-Business-Zugang da ist (der Kommentar dort nennt es beim Namen). Registrieren geht, bezahlen nicht. Der erste echte Partnercode lag damit seit gestern hinter einer Tuer, die sich gar nicht oeffnen laesst -- er waere fuer NIEMANDEN sichtbar gewesen ausser fuer Dogi und VanVan ueber die Rollenvorschau. Entschieden wird jetzt an "supporterToken" (beim Login gesetzt, beim Logout entfernt, supporter.js). Der Abo-Stand wird als Sicherheitsnetz weiter mitgelesen: Niemand soll Zugang verlieren, den er gestern hatte. BEIDE STELLEN, NICHT EINE Die Bedingung steht doppelt im Haus -- an der Kachel auf links.html und an der Seite selbst. Nur eine davon umzustellen erzeugt einen Fehler, den keine der beiden fuer sich zeigt: Man kaeme mit Konto auf die Seite und saehe dort die Sperre. Beide sind umgestellt, tragen den Hinweis aufeinander, und die Pruefung vergleicht sie in jedem Anmeldezustand gegeneinander. TEXTE, DIE SONST GELOGEN HAETTEN "Nur fuer Supporter" auf einer Seite, die ein kostenloses Konto oeffnet, schickt Leute zum Bezahlen fuer etwas, das sie umsonst bekommen. Kopf, Vorspann, Kachelband, Beschreibung und Sperrtext sagen jetzt "Konto", in allen fuenf Sprachen. Die Sperre bietet auf Filipes Wunsch beide Wege an: den kostenlosen zuerst, das Abo daneben -- mit einer Zeile darunter, dass es erst startet, wenn es offiziell live geht. Ohne die waere der zweite Knopf eine Falle. EIN FEHLER, DER SEIT DEM 03.08.2026 DRINSTAND Die Pruefung meldete auf der FREIGESCHALTETEN Kachel weiter "Nur mit Konto" statt "Freigeschaltet". Ursache: Das Skript setzte den Text (`badge.textContent = ...`), aber applyTranslations() schreibt aus dem data-i18n-Attribut zurueck -- und es laeuft danach noch einmal, weil dogiSiteTexteLaden() die Texte aus der Verwaltung holt und dann neu uebersetzt. NACHGEMESSEN STATT HERGELEITET, und die erste Erklaerung war zu schnell: Der Text war schon nach 50 ms falsch, also nicht "irgendwann spaeter ueberschrieben". Der Grund ist, dass TEAM_API_BASIS auf den ECHTEN Worker zeigt -- der Abruf gelingt selbst aus einer lokalen Testseite. Kontroll- versuch mit blockiertem Abruf: derselbe alte Code, und das Band bleibt korrekt. Ursache weg, Fehler weg. Behoben, indem der SCHLUESSEL getauscht wird statt des Textes. Damit schreibt jeder weitere Uebersetzungslauf von selbst das Richtige hin -- auch bei Sprachwechsel, wo die alte Fassung ebenfalls zurueckfiel. Aufgefallen ist es nie, weil bis gestern niemand in den freigeschalteten Zustand kommen konnte. NEBENBEFUND, NICHT ANGEFASST: index.html hat dieselbe Bauart beim Live-Status (#live-text mit data-i18n, Text per Skript gesetzt). Gemessen ist es dort ein Wettlauf zweier Abrufe -- in meinem Lauf gewann der Status um Haaresbreite, und ein Sprachwechsel repariert es dort ohnehin (dogi-sprache-geaendert). Kleiner, aber echt. Auf Ansage. pruef-rabattcodes EXIT=0 (63 Pruefungen, vorher 42). Neu darunter: drei Anmeldezustaende statt zweier -- ausgeloggt, angemeldet ohne Abo, angemeldet mit Abo --, jeder auf BEIDEN Seiten, dazu der Klick auf die Kachel (fuehrt sie wirklich weiter?), die Beschriftung des Bands und als Gegenprobe ein erzwungener Uebersetzungslauf, der den alten Fehler zuverlaessig ausloest. 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
|
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
|
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
|
6541ecbfa7 |
Alte Symboldateien tragen jetzt auch das neue Bild
Filipe hat die Verknuepfungen dreimal neu angelegt und sah trotzdem das alte Symbol. Die Ursache lag nicht an den neuen Dateien - die werden nachweislich korrekt ausgeliefert (36 von 36 live byteweise geprueft), sondern an vier Altlasten: /assets/img/favicon.png 256x256 /assets/img/apple-touch-icon.png 180x180 /assets/img/icon-192.png 192x192 /assets/img/icon-512.png 512x512 Die stammen aus der Zeit vor dem Umbau auf app-symbole/ und werden von KEINER Seite mehr verlinkt - geprueft mit einer Suche ueber alle html, js, json und webmanifest: nur noch sw.js und main.js nennen sie. Aber Chrome hat sich das Favicon dieser Domain gemerkt, als favicon.png noch verlinkt war, und gibt es nicht mehr her: Beim Anlegen einer Verknuepfung nimmt Windows dieses alte Bild, egal was im HTML steht. Auf Filipes Bildschirm trugen deshalb ZWEI verschiedene Verknuepfungen dasselbe Symbol - das war der entscheidende Hinweis, denn zwei Apps mit verschiedenen Manifesten koennen unmoeglich dasselbe Symbol haben. Statt zu hoffen, dass ein Zwischenspeicher irgendwann aufgibt, tragen die alten Adressen jetzt einfach dasselbe Bild wie die neuen. Damit ist es egal, welche ein Programm nimmt. Dazu im Service Worker: CACHE_NAME auf v2 hochgezaehlt - activate() loescht dadurch den alten Zwischenspeicher samt altem Symbol. Und SHELL_ASSETS zeigt nicht mehr auf die verwaisten icon-192/-512, sondern auf die Adressen aus dem Manifest. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
ed12d75404 |
App-Symbole: Kennzeichen-Plakette, damit man sie klein unterscheiden kann
Die Symbole waren farblich schon verschieden, zeigten aber alle dasselbe Motiv. Gemessen in echter Groesse: Bei 24px (Startmenue) und 32px (Taskleiste) ist der Husky nur noch ein Fleck - es unterscheidet sie einzig die Farbe, und Webdesign, Kundenportal und WD-Verwaltung liegen im Lila-Rosa-Bereich dicht beieinander. Jedes Symbol traegt jetzt unten rechts eine Plakette mit einem Kennzeichen in der Farbe der App: Hauptseite * DogiCrew-Verwaltung C Webdesign W Kundenportal K WD-Verwaltung V Creator Workspace A Der Husky bleibt gross und dominant - die Marke wird nicht angetastet, die Plakette traegt nur die Unterscheidung. Die maskable-Fassungen haben eine EIGENE Plakettenlage, und die ist gerechnet, nicht geschaetzt: Android behaelt nur den Kreis mit 80% Durchmesser (Radius 0.40 ab Mitte). Der aeusserste Punkt der Plakette liegt bei sqrt(2)*(0.5-rand-groesse/2)+groesse/2. Der erste Entwurf kam damit auf 0.417 - die Plakette waere auf dem Handy angeschnitten worden. Mit rand 0.190 und groesse 0.280 sind es 0.380, also mit Reserve drin. Erzeugt aus den vorhandenen Symbolen (nicht neu gezeichnet), 36 Dateien: je App 32, 180, 192, 512 und die beiden maskable. Jede Datei danach einzeln aus dem PNG-Kopf vermessen - 36 von 36 haben die richtige Groesse und Inhalt. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
5119e0139d |
vanvan.html: Coming-soon-Knopf wird Link zu VAN'S DIY
Der silberne Knopf trug 'Coming soon...' und war gesperrt (aria-disabled, kein href). Er heisst jetzt 'VAN`S DIY' und fuehrt zu https://vans-diy-bastelbedarf.com/ - in neuem Tab, mit rel=noopener, wie der TikTok-Knopf darueber und die uebrigen Shop-Verweise im Projekt. aria-disabled musste weg: sonst meldet ein Bildschirmleser 'nicht bedienbar', obwohl der Knopf jetzt bedienbar ist. Dabei aufgefallen und mitbehoben: Die Beschriftung brach auf schmalen Geraeten mitten im Wort um ('VAN / `S / DIY' bei 390px, Knopf 117px statt 89px hoch), weil die Sektion auf vanvan.html auch auf dem Handy zweispaltig bleibt - ein Inline-Style ueberschreibt dort die Regel aus @media(max-width:620px). .btn-silver bekommt deshalb white-space:nowrap. Das behebt zugleich den gleichen Umbruch von 'Coming soon...' auf abonnieren.html bei 320px. Geprueft im echten Browser: 52 Pruefungen (5 Sprachen x Text, href, kein aria-disabled, target, rel, sichtbar, bedienbar) plus echter Klick, der auf vans-diy-bastelbedarf.com landet - alle gruen, Gegenprobe schlaegt an. Zusaetzlich 180 Messungen ueber 4 Seiten x 9 Breiten x 5 Sprachen (270 Knoepfe angesehen): kein Umbruch, kein Ueberlauf. Ohne den nowrap-Fix meldet dieselbe Messung 30 Befunde. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
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
|
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
|
80639d0bab |
Abnahme vor der Vorstellung: eine tote Kachel gefunden und geschlossen
Morgen wird die Seite als Produkt vorgestellt. Deshalb eine Pruefung,
die es bisher nicht gab: server/pruef-live-abnahme.mjs geht gegen die
ECHTE Domain statt gegen einen Server auf diesem Rechner.
Der Unterschied ist nicht theoretisch. Zwischen "laeuft bei mir" und
"laeuft im Netz" liegen Caddy, Cloudflare, der Cache-Stempel, das
Zertifikat und der Dienst-Neustart -- genau dort ist am 18.08. und am
22.08.2026 schon zweimal etwas haengengeblieben, das lokal tadellos war.
Sie geht 26 Seiten in DREI Gestalten durch:
RECHNER 1440 px
HANDY 390 px, mit Fingerbedienung
INSTALLIERT als App vom Startbildschirm -- ohne Adresszeile und ohne
Zurueck-Knopf des Browsers. Dort faellt auf, was man mit
Browserleiste nie merkt.
Gemessen je Seite: Konsolenfehler, fehlgeschlagene Anfragen, seitlicher
Ueberlauf, tote Verweise, fehlende Bilder, ueberhaupt Inhalt, Titel.
Dazu die App selbst: Manifest, Name, Start ohne Browserleiste, alle vier
Startbildschirm-Symbole einzeln abgefragt, Hintergrunddienst angemeldet
und aktiv.
DER EINE ECHTE FUND: Auf links.html war die Kachel "Merchandise / Shop"
ein <a href="#"> -- sie sah aus wie ein Verweis, liess sich anklicken
und tat nichts. Auf der Kachel steht "Folgt in Kuerze"; genau dann darf
sie nicht klickbar sein. Ein Knopf, der nichts tut, ist schlimmer als
gar keiner: Man drueckt ihn zweimal und haelt die Seite fuer kaputt.
Jetzt ein <div> mit denselben Klassen -- gleiches Aussehen, kein
Versprechen mehr, das die Seite nicht halten kann.
ZWEI FEHLALARME, beide in MEINER Pruefung, beide aufgeschrieben:
* Sie meldete "fehlende Bilder" auf zwei Seiten. Es waren versteckte
Platzhalter (<img hidden> ohne src), die JavaScript erst fuellt --
der Normalzustand. Jetzt zaehlen nur sichtbare Bilder mit Quelle.
* Sie meldete "manifest.json nicht ladbar", waehrend curl gleichzeitig
200 lieferte. Die Probe stand noch auf about:blank und holte von
dort -- fremde Herkunft, der Browser lehnt ab. Sie hat also nicht
die Seite geprueft, sondern sich selbst. Erst navigieren, dann
messen.
Die beiden anderen href="#" auf der Seite (index.html, streamplan.html)
bleiben: Sie sind versteckt und werden von JavaScript gefuellt, sobald
es etwas zu verlinken gibt. Geprueft wird nur, was man auch sieht.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
95f54fd211 |
Die ganze Oberflaeche spricht jetzt dieselbe Sprache wie die Zeichen
"bring alles auf dieses niveau -- texte, kacheln, hinweise, titel,
buttons, einfach alles."
Berechtigt, und der Fehler war meiner: Die Kachelzeichen sind Koerper
geworden, alles andere blieb flach. Ein plastisches Zeichen neben einem
gemalten Knopf sieht nicht nach "teilweise gut" aus, sondern nach
Versehen.
Ab jetzt gelten fuer JEDES Bauteil dieselben drei Regeln -- dieselben,
nach denen auch die Zeichen gebaut sind:
1. LICHT VON OBEN. Eine helle Kante an der Oberkante, in der Mitte am
staerksten, nach aussen auslaufend. Echtes Licht auf einer Kante
sieht so aus; eine durchgehend gleich helle Linie ist ein Strich.
2. TIEFE NACH UNTEN. Ein versetzter Schatten -- wie bei jedem
Gegenstand, der auf etwas liegt. Ohne ihn klebt ein Element auf der
Seite, statt darauf zu liegen.
3. VERLAUF STATT FLAECHE. Oben eine Spur heller als unten. Kaum zu
sehen, aber ohne ihn bleibt jede Flaeche tot.
Und eine vierte, nur fuer Bedienbares:
4. WAS MAN DRUECKT, GEHT HINEIN. Beim Klick kehrt sich die Woelbung um:
Licht nach unten, Schatten nach oben. Das ist der Unterschied
zwischen "es passiert etwas" und "ich habe etwas gedrueckt".
ANGEFASST -- beide Seiten, nicht nur eine:
Workspace (gate.css, gilt auf jeder Seite)
Knoepfe, Schritte, Abmelden, Stufenknoepfe, Suchknopf
Eingabefelder, Auswahlfelder, Suchfeld -- die bekommen die Woelbung
ABSICHTLICH ANDERSHERUM: Ein Feld, in das man schreibt, ist eine
Mulde, kein Knopf. Licht unten, Schatten oben.
Marken, Rollenabzeichen, Zaehler, Filterchips
Hinweisflaechen, Notizen, Call-Raum, Codekasten
Ueberschriften und Schilder
Oeffentliche Seite (main.css)
Knoepfe (btn, btn-primary, btn-outline) samt geschliffener Kante
Marken und Abzeichen
Ueberschriften
Der Textschatten aendert die FARBE nicht -- die Kontrastpruefung misst
weiter denselben Wert --, legt den Text aber auf die Seite, statt ihn in
den Hintergrund zu mischen.
Alles gedeckt. Diese Bauteile stehen zu Dutzenden auf einer Seite, und
was einzeln beeindruckt, blendet im Dutzend.
GEPRUEFT, zehn Laeufe, alle gruen: Buehne 38 (Textkontrast an echten
Bildpunkten), Rollen 97, Handy 50, Formulare 19, Grosscheck 15,
Lesbarkeit 14 -- dazu die vier Laeufe der oeffentlichen Seite
(Startseite, Design, Barrierefreiheit, Tastaturbedienung).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
44716fa54b |
Aus Zeichnungen werden Gegenstaende -- Kacheln der GANZEN Seite
"ich will dass die krank realistisch sind, und alle kacheln durch die
ganze website perfektionieren."
DIE ZEICHEN bekommen die Beleuchtung, die man aus der Wirklichkeit
kennt -- vier Lagen statt einer:
KOERPER gefuellte Grundform, oben satt, unten auslaufend
EIGENSCHATTEN eine dunkle Lage, die von unten hereinkriecht. Ein
Koerper ist unten dunkler als oben; ohne das bleibt
jede Flaeche eine Farbflaeche
GLANZ die Spiegelung, schmal ueber die obere Haelfte
KONTUR mit ZWEI Lichtquellen: oben das Hauptlicht (fast weiss),
in der Mitte der Eigenton, unten STREULICHT vom
Untergrund. Der letzte Stopp ist der Unterschied
zwischen "Zeichnung" und "Ding" -- ohne ihn laeuft jede
Form nach unten ins Dunkle aus.
Dazu ein SCHLAGSCHATTEN auf die Plakette, versetzt nach unten statt
mittig. Er ist der Grund, warum das Zeichen ueber der Flaeche schwebt
statt darauf zu liegen.
DIE PLAKETTE bekommt eine KOERNUNG -- eine sehr feine, unregelmaessige
Struktur. Das ist der Unterschied zwischen "am Rechner gemacht" und
"Gegenstand": Eine makellos glatte Farbflaeche gibt es in der
Wirklichkeit nicht, und das Auge erkennt das sofort, auch wenn niemand
sagen koennte woran. Eingebettetes Rauschen, keine Bilddatei -- kostet
nichts zu laden und kann nicht fehlen.
DIE KACHELN, und zwar BEIDE Systeme:
workspace .kachel -- bekam Tiefe nach unten (fehlte ganz: die Kachel
klebte auf dem Hintergrund statt darauf zu liegen) und eine
Lichtkante, die in der Mitte am hellsten ist und nach
aussen auslaeuft. Echtes Licht auf einer Kante sieht so
aus; eine durchgehend gleich helle Linie ist ein Strich.
oeffentlich .card (133 Vorkommen auf der Website) -- war eine Flaeche
mit einem Rand. Jetzt: Verlauf statt Flaeche, Lichtkante
oben, Schatten nach unten. Beim Ueberfahren hebt sie sich,
der Schatten wird laenger, die Kante heller.
Alles bleibt gedeckt. Diese Kacheln stehen zu Dutzenden auf einer Seite
-- was einzeln beeindruckt, blendet im Dutzend.
GEPRUEFT: Buehne 38 (Textkontrast an echten Bildpunkten), Startansicht
133, Rollen 97, Handy 50, Grosscheck 15, Lesbarkeit 14, dazu die drei
Laeufe der oeffentlichen Seite (Startseite, Design, Barrierefreiheit).
Alle gruen.
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
|
43264c0990 |
Startseite hochwertiger: Typografie, Weltfarben, Event-Karte
Wunsch 27.08.2026: "soll nur noch hochwertiger und professioneller
aussehen." Kein neues Design, sondern die Details, die den Unterschied
zwischen "gemacht" und "gesetzt" ausmachen:
- Ueberschrift enger gesetzt (-.022em, Zeilenabstand 1.08, text-wrap:
balance). Bei 4rem wirkt normale Laufweite auseinandergefallen; die
drei Zeilen verteilen sich jetzt gleichmaessig statt mit kurzer
Restzeile.
- Jede Welt-Kachel traegt die Farbe IHRER Welt statt dreimal derselben:
Babyblau, Silber, das gedeckte Rot von Spicy Media. Die Werte sind
nicht erfunden, sondern die --accent-Toene der drei Themendateien.
- Plaketten ("WELT 1") klein, in Versalien, weit gesperrt -- liest sich
als Kapitelmarke statt als Beschriftung.
- Event-Karte: Datum als gesperrte Versalzeile (ordnet sich dem Titel
unter), "Mehr erfahren" als ruhiger Knopf statt nacktem Textlink,
Haarlinie am Bild, Text auf 5 Zeilen begrenzt -- damit nicht die
Textlaenge aus der Verwaltung das Aussehen der Startseite bestimmt und
bei zwei Events beide Kacheln gleich hoch sind (geprueft: 572/572px).
ZWEI FUNDE BEIM PRUEFEN, BEIDE WICHTIGER ALS DER FEINSCHLIFF:
1. INHALTSRICHTLINIE UND ZEILENENDEN. Der Browser rechnet die Pruefsumme
eines Inline-Skripts NICHT ueber die Bytes der Datei, sondern ueber
den Text im Dokument -- und der HTML-Parser ersetzt beim Einlesen
jedes CR LF durch LF (HTML-Spezifikation, "preprocessing the input
stream"). Eine Datei mit Windows-Zeilenenden ergibt serverseitig also
eine ANDERE Summe, und die Seite fuehrt ihr eigenes Skript nicht mehr
aus: kein Live-Status, keine Events, nichts. Live war es unauffaellig
(Linux-Auscheckung hat LF), auf dem Windows-Rechner sofort tot
(core.autocrlf=true). inhaltsrichtlinie.js vereinheitlicht jetzt vor
dem Rechnen auf LF -- das ist die Summe, die der Browser wirklich
bildet, und macht die Richtlinie unabhaengig davon, mit welchem
Werkzeug eine Datei zuletzt gespeichert wurde.
2. TESTS MIT FESTEM PORT KOENNEN LUEGEN. Drei Server aus frueheren
Laeufen liefen noch. Neue Testlaeufe konnten ihren Port nicht belegen,
starben still -- und massen weiter gegen den ALTEN Code. Ergebnis
waren Fehlermeldungen zu einem laengst behobenen Fehler. pruef-musik,
pruef-kasse und pruef-startseite suchen sich jetzt einen freien Port.
Neuer Test pruef-startseite.mjs (19 Pruefungen) mit FESTEN Event-Daten:
Beim Pruefen kam einmal nichts vom Server, der Abschnitt blieb leer und
der Test haette "kein Fehler" gemeldet, obwohl er nichts gesehen hat.
Geprueft werden Maske am Artwork, genau eine Kachel bei einem Event,
volle Breite, saubere Textkuerzung auf ganze Zeilen, eigene Weltfarben,
zwei gleich hohe Kacheln bei zwei Events, Handy ohne Ueberlauf.
Alles gruen: startseite 19, musik 17, kasse 15, inhaltsrichtlinie 22,
handy 56.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
57d90b9905 |
4 weitere überdimensionierte Bilder verkleinert + Cache-Buster vereinheitlicht
pruef-bildgroessen.mjs (neu) misst systematisch über alle Seiten (Desktop + Handy, mal Pixeldichte), welche <img> größer sind als ihre größte Anzeige. Fand 4 klare Fälle: streamer-mascot.jpg 900px, gezeigt 230px -> 480px 360->119 KB bewerben-poster-dogfather.jpg 800px, gezeigt 204px -> 440px 199->80 KB avatar-bananenstift.jpg 1122px, gezeigt 108px -> 400px 167->25 KB avatar-marina.jpg 1086px, gezeigt 90px -> 400px 157->20 KB Zusammen 639 KB gespart. Avatare bewusst auf 400px (großzügiger als die 2x-Anzeige), falls doch mal eine Detailansicht kommt. Qualität am Maskottchen per Screenshot geprüft: scharf, Schrift lesbar, keine Artefakte. CACHE-BUSTER-BUG behoben: 69 Ressourcen-Verweise standen noch auf dem alten Marker "20260827hero" (einer sogar auf "20260820h"), der Rest auf "20260828c". Verschiedene Seiten luden dieselbe main.css/js unter verschiedenen Cache-Keys -- wiederkehrende Besucher der hero-Seiten bekamen bei Änderungen eine veraltete gecachte Fassung. Die Playwright-Tests sahen das nie (leerer Cache). Jetzt alle 245 einheitlich auf 20260828d; der bewusste admin-auth "-jedesmal"-Marker bleibt unberührt. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
508009ecc7 |
Startseite: Hintergrund-Kanten weg, "Event des Jahres" neu aufgebaut
Gemeldet 27.08.2026: "es ueberschneidet den hintergrund sieht irgendwie scheisse aus." 1. HARTE KANTEN IM HINTERGRUND Das scharfe Trio-Artwork lag als CSS-Hintergrund mit "contain" hinter der Seite und endete an einer messerscharfen Linie (bei 1366x800 exakt bei 570px und 1345px); darueber/darunter lag sichtbar die verwaschene Fassung. Das las sich wie ein aufgeklebtes Band quer ueber der Seite. Jetzt ein echtes <img>, das an seinen EIGENEN Raendern weich in die verwaschene Ebene uebergeht. Entscheidend: Die Maske haengt am Bild, nicht am Fenster -- als CSS-Hintergrund war das unmoeglich, weil die Kante je nach Fensterformat wandert. 2. "EVENT DES JAHRES" -- 700px tote Flaeche Eine 480px schmale Kachel sass zentriert in einer 1180px breiten Kiste, die selbst Rahmen und Hintergrund trug: drei Rahmen ineinander um einen einzigen Inhalt, links und rechts je 350px Leere. Jetzt volle Breite mit Bild links / Text rechts, die umgebende Kiste ist rahmenlos. Hoehe von 656px auf 332px, ohne dass Inhalt verloren geht -- das Bild ist dabei doppelt so gross wie vorher. 3. Welt-Kacheln mit einer Spur Milchglas und feinem Lichtsaum, damit sie zur Szene gehoeren statt als flache Rechtecke daraufzuliegen. BEIM BAUEN GEFUNDEN UND KORRIGIERT: Der erste Entwurf hat die versteckte zweite Event-Kachel wieder sichtbar gemacht (leere Kachel mit einsamem "Mehr erfahren"). Ursache ist die im Code zweimal dokumentierte Falle: ".jahres-event-card[hidden]" ist genau so stark wie eine Zwei-Klassen-Regel und verliert gegen die spaetere. Deshalb steht in den neuen Regeln ueberall :not([hidden]). Versionsnummern von main.css/main.js hochgesetzt -- Assets werden mit max-age=14400 ausgeliefert, sonst haette Dogi die Aenderung bis zu vier Stunden nicht gesehen. Geprueft: pruef-handy (56), pruef-barrierefrei (60), pruef-design (0 Fundstellen), pruef-blickfang (13), pruef-assets (67), pruef-musik (17) -- alle gruen. Der Musik-Knopf holt seine Farben jetzt aus dem <img> statt aus dem CSS-Hintergrund (main.js), sonst waere er ausgerechnet auf der Startseite auf die Ersatzfarbe zurueckgefallen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
e2a40313d6 |
Startseiten-Bilder verkleinert: 3 überdimensionierte Fotos (687 KB gespart)
Der Performance-Check (pruef-tempo.mjs, neu) zeigte die Startseite mit 3,5 MB, überwiegend Bilder. Drei davon waren viel größer als je angezeigt (gemessen über Desktop + Handy, alle Seiten, mal Pixeldichte): card-dogfather.jpg 1200px, angezeigt max 359px -> 720px 534->201 KB casper-4.jpg 1400px, angezeigt max 359px -> 720px 350->115 KB casper-3.jpg 1400px, angezeigt max 359px -> 720px 259->140 KB 720px = doppelte Anzeigebreite, also auch auf Retina-Displays scharf. Qualität an zwei Motiven per Screenshot geprüft: keine sichtbaren Artefakte, Schrift und Details erhalten. card-vanvan bewusst UNANGETASTET: wird auf vanvan.html mit 578 CSS-px gezeigt, bräuchte für Retina ~1156px -- das 1200er ist dort passend. Verkleinert über Browser-Canvas (kein ImageMagick/sharp verfügbar; das gefundene "convert" war das Windows-Dateisystem-Tool, nicht ImageMagick). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
5b2a1daabe |
Öffentliche Avatar-Uploads vor dem Absenden verkleinern (1,1 MB -> ~40 KB)
Der Performance-Check (pruef-tempo.mjs, neu) fand als größte Einzel- ressource ein 1,1-MB-Profilbild, ausgeliefert an jeden Besucher der Startseite und von stimmen.html -- angezeigt wird es handgroß. Ursache: Das öffentliche Stimmen-Formular (stimmen.js) lud Profilbilder ROH hoch. Die Bildaufbereitung vom 27.08. bekam nur die Verwaltung, nicht das öffentliche Formular. So landete das Kamera-Foto in voller Auflösung auf dem Server. - bild-vorbereiten.js (neu): die Verkleinerungs-Funktion, jetzt einmal und parametrisierbar (maxBreite). Verwaltung nutzt weiter 1600px, Avatare 512px. Test pruef-bild-vorbereiten.mjs: 8/8, u.a. 512er-Avatar ~40 KB statt >1 MB. - stimmen.js: verkleinert vor dem Upload (window.bildVorbereiten mit maxBreite 512); fällt die Funktion aus, wird das Original genommen -- kein Upload darf daran scheitern. - stimmen.html: lädt bild-vorbereiten.js; veralteten Kommentar richtiggestellt (behauptete "kein Upload", obwohl es seit 21.08. einen gibt -- mit Bremse, Typ-/Größenlimit, Freigabe-Pflicht). Zwei neue Checks als bleibende Absicherung mit committet: pruef-links.mjs (41 interne Ziele, 0 kaputt) und pruef-assets.mjs (67 Ressourcen, 0 fehlen). NOCH OFFEN: verwaltung.html hat noch eine eigene, identische Inline-Kopie der Funktion -- die Zusammenführung ist ein eigener, testbarer Schritt (das Inline-Skript dort ist groß und die Verwaltung hinter dem Gate schwer live zu testen). Das bestehende 1,1-MB-Bild auf dem Server bleibt, bis es neu hochgeladen/ersetzt wird. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
7960b212c8 |
Verwaltung: Zugangscode wieder bei jedem Oeffnen noetig
Dogi hat die Lockerung vom 04.08.2026 ("Code nur einmal am Tag") heute
zurueckgenommen. Gewaehlte Auspraegung: Code beim OEFFNEN der Seite/App,
Neuladen im selben Tab wirft nicht raus, keine Abmeldung bei Untaetigkeit.
- admin-auth.js legt die Sitzung jetzt in sessionStorage statt in
localStorage: gehoert zum Tab/App-Fenster, uebersteht F5 und Uploads,
ist beim naechsten Oeffnen weg. Zweiter Tab = eigener Code.
- Alte localStorage-Sitzung wird beim ersten Laden einmalig entfernt --
sonst waere Dogi trotz Umstellung mit dem alten Token weiter drin und
ein Token laege monatelang im Browser herum.
- Versionsnummer des Skripts hochgesetzt: Caddy liefert Assets mit
max-age=14400, der Browser haette die alte Anmelde-Logik sonst bis zu
vier Stunden weiterbenutzt.
- Der 24-Std-Ablauf bleibt als Rueckfallsicherung fuer tagelang offene
Tabs; der Server erzwingt dieselbe Grenze weiterhin selbst.
- Neuer Test pruef-verwaltung-anmeldung.mjs (12 Pruefungen: Gate beim
Oeffnen, alte Sitzung wirkungslos, falscher/richtiger Code, F5 bleibt
drin, neuer Tab verlangt Code, Abmelden raeumt auf, Untaetigkeit meldet
NICHT ab).
- pruef-verwaltung-kacheln.mjs: echten Aufruf ans Live-Backend abgefangen
und auf die Supporter-Zeilen gewartet -- der Test hatte dadurch
gelegentlich falsch gemeldet.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
68b421b79a |
Zahlungen-Bühne: besserer Bildausschnitt statt flacher Mitte
Das cryo-kristall-Motiv (Zahlungen) ist als einziges der sechs HOCHKANT (702x941) statt quer (1672x941). Auf der breiten 16:9-Bühne zeigt "cover" davon nur einen horizontalen Streifen -- der mittige (Standard center center) traf die unruhigen Kristallsplitter und wirkte flach und beschnitten. Jetzt zeigt Zahlungen den oberen Streifen (background-position center 15%): die eleganten geschwungenen Kristallbänder rechts als Blickfang, links ruhiger dunkler Raum für die Karten -- eine klare Komposition wie bei den anderen Motiven. Nur für Zahlungen überschrieben, die übrigen fünf bleiben mittig. Nebenbei: Der Wert kommt aus --vw-blick, das für alle Bereiche längst definiert, bisher aber nirgends ausgelesen wurde (toter Code). Die neue .vw-buehne-Ausnahme wendet ihn für Zahlungen erstmals an. Service-Worker-Cache v63 -> v64 (beide Stellen), damit Geräte mit der App den neuen Ausschnitt bekommen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
9bd9357185 |
Überschriftenordnung im Hauptinhalt: keine übersprungenen Ebenen mehr
Fünf Seiten hatten einen Sprung h1 -> h3 im Hauptinhalt (die Kachel- Überschriften waren h3, ohne h2 dazwischen). Für Bildschirmleser fehlte damit eine Ebene im "Inhaltsverzeichnis" der Seite (WCAG 1.3.1). Pro Seite der passende, optik-erhaltende Weg -- jede Änderung mit Screenshot bzw. gemessener Schriftgröße gegengeprüft: - werte, kontakt, index: Kachel-h3 -> h2 (die Kacheln SIND die Hauptabschnitte unter der h1). Neue Regel .card > h2 hält die kompakte h3-Optik (1.62rem); Varianten .card-brand/.card-feature bleiben über ihre eigenen h3-Regeln unberührt. Gemessen: 25.92px vorher = nachher. - bewerben: die schon sichtbaren Gruppenlabels (Community / Agentur) waren <span> -> jetzt <h2> mit derselben Klasse. Optik per Screenshot identisch (zentriert, uppercase, Zierstrich). - links: die Kacheln nutzen Spezial-Varianten mit eigenen Größen, ein Tag-Wechsel wäre riskant -> stattdessen eine unsichtbare Gruppen- überschrift (.sr-only, neue Klasse nach WCAG-Standard). Ändert die Optik nicht, vervollständigt aber die Ordnung für Bildschirmleser. Cache-Buster 20260828b (main.css geändert: .card > h2, .sr-only). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
8a2943df35 |
Fußzeilen-Spaltentitel h4 -> h2 (Überschriftenordnung, WCAG 1.3.1)
Die drei Fußzeilen-Spaltentitel (Filipe, Dogi&Hasi & Manager, Mehr) waren <h4>, obwohl der Hauptinhalt bei h2/h3 endet -- ein Sprung in der Überschriftenordnung (h2 -> h4) auf jeder Seite. Für Bildschirmleser ist die Überschriftenliste das Inhaltsverzeichnis; eine übersprungene Ebene stört die Orientierung. Jetzt <h2> (eigenständige Abschnitte unter der Seiten-h1). Die Optik bleibt exakt: Der CSS-Selektor .footer-grid h4 wurde zu .footer-grid h2 umgezogen, die kleine, gedämpfte Darstellung (.85rem, uppercase, Akzentfarbe) überschreibt weiterhin die große globale h2-Größe. Teil des Barrierefreiheits-Durchgangs (pruef-barrierefrei.mjs). Behebt die reinen Fußzeilen-Fälle; die Hauptinhalt-Überschriften folgen separat. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
efe98e32a7 |
Sprung zum Inhalt: Seite ohne Maus in einem Schritt bedienbar
Der Tastatur-Test (pruef-tastatur.mjs, neu) zeigte auf allen fünf geprüften Seiten dasselbe Bild: jedes Bedienelement erreichbar, Fokus durchgehend sichtbar, keine Tastaturfalle -- aber kein Sprunglink. Ohne ihn muss sich jemand, der die Tastatur benutzt, auf JEDER Seite erneut durch das komplette Menü tabben (31 bis 52 Punkte), bevor der eigentliche Inhalt beginnt. WCAG 2.4.1 verlangt genau diesen Ausweg. An einer Stelle gelöst statt in 35 Dateien: renderHeader() in main.js setzt das Sprungziel und stellt den Link davor. Das tabindex="-1" am <main> ist der Teil, der meistens fehlt: ohne ihn verschiebt der Sprung in Chrome und Safari nur die Bildlaufleiste, der Tastaturfokus bleibt in der Navigation -- der nächste Tab landet wieder im Menü und der Sprung war wirkungslos. Cache-Buster auf 20260827a (244 Stellen), sonst bekäme niemand die geänderte main.js und main.css ausgeliefert. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
5deb920f39 |
Fuenf Bilder auf die tatsaechlich benoetigte Groesse gebracht
Die Startseite uebertrug 3,72 MB. Gemessen wurde, wie breit jedes Bild tatsaechlich angezeigt wird -- in Handy- UND Desktop-Ansicht, denn die groessere der beiden bestimmt, wie gross die Datei sein MUSS. Wer nur am Handy misst und danach verkleinert, macht die Desktop-Ansicht unscharf. casper-2.jpg 1050px -> 420px 245 KB -> 47 KB dogfather-casper-2.jpg 1050px -> 420px 182 KB -> 35 KB dogfather-portrait.jpg 933px -> 420px 122 KB -> 35 KB casper-1.jpg 720px -> 420px 153 KB -> 72 KB dogfather-casper-1.jpg 770px -> 400px 150 KB -> 63 KB 600 KB weniger. Die Zielbreiten liegen bewusst ueber dem gemessenen Bedarf (408-411px gemessen, 420px gesetzt): Ein Bild kleiner zu machen als noetig waere schlimmer als ein zu grosses -- Unschaerfe sieht man, ein paar Kilobyte nicht. Qualitaet vor dem Ersetzen angesehen, nicht nur die Zahl: Augen, Fell und Kanten sind bei 420px unveraendert scharf. NICHT ANGEFASST, WEIL ZU KLEIN char-dogfather.jpg und char-hasidog.jpg haben 599px, brauchen auf grossen Schirmen aber 954px. Sie sind also UNSCHAERFER als noetig -- das ist der umgekehrte Fall und gehoert getrennt betrachtet. DER GROESSTE BROCKEN BLEIBT Das Bild "Event des Jahres" ist ein PNG mit 2524 KB -- zwei Drittel der ganzen Startseite. PNG ist fuer ein Foto das falsche Format; als JPEG in der benoetigten Breite (840px) waeren es rund 150 KB. Die Datei liegt unter /var/lib/dogfather-internal/uploads und ist ueber den Verwaltungsbereich hochgeladen worden -- dort wird nicht umgewandelt. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
40714b382e |
"Es fehlt: —." war ein Satz ohne Aussage
Beim optischen Durchsehen der Handy-Aufnahmen gefunden: Im Bereich
Zahlungen stand woertlich
NOCH NICHT EINGERICHTET
Es fehlt: —. Solange sagt das Kundenportal freundlich Bescheid …
Kommt die Liste der fehlenden Angaben leer zurueck -- etwa weil der
Server sie nicht mitschickt --, fiel der Text auf einen Gedankenstrich
zurueck. Man liest eine Fehlermeldung, die nicht sagt, was fehlt, und
sucht dann bei den Zugangsdaten statt bei der Antwort des Servers.
Jetzt zwei getrennte Saetze: einer, wenn bekannt ist WAS fehlt, und
einer fuer den Fall, dass nur bekannt ist DASS etwas fehlt.
Ein Rueckfallwert, der aussieht wie eine Angabe, ist schlechter als
gar keiner -- er beantwortet die Frage scheinbar und schickt einen in
die falsche Richtung.
Nebenbei geprueft und in Ordnung: Der Installationshinweis am unteren
Rand verdeckt nichts dauerhaft; er schafft sich seinen Platz ueber ein
gemessenes padding-bottom (steht seit dem 23.08.2026 so drin, damals
blockierte er den Annehmen-Knopf).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
504965e875 |
Push-Zustand macht der Uebersicht keinen Platz mehr streitig
Ein Gesamtdurchlauf aller Suiten nach dem heutigen Tag hat vier Fehlschlaege in pruef-handy.mjs gezeigt -- eine Regression aus meiner eigenen Arbeit. DIE URSACHE Die Karte zum Zustand der Benachrichtigung stand als ausgewachsener Block ganz oben in der Uebersicht. Auf dem Handy schob sie die erste Kennzahl auf 513 Punkte nach unten: Man oeffnete die Verwaltung und sah zuerst einen Hinweis, die Arbeit erst nach dem Scrollen. ZWEI ANLAEUFE, WEIL DER ERSTE ZU KURZ SPRANG Zuerst wurde nur der GUTE Fall zu einer Zeile. Das half nichts -- im Pruefbrowser sind Benachrichtigungen blockiert, also griff weiterhin der Zweig mit der grossen Karte. Eine Aenderung, die nur den Fall behebt, den man gerade vor Augen hat, ist keine. Jetzt sind alle drei Zustaende eine Zeile mit Punkt und Kurztext, die Erklaerung erst beim Aufklappen. Und der gute Zustand steht am ENDE der Uebersicht statt oben: Eine Bestaetigung, dass nichts zu tun ist, gehoert nicht an den Anfang. Oben bleibt nur, was Handlung verlangt. Ergebnis: 513 -> 204 Punkte bis zum Ende des Kopfbereichs, Laenge 2635 -> 2028. DREI RUNDUNGSFAELLE .wd-btn--klein und zwei summary-Elemente kamen mit Rahmen und Zeilenhoehe auf 43,x Punkte. Der Test vergleicht mit "< 44", gibt aber gerundet "44" aus -- man sucht dann einen Fehler in einer Zahl, die richtig aussieht. Jetzt 44.5 bzw. 46; optisch aendert das nichts. ZWEI PRUEFUNGEN PRAEZISIERT, NICHT AUFGEWEICHT 1. "Erste Zahl im oberen Drittel" mass ab dem Seitenanfang und schlug damit auch bei einer BERECHTIGTEN Warnung an. Ein Test, der Warnungen als Mangel zaehlt, erzieht dazu, sie zu verstecken. Er misst jetzt den festen Kopfbereich (Titel, Suche, Reiter) -- also das, was man nicht wegbekommt. 2. Die Folgepruefung mass zunaechst Punkte-Abstaende. Das war fragil: Der Reiterstreifen klebt beim Scrollen oben fest, eine Messung lieferte -204. Sie zaehlt jetzt HINWEISBLOECKE statt Punkte -- unabhaengig von Scrollposition und Schriftgroesse. Gemeint war ohnehin "hoechstens eine Meldung", nicht "hoechstens 140px". 56/56 in pruef-handy, alle uebrigen Suiten unveraendert gruen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
c03793b25f |
Oberflaeche fuer Auskunft und Loeschung
Sitzt im Kunden-Bereich, zugeklappt. Ein eigener Reiter waere zu prominent fuer etwas, das man vielleicht zweimal im Jahr braucht -- ganz weglassen hiesse, im Ernstfall von Hand durch ein Dutzend Tabellen zu suchen, bei laufender Monatsfrist. DREI SCHRITTE, IN DIESER REIHENFOLGE Auskunft erstellen unschaedlich, jederzeit Loeschvorschau zeigt, was betroffen waere Loeschen nur nach Vorschau, mit doppelter Eingabe Die Auskunft laesst sich als Datei herunterladen, nicht nur ansehen. Man muss sie der Person schicken koennen, und zwar vollstaendig -- abtippen waere der sicherste Weg, etwas zu vergessen. JSON, weil Art. 20 DSGVO ein "gaengiges, maschinenlesbares Format" verlangt. Die Vorschau zeigt beides getrennt: was geloescht wuerde, und was bleiben muss -- mit Grund und mit dem Datum, ab dem es weg darf. Ohne diese Angabe muesste man bei jeder Anfrage neu nachschlagen, welche Frist gilt. Vor dem Loeschen wird die Adresse ein zweites Mal verlangt. Der Unterschied zwischen .de und .com ist ein Buchstabe, die Folge unwiederbringlich. GEPRUEFT Im Handy-Format mit nachgebildeten Antworten: Auskunft zeigt die Bereiche samt Kennzeichnung "aufbewahrungspflichtig", der Herunterladen-Knopf erscheint, die Vorschau trennt richtig, eine abweichende Bestaetigung wird abgelehnt. Kein Ueberlauf, keine Skriptfehler. Die Handy-Suite bleibt bei 25/25, keine Namenskollision. Ein Fehler lag dabei im Test selbst: Playwright prueft die ZULETZT registrierte Route zuerst, und meine allgemeine Auffangregel ueberdeckte die spezifischen. Die Auskunft meldete "nichts gespeichert", obwohl die Oberflaeche richtig arbeitete. Die Endpunkte dazu liegen in server-internal und brauchen noch einen Deploy durch Filipe (/home/dogiintern, Rechte 700). Bis dahin meldet die Oberflaeche einen 404 -- mit dem Hinweis, dass der Server einen Neustart mit dem neuen Stand braucht, statt nur "Fehler" zu sagen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
ea11cefe17 |
Verwaltung auf dem Handy: vier Fehler behoben
Geprueft mit nachgebildeten Daten -- lange Firmennamen, lange
E-Mail-Adressen, mehrstellige Betraege. Eine leere Seite laeuft nie
ueber; die Fehler, um die es geht, entstehen erst mit Inhalt.
1. DAS RASTER DER KOPFZEILE WAR BREITER ALS SEIN BEHAELTER
Auf 390px summierten sich die beiden Spalten auf 372,7px, waehrend die
Leiste nur 358px breit ist. Rasterspalten schrumpfen von sich aus nicht
unter ihren Inhalt ("min-width: auto"). Alles darin schob sich nach
rechts hinaus: die Kopfzeile 8px, der Reiterstreifen 12px.
Sichtbar war das kaum -- der Streifen ist ohnehin wischbar, rechts
fehlte nur ein Stueck Rand. Genau deshalb blieb es liegen: ein Fehler,
der sich als Eigenart tarnt. Jetzt minmax(0, …) plus min-width: 0 an
den Kindern; lange Titel kuerzen mit Auslassungspunkten, statt zu
schieben.
2. DER INSTALLATIONSHINWEIS ZEIGTE DAS FALSCHE SYMBOL
Seit die Verwaltung eine eigene App ist, stand dort weiter der schwarze
Husky. Man las "Als App installieren" neben dem einen Bild und bekam
das andere auf den Startbildschirm. Das Symbol wird jetzt aus dem
Manifest abgeleitet, das die Seite tatsaechlich einbindet -- damit
stimmt es auch fuer jede kuenftige App, ohne dass jemand daran denken
muss.
3. DIE UEBERSICHT BRACH BEI UNVOLLSTAENDIGER ANTWORT AB
d.projekte und d.verlauf wurden ungeprueft mit .length angefasst,
waehrend drei andere Felder ausdruecklich geprueft wurden. Fehlte eine
der Listen, brach die Uebersicht mit "Cannot read properties of
undefined" ab -- und zwar NACH dem Aufbau der oberen Kacheln: Die halbe
Seite stand da, der Rest fehlte kommentarlos. Genau der Fall, den der
Kommentar daneben als "realistisch" beschreibt. Jetzt wird aufgefuellt
statt abgebrochen.
4. ZWEI FEHLALARME IM TEST SELBST
Der Test meldete den Reiterstreifen als Ueberlauf (er ist ein
Wischstreifen -- dass dort etwas ausserhalb liegt, ist sein Sinn) und
eine 1x1-Checkbox als zu kleines Tippziel (bedient wird sie ueber ihr
Label, 315x162 Punkte). Beides wuerde dazu verleiten, Funktionierendes
"zu reparieren". Der Test unterscheidet das jetzt.
Ebenso meldete er "Strg" und "Enter" mit 10,4px -- beide sind auf
schmalen Schirmen laengst ausgeblendet. getComputedStyle liefert auch
fuer verborgene Elemente eine Schriftgroesse; jetzt zaehlt nur
Sichtbares.
25 Pruefungen ueber sechs Bereiche gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
1608521854 |
Verwaltung ist jetzt eine eigene App
Wunsch: "ich will die verwaltungsseite auch getrennt runter laden koennen und installieren koenne." Bisher gab es ein Manifest fuer den ganzen Webdesign-Bereich; die Verwaltung war darin nur eine Verknuepfung. Jetzt hat sie ein eigenes mit eigener "id" -- der Wert, an dem alles haengt: Ohne ihn halten Browser beide fuer dieselbe App, und die zweite Installation ueberschreibt die erste, statt danebenzustehen. EIGENES SYMBOL Zwei gleich aussehende Kacheln auf dem Startbildschirm waeren keine Trennung. Das neue Symbol ist ein Ausschnitt des Eiskristall-Wappens -- dasselbe Motiv, das die Verwaltung ohnehin traegt, und klar unterscheidbar vom schwarzen Husky der oeffentlichen App. Erzeugt aus cryo-wappen.webp in drei Groessen, die beschneidbare Fassung weiter herausgezoomt, damit Android die Spitzen des Wappens nicht abschneidet. Als JPEG statt PNG: 76 statt 385 KB bei 512 Punkten. Bei einem fotografischen Motiv hat PNG nichts zu gewinnen, und 385 KB fuer ein Symbol waeren unverhaeltnismaessig. ⚠️ DER GELTUNGSBEREICH IST ABSICHTLICH WEIT Naheliegend waere "/webdesign/verwaltung" gewesen. Das haette die App unbrauchbar gemacht: Ohne gueltigen Ausweis leitet der Server auf /webdesign/zugang.html um -- ausserhalb des Bereichs, und was ausserhalb liegt, oeffnet der Browser in einem eigenen Fenster. Weil der Zugang beim Schliessen endet, waere das bei fast jedem Start passiert: Man tippt auf die App und landet im Browser. Nachgemessen: verwaltung.html antwortet ohne Ausweis mit 302. EIN STILLES VERSPRECHEN EINGELOEST Die Verknuepfungen zeigen auf "?bereich=anfragen" und dergleichen -- und derselbe Parameter steht in den Push-Meldungen. Ausgewertet hat ihn bisher NIEMAND. Man landete immer auf der Uebersicht, ohne dass etwas kaputt aussah. Jetzt oeffnet die Seite den gewuenschten Reiter, ueber einen ausgeloesten Klick auf den vorhandenen Reiter statt ueber nachgebaute Logik: Daran haengen Signatur, Leuchtbalken, Nachladen und der Wischstreifen auf dem Handy. Auch hier hat erst der Test den Fehler gezeigt -- und danach einen in der Pruefung selbst: Sie erreichte die Funktion gar nicht, weil diese im gekapselten Bereich liegt. Jetzt nach aussen gegeben, wie schon window.vwBalkenSetzen. 23 Pruefungen gruen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
92d2b568de |
Pruefung auf doppelte Funktionsnamen — und ein zweiter Fund
Die Kollision von heute war weder fuer den Browser noch fuer einen Syntaxpruefer sichtbar: Zwei Funktionen desselben Namens sind erlaubtes JavaScript, die spaetere gewinnt lautlos. Auch die Oberflaechen-Tests schwiegen -- sie pruefen, ob Kacheln DA sind, nicht ob sinnvoller Text darin steht. pruef-namenskollision.mjs durchsucht jetzt alle 110 Dateien mit eigenem JavaScript. Mit Gegenprobe, damit die Pruefung nicht selbst kaputtgehen und dabei "sauber" melden kann. ZWEITER FUND, AELTER ALS MEIN FEHLER Sie meldete sofort eine weitere Kollision: tageSeit stand zweimal in verwaltung.html. Beide rechneten dasselbe, mit einem Unterschied -- bei fehlendem Datum gab die eine null zurueck, die andere 0. Die spaetere (mit 0) gewann. Damit war die frueher definierte wirkungslos, und mit ihr die Pruefungen "if (t === null) return ''" in altersText und dringlichkeit: Ohne Datum stand dort "seit heute" statt gar nichts. Entfernt wurde die spaetere. Die beiden verbliebenen Aufrufer vertragen null genauso wie 0 -- nachgeprueft, nicht angenommen: Math.max(x, null) ergibt x, und null >= 7 ist falsch, gleich wie bei 0. 110 Dateien jetzt sauber. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
0e8c1447f2 |
DRINGEND: Namenskollision zerstoerte die Uebersicht
Alle Kacheln der Uebersicht zeigten "[object Object]" und "undefined". Ursache war mein Push-Code von heute. Er brachte eine Hilfsfunktion namens kachel(titel, inhalt, art) mit -- und weiter oben in derselben Datei gibt es seit langem kachel(o), die die Uebersichtskacheln baut. JavaScript kennt keine Ueberladung. Steht spaeter eine zweite Funktion desselben Namens im selben Gueltigkeitsbereich, gewinnt sie. Ohne Warnung, ohne Fehlermeldung, ohne dass irgendein Werkzeug anschlaegt. Danach bekam jede Uebersichtskachel mein Objekt als ersten Parameter und gab es als Zahl aus. Besonders tueckisch: Die Push-Karte selbst funktionierte einwandfrei -- sie steht ja unmittelbar ueber den kaputten Kacheln. Der sichtbare Schaden lag weit weg von seiner Ursache, und nichts deutete auf den neuen Code hin. Die Funktion heisst jetzt pushKachel und sagt damit, wozu sie gehoert. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
0f253df134 |
Service Worker: Versionsnummer in der Adresse gegen fremden Cache
Bei der Fehlersuche zur lahmgelegten App kam ein zweiter, aelterer
Mangel zum Vorschein.
GEMESSEN
Dienst selbst Cache-Control: no-cache
nach Cloudflare Cache-Control: max-age=14400 (auch bei MISS)
Cloudflare ersetzt die Vorgabe des Servers durch vier Stunden. Ursache
ist eine feste "Browser Cache TTL" in den Einstellungen. Der Kommentar
in server/index.js behauptet das Gegenteil ("Cloudflare respektiert
laut Doku ein vom Origin gesetztes Cache-Control") -- fuer diese Domain
stimmt das nicht. Nachgemessen, nicht vermutet.
WARUM DAS MEHR ALS EIN SCHOENHEITSFEHLER IST
Jede Aenderung am Service Worker erreicht die Geraete bis zu vier
Stunden zu spaet. Solange alles laeuft, faellt das nicht auf. Ist der
ausgelieferte Stand aber fehlerhaft -- wie heute, als eine zu strenge
Inhaltsrichtlinie ihn lahmlegte und die App "Keine Verbindung" zeigte
--, sind es vier Stunden, in denen sich nichts reparieren laesst.
Genau dann, wenn Tempo zaehlt, ist man am langsamsten.
LOESUNG OHNE FREMDE EINSTELLUNGEN
Die Registrierung laedt jetzt "/webdesign/sw.js?v=56". Aendert sich die
Nummer, ist es eine andere Adresse -- dafuer kann kein Zwischenspeicher
einen alten Stand haben. Die Nummer wird zusammen mit CACHE_NAME
hochgezaehlt; beide gehoeren zusammen und stehen jetzt auf 56.
Das wirkt unabhaengig davon, wie Cloudflare eingestellt ist. Die
Einstellung selbst sollte trotzdem geprueft werden -- sie betrifft auch
CSS und JavaScript.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
094a69732b |
Portfolio: Spicy SafeAddress als sechstes Projekt
Die Rechtsplattform der Spicy Media Agency fehlte -- dabei ist sie das technisch anspruchsvollste Stueck der Sammlung. WAS IM TEXT STEHT UND WARUM SO Die Projektdokumentation haelt ausdruecklich fest, dass die Wendung "100 Prozent rechtssicher" dort nirgends verwendet wird. Ein Portfolio, das mehr verspricht als die Sache selbst, waere genau der Fehler, den das Projekt vermeiden will. Im Ergebnis steht deshalb, dass die Plattform fertig gebaut und bewusst noch vollstaendig gesperrt ist und auf die schriftliche Freigabe einer Fachkanzlei wartet -- nicht, dass sie "im Einsatz" sei. KEIN LIVE-KNOPF Wie bei der Buchhaltung. Ein "Live ansehen", das auf eine Zugangswand fuehrt, bricht das Versprechen, das der Knopf gibt. Stattdessen steht dort ein Satz, der den Grund nennt. GESICHTER UNKENNTLICH Auf der Zugangswand stehen zwei Profilfotos. Eines davon gehoert einer Geschaeftspartnerin, die dieser Veroeffentlichung nicht zugestimmt hat. Beide sind in der Aufnahme weichgezeichnet, das Firmenzeichen bleibt scharf. Begruendet im alt-Text und in einem eigenen Abschnitt -- genau wie bei Projekt 5, wo derselbe Fall schon einmal auftrat. Nebenbei: Die strenge Inhaltsrichtlinie der Seite (style-src 'self') hat das eingefuegte Stylesheet fuers Weichzeichnen blockiert. Sie tut also genau das, wofuer sie da ist. Ueber die Stil-Eigenschaft im Skript ging es dann. ZWEI STELLEN, DIE SONST FALSCH GEBLIEBEN WAEREN Die Ueberschrift hiess "Fuenf Projekte, die man anfassen kann". Mit SafeAddress steht dort erstmals ein Projekt, das man NICHT besuchen kann -- die Ueberschrift haette also gleich doppelt daneben gelegen. Jetzt: "Sechs Projekte, die es wirklich gibt", und die Einleitung sagt ausdruecklich, dass eine der Seiten gesperrt ist. Der Schlussaufruf lud dazu ein, "das sechste" Projekt zu werden. Bei sechs vorhandenen waere das das Angebot gewesen, eines davon zu ersetzen. Jetzt das siebte. Beides in allen fuenf Sprachen, de-CH als echter Dialekt wie im Rest dieser Datei. TEST Zwei Fehlschlaege, beide berechtigt: die Projektzahl und ein zu grobes Suchmuster, das bei "zwei MENSCHEN" ansprang, obwohl es die veraltete Aussage "zwei PROJEKTE" sucht. Das Muster laesst jetzt hoechstens ein Wort zwischen Zahlwort und Substantiv zu. Mit Gegenprobe abgesichert: faengt weiterhin "Two projects you can visit", ignoriert "Two people work together on that site". Ein Fehlalarm, den man nur wegdrueckt, faengt beim naechsten Mal auch den echten Fall nicht mehr. 35 Pruefungen gruen, i18n vollstaendig. Co-Authored-By: Claude Opus 5 <[email protected]> |