279 Commits

Include renames

Author	SHA1	Message	Date
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]>	2026-08-27 10:57:55 +02:00
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]>	2026-08-27 01:21:31 +02:00
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]>	2026-08-27 00:31:07 +02:00
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]>	2026-08-26 23:43:23 +02:00
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]>	2026-08-26 23:01:12 +02:00
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]>	2026-08-26 20:03:35 +02:00
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]>	2026-08-26 19:09:33 +02:00
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]>	2026-08-26 16:12:35 +02:00
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]>	2026-08-26 14:58:12 +02:00
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]>	2026-08-26 14:55:31 +02:00
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]>	2026-08-26 14:43:45 +02:00
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]>	2026-08-26 12:19:50 +02:00
DogFatherGitandClaude Opus 5	bad5496adc	Portfolio: Buchhaltungsseite mit dem aktuellen Stand zeigen ... Das bisherige Bild zeigte eine fruehere Fassung der Anmeldeseite -- flaches Logo als blasses Wasserzeichen, Text darueber, keine Anmeldekarte. Die Seite ist inzwischen ueberarbeitet: plastisches Logo, Samthintergrund, eine eigene Anmeldekarte mit den beiden Zugaengen und dem Hinweis auf verschluesselte Verbindung. Ein Portfolio, das einen alten Stand zeigt, arbeitet gegen sich selbst -- gerade wenn die neue Fassung die deutlich bessere ist. Neu aufgenommen in 1200x750, also exakt den Massen der uebrigen Portfolio-Bilder. Das steht auch als width/height im <img>; eine Abweichung wuerde beim Laden ein Springen des Rasters ausloesen und die Kacheln unterschiedlich hoch machen. 154 KB statt 49 KB. Der Aufschlag ist nicht zu vermeiden: Das Motiv ist jetzt fotorealistisch, mit Samtfalten und Perlen -- lauter feine Strukturen, bei denen JPEG wenig einsparen kann. Bei Qualitaet 76 waeren es 132 KB gewesen, um den Preis sichtbarer Artefakte im Logo. Das Bild laedt ohnehin verzoegert (loading="lazy"). Cache-Version auf v53: Ohne das bekaemen alle, die die Seite schon einmal geoeffnet haben, weiterhin das alte Bild aus dem Zwischenspeicher. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-26 11:42:11 +02:00
DogFatherGitandClaude Opus 5	2e2172202e	Rechtstexte in fuenf Sprachen ... Impressum, AGB, Widerrufsbelehrung und Datenschutzerklaerung gibt es jetzt auf Deutsch, Schweizer Hochdeutsch, Englisch, Franzoesisch und Portugiesisch. 95 Textbloecke, rund 13.000 Zeichen je Sprache. DIE MASSGEBLICHKEITSKLAUSEL STEHT IN JEDER SPRACHE Nur die deutsche Fassung ist verbindlich; die Uebersetzung dient dem Verstaendnis. Ohne diesen Hinweis waere die Uebersetzung ein Risiko -- ein Kunde koennte sich auf die franzoesische Fassung berufen. Der Hinweis stand schon auf der Seite, aber selbst nur auf Deutsch: Genau die Leute, fuer die er gedacht ist, konnten ihn nicht lesen. WIDERRUFSBELEHRUNG UND MUSTERFORMULAR SIND AMTLICH Sie folgen dem Wortlaut aus Anhang I der Richtlinie 2011/83/EU in der jeweiligen Amtssprache -- nicht einer eigenen Uebersetzung. Der Gesetzgeber hat diese Saetze selbst formuliert; wer sie neu uebersetzt, verliert den Schutz der Musterbelehrung. Angepasst ist nur die Person: Die Muster sprechen von "wir/uns", hier schreibt ein Einzelunternehmer "ich/mir" -- diese Anpassung sieht das Muster ausdruecklich vor. SCHWEIZERDEUTSCH GIBT ES HIER BEWUSST NICHT Auf allen anderen Seiten spricht "de-CH" echten Dialekt. In Rechtstexten waere das unserioes -- es gibt keine Widerrufsbelehrung auf Mundart. Die Schweiz schreibt Hochdeutsch, nur ohne Eszett. Genau das erzeugt eine Zeile Code aus dem deutschen Text, statt 95 von Hand gepflegter Doppeleintraege, die beim naechsten Aendern auseinanderlaufen wuerden. DER FEHLER, DER FAST LIVE GEGANGEN WAERE Beim Aufbau wurden zwei Bloecke uebersprungen: eine reine Formularlinie und eine zweite "Fassung vom"-Zeile. Ab dort war jede Schluesselnummer um eins verschoben. Im Musterformular haette dadurch ueber jedem Feld die falsche Beschriftung gestanden -- "Datum" wo "Name" hingehoert. Und in fuenf Sprachen waere es niemandem aufgefallen, denn jede Sprache war ja vollstaendig gefuellt: Eine Vollstaendigkeitspruefung ist gegen diese Art Fehler wehrlos. Die Schluessel sind deshalb jetzt ueber den TEXT zugeordnet, nicht ueber eine laufende Nummer. Ein eigener Durchlauf vergleicht jeden deutschen Text im Woerterbuch mit dem an derselben Stelle im HTML. WAS DER NEUE DURCHLAUF SONST PRUEFT - Greift die Umschaltung in jeder der fuenf Sprachen, folgt das lang-Attribut, bleibt kein Textblock leer? - Gegenprobe, dass die Umschaltung ueberhaupt etwas tut: Englisch, Franzoesisch und Portugiesisch MUESSEN sich vom Deutschen unterscheiden. Ohne diese Probe waere ein Woerterbuch, das ueberall denselben deutschen Text zurueckgibt, gruen durchgelaufen. - Kein Eszett in der Schweizer Fassung, sonst wortgleich. - Die Massgeblichkeitsklausel nennt in jeder Sprache die deutsche Fassung. Geprueft: 1303 Pruefungen gruen (Browser 737, Server 566), i18n ohne Fehler, WCAG ohne Fundstellen. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-25 22:28:52 +02:00
DogFatherGitandClaude Opus 5	0ef64ba222	Systemabnahme: fuenf Altlasten geschlossen ... Vollstaendiger Durchlauf ueber alle Pruefungen. Dabei kamen fuenf Dinge ans Licht, die teils seit Wochen offen standen. 1. WCAG-KONTRAST -- der einzige Punkt, der echte Besucher betraf Die lila Schilder erreichten nur 4,08:1, verlangt sind 4,5:1 fuer normalen Text. 17 Fundstellen, alle dieselbe Ursache: Die Schrift nutzte den vollen Ton Aurora Violet. Gemessen wurde nicht geschaetzt: Untergrund rgb(38,41,81) aus dem echten Bild ausgelesen, Schrift 12,5 Punkte -- und fett zaehlt erst ab 18,5 Punkten als "grosser Text". Neu ist --wd-lila-hell (#C197FF, 6,02:1). Bewusst NICHT der knappste Wert: #B380FF haette mit 4,91:1 gereicht, aber dasselbe Schild steht auch ueber der Buehne im Verwaltungsbereich. Ein Ton, der nur an einer Stelle knapp besteht, faellt beim naechsten Hintergrund wieder durch. Dasselbe Muster wie --wd-blau-hell, das genau deshalb existiert. 2. GEHEIMNIS-TEST -- der Test war veraltet, nicht der Code Er verlangte ".env hat Vorrang", die Umsetzung macht das Gegenteil. Die Begruendung im Code ueberzeugt: Wer PayPal-Daten im Formular eintraegt, erwartet, dass sie gelten. Andernfalls koennte ein alter Wert in der .env sie stumm ueberstimmen -- und man sucht stundenlang. Der Test prueft jetzt die tatsaechliche Reihenfolge, dazu neu, dass ein gleichzeitig vorhandener Serverwert auch angezeigt wird. Ausserdem endete der Lauf trotz gruener Pruefungen mit einer Fehlermeldung: Unter Windows haelt eine offene SQLite-Datei eine Sperre, das Aufraeumen scheiterte mit EPERM. Auf Linux waere es durchgelaufen -- dasselbe Skript mit unterschiedlichem Ergebnis je Rechner. Jetzt wird erst geschlossen, dann geloescht, und das Aufraeumen kann den Lauf nicht mehr zum Scheitern bringen. 3. PORTAL-TEST -- ebenfalls veraltet Er suchte "1500,00" und schlug fehl, seit der Formatierer den Tausenderpunkt setzt. "1.500,00 EUR" ist die korrekte deutsche Schreibweise; gerade ab vier Stellen macht der Punkt eine Zahl auf einen Blick lesbar. 4. ZWEI SEITEN OHNE WOERTERBUCH -- eine Entscheidung, keine Luecke "diagnose" ist ein Betriebswerkzeug. "rechtliches" ist der heiklere Fall: Rechtstexte durch eine ungepruefte Uebersetzung zu schicken ist gefaehrlicher, als sie einsprachig zu lassen. Ein Fehler in einer Widerrufsbelehrung wirkt gegen den Verfasser. Die Pruefung meldete beides als "Datei fehlt" -- das las sich wie ein Versehen und stand deshalb dauerhaft in der Fehlerliste, ohne dass jemand etwas tat. Jetzt sind beide benannt und begruendet. 5. TAG-UNGLEICHGEWICHT -- eine Fehlmessung Die Pruefung zaehlte auch HTML-Schnipsel, die als Zeichenketten im JavaScript stehen. Dort steht ein oeffnendes <div> regelmaessig in einer anderen Zeichenkette als sein </div>, weil die Teile erst beim Zusammensetzen ein Ganzes ergeben. Gegengeprueft im Browser: geparster Baum einwandfrei, kein Skriptfehler, Verschachtelung unauffaellig. Es war nie ein Strukturfehler. Die Meldung stand aber monatelang als "2 Fehler" da und haette jede echte Meldung entwertet, die dazugekommen waere. STAND Browser 717 Pruefungen 0 offen Server 566 Pruefungen 0 offen i18n keine Fehler WCAG 0 Fundstellen (vorher 17) Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-25 17:13:42 +02:00
DogFatherGitandClaude Opus 5	81c7d40274	Grosse Kacheln kippen jetzt weniger als kleine ... Auf der Portfolio-Seite war die Bewegung zu stark. Der Grund liegt nicht am Winkel, sondern an der Groesse: Bei gleichem Winkel legt eine grosse Kachel an ihren Ecken viel mehr Weg zurueck als eine kleine. Eine Preiskachel auf der Startseite ist 282 Punkte lang, eine Portfolio-Kachel 1503. Fuenf Grad sehen bei der einen beilaeufig aus und bei der anderen wie das Kippen des halben Bildschirms -- obwohl in beiden Faellen exakt derselbe Wert im Stilblatt steht. Der Winkel haengt jetzt an der Kachelgroesse. Bezugswert sind 420 Punkte: Kacheln bis dahin kippen voll, groessere anteilig weniger. Nach unten bei 1,4 Grad begrenzt, damit auch die groesste Kachel noch erkennbar reagiert und der Effekt nicht einfach ausfaellt. Gemessen ueber alle Seiten: index 282px Faktor 5,00 2,45 Grad ueber 588px Faktor 3,57 1,76 Grad portal 562px Faktor 3,74 1,83 Grad ablauf 1130px Faktor 1,86 1,19 Grad leistungen 1206px Faktor 1,74 1,14 Grad portfolio 1503px Faktor 1,40 0,92 Grad Der Durchlauf sammelt diese Werte jetzt und prueft das Verhaeltnis: Die grosse Kachel MUSS weniger kippen als die kleine, und der Faktor darf nie unter 1,4 fallen. Ein blosser Test auf "hoechstens neun Grad" haette den Unterschied nicht bemerkt -- beide Faelle lagen ja deutlich darunter, und trotzdem war einer davon zu viel. Geprueft: 298 Pruefungen gruen (Bewegung 34, Portfolio 19, Verwaltung 62, CRYONOVA 53, Blickfang 13, System 5, Abmelden 16, Abbruch 42, Angebot 54). Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-25 13:11:53 +02:00
DogFatherGitandClaude Opus 5	52f5d31199	Die farbige Oberkante der Kacheln ist zurueck ... Aufgefallen an einem Screenshot: Bei einer Kachel lag oben ein lila Streifen, bei den anderen fehlte jede Farbe. Die Ursache war meine eigene Aenderung von gerade eben. Der Glanzstreifen kam ins ::before -- dort wohnt aber schon die farbige Oberkante (.wd-karte--kappe), und zwar seit dem urspruenglichen Bau der Seite. Ein Element hat nur ZWEI Pseudoelemente, und beide waren belegt: ::after traegt den Lichtkegel, ::before die Kante. Der Glanz hat sich das ::before genommen und die Kante damit still ueberschrieben. Warum es nur teilweise auffiel: ".wd-karte--lila.wd-karte--kappe::before" hat zwei Klassen und damit mehr Gewicht als mein ".wd-karte::before" -- die lila Farbe blieb also stehen, die blaue verschwand. Deshalb sah es aus wie ein Zufall statt wie ein Fehler. DIE LOESUNG Glanzstreifen und Lichtkegel teilen sich jetzt das ::after -- als zwei Hintergrundebenen desselben Pseudoelements. Das ::before ist wieder frei fuer die Oberkante. Beides funktioniert unveraendert: Der Glanz wandert weiterhin mit der Neigung (er nimmt --wd-nx in seinen Winkel auf), der Lichtkegel weiterhin mit dem Zeiger. DIE PRUEFUNG DAZU Ein neuer Abschnitt in pruef-bewegung.mjs misst alle acht Kacheln mit Oberkante: 5 Punkte Hoehe, ganz oben sitzend, Farbe vorhanden -- und ausdruecklich BLAUE UND LILA zusammen. Haette der Test nur eine Sorte angesehen, waere genau dieser Fehler wieder durchgerutscht, denn die lila Fassung war ja nie kaputt. Dazu die Gegenprobe, dass der Glanz nicht einfach verlorengegangen ist: Das ::after muss beide Verlaeufe tragen. Geprueft: 296 Pruefungen gruen (Bewegung 32, Portfolio 19, Verwaltung 62, CRYONOVA 53, Blickfang 13, System 5, Abmelden 16, Abbruch 42, Angebot 54). Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-25 12:41:30 +02:00
DogFatherGitandClaude Opus 5	e4216a2c7a	Kachel-Effekte gelten jetzt auf der ganzen Seite, nicht nur intern ... Neigung, Glanzstreifen und Lichtkante lagen bisher nur im Verwaltungsbereich. Sie stehen jetzt im Grundsystem und gelten damit ueberall: Startseite, Leistungen, Ablauf, Portfolio, "Ueber mich", Kundenportal. Die Farbe kommt aus --wd-lumen. Jede Kachel bringt die ohnehin mit (Token-Regel 02), der Verwaltungsbereich ueberschreibt sie mit der Farbe des jeweiligen Bereichs. Dadurch braucht es keine einzige Sonderregel. DREI FEHLER, DIE DIE REGRESSION GEFUNDEN HAT 1. Die Einblendung hat die Neigung geloescht. ".wd-bereit .wd-auf.wd-sichtbar" setzt "transform: none" und hat mit drei Klassen die hoehere Gewichtung. Sichtbar war das nur auf Seiten, deren Kacheln eine Einblendung tragen: Auf "ablauf" kippte die Kachel, auf "leistungen" nicht -- und der Wert kam in beiden Faellen korrekt an. Die Einblendung nutzt jetzt "translate". Das ist zum dritten Mal dieselbe Falle nach Buehne und Kacheln im Verwaltungsbereich. Merksatz: Wer "transform" animiert oder zuruecksetzt, blockiert es fuer alles andere. 2. Die Perspektive hat die Buehne zerlegt. "perspective" auf dem Abschnitt macht diesen zum Bezugsrahmen fuer position:fixed in seinem Inneren -- genau wie "transform" oder "filter". Die bildschirmfuellende Buehne im Verwaltungsbereich lag danach nicht mehr am Fenster, sondern am Abschnitt: gemessen 472 statt 900 Punkte Hoehe. Die Perspektive steckt jetzt als Funktion im transform der Kachel selbst. Der gemeinsame Fluchtpunkt benachbarter Kacheln entfaellt damit, was bei hoechstens fuenf Grad niemand sieht. 3. Kachel-Neigung und Bild-Parallaxe haben sich aufgeschaukelt. Die kippende Kachel schiebt das Bild unter dem Zeiger weg, der landet dadurch auf einem Nachbarelement, das Bild springt zurueck auf null -- und beim naechsten Zucken von vorne. Messbar war das als "an einer Ecke sauber, an der anderen dauerhaft 0". Klare Arbeitsteilung: Ein Bild INNERHALB einer Kachel bekommt nur den Zoom, die Kachel kippt darum herum. Freistehende Bilder behalten ihre eigene Gegenbewegung. NEUER DURCHLAUF ueber alle Seiten (pruef-bewegung.mjs) Weil die Effekte im Grundsystem liegen, reicht eine Pruefung auf einer Seite nicht: Genau so ist Fehler 1 entstanden und waere unbemerkt geblieben. Der Durchlauf geht sechs Seiten ab und prueft je Seite Neigung, Winkel unter neun Grad, Zuruecksetzen beim Verlassen und Skriptfehler. Zwei Stolpersteine stecken darin dokumentiert: Die Startseite legt beim Laden einen Vorhang ueber alles (wer zu frueh misst, trifft den Vorhang statt der Kachel), und eine Portfolio-Kachel ist ueber 1400 Punkte hoch -- ein fester Anteil ihrer Hoehe landet ausserhalb des Bildschirms. Geprueft: 291 Pruefungen gruen (Bewegung 27, Portfolio 19, Verwaltung 62, CRYONOVA 53, Blickfang 13, System 5, Abmelden 16, Abbruch 42, Angebot 54). Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-25 12:12:31 +02:00
DogFatherGitandClaude Opus 5	76aea6ac3f	Bilder bewegen sich unter dem Zeiger ... Faehrt der Zeiger ueber ein Bild, tritt es leicht naeher und wandert ein Stueck GEGEN die Zeigerrichtung -- als schaue man durch ein Fenster und lehne sich zur Seite. Warum gegen die Richtung: Bewegt sich das Bild MIT dem Zeiger, wirkt es wie ein Aufkleber, der verrutscht. Nur die Gegenbewegung liest das Auge als Tiefe hinter dem Rahmen. Derselbe Grund wie bei der Buehne im Verwaltungsbereich, eine Ebene kleiner. Der Effekt liegt im GRUNDSYSTEM, nicht in einer einzelnen Seite. Er gilt damit ueberall: Portfolio, Startseite, "Ueber mich", Zugangswand und die Vorschaubilder im Verwaltungsbereich. Eine Sonderloesung je Seite waere beim naechsten neuen Bild wieder vergessen worden. Zwei Zahlen, die bewusst klein sind: - Der Ausschlag liegt bei hoechstens 14 Punkten (gemessen 13,9). - Der Zoom bei 1,055. Zusammen ergibt das Bewegung, ohne dass ein Bild beim blossen Vorbeifahren seinen Ausschnitt merklich aendert. Ein groesserer Wert waere kein Effekt mehr, sondern ein Bildsprung. Umgerechnet wird auf die Groesse des jeweiligen Bildes (-1 bis +1), nicht in festen Bildpunkten. Sonst wanderten ein Vorschaubild von 1200 Punkten Breite und ein Logo von 80 gleich weit -- beim kleinen saehe das aus wie ein Ruck. Zwei Faelle, die im Code ausdruecklich abgefangen sind: - Der Zeiger liegt ueber einem Element, das das Bild UEBERDECKT (etwa einem Textblock in derselben Kachel). Ohne Behandlung bliebe das Bild stehen, sobald man den Rahmen verlaesst, aber die Kachel noch nicht. - Der Zeiger steht neben dem Bild, aber noch in der Kachel. Die Werte liefen dann weit ueber 1 hinaus und das Bild schoesse aus dem Rahmen. Deshalb wird auf -1 bis +1 begrenzt. Beim Verlassen stellt sich alles zurueck -- sonst bliebe das Bild verschoben stehen, nachdem der Zeiger laengst weg ist. Bei prefers-reduced-motion ist der Effekt aus. Geprueft: 265 Pruefungen gruen (Portfolio 20, Verwaltung 62, CRYONOVA 53, Blickfang 13, System 5, Abmelden 16, Abbruch 42, Angebot 54). Der Test prueft ausdruecklich die RICHTUNG der Bewegung, nicht nur, dass sich ueberhaupt etwas tut. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-25 09:48:17 +02:00
DogFatherGitandClaude Opus 5	09bd6330f7	Verwaltung: jeder Bereich bekommt eine eigene Signatur ... Aus einem festen Streifen werden sechs. Jeder Reiter hat jetzt ein eigenes Motiv UND eine eigene Leitfarbe, beides wechselt beim Klick. Die Zuordnung ist gelesen, nicht ausgewuerfelt: Uebersicht Wappen Die Zentrale, wo alles zusammenlaeuft. Anfragen Portal Ein Tor. Hier kommt Neues herein. Projekte Monolith Etwas, das aufrecht steht und gebaut wird. Kunden Thron Wer bestellt, steht auf dem Podest. Zahlungen Kristall Der Wert selbst. Dazu Liquid Gold. Postfach Portal Wieder ein Tor -- Nachrichten gehen durch. Farben: Baby Blue, Hyper Aqua, Aurora Violet, Prism Indigo, Liquid Gold, Ion Blue. Nach ein paar Tagen erkennt man den Bereich an der Farbe, bevor man den Titel gelesen hat. Aus Deko wird Orientierung. Das neue Thron-Motiv ist aus dem vierten Bild aufbereitet, im selben Mass wie die bestehenden (1672x941) und mit kleiner Fassung fuers Handy. DIE ENTSCHEIDENDE IDEE: Bild und Text teilen sich nicht mehr denselben Platz. Eine Deckschicht ist links voll deckend und oeffnet sich nach rechts. Links stehen Titel und Reiter, rechts ist die Flaeche leer -- dort darf das Motiv mit 82 % auftreten statt mit 17 %. Der erste Versuch war gleichmaessig bei 17 %: ueberall gleich schwach zu ahnen, ein Fleck statt eines Bildes, und trotzdem hinter der Schrift. Kurz und kraeftig ist beides besser -- mehr Wirkung dort, wo Platz ist, null Stoerung dort, wo gearbeitet wird. Der Streifen ist jetzt auch kuerzer und endet, BEVOR die erste Kachel anfaengt. Drei Fehler, die der Test gefunden hat und nicht das Auge: - Alle sechs Bereiche zeigten dasselbe Bild. Die Variablen hingen an #vw-bereich, der Schmuckstreifen liegt aber ausserhalb davon -- er erbte sie nie und fiel auf den Rueckfallwert zurueck. Die Farben wechselten (Reiter und Titel liegen drinnen), die Motive nicht. - Die waagerechten Ausschnitte bewirkten nichts. Bei "cover" skaliert der Browser auf die Breite des Streifens, die volle Bildbreite ist immer sichtbar. Erst ein Zoom ueber 100 % schafft Spielraum. - Das Thron-Motiv schob seine hellen Kristallfluegel bis unter die Reiter. Deshalb deckt die Schicht jetzt bis 46 % statt 34 % -- der Wert ist gemessen, nicht geschaetzt. Dazu zwei Dinge, die erst der Screenshot zeigte: angeschnittene Logos im Streifen (sieht nach Versehen aus, und das Logo steht ohnehin oben links), und die Knoepfe Suchen/Abmelden lagen ueber dem hellsten Teil des Bildes. Sie haben jetzt einen eigenen dichten Grund -- Bedienelemente muessen lesbar sein, egal was dahinter liegt. Der Test misst nicht mehr "Deckkraft unter 20 %". Dieser Massstab ist hinfaellig, seit das Motiv nach rechts gerueckt ist: Es darf kraeftig sein, WEIL es nicht mehr hinter der Schrift liegt. Geprueft wird stattdessen, wie ruhig der Grund unter der Reiterzeile ist -- mit Motiv gegen ohne Motiv, in allen sechs Bereichen. Gemessen: plus 0 bis plus 6. Unveraendert gilt: kein Motiv hinter Listen, Tabellen oder Zahlen. Ein Bild hinter einer Zahlenspalte ist genau die Art von Schoenheit, die ein Werkzeug unbrauchbar macht. Geprueft: 237 Pruefungen gruen (Verwaltung 39, Portfolio 15, CRYONOVA 53, Blickfang 13, System 5, Abmelden 16, Abbruch 42, Angebot 54). Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-25 00:26:23 +02:00
DogFatherGitandClaude Opus 5	a6c6bbe3ca	Portfolio: ZockerAnstalt, Buchhaltung und Command Center aufgenommen ... Aus zwei Projekten werden fuenf. Alle drei neuen laufen wirklich, die Adressen wurden vorher einzeln geprueft: zockeranstalt.dogfather-universe.com Netcup, via Caddy buchhaltung.vans-diy-bastelbedarf.com Netcup, via Caddy analyse.dogfather-universe.com Cloudflare Worker (kein via) Die Vorschaubilder sind echte Aufnahmen vom 24.08.2026, aufgenommen im selben Mass wie die bestehenden (1200x750), damit in der Liste nichts aus der Reihe faellt. Zwei Aufnahmen sind bewusst nicht unbearbeitet, und das steht auch fuer die Besucher auf der Seite -- nicht nur im Code: - Die Buchhaltung zeigt nur die Anmeldung. Sie bekommt deshalb auch KEINEN "Live ansehen"-Knopf: Ein Knopf, der bloss auf eine Anmeldemaske fuehrt, ist ein leeres Versprechen. Ein Test haelt das fest, damit es niemand spaeter "der Vollstaendigkeit halber" einbaut. - Beim Command Center sind die Gesichter unkenntlich gemacht. Die Seite gehoert dem Team, nicht mir, und niemand hat zugestimmt, sein Bild im Portfolio zu zeigen. Der Weichzeichner wurde vor der Aufnahme im Browser gesetzt, nicht nachtraeglich ins Bild gemalt. Zwei neue Schildfarben. Aqua traegt Schrift problemlos (11,5:1 gemessen). Indigo NICHT: Prism Indigo ist die einzige Farbe der Palette, die als Text durchfaellt (3,25--4,29:1) -- das Schild nutzt es deshalb nur als Flaeche und Kante, die Schrift bleibt Chrome Silver (9,8:1). Texte in allen fuenf Sprachen, inklusive Schweizerdeutsch. Ueberschrift, Einleitung und Schlusssatz sagen nicht mehr "zwei" bzw. "beide" -- und zwar sowohl im Woerterbuch ALS AUCH im deutschen Rueckfalltext im HTML. Nur die JS-Datei zu aendern haette gereicht, damit es in vier Sprachen stimmt und ausgerechnet auf Deutsch falsch bleibt. Drei Fehler steckten wieder in der Pruefung, nicht auf der Seite: - Sie meldete drei Vorschaubilder als "nicht geladen". Die tragen loading="lazy" -- der Test hatte schlicht nie hingesehen. - Sie zaehlte Navigations- und Markentexte mit. Die liegen aber in wd-core.js, gelten fuer alle Seiten und werden von server/pruefe-webdesign-i18n.mjs abgedeckt. - Ihre "kein Zwei mehr"-Suche haette auch Projekttexte getroffen, in denen das Wort voellig zurecht steht. Geprueft wird jetzt das Ergebnis statt des Woerterbuchs: Die Seite wird wirklich auf jede der fuenf Sprachen umgeschaltet, plus eine Gegenprobe, dass die Umschaltung ueberhaupt etwas tut. Geprueft: 198 Pruefungen gruen (Portfolio 15, CRYONOVA 53, Blickfang 13, System 5, Abmelden 16, Angebot 54, Abbruch 42). Die vier Meldungen aus server/pruefe-webdesign-i18n.mjs betreffen verwaltung.html und zwei fehlende Woerterbuecher -- Altbestand, keine dieser Dateien wurde hier angefasst. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-24 23:23:27 +02:00
DogFatherGitandClaude Opus 5	99b5dd4eb2	CRYONOVA Schritt 3: Feldfokus, Blickfaenge, Testkorrekturen ... Der Feldfokus zeigt jetzt den Ion-Rand und den weichen Schein, den das Design-System auf Seite 15 verlangt. Er fehlte, weil der allgemeine Tastaturring seinen dunklen Innenring darueberlegte: Dessen Selektor hat Spezifitaet 0,3,0, die Feldregel nur 0,2,1 -- und Spezifitaet schlaegt Reihenfolge, egal wie weit unten die Regel steht. Eingabefelder sind jetzt vom Innenring ausgenommen; sie brauchen ihn nicht, weil sie selbst eine dunkle Flaeche sind. Der Aqua-Umriss bleibt fuer alle erhalten. Die zwei Blickfang-Motive stehen jetzt auch wirklich auf einer Seite: das Wappen auf "Ueber mich", direkt nach dem Absatz ueber die Herkunft des Namens, der Monolith auf "Portfolio" zwischen Einleitung und den echten Projekten. Beide als Zierbild ausgezeichnet -- ihre Aussage steht schon im Text daneben. Auf dem Handy laedt automatisch die kleine Fassung. Vier Fehler steckten in der Pruefung selbst, nicht im Stilblatt: - Sie griff das erste "input" der Anfrageseite. Das sind aber sechs optisch versteckte Auswahl-Radios, kein Textfeld. - Sie mass ohne Fensterfokus. Ein Browser wendet :focus nur an, wenn das Fenster selbst den Fokus hat -- das DOM meldet trotzdem brav matches(":focus") === true, die Farbe bleibt die alte. - Sie mass mitten im Uebergang, bevor die Animation stand. - Und sie zaehlte Schattenebenen an "),", einem Muster, das in keinem Schattenwert je vorkommt. Geprueft wird jetzt die Anforderung selbst: Ion-Farbe und ein Weichzeichner ueber 0. Geprueft: 334 Pruefungen gruen (CRYONOVA 53, Blickfang 13, Abmelden 16, Angebot 54, Abbruch 42, System 5, Automatik 55, Angebote 56, Kette 40). Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-24 23:03:27 +02:00
DogFatherGit	e92daed103	CRYONOVA Schritt 2: Bildwelt, Materialien, Rangsystem, Status ... Setzt die restlichen Kapitel des Design-Systems um (Seiten 7, 14, 16, 19, 24-29). Wie Schritt 1 ausschliesslich Farbe, Material und Licht -- Aufbau, Navigation, Texte und Funktionen bleiben unangetastet. BILDWELT (Seiten 24-29) Die Motive sind jetzt echte Seitenhintergruende: Ring auf Startseite und Portal, Kristallwelt an der Zugangswand. Ueber jedem Motiv liegt eine Navy-Glasflaeche -- das System fordert auf Seite 31 ausdruecklich, dass bei Bedarf "eine Navy- oder Frost-Glasflaeche zwischen Bild und Inhalt" liegt. Ohne sie waere Text auf den hellen Kristallspitzen nicht sicher lesbar, und genau dort macht ein schoenes Bild eine Seite unbrauchbar. Von 2,5 MB auf 96-229 KB (WebP), auf dem Handy 30-73 KB. Das System nennt fuer Mobile ausdruecklich Ladezeit als Kriterium. DAS LOGO IM BILD -- eine Entscheidung gegen die woertliche Vorgabe Zwei der drei Motive zeigen das Dogfather-Logo gross in der Mitte. Als Seitenhintergrund waere das ein zweites Logo neben dem echten in der Kopfzeile: zwei Marken, die um dieselbe Aufmerksamkeit ringen. Beim ersten Versuch schien es an der Zugangswand hinter den Karten durch (gemessen 15,9 % helle Flaeche im Logobereich). Die Zugangswand nutzt deshalb jetzt einen Ausschnitt der linken Bildhaelfte -- dieselbe Kristallwelt, dasselbe Licht, nur ohne Wappen. Die Logo-Motive bleiben als Blickfang-Klasse erhalten, dort wo sie fuer sich stehen duerfen. MATERIALIEN (Seite 7) Optic Glass, Frosted Ice, Prism Edge und Void Navy als Klassen. "Hell" heisst auf einer dunklen Seite aufgehelltes Navy, nicht Weiss -- echtes Weiss waere ein Loch im Bildschirm, und das System verbietet weisse Vollflaechen ausdruecklich. RANGSYSTEM (Seite 14) Drei Stufen fehlten: Premium (Indigo), VIP (Champagne), Gefahr (Coral). Wenn jeder Knopf gleich laut ist, ist keiner mehr laut. Zwei bewusste Abweichungen von der naheliegenden Loesung: - Indigo steht als FLAECHE unter hellem Text, nie als Schriftfarbe. Es erreicht als Text nirgends 4,5:1 (gemessen 3,25-4,29). Der Test haelt das dauerhaft fest. - Gefahr ist NICHT vollflaechig rot. Ein voll gefuellter roter Knopf zieht den Blick staerker an als die Hauptaktion und wird dadurch versehentlich gedrueckt. Kritische Aktionen sollen auffindbar sein, nicht verlockend. FOKUSRING (Seite 19) Doppelter Aqua-Ring: 2 px Aqua aussen, dunkler Innenring. Kein Schmuck -- ein einfacher heller Ring verschwindet auf hellen Flaechen, ein dunkler auf dunklen. Die Kombination ist auf JEDEM Untergrund sichtbar. STATUS-SPEKTRUM (Seite 16) Acht Zustaende. Die Klasse faerbt nur -- den Text liefert immer das Markup. Es gibt bewusst keine Variante, die nur einen farbigen Punkt zeigt: Wer Farben nicht unterscheiden kann, saehe dann gar nichts. Der Test prueft, dass keine Statusmarke ohne Text existiert. Dabei einen eigenen Fehler gefunden und behoben: Ich hatte beim Bauen des Premium-Knopfes selbst einen losen Hex-Wert eingesetzt -- genau das, was Token-Regel 05 verbietet und was der Test dann meldete. Geprueft: 43 (CRYONOVA, von 24 erweitert) + 0 Fundstellen (WCAG ueber 12 Seiten x 5 Sprachen, jetzt MIT Bildhintergruenden) + 55 + 40 + 69 + 54 + 42 + 16 + 5 + 20 + 64 + 58 -- alles gruen.	2026-08-24 22:43:58 +02:00
DogFatherGit	de8819f1fd	CRYONOVA: Farb- und Lichtsystem nach dem Design-System umgesetzt ... Umsetzung des Design-Systems "Baby Blue Optical Luxury" (Edition 2.0), Schritt 1 von mehreren: die zentrale Farbquelle. Nach der Kernregel auf Seite 3 ist das ausdrücklich ein Farb- und Licht-Redesign — Aufbau, Navigation, Texte und Funktionen bleiben unangetastet. FARBEN Grundflächen auf die vier Tiefenebenen des Systems (Void, Midnight, Obsidian, Deep Glass). Palette nach Seite 5: Signature Baby, Ion Blue, Hyper Aqua, Aurora Violet, Prism Indigo, Liquid Gold, Signal Coral, Chrome Silver. Die Variablen behalten ihre alten NAMEN (--wd-blau statt --cryo-baby). Ein Umbenennen hätte über 155 Fundstellen anfassen müssen — viel Bewegung ohne sichtbaren Nutzen, mit der realen Gefahr, eine Stelle zu übersehen und danach zwei fast gleiche Blautöne zu haben. Entscheidend ist die Rolle, nicht der Name; die Systembezeichnungen stehen als Kommentar daneben. EIN FEHLER IM DESIGN-SYSTEM, DER BEWUSST NICHT ÜBERNOMMEN WURDE Die Token-Liste auf Seite 20 ist um eine Zeile verrutscht — Namen und Hex-Werte passen dort nicht zusammen. Am folgenreichsten: --cryo-baby stünde auf #0C2740, einem fast schwarzen Navy, und ist laut Seite 21 zugleich die Standard-Lumenfarbe. Das Mauslicht wäre damit praktisch unsichtbar geworden — ausgerechnet der Effekt, den das System auf fünf Seiten als unantastbar schützt. Maßgeblich ist deshalb die Palette auf Seite 5 und die Lumen-Logik auf Seite 9, die untereinander stimmig sind. MAUSLICHT Der bestehende Effekt bleibt vollständig erhalten (Systemauflage) und bekommt eine Farbvariable pro Kachel: --wd-lumen. Vorher war die Farbe im Verlauf fest verdrahtet, und jede weitere Kachelfarbe hätte zwei neue Blöcke gebraucht (Fläche + leuchtende Kante). Bei sechs Lumen-Rollen wären das zwölf fast gleiche Blöcke gewesen, die beim nächsten Feinschliff zwangsläufig auseinanderlaufen. Jetzt setzt die Kachel nur ihre Farbe, der Verlauf steht einmal da — genau das meint Token-Regel 02 mit "Kachelfarbe steuert Lumenfarbe". 38 lose Hex-Codes durch Token ersetzt (Token-Regel 05). Drei davon (#3d9dbd, #7c5cd6, #a8873a) waren noch die ALTEN Markenfarben und hätten still neben den neuen weitergelebt — genau der Mechanismus, durch den Oberflächen mit der Zeit zwei fast gleiche Töne bekommen. KONTRASTE NACHGERECHNET Die Palette ist auf dunklem Grund durchweg stark (9,7 bis 19,8:1) — mit einer Ausnahme: Prism Indigo erreicht auf keiner Fläche 4,5:1 (nur 3,25 bis 4,29). Es ist deshalb ausschließlich für Kanten, Verläufe und große Premium-Flächen zugelassen, nie für Fließtext. Das System sieht Indigo ohnehin nur für "Premium-Momente" vor — die Rechnung bestätigt die Regel, statt ihr zu widersprechen. NEUER TEST: pruef-cryonova.mjs (24 Prüfungen) Palette, Grundflächen, Mauslicht-Erhalt, echte Zeigerbewegung, keine losen Hex-Codes, Kontraste und die Frage, ob alle 12 Seiten wirklich aus derselben Quelle schöpfen. Dabei drei Fehlalarme im eigenen Test gefunden und behoben — jeder davon hätte dauerhaft rote Zeilen erzeugt und irgendwann dazu geführt, dass man eine echte Meldung übersieht: - Halbtransparente Flächen müssen über ihren Untergrund gerechnet werden. Der aktive Reiter kam sonst auf 1:1 statt echter 8,25–10,23:1. - Text auf Farbverläufen liefert rgba(0,0,0,0) als Hintergrund; der Hauptknopf kam so auf 1:1 statt rund 11:1. - Die Maus muss mit Zwischenschritten bewegt werden, sonst feuert pointermove nicht. Eine Direktmessung bestätigte: Das Licht folgt einwandfrei (30px → 723px, Deckkraft 1). pruef-system.mjs auf den neuen Markenton gesetzt. Dass er dort zunächst "0 von 1804 Elementen" meldete, war kein Fehler, sondern der Beweis, dass der alte Ton nirgends mehr vorkommt. Geprüft: 24 (CRYONOVA) + 0 Fundstellen (Design/WCAG über 12 Seiten × 5 Sprachen) + 40 + 56 + 69 + 54 + 42 + 55 + 5 + 16 — alles grün.	2026-08-24 22:32:04 +02:00
DogFatherGit	521f0d5a80	Kompletten Ablauf einmal durchgespielt — echten Fehler dabei gefunden ... Wunsch: "ich will dass du es abcheckst" — nicht Stück für Stück (das war schon geprüft), sondern EINMAL DURCHGÄNGIG als ein zusammenhängender Ablauf, so wie ein echter Auftrag tatsächlich läuft: Anfrage → Angebot → Zusage im Portal → Anzahlung → laufende Uhr → Benachrichtigung → Arbeit → Restzahlung → Gegenprobe mit Abbruch. test-kette.mjs bildet genau das ab, gegen die echten Funktionen aus server-internal/, mit einer Wegwerf-Datenbank. 40 Prüfungen, alle grün. DABEI GEFUNDEN: Der Liefertermin-Countdown im Portal prüfte nicht, ob die Uhr überhaupt schon läuft. Ein frisch zugesagtes Projekt hat schon ein termin_am (aus der Zusage vorgerechnet), aber uhr_start_am steht noch auf null, solange die Anzahlung nicht da ist. Der Kunde hätte also direkt nach der Zusage einen tickenden Countdown gesehen — und wenn die Anzahlung eintrifft, wird der Termin ab dem Zahlungstag NEU berechnet und springt dann sichtbar nach hinten. Das sieht aus wie ein Fehler, auch wenn die Zahl rechnerisch stimmt: Kaum zu erklären, warum "noch 8 Tage" plötzlich wieder "noch 10 Tage" werden. Jetzt zwei klar getrennte Zustände: Vor der Anzahlung steht "Startet, sobald deine Anzahlung da ist — voraussichtlicher Liefertermin danach: ca. {datum}" (kein Countdown, aber der Termin bleibt sichtbar, kein Verstecken). Danach der echte Countdown. Fünf Sprachen ergänzt. Nebenbei einen irreführenden Kommentar korrigiert: Ein neuer Kunde wird beim Angebot-Senden SOFORT freigeschaltet (nicht erst bei Zusage, wie der alte Kommentar behauptete) — sonst könnte er sich gar nicht einloggen, um sein eigenes Angebot anzusehen. Der Code war richtig, nur die Erklärung falsch, und mein erster Testentwurf ist genau darauf hereingefallen. Bei der Gelegenheit auch die bekannte better-sqlite3-Aussetzer-Eigenart (zufälliger Absturz beim Prozessende, dokumentiert seit früheren Commits) noch einmal eingegrenzt: Derselbe Import in test-angebote.mjs brach mal nach "GEHEIM", mal nach "VORLAGEN" ab — der Absturzpunkt verschiebt sich zwischen identischen Läufen. Das ist der endgültige Beweis, dass es reine GC-Zeitfensterflakiness in der nativen Bibliothek ist, kein Fehler im eigenen Code. Geprüft: 40 (Kette) + 55 + 56 + 70 + 28 + 49 serverseitig (alle mehrfach unabhängig grün), 261 im Browser (Portal, Angebot, Übersicht, Verwaltung, Abbruch, Design). Ein Screenshot bestätigt den neuen Wartehinweis visuell.	2026-08-24 16:54:35 +02:00
DogFatherGitandClaude Opus 5	8726110035	Angebote in der Oberflaeche: schicken und im Portal zusagen ... VERWALTUNG Der Angebotsbereich steht in der Anfrage-Detailansicht ueber dem direkten Annehmen. Der uebliche Weg ist: Angebot raus, Kunde sagt zu, Projekt entsteht -- direkt anzunehmen ist der Sonderfall (man hat schon telefoniert). Stuende der Sonderfall oben, waere er der naheliegende Griff, und man verschenkte den Beleg, den eine Zusage im Portal erzeugt. Vorbelegt sind Paket, Preis, Anzahlung, Laufzeit, Ablaufdatum und der komplette Leistungstext. Zu tun bleibt: Paket bestaetigen, Preis bestaetigen. Der Leistungstext ist eingeklappt statt die Seite zu fluten, aber aenderbar. Ein Paketwechsel laedt ALLES neu -- auch den Leistungstext. Ein stehengebliebener Text vom vorigen Paket waere der schlimmste Fall: Er ginge unbemerkt hinaus, und im Angebot staende etwas, das zum Preis nicht passt. Genau das prueft der Test. PORTAL Die Angebotskarte steht ganz oben, vor allen Projekten: Ein Angebot ist das Einzige im Portal, das eine ENTSCHEIDUNG verlangt -- alles andere ist Auskunft. Der eingefrorene Leistungstext wird lesbar aufbereitet (Zwischenueberschriften, Punkte), nicht als Textblock hingeworfen. Vor der Zusage wird gefragt, und die Frage nennt die Folgen ('verbindlich', 'Anzahlung'). Nicht aus Foermlichkeit: Hier entsteht ein Vertrag, und ein Knopf, der beim Danebentippen einen Auftrag ausloest, waere eine Falle. Beim Ablehnen wird NICHT gefragt -- das ist folgenlos. ZWEI FEHLER GEFUNDEN, BEIDE IM NORMALFALL - Die Angebotskarten standen im Zweig 'es gibt Projekte'. Ein Kunde mit offenem Angebot hat aber typischerweise noch KEIN Projekt -- genau der Normalfall -- und saeh damit nichts. Der Server lieferte das Angebot, die Seite zeichnete es nur nie. Nur im Browsertest sichtbar. - Eine Antwort ohne 'nachrichten' liess das Postfach werfen, und weil der Fehler den Aufbau abbrach, erschien danach GAR NICHTS mehr -- auch nicht das Angebot, das ueber allem stehen sollte. Dieselbe Sorte wie zuvor im Cockpit: Ein halber Server ist ein realistischer Fall. Neun Sprachschluessel in fuenf Sprachen ergaenzt. Geprueft mit 54 Pruefungen auf Computer und Handy, die messen, was tatsaechlich an den Server geht. Alle bestehenden weiter gruen. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-24 12:23:44 +02:00
DogFatherGitandClaude Opus 5	131bc8a755	Anfragen annehmen und ablehnen — mit laufender Zeit bis zur Übergabe ... Annehmen war bisher nur ein Etikett: Man stellte den Status um, und es passierte nichts. Kunde, Projekt, Aufgabenliste, Termin und Zugang musste man danach von Hand in fünf Schritten nachbauen. Der alte Code gab das im Kommentar selbst zu -- schlug der zweite von zwei Aufrufen fehl, stand der Kunde schon in der Datenbank und man durfte es nicht noch einmal versuchen. Jetzt macht das EIN Aufruf, ganz oder gar nicht: Kunde finden oder anlegen, Projekt anlegen, die komplette Aufgabenliste des Pakets einsetzen, Liefertermin berechnen, Einladungslink erzeugen. Der Kunde verfolgt ab diesem Moment alles in seinem Portal. Die Zeit läuft wirklich: - Eigenes Datumsfeld (termin_am) neben dem freien Text. Aus 'Mitte Oktober' kann man keine verbleibenden Tage rechnen. - Werktage statt Kalendertage, inklusive luxemburgischer Feiertage. Die beweglichen werden über die Osterformel berechnet statt gepflegt -- eine Liste ist im übernächsten Jahr lautlos falsch. - Vorschlag je Paket (Onepager 10, Website 20, Shop 30 Werktage), überschreibbar vor dem Bestätigen. - Verbleibende Zeit wird SERVERSEITIG gerechnet. Der Browser kennt die Feiertage nicht; zwei verschiedene Zahlen für denselben Termin wären schlimmer als gar keine. Ablehnen mit Grund und vorbereiteter Absage in fünf Sprachen, Text serverseitig erzeugt und vor dem Abschicken lesbar. Ein laufendes Projekt lässt sich nicht nachträglich als Anfrage ablehnen. Sechs Fehler dabei gefunden: - Ein unbekanntes Paket hätte GAR KEINEN Termin bekommen statt des Ersatzwerts. Zwei Funktionen lasen dieselbe Tabelle, nur eine hatte einen Rückfallwert. Eine fehlende Zahl fällt nirgends auf. - wd_anfragen hat keine Spalte 'firma' -- better-sqlite3 weist undefined ab, die ganze Annahme wäre gescheitert. - Migrationen stehen in einer ausdrücklichen Liste; 0015 fehlte darin. - datumKurz() wurde aufgerufen, gab es aber nicht. Der Fehler wäre erst NACH dem Anlegen aufgetreten. - Der Installations-Hinweis lag fest über dem Annehmen-Knopf und machte ihn auf dem Handy untreffbar. Die Seite reserviert jetzt Platz dafür. - 'richttermin' ist freier Text, lief aber durch einen Datumsformatierer: Der Kunde las 'Invalid Date' an der wichtigsten Stelle seines Projekts. Geprüft: 49 Prüfungen der Terminrechnung gegen nachschlagbare Osterdaten und Wochentage, 70 gegen eine echte Datenbank (darunter: zweiter Klick legt nichts doppelt an, Abbruch mittendrin lässt NICHTS zurück, gesperrter Kunde wird nicht still entsperrt), 42 im Browser auf Computer und Handy, 40 im Portal. Alle bestehenden Prüfungen weiter grün. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-23 22:44:08 +02:00
DogFatherGitandClaude Opus 5	37f1b4a8f5	Handy: Sicherheitsabstaende, Wisch-Reiter, zweispaltige Uebersicht ... Der wichtigste Fund: env(safe-area-inset-*) stand bereits im CSS, lieferte aber immer null -- viewport-fit=cover fehlte auf allen dreizehn Seiten. Der Code sah richtig aus und tat nichts. Zusammen mit apple-mobile-web-app-status-bar-style=black-translucent (schon gesetzt) hiess das: installiert lag die Kopfzeile auf einem iPhone hinter Uhr und Akkuanzeige. Behoben: - viewport-fit=cover auf allen 13 Seiten. - Vier Sicherheitsabstaende zentral benannt statt an jeder Stelle einzeln geschrieben. Kopfzeile weicht der Statusleiste, Container dem seitlichen Notch im Querformat, Fusszeile der Gestenleiste. - Der 'Ueberspringen'-Knopf des Vorspanns lag mit bottom:2rem praktisch AUF dem Entsperr-Strich (34px). Man haette die App verlassen statt uebersprungen. - Eigener Zweig fuer den installierten Betrieb: kein Gummiband- Nachfedern (sieht in einer App nach einem Fehler aus), kein Installations-Hinweis. - Die vier Sprungmarken auf der Rechtsseite waren 39px hoch -- fuenf unter dem Daumenmass. Ausgerechnet dort muss man zum Widerrufsrecht springen koennen. - 'Waehle links einen Verlauf aus': Auf dem Handy gibt es kein links, die Liste steht darueber. Richtungswort entfernt. - Sechs Reiter brauchten auf dem Handy drei Zeilen. Jetzt ein Wischstreifen mit Einrasten und Auslauf am Rand; der aktive Reiter wird herangeholt, wenn man ueber eine Kachel springt. - Uebersicht zweispaltig statt zwoelf Zeilen untereinander: 2635px -> 1924px. Eine Uebersicht, an der man vorbeiwischen muss, ist keine. Geprueft mit 55 neuen Handy-Pruefungen auf iPhone 14 Pro, Pixel 7 und 320px Breite, jeweils im Browser und im installierten Zweig. Drei Fehlalarme der eigenen Pruefung wurden begruendet ausgenommen (Honigtopf bei left:-9999px, Eingabefeld in einer Beschriftung, Inline-Link im Fliesstext -- WCAG 2.5.8 nimmt letztere ausdruecklich aus). Zwei Selbstkorrekturen an der Pruefung dokumentiert: Die Emulation von display-mode wirkt nicht (Chromium nimmt den Befehl an und ignoriert ihn) -- ohne das waeren die zwoelf 'installiert'-Zeilen ein zweiter Browser-Durchgang gewesen. Und die Messung gegen die Systemleisten mass zuerst die Kastenkante statt der Inhaltskante und meldete elf korrekte Seiten als fehlerhaft. Eine Selbstpruefung mit einem absichtlich falsch gesetzten Knopf belegt jetzt, dass die Messung echte Fehler findet. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-23 19:51:10 +02:00
DogFatherGitandClaude Opus 5	4fe66e1e0e	"Preise & Zeit" entfernt -- Inhalte in die Leistungen uebernommen ... "leistungen und preis&zeit ist ja das gleiche, nimm die kategorie preise&zeit komplett weg" Stimmt bei den Paketen und Preisen: Beide Seiten zeigten dieselben Zahlen. Zwei Orte fuer dieselbe Zahl sind eine Einladung, dass sie irgendwann auseinanderlaufen -- und dann steht ein falscher Preis auf der Seite, ohne dass es jemand merkt. NICHT ALLES WAR DOPPELT Vor dem Loeschen nachgesehen statt einfach geloescht. Zwei Abschnitte gab es NUR dort: "Was den Preis bewegt" -- beantwortet die Frage, die nach jeder Preisliste kommt: Warum kostet es bei mir mehr oder weniger? Ohne sie ist eine Preisspanne eine Behauptung. "Wie bezahlt wird" -- Angebot, 30 % Anzahlung, Restbetrag, Betreuung. Rechtlich relevant und aus den AGB verlinkt. Beide sind in die Leistungen umgezogen, samt ihrer 24 Textbausteine in allen fuenf Sprachen. Waeren sie mitgeloescht worden, haette es niemand sofort bemerkt -- und die Seite haette ab dann Preise genannt, ohne sie zu erklaeren. WEITERLEITUNG STATT 404 Die Adresse /webdesign/preise.html bleibt bedient und fuehrt auf die Leistungen. Lesezeichen, alte Links aus Nachrichten und die installierte App zeigen sonst ins Leere, und ein 404 auf einer Preisseite ist der denkbar schlechteste erste Eindruck. 302 statt 301: Eine dauerhafte Weiterleitung merken sich Browser hartnaeckig; sollte die Seite je zurueckkehren, muesste jeder Besucher seinen Zwischenspeicher leeren. EIN FEHLER BEIM EINBAU Die Weiterleitung stand zuerst weiter unten in der Schranke, bei den ohne Code erreichbaren Seiten. Dort haette sie nur fuer NICHT angemeldete Besucher gegriffen -- wer angemeldet ist, passiert die Schranke vorher mit next() und haette einen 404 auf die geloeschte Datei bekommen. Genau die Person also, die die Seite am ehesten im Lesezeichen hat. Jetzt steht sie ganz vorne, vor jeder Zugangspruefung. GEPRUEFT: 10 Pruefungen -- beide uebernommenen Abschnitte erscheinen in allen fuenf Sprachen, kein unuebersetzter Schluessel sichtbar. Kein Verweis auf die alte Seite blieb irgendwo stehen (ablauf.html hatte einen, der ist umgebogen). Gestaltung 0 Befunde, Textkodierung sauber, Designsystem 5. Versionsstempel und Cache auf v20. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-23 19:00:49 +02:00
DogFatherGitandClaude Opus 5	d6e75ce56a	Kacheln: Licht folgt dem Zeiger, Rand glueht mit ... "ich will das die kacheln richtig speziell sind und modern ... dass viel mehr auffaellt und doch modern und profissionell" Die Kacheln hatten Verlaufsrand, Verlaufsflaeche, Schatten und Lichtkante -- alles richtig, alles STATISCH. Was fehlte, war das Gefuehl von Material: eine Flaeche, die auf Licht reagiert. ZWEI EBENEN Ein weicher Lichtfleck folgt dem Zeiger ueber die Flaeche. Und -- der Teil, der wirklich auffaellt -- der RAND glueht an derselben Stelle auf und verlaeuft nach beiden Seiten aus. Das geht ohne zusaetzliches Element: Die Kachel hat bereits zwei Hintergrundebenen (Flaeche padding-box, Verlaufsrand border-box). Beim Ueberfahren bekommt die Randebene einen Lichtpunkt an der Zeigerstelle. Der Rand ist nur einen Pixel breit -- genau dort laesst sich Licht am staerksten zeigen, ohne kitschig zu werden. Ein Lichtfleck OHNE mitleuchtende Kante wirkt wie ein Fleck AUF der Kachel; mit ihr wirkt die ganze Kachel beleuchtet. Die Flaeche selbst bleibt beim Ueberfahren unveraendert -- sonst wuerde der Text flackern. VIER ENTSCHEIDUNGEN GEGEN BILLIGE OPTIK Die Farbe folgt der Kachel: blaue leuchten blau, lila lila. Sonst braeche der Effekt die Farbordnung, die ueberall sonst Bedeutung traegt. Nur bei echtem Zeiger (hover: hover, pointer: fine). Auf dem Handy gibt es keinen; dort bliebe der Lichtfleck an einer zufaelligen Stelle kleben. Aus bei prefers-reduced-motion. Auch wenn sich nichts bewegt: Etwas, das dem Zeiger folgt, ist Bewegung. Erste Fassung war mit 13 % zu zurueckhaltend -- am Screenshot geprueft und auf 22 % angehoben. "Man soll es spueren" ist richtig, aber es muss auch ankommen. SPARSAM GEBAUT EIN Zuhoerer am Dokument statt einem je Kachel -- sonst muesste jede nachgeladene Kachel einzeln nachgeruestet werden. Geschrieben wird erst im naechsten Bildaufbau: Der Zeiger meldet sich bis zu tausendmal je Sekunde, der Bildschirm zeichnet sechzigmal; ohne Drosselung rechnet der Browser neunhundertmal umsonst. Der Inhalt bekommt z-index 1. Ohne das legt sich der absolut gesetzte Lichtfleck ueber den Text -- absolut positionierte Elemente malen ueber Fluss-Inhalt, auch wenn sie im Quelltext davor stehen. Das Ergebnis waere ein Schleier auf der Schrift, den man erst beim Vergleich zweier Kacheln bemerkt. Eigens geprueft. GEPRUEFT: 7 Pruefungen fuer den Effekt selbst -- unsichtbar im Ruhezustand, erscheint beim Ueberfahren, folgt dem Zeiger auf 6 Pixel genau, Inhalt liegt darueber, lila Kacheln leuchten lila, bei Bewegungsempfindlichkeit vollstaendig abgeschaltet. Gestaltung 0 Befunde, Designsystem 5, Verwaltung 69, Portal 32. Versionsstempel und Cache auf v19. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-23 18:53:05 +02:00
DogFatherGitandClaude Opus 5	e495542fe5	Typografie: Lesebreite begrenzt -- 105 zu breite Absaetze behoben ... Gemessen ueber alle Seiten: 105 von 200 Textabsaetzen waren zu breit, der schlimmste mit 151 Zeichen pro Zeile. WARUM DAS ZAEHLT Beim Zeilensprung muss das Auge zurueck an den Zeilenanfang finden. Je laenger die Zeile, desto haeufiger landet es in der falschen -- man liest eine Zeile doppelt oder ueberspringt eine und merkt es erst zwei Saetze spaeter. Der Text ist dann nicht "schwer", er ist schlecht gesetzt. Bewaehrt sind 45 bis 75 Zeichen. Das ist der aelteste und bestbelegte Grundsatz der Typografie ueberhaupt -- jedes ordentlich gesetzte Buch haelt sich daran. Jetzt 68 Zeichen fuer Fliesstext, 60 fuer Kleingedrucktes. Die Einheit ist ch statt Pixel: Damit haengt die Breite an der SCHRIFTGROESSE. Kleingedrucktes bekommt automatisch einen schmaleren Block, grosse Schrift einen breiteren -- beide landen bei aehnlich vielen Zeichen. max-width macht nie etwas breiter. In schmalen Karten und Spalten aendert sich also nichts; die Regel greift nur dort, wo eine Zeile wirklich ueber das Lesbare hinauswaechst. Ergebnis: von 105 auf 0. DREI FEHLER BEIM EINBAU, ALLE VON DER MESSUNG GEFUNDEN 1. Zentrierter Text stand ploetzlich links. Eine Breitenbegrenzung zentriert den KASTEN nicht mit -- die Schrift war mittig, ihr Kasten klebte am linken Rand, mit 384 Pixeln Luft rechts und null links. Gefunden, weil die Pruefung den Abstand links mit dem rechts VERGLEICHT, statt nur zu zaehlen, ob zentriert ist. 2. Meine erste Regel deckte nur den Fall ab, dass das ELTERNELEMENT zentriert -- nicht den, dass der Absatz es selbst tut. 3. Und dann blieb einer uebrig, bei dem beides stimmte. Ursache: ein Inline-Stil "margin:1.2rem 0 0". Die Kurzschreibweise setzt links und rechts hart auf 0 und schlaegt jede Stilvorlage. 11 solche Stellen ueber fuenf Seiten auf margin-top umgestellt -- gemeint war ohnehin immer nur der Abstand nach oben. Ausnahmen bewusst gesetzt: Nachrichtenblasen tragen ihre Breite schon selbst, Tabellenzellen und Beschreibungslisten richten sich nach ihrer Spalte, die Fusszeile ist mehrspaltig und ohnehin schmal. ALLES GRUEN: Gestaltung 0 Befunde, Designsystem 5, Verwaltung 69, Portal 32, Widerruf 58, Anfragedetail 20. Versionsstempel und Cache auf v18. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-23 18:47:34 +02:00
DogFatherGitandClaude Opus 5	10a075cc33	Gestaltung: Hoehensystem -- mehrschichtige Schatten und Lichtkante ... Bis hierher trug jede Karte EINEN Schatten. Das ist solide und genau der Grund, warum eine Oberflaeche "ordentlich" statt "teuer" wirkt. Echtes Licht erzeugt zwei Dinge gleichzeitig: einen engen, dunklen Kontaktschatten an der Kante -- er sagt dem Auge, dass etwas AUFLIEGT -- und einen weiten, weichen Umgebungsschatten, der sagt, wie HOCH es darueber schwebt. Nur einen von beiden zu setzen sieht aus wie ein Aufkleber; beide zusammen ergeben einen Gegenstand. Dazu die LICHTKANTE: eine 1 Pixel hohe, sehr schwache weisse Linie an der Oberkante. Sie tut so, als kaeme das Licht von oben und braeche sich an der Kante. Das ist das meistuebersehene Detail in dunklen Oberflaechen und dasjenige mit der groessten Wirkung -- ohne sie wirkt eine Karte wie ein Loch im Hintergrund, mit ihr wie ein Stueck Material. Drei Stufen, mehr braucht es nicht: ruhende Flaechen, hervorgehobene Flaechen, Schwebendes. Dazu eine vierte, umgekehrte fuer Eingabefelder: Die liegen nicht AUF der Flaeche, sie sind hineingeschnitten -- oben dunkel, unten hell. Weil es die gemeinsamen Bausteine sind, wirkt es sofort auf allen 13 Seiten: Hauptseite, Portal und Verwaltung. Dazu Feinheiten, die einzeln niemand bemerkt und in Summe den Unterschied machen: Uebergaenge auf 160-180 ms verkuerzt (alles darueber wirkt beim Ueberfahren traege), eigene Rueckmeldung beim Druecken, optische Laufweitenkorrektur fuer grosse Ueberschriften (-.028em bei h1; das Auge sieht bei 48px mehr Weissraum zwischen Buchstaben als bei 16px), text-wrap: balance gegen einzelne Woerter in der letzten Zeile. EIN FEHLER BEIM EINBAU, GEMESSEN STATT UEBERSEHEN Nach dem ersten Durchgang hatten die Karten ihre Lichtkante, der Hauptknopf nicht. Grund: Die Grundregel lautet ".wd .wd-btn--haupt, .wd-btn--haupt" -- der erste Teil zaehlt ZWEI Klassen. Mein Nachtrag zaehlte eine und verlor, obwohl er spaeter steht. Dieselbe Falle wie am 22.08.2026 bei ".wd a" gegen ".wd-btn--haupt". Aufgefallen nur, weil die Pruefung die Lichtkanten ZAEHLT. PRUEFWERKZEUGE ANGEPASST diagnose.html ist jetzt ausgenommen. Sie traegt bewusst alles fest in sich -- eigene Farben, keine Uebersetzung -- weil sie funktionieren muss, wenn genau das kaputt ist, was sie untersucht. Sie an den Regeln der eigentlichen Seite zu messen erzeugte zwei Meldungen, die man auf Dauer wegsieht. Und irgendwann sieht man dann auch eine echte weg. ALLES GRUEN: Gestaltung 0 Befunde (12 Seiten x 5 Sprachen gegen WCAG 2.2 AA), Designsystem 5, Verwaltung 69, Portal 32. Versionsstempel und Cache auf v17. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-23 18:37:17 +02:00
DogFatherGitandClaude Opus 5	be3599239d	Designsystem: eine Quelle je Farbe, Radien auf eine Skala ... Diese Runde ging eine Ebene tiefer als "sieht es gut aus": Ist das System, aus dem das Aussehen entsteht, ueberhaupt eines? DIE MESSUNG VORWEG Markenfarben ausgeschrieben im Quelltext: 155 Stellen davon Blau 74, Gold 33, Lila 22, Gruen 16, Rot 10 verschiedene Eckenradien: 12 darunter 5px, 7px, 9px, 11px Die Farben gab es laengst als Variablen. Sie standen trotzdem ueberall ausgeschrieben da, weil halbdurchsichtige Toene -- Raender, Leuchten, sanfte Flaechen -- einen Alphawert brauchen, und das mit einer fertigen Farbvariablen nicht geht: rgba(127, 208, 232, .16). Die Folge waere beim ersten Farbwechsel sichtbar geworden: Man findet 150 Stellen, uebersieht fuenf, und die Seite hat danach zwei Blautoene, die sich um eine Nuance unterscheiden. Genau das ist der Unterschied zwischen einer gewachsenen und einer gestalteten Oberflaeche. WAS GEAENDERT WURDE Kanalvariablen (--wd-blau-rgb: 127 208 232) neben den fertigen Farben. Damit schreibt man rgb(var(--wd-blau-rgb) / .16), und eine Aenderung wirkt ueberall. 164 Stellen umgestellt, verteilt ueber CSS und neun Seiten. Auch die abgeleiteten Farben zeigen jetzt auf die Kanaele statt eigene Werte zu fuehren -- und die vier Prozessfarben (--wd-p1 bis p4) sind keine eigenen Farben mehr, sondern Rollen: --wd-p1: var(--wd-blau). Sonst haette man vier weitere Stellen, die beim naechsten Farbwechsel stillschweigend zurueckbleiben. Ergebnis: Jede Markenfarbe hat genau EINE Quelle. Ausgeschriebene Markenfarben im Quelltext: 0. Radien auf vier Stufen plus Pillenform: 6 / 10 / 14 / 20 / 999. Kein Wert wurde um mehr als 2px verschoben, optisch aendert sich also nichts Spuerbares -- 12 verschiedene Werte sind auf 3 tatsaechlich verwendete zusammengeschmolzen. Zwischenwerte wie 7px oder 11px entstehen nicht aus Absicht, sondern weil man beim Bauen einer neuen Kachel nicht nachschaut, was nebenan schon gilt. DER BEWEIS, DASS ES EIN SYSTEM IST Neue Pruefung pruef-system.mjs. Sie behauptet nicht, sie STELLT UM: Die Markenfarbe wird von Babyblau auf kraeftiges Orange gesetzt und dann nachgezaehlt, ob irgendwo der alte Ton stehen bleibt. 658 von 1975 sichtbaren Elementen tragen die Markenfarbe 0 bleiben nach der Umstellung beim alten Ton Prozessfarben folgen nachweislich mit Radien: 3 Stufen UND DIE WICHTIGSTE ERKENNTNIS -- ueber das Messen selbst Der erste Anlauf meldete 110 haengengebliebene Elemente, alle in Kopf- und Fusszeile. Die naheliegende Erklaerung waere gewesen: "da steht die Farbe noch ausgeschrieben". Sie war falsch. Nachgewiesen ueber die DevTools-Schnittstelle: Auf diese Elemente wirkt die Regel ".wd a:not(.wd-btn) -> var(--wd-blau)", und --wd-blau resolviert an genau dieser Stelle korrekt zum neuen Orange. Trotzdem blieb die berechnete Textfarbe alt -- auch nach erzwungener Neuberechnung. Der Unterschied: Kopf- und Fusszeile werden von wd-core.js per innerHTML eingefuegt. Chromium erneuert solche Teilbaeume nicht zuverlaessig, wenn man eine Variable NACHTRAEGLICH umstellt. Laedt man dieselbe Seite mit bereits geaenderter Variable, sind sie orange -- gegengeprueft mit einem Minimalbeispiel, in dem derselbe Mechanismus einwandfrei funktioniert. Das Pruefverfahren wurde deshalb umgestellt: Die Variable wird VOR dem Laden ueberschrieben. Das entspricht genau dem, was eine Aenderung in der CSS-Datei bewirkt -- also dem Fall, um den es wirklich geht. Haette ich der ersten Messung geglaubt, haette ich 110 einwandfreie Stellen "repariert" und dabei das gerade aufgebaute System wieder zerlegt. Es ist der siebte Fehlalarm in eigener Messtechnik innerhalb von zwei Runden -- und der subtilste. ALLE PRUEFUNGEN GRUEN: Gestaltung 0 Befunde (13 Seiten x 5 Sprachen gegen WCAG 2.2 AA), Anfragedetail 20, Verwaltung 69, Portal 32, Widerruf 58, Textkodierung 55 Kombinationen, Designsystem 5. Versionsstempel und Cache-Name auf v9. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-23 13:05:12 +02:00
DogFatherGitandClaude Opus 5	3ca9f0b0cd	Gestaltung: WCAG-Messung ueber alle Seiten, alle Befunde behoben ... "Sieht gut aus" ist Geschmack und laesst sich nicht pruefen. Handwerkliche Qualitaet laesst sich pruefen -- und bei einer WEBDESIGN-Seite ist sie zugleich das Verkaufsargument: Wer selbst schludert, kann schlecht Sorgfalt verkaufen. Neues Werkzeug pruef-design.mjs misst 13 Seiten x 5 Sprachen auf Handy-Breite gegen WCAG 2.2 AA -- denselben Standard, auf den auch das Barrierefreiheitsstaerkungsgesetz verweist. Der Browser rechnet, es wird nichts geschaetzt. ERGEBNIS: 0 Befunde. Kontrast, Klickflaechen, Tastaturfokus, Ueberschriftenstruktur, Bildalternativen, Feldbeschriftungen, lang-Attribut, Schriftgroessen. ECHTE BEFUNDE, DIE BEHOBEN WURDEN 1. 23 Schriftgroessen unter 12px (bis hinunter zu 10,9px), verteilt ueber CSS und sieben Seiten. Betroffen waren durchweg gesperrte Grossbuchstaben-Beschriftungen -- also genau die Textsorte, die klein ohnehin am schlechtesten lesbar ist. Alle auf mindestens 12px, die gesperrten auf 12,8px. Das ist zugleich die Dauervorgabe "augenschonend" ernst genommen. 2. Ueberschriftensprung h2 -> h4 in der Fusszeile, auf ALLEN 13 Seiten in allen 5 Sprachen (42 Stellen). Wer sich mit einem Screenreader durch die Ueberschriften bewegt, hoert dadurch eine Gliederung, die es nicht gibt, und vermutet uebersprungene Abschnitte. Jetzt h2 mit Gestaltungsklasse: Die Ebene sagt etwas ueber die STRUKTUR, die Groesse ueber die GEWICHTUNG -- zwei verschiedene Dinge. 3. code-Auszeichnung auf der Rechtsseite rutschte durch relative Groessenangabe auf 11,2px. Jetzt mit Untergrenze abgesichert. SECHS FEHLALARME IM WERKZEUG -- ALLE GEFUNDEN UND BESEITIGT Der erste Lauf meldete 302 Fundstellen. Fast alle waren falsch. Haette ich sie "repariert", haette ich funktionierende Gestaltung zerstoert. Jeder Fehlalarm hatte eine eigene, nicht offensichtliche Ursache: * Farbverlaeufe: getComputedStyle().backgroundColor liefert bei einer reinen Verlaufsflaeche "rgba(0,0,0,0)". Die Suche lief an der hellen Knopfflaeche VORBEI bis zum dunklen Seitengrund und verglich dunkle Schrift mit dunklem Grund -- Ergebnis 1:1 fuer 60 einwandfreie Knoepfe. Jetzt werden die Farbstopps ausgelesen und der unguenstigste Fall gerechnet. * MEHRERE Hintergrundebenen: Die Karten nutzen den bekannten Kniff "Flaeche padding-box, Rahmenverlauf border-box". Der helle Rahmenverlauf ist im Textbereich gar nicht sichtbar. Alle Ebenen zusammenzurechnen ergab 820 Meldungen mit Werten wie "3,45:1" fuer Text, der in Wahrheit ueber 7:1 liegt. CSS malt die ERSTE Ebene oben -- nur die zaehlt. Das Trennen an Kommas muss dabei die Kommas INNERHALB der Verlaufsklammern respektieren. * Verlaufsschrift (background-clip:text): Dort ist die Schriftfarbe durchsichtig und der Verlauf IST der Text. Farbe gegen Hintergrund zu vergleichen ergibt zwangslaeufig 1:1. * Verlaufsstopps mit wenig Deckkraft (9 % und 4 % Gold in den Hinweiskaesten) wurden verworfen statt auf den Untergrund gerechnet. Uebrig blieb "nicht messbar" fuer 72 Textstellen. Ein Pruefwerkzeug, das bei allem passt, prueft nichts. * Laufende Ueberblendungen: getComputedStyle liefert waehrend einer Ueberblendung den ZWISCHENWERT. Nach blur() verblasst der Fokusring ueber 0,16 s -- misst man sofort, sieht man ihn noch, und "vorher" ist identisch mit "nachher". Das Codefeld der Verwaltung wurde dadurch als "ohne sichtbaren Fokus" gemeldet. Nachgewiesen mit el.matches(":focus") === false bei gleichzeitig sichtbarem Schatten. Loesung: Ueberblendungen fuer die Messung abschalten. * Ausgeblendete Abschnitte: Eine Ueberschrift in einem versteckten Bereich hat selbst weiterhin display:block. Im Portal wurden dadurch drei h1 gezaehlt, obwohl immer nur eine sichtbar ist. Jetzt getClientRects(). Dazu zwei bekannte Muster, die das Werkzeug jetzt kennt: der Sprunglink (absichtlich aus dem Bild geschoben) und die winzigen Auswahlfelder hinter den Kacheln (die Kachel IST die Klickflaeche). ALLE UEBRIGEN PRUEFUNGEN WEITERHIN GRUEN nach den Aenderungen: Anfragedetail 20, Verwaltung 69, Portal 32, Widerruf 58, Textkodierung 55 Seiten-Sprach-Kombinationen. Versionsstempel und Cache-Name auf v8. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-23 12:49:29 +02:00
DogFatherGitandClaude Opus 5	14ad108c87	Rechtliches: elektronische Widerrufsfunktion (§ 356a BGB), Impressum, AGB, ... Widerrufsbelehrung und Datenschutz RECHERCHIERT, NICHT AUS DEM GEDAECHTNIS Der Webdesign-Bereich hatte KEINE eigene Rechtsseite -- obwohl dort Vertraege geschlossen und Zahlungen ausgeloest werden. Die Fusszeile verwies auf die Kontaktseite des Universe, die ein Content-Projekt beschreibt, kein Dienstleistungsgeschaeft. Die Web-Recherche hat eine Pflicht zutage gefoerdert, die seit zwei Monaten gilt und die die Seite nicht erfuellt hat: § 356a BGB -- elektronische Widerrufsfunktion, in Kraft seit 19.06.2026. Sie gilt fuer ALLE Fernabsatzvertraege, die ueber eine Online-Benutzeroberflaeche geschlossen werden, nicht nur fuer Finanzdienstleistungen. WARUM DAS HIER GILT: Im Kundenportal nimmt der Kunde Zusatzangebote per Klick VERBINDLICH an ("Damit nimmst du das Zusatzangebot verbindlich an"). Das ist ein Vertragsschluss ueber eine Online-Benutzeroberflaeche. Fuer die geplanten PayPal-Zahlungen gilt dasselbe. Der Anbieter sitzt in Luxemburg. Fuer Verbraucher mit gewoehnlichem Aufenthalt in Deutschland gilt nach Art. 6 Rom-I-VO trotzdem das deutsche zwingende Verbraucherrecht, weil die Seite sich erkennbar an den deutschsprachigen Markt richtet. Deshalb wurde der STRENGERE Standard umgesetzt, nicht der bequemere. WAS GEBAUT WURDE webdesign/widerruf.html -- die Widerrufsfunktion, genau nach dem Wortlaut der Vorschrift: * Beschriftung "Vertrag widerrufen" (gesetzlich vorgegeben) * ZWEITE Schaltflaeche "Widerruf bestaetigen" (ebenfalls vorgegeben -- ein einstufiges Formular wuerde die Vorschrift nicht erfuellen) * unverzuegliche Eingangsbestaetigung mit Nummer, ZEITPUNKT (nicht nur Datum), Empfaenger und dem Wortlaut der Erklaerung * Link in der Fusszeile JEDER Seite -- "staendig verfuegbar, hervorgehoben platziert, leicht zugaenglich" heisst nicht "in den AGB versteckt" Drei Entscheidungen, die unmittelbar aus dem Sinn der Vorschrift folgen: KEINE ANMELDUNG. Die Seite ist von der Zugangswand ausgenommen. Wer seinen Code verlegt hat, wuerde sonst seine Frist verlieren -- Fristverlust durch eine selbstgebaute Huerde ist der schlimmste denkbare Fall. KEINE MENGENBEGRENZUNG. Ueberall sonst richtig, hier ein Rechtsverlust: Wer in der letzten Stunde seiner Frist wegen eines hakenden Netzes dreimal klickt, darf nicht abgewiesen werden. KEIN ZWISCHENSPEICHER. Beim Anfrageformular ein Segen, hier eine Falle: Auf einem geteilten Rechner laege der halb ausgefuellte Widerruf des einen im Browser des naechsten. webdesign/rechtliches.html -- Impressum, AGB, Widerrufsbelehrung samt Muster-Widerrufsformular, Datenschutzerklaerung. Alle Betreiberangaben sind aus den bestehenden Seiten UEBERNOMMEN, nichts erfunden: Anschrift in Mondercange, Kleinunternehmerregelung nach Art. 57 TVA-Gesetz LU und Richtlinie (EU) 2020/285, netcup/Cloudflare, PayPal Luxemburg. Migration 0014: wd_widerrufe (der dauerhafte Datentraeger und der Nachweis, wird nie geleert) und wd_zustimmungen. Letztere speichert nicht nur den Haken, sondern den WORTLAUT, den der Kunde gesehen hat -- die Beweislast fuer die Zustimmung zum vorzeitigen Leistungsbeginn liegt beim Unternehmer (§ 356 Abs. 4 BGB), und im Streit zaehlt, WAS bestaetigt wurde. Bewusst OHNE Fremdschluessel: CASCADE wuerde den Nachweis mit dem Kunden mitloeschen, RESTRICT wuerde eine DSGVO-Loeschung blockieren. Druckansicht: Die Eingangsbestaetigung ist ein Rechtsnachweis. Auf Papier schwarz auf weiss, ohne Navigation und Knoepfe -- ein Nachweis, den niemand ausdruckt, weil er eine halbe Patrone kostet, erfuellt seinen Zweck nicht. ZWEI ECHTE FEHLER GEFUNDEN 1. Die Pflicht-Sternchen verschwanden nach der Uebersetzung. Ursache: data-i18n stand auf dem <label> selbst und ersetzte dessen ganzen Inhalt -- samt <span class="wd-pflicht">. Das Anfrageformular macht es laengst richtig (data-i18n auf einem INNEREN span); die neue Seite hatte das Muster nicht uebernommen. Aufgefallen ist es nur, weil der Test die Pflichtfelder GEZAEHLT hat statt sie vorauszusetzen. 2. window.WD.sprache() gibt es nicht, die Funktion heisst getSprache(). Dadurch brach der Uebergang zur zweiten Stufe stumm ab. GEPRUEFT: 58 Pruefungen, alle bestanden. Darunter die gesetzlich vorgegebenen Beschriftungen in allen FUENF Sprachen, "kein Grund noetig", genau drei Pflichtfelder, Datum UND Uhrzeit in der Bestaetigung, und die Druckansicht. WAS FILIPE NOCH PRUEFEN LASSEN MUSS: Diese Texte sind sorgfaeltig recherchiert, aber ich bin keine Rechtsanwaeltin. Vor dem oeffentlichen Start gehoert das Ganze einmal zu einer im luxemburgischen Recht qualifizierten Fachperson -- besonders die grenzueberschreitende Lage (Sitz LU, Kunden in DE/CH/FR/PT) und die Frage, ob die Seite in Franzoesisch und Portugiesisch aktiv verkaufen soll. Dann muessen die Rechtstexte auch dorthin uebersetzt werden, und zwar fachlich. Versionsstempel und Cache-Name auf v7. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-23 12:29:09 +02:00
DogFatherGitandClaude Opus 5	469a6c195f	Portal: Aufgabenliste und Postfach fuer den Kunden ... Schritt 4 von 4 -- damit sind beide Wuensche vom 22.08.2026 vollstaendig: "wenn sie drauf druecken sollen sie auch sehen was ich schon gemacht habe von dem was im plan war" und "die kunden sollen mir auch nachrichten hinterlassen koennen". AUFGABENLISTE IM PROJEKT Bisher sah der Kunde nur die Phase ("Design . 3/7") -- eine Zahl ohne Inhalt. Sie beantwortet die eigentliche Frage nicht: WAS ist denn fertig? Die Liste steht GANZ OBEN, direkt nach dem Projektkopf, noch vor Zahlungen und Dateien. Die sind wichtig, aber sie sind nicht der Grund fuer den Klick. Zwei Entscheidungen praegen die Ansicht: 1. Offene Kundenpunkte stehen in einem EIGENEN Kasten ganz oben ("Das brauche ich noch von dir"), nicht nur farblich markiert irgendwo mittendrin. Wer eine lange Liste sieht, liest sie als Bericht ueber fremde Arbeit und ueberliest seinen eigenen Teil -- genau daraus entstehen die meisten Verzoegerungen. Ist nichts offen, steht das auch da: "Von dir wird gerade nichts gebraucht." Eine gute Nachricht darf ausgesprochen werden. 2. Der Kunde hakt seine eigenen Punkte selbst ab. Nur diese haben einen Knopf; bei fremden Punkten ist das Zeichen reine Anzeige. Ein Knopf, der nichts tut, laesst die Seite kaputt wirken. Geprueft: 4 Knoepfe bei 2 offenen eigenen Punkten (sie erscheinen zweimal), 5 feste. Grosse Zahl statt Prozent: "2 von 6 erledigt" ist greifbar, "33 %" ist eine Rechnung, die niemand fuehlt. Der Balken traegt die vier Prozessfarben -- dieselben wie auf der Ablaufseite und in der Verwaltung. Der Ton ist bewusst gewaehlt. Der Kunde liest die Liste, wenn er unsicher ist -- also im Zweifel schon angespannt. "Wir warten auf dich" waere Druck, "Das brauche ich noch von dir" ist eine Bitte. POSTFACH AUF DER UEBERSICHT Bewusst auf der Uebersicht, nicht im Projekt: Wer kein Projekt hat -- oder eine Frage, die zu keinem gehoert -- konnte vorher gar nicht schreiben und musste zur E-Mail greifen. Damit war der Verlauf weg, sobald man ihn brauchte. Niedrigschwellig: kein Betreff, kein Pflichtfeld, der Projektbezug ist freiwillig. Wer glaubt, eine Nachricht muesse eine "richtige" Anfrage sein, schreibt gar nicht erst -- und genau die kurzen Fragen sollen hier landen. Wird nachgeladen, damit die Uebersicht sofort dasteht. Projekt- und Aufgabendaten werden gleichzeitig angefordert statt nacheinander -- sonst waere die Wartezeit die Summe beider Anfragen. Die Aufgabenliste darf dabei fehlschlagen, ohne die Seite mitzureissen: Wer wegen einer leeren Liste seine Zahlungen nicht mehr saehe, waere schlechter dran als vorher. EIN SICHTBARER FEHLER GEFUNDEN Auf dem Screenshot stand "Ideen &amp;amp; Aenderungswuensche". Ursache ist eine Falle mit zwei Wegen: Texte ueber data-i18n landen als HTML in der Seite, dort ist "&amp;" richtig. Derselbe Text im JavaScript laeuft aber durch die Absicherung und wird ein zweites Mal kodiert. Derselbe Baustein ist also je nach Verwendungsort richtig oder falsch. Das kann man nicht im Kopf behalten -- deshalb neu pruef-texte.mjs mit ZWEI Pruefungen: Anzeige: alle 11 Seiten x 5 Sprachen = 55 Kombinationen, sichtbarer Text darf keine Kodierungsreste enthalten. Quelltext: welcher Baustein mit "&amp;" wird irgendwo abgesichert eingesetzt? Beide sind noetig. Gegengeprueft: Die Anzeigepruefung allein haette den Fehler NICHT gefunden, weil die Ideen-Karte erst nach einer Anmeldung erscheint. Die Quelltextpruefung findet ihn ohne Anzeige. Auch die Quelltextpruefung selbst wurde zweimal gegengeprueft: Zuerst meldete sie zusaetzlich po_senden ("Senden", voellig harmlos) -- ihre Blockerkennung lief bis zum naechsten Schluessel und schluckte dabei einen Kommentar mit "&". Jetzt zaehlt sie geschweifte Klammern. Ein Fehlalarm im Pruefwerkzeug ist fast so schaedlich wie ein uebersehener Fehler: Man gewoehnt sich daran, ihn wegzusehen. GEPRUEFT 32 Pruefungen im Portal (Computer und Handy), alle bestanden. Darunter: 114 Texte in allen fuenf Sprachen vollstaendig, Kundenpunkte stehen vor der langen Liste, Aufgaben vor den Zahlungen, Abhaken meldet den richtigen Punkt, alle Kaestchen mindestens 24 px, keine Fehler im Protokoll. Dazu 55 Seiten-Sprach-Kombinationen ohne Kodierungsreste. Ein Fehler im Test selbst gefunden und behoben: Die Adressabfrage prueft jetzt den PFAD statt der ganzen Adresse. Der API-Server heisst "postfach.dogfather-universe.com" -- ein includes("/postfach") traf den HOSTNAMEN und damit jede Anfrage, auch die Uebersicht. Versionsstempel und Cache-Name auf v5. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-23 10:46:09 +02:00
DogFatherGitandClaude Opus 5	9186d4cc1a	Verwaltung uebersichtlicher, Bildlaufleiste dunkel ... Rueckmeldung 22.08.2026 zur Anfrage-Detailansicht: "das ganze soll viel uebersichtlicher sein und nicht so durcheinander" und "die leiste rechts zum hoch und runter, kannst du die mal geil aussehen lassen anstatt einfach so kake weiss." 1. DAS DURCHEINANDER HATTE EINE URSACHE Die Kaesten standen in "columns: 2" -- Zeitungsspalten. Die fuellen sich von selbst: erst Spalte eins bis oben voll, dann Spalte zwei. Wo ein Kasten landet, haengt allein davon ab, wie lang die vor ihm sind. Bei einer Anfrage stand "Interne Notizen" oben rechts, bei der naechsten unten links. Es gab schlicht keine Ordnung, der man haette folgen koennen. Jetzt ein festes Raster mit einer Aussage: LINKS = was der Kunde geschickt hat (lesen) RECHTS = was du damit machst (handeln) Immer gleich. Nach der zweiten Anfrage weiss man, wo man hinschaut, ohne zu suchen. Rechts ist schmaler (Knoepfe brauchen weniger Platz als laufender Text) und klebt beim Scrollen mit -- die Handlungen sind der Grund, warum man die Ansicht oeffnet, sie duerfen nicht aus dem Bild wandern. Reihenfolge rechts korrigiert: "Anfrage uebernehmen" steht jetzt oben. Es ist der Knopf, den man bei einer neuen Anfrage druecken WILL -- er stand unter den Notizen und damit ausserhalb des sichtbaren Bereichs. 2. "KEINE ANGABE" WAR DIE HALBE ANSICHT Jede fehlende Angabe bekam eine eigene Zeile. Der Kasten "Umfang" enthielt zweimal nichts und war trotzdem so gross wie einer mit Inhalt. Leere Felder sind aber keine Information, sondern deren Fehlen. Sie stehen jetzt als EINE leise Zeile am Fuss: "Ohne Angabe: Bereiche, Funktionen". Aus sechs Zeilen wird eine. Weggelassen werden sie nicht -- man muss sehen, wonach gefragt wurde und was unbeantwortet blieb, genau daraus entstehen die Rueckfragen. Neu darueber: "Auf einen Blick" mit Paket, Budget, Wunschtermin und Alter. Die vier Fragen, die man immer zuerst hat, standen vorher auf drei Kaesten verteilt. Das Alter als "vor 3 Tagen" statt als Datum -- die Frage ist nie "welcher Tag war das", sondern "wie lange liegt das schon hier", und die beantwortet ein Datum erst nach Kopfrechnen. 3. BILDLAUFLEISTE -- und ein Fehler, der fast durchgegangen waere Auf einer durchgehend dunklen Seite ist eine weisse Bildlaufleiste der einzige grelle Streifen im Bild. Sie zieht den Blick dorthin, wo nichts Wichtiges steht, und blendet. Verstoesst gegen die Dauervorgabe "augenschonend". Zwei Wege noetig, weil kein Browser beide versteht: color-scheme: dark fuer Firefox/Safari (wirkt zusaetzlich auf Auswahl- und Datumsfelder, die sonst weiss aufblitzen), ::-webkit-scrollbar fuer Chrome/Edge. scrollbar-width/-color bewusst NICHT gesetzt -- sobald es dasteht, ignoriert Chrome die feineren ::-webkit-Regeln. Beim ersten Versuch stand dort nur ".wd ::-webkit-scrollbar" -- MIT Leerzeichen. Das trifft nur Elemente INNERHALB der Seite, nicht den body selbst. Alle Messungen sahen gut aus; an der einen Leiste, ueber die sich jemand beschwert hatte, haette sich nichts geaendert. Jetzt beide Fassungen, mit einem Warnhinweis im CSS. GEPRUEFT Neue Datei pruef-detail.mjs: echter Browser, 1440x900 und 390x844, mit einer absichtlich sehr knappen Anfrage -- genau die sah vorher schlecht aus. 20 Pruefungen, alle bestanden: Spalten nebeneinander bzw. auf dem Handy untereinander, rechte schmaler als linke, keine Ueberlappung, kein waagerechtes Schieben, nichts ragt aus dem Fenster, keine einzelne "keine Angabe"-Zeile mehr, keine Fehler im Protokoll. Die Bildlaufleiste liess sich nur in einem ECHTEN Browserfenster pruefen: Headless-Chromium blendet Leisten grundsaetzlich ueber dem Inhalt ein und meldet deshalb immer 0 px Breite. Mit sichtbarem Fenster gemessen: 12 px, alle sechs Regeln vom Browser akzeptiert. Versionsstempel auf allen 11 Seiten und Cache-Name des Service Workers auf v3 -- sonst liefert der eigene Zwischenspeicher beim ersten Laden weiter die alte Fassung aus. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-22 23:05:47 +02:00
DogFatherGit	38bc741660	Aufraeumen: versehentlich mitcommittete Dateien entfernt ... Ein 'git add -A' hat 13 Bild-Sicherungskopien (.bak-*, zusammen 2,6 MB), den lokalen Testserver und eine erzeugte package-lock.json mitgenommen. Die package-lock.json war der schaedlichste Teil: Auf dem Server existiert eine eigene, dort erzeugte Fassung. Eine versionierte Datei gleichen Namens laesst 'git pull' abbrechen -- der Deploy stand sofort still. Alle drei Muster stehen jetzt in .gitignore.	2026-08-22 22:57:26 +02:00
DogFatherGit	4ce51c127e	WIP: Aufgaben- und Postfach-Routen (Test folgt auf dem Server)	2026-08-22 22:56:59 +02:00
DogFatherGitandClaude Opus 5	2539fdea8d	Zahlenkreise repariert und vier Prozessfarben durchgaengig ... "wieso sehen die zahlen immer noch so scheisse aus?" -- zu Recht, und die Ursache war nicht Geschmack, sondern ein Fehler. Nachgemessen sass die Ziffer 15px NEBEN der Kreismitte. Ursache: ".po-leer-punkt span" (fuer den Beschreibungstext) trifft auch den Zahlen-Span und ist spezifischer (Klasse + Element) als ".po-leer-nr" (nur Klasse). Sie erzwang display:block, 14,4px Schrift und 23px Zeilenhoehe -- exakt die gemessenen Werte. Meine eigene "line-height: 1"-Regel kam gar nicht zum Zug. Das ist derselbe Spezifitaets-Fehler wie zuvor beim Hauptknopf (blaue Schrift auf blauem Grund) und bei den Namen auf der Zugangswand. Dreimal dieselbe Falle, deshalb steht die Begruendung jetzt ausfuehrlich im Code. Behoben ueber :not(.po-leer-nr) an beiden Textregeln. Nachgemessen: Versatz waagerecht -15px -> 0px Versatz senkrecht -8px -> -1,3px display block -> grid Schrift/Zeile 14,4/23px -> 18,4/18,4px Zweite Rueckmeldung: "es soll 4 farben geben wie 4 kategorien zum prozess". Sehr gute Idee -- sie macht das System erst schluessig. Die sieben Phasen sind in Wahrheit vier Abschnitte, und die vier Merkmalskacheln trugen ohnehin schon vier Farben. Jetzt bedeuten diese Farben ueberall dasselbe: 1 Blau Start Briefing, Angebot 2 Lila Gestaltung Design 3 Gruen Umsetzung Entwicklung, Tests 4 Gold Abschluss Abnahme, Uebergabe Die Phasenleiste faerbt erledigte Abschnitte in IHRER Farbe statt pauschal gruen -- man sieht dadurch, wie weit man ist, nicht nur DASS etwas fertig ist. Die Vorschau laeuft in denselben Farben durch. Die Legende nennt die vier Abschnitte beim Namen, damit Farbe nicht geraten werden muss: Farbe allein ist nie Information. 45/45 Handy-Abnahme, i18n vollstaendig. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-22 22:26:04 +02:00
DogFatherGitandClaude Opus 5	c597753abf	Portal: Zahlenkreise, Typografie und eine echte Farblogik fuer Phasen ... Drei Rueckmeldungen vom 22.08.2026, alle drei berechtigt. 1) "die kisten sollen auch eine spezielle farbe bekommen wenn sie fertig sind" -- das war inhaltlich der wichtigste Punkt. Vorher sahen erledigte und gerade laufende Phase fast gleich blau aus. Damit ging die einzige Aussage verloren, die die Leiste ueberhaupt traegt: naemlich WO man steht. Jetzt drei klar getrennte Zustaende: erledigt gruen, ruhig laeuft grad leuchtendes Blau mit langsamem Puls kommt noch gedaempft Die Vorschau erklaert die Logik gleich mit: ihre Leiste wandert von blau nach gruen, statt nur an- und auszugehen. Dazu eine Legende in Worten. Farbe allein ist nie Information -- wer sie nicht unterscheiden kann, liest hier trotzdem, was sie bedeutet. 2) "die zahlen sollen besser im kreis sein" -- vorher ein flacher Kreis mit Zahl. Jetzt ein doppelter Ring: aussen ein Farbverlauf als Rand, innen die dunkle Flaeche, dazu ein weicher Schein. Derselbe Kniff wie bei den Karten (Verlauf ueber border-box); der Kreis wirkt dadurch plastisch statt aufgemalt. Jede der vier Kacheln hat ihre eigene Farbe -- vier gleiche Kacheln wirken wie eine Aufzaehlung, vier unterscheidbare wie ein System. 3) "schrift soll spezieller sein" -- die Kachel-Ueberschrift war so gross wie der Text darunter und ging unter. Jetzt groesser, in der Headline-Schrift, enger gesetzt mit leicht negativer Laufweite. Die Ueberschrift "Gleich geht es los" bekommt einen Farbverlauf. 45/45 Handy-Abnahme, i18n vollstaendig, prefers-reduced-motion beachtet. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-22 22:14:00 +02:00
DogFatherGitandClaude Opus 5	ad58ab99d3	Leeres Portal: zeigen statt erzaehlen ... Rueckmeldung 22.08.2026 mit Bildschirmfoto: "dass muss noch viel spezieller, krasser und geiler sein, nicht so einfach". Der Kern des Problems war nicht die Optik, sondern die Haltung: Die Seite BESCHRIEB, was hier bald stehen wird ("Eine Leiste zeigt dir, in welcher Phase dein Projekt ist"). Beschreibungen sind schwach -- man muss sie lesen und sich dann etwas vorstellen. Jetzt steht dort eine echte, als Vorschau gekennzeichnete Projektkarte: Projektnummer, Titel, eine Phasenleiste, die langsam durchlaeuft, die Marke "Dogfather ist dran" und ein naechster Schritt. Man sieht in zwei Sekunden, was drei Saetze nicht erklaeren. Die Karte ist bewusst als Vorschau erkennbar -- gestrichelter Rand, Etikett oben rechts, gedaempfte Schrift, Nummer P-0000-0000. Sie darf nie mit einem echten Projekt verwechselt werden. Dazu ein sehr langsamer Lichtstreifen, der einmal durchwandert. Er sagt ohne Worte "hier passiert gleich etwas", ohne zu blinken oder zu zappeln -- augenschonend bleibt Dauervorgabe. Bei prefers-reduced-motion laeuft nichts, aber die Phasenleiste zeigt trotzdem drei erledigte Phasen. Ohne das staende dort eine leere graue Reihe und die Vorschau erklaerte gar nichts mehr -- ein abgeschaltetes Element muss trotzdem noch seine Aussage transportieren. 45/45 Handy-Abnahme, i18n vollstaendig. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-22 22:07:06 +02:00
DogFatherGitandClaude Opus 5	097e80b845	Projekte anlegen und ein leerer Zustand, der fuehrt statt zu enttaeuschen ... Rueckmeldung 22.08.2026 mit Bildschirmfoto aus dem eigenen Testzugang: "die seite soll jetzt schon bitte richtig krass sein und hoch profissionel, auch sehr detailliert." Zwei Luecken, beide geschlossen: 1) Projekte liessen sich nur ueber die Schnittstelle anlegen. Jetzt in der Verwaltung: pro Kunde ein "+ Projekt" mit Titel, Paket, Preis, Richttermin und naechstem Schritt. Bewusst als Einblendung direkt bei der Kundenzeile statt als eigene Seite -- man legt ein Projekt IMMER fuer einen bestimmten Kunden an, nie im luftleeren Raum. Der Kundenname steht deshalb gross im Formular, damit es nicht versehentlich dem Falschen angehaengt wird. Die 30 % Anzahlung wird beim Tippen live mitgerechnet. Sie wird zwar serverseitig berechnet, aber wer sie beim Eintippen sieht, merkt eine falsche Null sofort -- und nicht erst, wenn der Kunde ueberweisen soll. 2) Der leere Zustand im Portal war ein einziger Satz. Das ist eine verpasste Gelegenheit: Wer dort zum ersten Mal landet, hat gerade sein Passwort gesetzt und weiss noch nicht, was ihn erwartet -- genau dann entscheidet sich, ob die Seite souveraen wirkt oder unfertig. Jetzt zeigt er in vier Punkten, WAS gleich hier stehen wird (Projektstand, wer am Zug ist, Dateien und Nachrichten, Ideen jederzeit) und schliesst mit der Zusicherung, dass nichts zu tun ist. Fuenfsprachig. 45/45 Handy-Abnahme, i18n vollstaendig. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-22 21:40:27 +02:00
DogFatherGitandClaude Opus 5	1b432f456f	Kundenportal: Oberflaeche (Masterplan S.12) ... Vier Ansichten in einer Seite: Anmeldung, Passwort festlegen ueber den Einladungslink, Uebersicht, Projektdetail. 71 Textbausteine in fuenf Sprachen. Korrektur an einer frueheren Entscheidung: Ich hatte das Portal als "nur Deutsch" eingestuft wie die Verwaltung. Denkfehler -- die Verwaltung nutzen Dogfather und VanVan, das PORTAL nutzen Kunden, und die koennen Franzosen oder Portugiesen sein. Jetzt fuenfsprachig, und die Sprache des Kunden wird bei der Anmeldung automatisch uebernommen. Gestaltungsentscheidungen: * Eine Phasenleiste zeigt auf einen Blick, wo das Projekt steht. Das ist die haeufigste Frage ueberhaupt und der Grund, warum Kunden anrufen. Bei pausierten oder abgebrochenen Projekten wird KEINE Leiste gezeigt -- ein Fortschrittsbalken waere dort irrefuehrend. * Eine Marke sagt, wer gerade am Zug ist ("Wir warten auf dich" / "Dogfather ist dran"). Das beendet die haeufigste Unklarheit im Projektverlauf. * Offene Zahlungen stehen ganz oben und in Gold -- das Einzige, was den Kunden wirklich zum Handeln auffordert. * Rueckfrage nur beim ANNEHMEN eines Zusatzangebots, nicht beim Ablehnen. Annehmen erzeugt eine Zahlungspflicht, Ablehnen ist folgenlos. * Abgelaufene Sitzung fuehrt zur Anmeldung mit klarer Ansage statt zu einer leeren Seite, die wie "du hast keine Projekte" aussaehe. * Der Einladungslink wird nach Gebrauch aus der Adresszeile entfernt -- er ist verbraucht und hat in der Chronik nichts verloren. * Die Zahlungsknoepfe sagen ehrlich, dass PayPal noch eingerichtet wird, statt so zu tun als wuerde etwas passieren. Pruefskript zweimal geschaerft, beide Male waren es Fehlalarme: * Die Heuristik fuer Nachschlagetabellen hielt gewoehnliche Woerter wie "abnahme" und "uebergeben" fuer Woerterbuch-Schluessel. Jetzt muss ein Unterstrich im Namen sein, so wie bei allen echten Schluesseln. * Eine Ueberschrift gilt jetzt auch als uebersetzt, wenn die Uebersetzung INNEN sitzt (fester Teil + dynamischer Teil). i18n vollstaendig, 45/45 Handy-Abnahme. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-22 21:17:22 +02:00
DogFatherGitandClaude Opus 5	9f74167f84	Sprungmarken brechen um statt zu scrollen, keine Silbentrennung in Ueberschriften ... Rueckmeldung 22.08.2026: "ich will nicht dass man die hin und her schieben muss man soll die alle sehen aber nicht schieben muessen." Richtig, und aus zwei Gruenden: Eine Wischleiste verbirgt, DASS es noch mehr gibt -- was rechts aus dem Bild ragt, existiert fuer die meisten Menschen schlicht nicht. Dazu kam ein haesslicher Scrollbalken quer ueber die Seite. Jetzt brechen die Knoepfe um, alle fuenf sind auf einen Blick da, auch bei 320px. Der Text in den Knoepfen darf dabei mitbrechen (white-space: normal) -- ohne das sprengt ein langer Name wie "Buchhaltungs- & Steuerverwaltungsseiten" auf schmalen Bildschirmen die Zeile und der waagerechte Ueberlauf waere durch die Hintertuer zurueck. Dabei mitgefunden: "hyphens: auto" auf Ueberschriften. Auf dem Handy stand dadurch "Alles, was vorher ge-klaert sein sollte". Der Browser trennt damit nach Silben, auch wenn ueberhaupt kein Platzproblem besteht. In Fliesstext ist das ein Gewinn, in grossen Ueberschriften sieht es billig aus -- und genau die sind das Erste, was jemand sieht. overflow-wrap: break-word bleibt und faengt echte Ueberlaeufe weiterhin ab. Pruefskript: die Sprungmarken-Leisten waren als "absichtlich scrollbar" von der Ueberlaufpruefung ausgenommen. Diese Ausnahme ist raus -- sonst wuerde ein zurueckkehrender Ueberlauf dort nie auffallen. 45/45 weiterhin sauber. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-22 19:03:30 +02:00
DogFatherGitandClaude Opus 5	eaeaec6b56	Anfrageformular fertig - vier Schritte, Zwischenspeicherung, echte Absendung ... Masterplan S.10 "Projektanfrage ohne Informationsverlust" umgesetzt. End-to-End gegen die echte Datenbank belegt: Anfrage A-2608-0002 liegt drin. 38/38 Browsertests, 45/45 Handy-Abnahme. Aufbau: 4 Schritte + Zusammenfassung + Dankeseite. - Zwischenspeicherung nach jedem Tastendruck. Geschlossener Tab, leerer Akku oder versehentliches Zurueck kosten keine Arbeit. Entwuerfe verfallen nach 30 Tagen -- ein halbes Jahr alter Entwurf verwirrt mehr als er hilft. - Folgefragen erscheinen nur passend zur Auswahl und werden beim Zurueckwechseln NICHT mitgeschickt, sonst landen alte Shop-Antworten in einer Onepager-Anfrage. - Die Zusammenfassung wird aus den Feldern gelesen, nicht aus einem nebenher gepflegten Objekt -- sie kann dadurch nie etwas anderes behaupten als das, was tatsaechlich abgeschickt wird. - Telefon wird zur Pflicht, sobald "Per Telefon" gewaehlt ist. Ein Wunsch, der nicht erfuellbar ist, ist schlimmer als eine Pflichtangabe. Drei Fehler, die erst der Test gefunden hat: 1. Der "Zurueck"-Knopf stand auch auf Schritt 1 da. Ursache: das hidden-Attribut wird nur ueber "display:none" umgesetzt und verliert gegen jedes eigene display -- und Knoepfe sind inline-flex. Zentral behoben ueber ".wd [hidden] { display:none !important }". 2. Nach erfolgreichem Absenden legte zeigeSeite() den geloeschten Entwurf sofort wieder an. Beim naechsten Besuch haette eine bereits gesendete Anfrage erneut im Formular gestanden. 3. Der Server meldet bei Spamverdacht bewusst Erfolg ohne Nummer. Ein echter Mensch, der zufaellig sehr schnell war, haette eine Dankeseite mit "—" gesehen und auf eine Antwort gewartet, die nie kommt. Jetzt ein ehrlicher Hinweis mit zweitem Weg, und der Entwurf bleibt erhalten. Pruefskripte geschaerft: - i18n-Pruefung liest jetzt auch assets/js/wd-<seite>.js, sonst meldet sie reihenweise "unbenutzt" fuer Schluessel, die aus dem Seitenskript kommen. - Handy-Abnahme ueberspringt absichtlich unsichtbare Eingabefelder (Auswahlkacheln, Honigtopf). Fehlalarme sind das Ende jeder Pruefung, weil man sie irgendwann pauschal ignoriert. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-22 18:47:45 +02:00
DogFatherGitandClaude Opus 5	8ace955740	Service Worker lieferte alte Stilvorlagen aus - Korrekturen blieben unsichtbar ... Gemeldet 22.08.2026 mit Bildschirmfoto: "immer noch so" -- das Logo im Marken-Intro stand weiterhin hochkant gestreckt da, obwohl die Korrektur (height:auto gegen die height-Attribute) laengst live war. Ursache war NICHT die Korrektur, sondern mein eigener Service Worker. Er lief fuer /assets/ als "stale-while-revalidate": die gespeicherte Fassung geht sofort raus, im Hintergrund wird eine frische geholt. Das ist schnell -- bedeutet aber, dass jede Aenderung an CSS oder JavaScript beim ersten Aufruf unsichtbar bleibt und erst beim zweiten wirkt. Ein behobener Fehler sieht dadurch aus wie ein nicht behobener. Die unangenehmste Sorte. Nachgemessen ist das Logo jetzt 160x161px bei einem natuerlichen Verhaeltnis von 472x476 -- also unverzerrt. Vorher erzwang das Attribut height="476" bei 160px Breite ein Verhaeltnis von 0,34 statt 0,99, genau das lange Gesicht auf dem Bildschirmfoto. Behoben: - Stilvorlagen und Skripte laufen jetzt "Netz zuerst", Zwischenspeicher nur als Notfallnetz. Richtigkeit vor Millisekunden. - Bilder und Symbole bleiben beim schnellen Weg -- die aendern sich praktisch nie und bekaemen sonst einen neuen Dateinamen. - CACHE_NAME auf v2 gesetzt, damit der alte Speicher beim naechsten Start vollstaendig weggeworfen wird. - Versionsnummer an allen CSS/JS-Verweisen hochgesetzt, damit es sich auch ohne Service Worker sofort selbst heilt. Ausserdem: Woerterbuch fuer das Anfrageformular, 101 Textbausteine in fuenf Sprachen (vier Schritte, Zusammenfassung, Fehlermeldungen). Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-22 18:34:15 +02:00
DogFatherGitandClaude Opus 5	29a054c359	Bilder waren hochkant gestreckt und ungleich hoch, Abstaende halbiert ... Rueckmeldung 22.08.2026 per Bildschirmfoto: "die sollen alle gleich aussehen und nicht einer groesser oder kleiner" und "ich will nicht soooo viel abstand". 1) Verzerrte, ungleich hohe Projektbilder Nachgemessen: 576px breit, aber 750px bzw. 696px hoch -- also hochkant gestreckt und unterschiedlich, obwohl im CSS sauber "aspect-ratio: 16/10" stand. Ursache: die width/height-Attribute im HTML (die dort bewusst stehen, damit der Browser vor dem Laden den Platz reserviert und die Seite nicht springt) wirken wie eine CSS-Hoehe und schlagen aspect-ratio. Fix zentral ueber ".wd img[width][height] { height: auto }" statt in jeder einzelnen Regel -- so kann es bei einem neuen Bild nicht vergessen werden. Jetzt beide 576x360, Karten beide 853px hoch. 2) Zu viel Leerraum .wd-abschnitt hatte 100,8px oben UND unten, also gut 200px zwischen zwei Abschnitten. Halbiert auf 57,6px, Hero von 78svh auf 68svh. Seitenlaenge dadurch 8798px -> 7089px bei gleichem Inhalt. 3) Zwei neue Dauerpruefungen in pruefe-webdesign-handy.mjs, damit genau diese beiden Fehlerarten nicht wieder per Bildschirmfoto auffallen muessen: - verzerrte Bilder (gewuenschtes vs. tatsaechlich gerendertes Seitenverhaeltnis, 2 % Toleranz) - ungleich hohe Karten innerhalb EINER Rasterzeile 40/40 Abnahme weiterhin sauber. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-22 18:26:07 +02:00
DogFatherGitandClaude Opus 5	356bb974b8	Knopf war unlesbar, und der Code wird jetzt bei jedem Schliessen neu verlangt ... Zwei Rueckmeldungen vom 22.08.2026, beide behoben und mit Tests abgesichert. 1) "das sieht nicht gut aus" (Bildschirmfoto des Hauptknopfs) Ursache: ".wd a" ist Klasse+Element und damit spezifischer als die reine Knopfklasse ".wd-btn--haupt". Die Textfarbe des Knopfs wurde dadurch ueberstimmt -- hellblaue Schrift auf hellblauem Grund, praktisch unlesbar. Derselbe Spezifitaetsfehler wie zuvor bei den Namen auf der Zugangswand. Fix: ".wd a:not(.wd-btn)" plus zweistufig geschriebene Knopfregeln, damit das nicht wieder passieren kann. 2) "das sieht lang gezogen aus" Die Pillenform (border-radius 999px) laesst breite Knoepfe auseinandergezogen wirken, weil der Radius optisch mit der Breite mitwaechst. Jetzt fester Radius von 14px -- gleiche Form bei jeder Breite, ruhiger und hochwertiger. 3) "ich will das ich jedes mal den code gefragt werde wenn man die seite zu macht" Das Sitzungs-Cookie allein reicht dafuer nicht: Browser stellen genau solche Cookies beim Wiederherstellen von Tabs zurueck ("Dort fortfahren, wo du aufgehoert hast"), man landet dann ohne Codeabfrage wieder mitten in der Seite. Zusaetzlich jetzt eine Sitzungsmarke im sessionStorage, die beim echten Schliessen verschwindet. Fehlt sie bei vorhandenem Cookie, wird die Sitzung serverseitig beendet und zur Zugangswand geleitet. Token-Notbremse von 24 auf 8 Stunden gesenkt. 13/13 Tests im echten Browser, inklusive Schutz vor Endlosschleife. DEPLOY.md: zwei Checkouts auf dem Server dokumentiert (/home/dogiweb und /home/dogiintern) und der Vorfall, dass /webdesign nach dem Pull kurz ohne Zugangsschutz erreichbar war, weil der Dienstneustart fehlte. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-22 18:20:34 +02:00
DogFatherGitandClaude Opus 5	4b3ec450d5	Webdesign-Bereich: Fundament, oeffentliche Seiten, Zugangsschutz, PayPal ... Umsetzung des "Website Masterplan" (16 Seiten) unter /webdesign. Zugangsschutz mit EIGENER Schranke (server/webdesign-gate.js) statt gate.js: gate.js laesst seit dem oeffentlichen Start am 21.08.2026 jeden durch, weil die Pruefung auf SITE_PUBLIC_LAUNCH_AT als allererste Zeile steht. Haette man /webdesign dahintergehaengt, waere der ausdruecklich nicht-oeffentliche Bereich inklusive Preisen und spaeteren Kundendaten ab der ersten Sekunde fuer jeden lesbar gewesen. Eigenes Sitzungs-Cookie, bereich="webdesign" im Token, damit ein gueltiges Universe-Cookie hier NICHT gilt. 37/37 Tests. Sieben oeffentliche Seiten in fuenf Sprachen (de, de-CH mit echtem Dialekt, en, fr, pt). Preise, Zeitrahmen, Paketnamen und die 30-%-Regel stehen an genau EINER Stelle in wd-core.js -- der Masterplan verlangt "ueberall widerspruchsfrei", und vier Kopien laufen bei der ersten Preisaenderung auseinander. Als App installierbar auf Handy und PC. Der Service Worker speichert bewusst KEINE HTML-Seite zwischen: nach dem Abmelden wuerden sonst geschuetzte Seiten weiter ausgeliefert, ohne dass der Server je gefragt wird. 18/18 Tests. Handy-Abnahme ueber alle Seiten in fuenf Breiten (320-1440) und fuenf Sprachen: 40/40. Der Test fand 35 echte Fehler (Touch-Ziele unter 44px), behoben im Designsystem statt einzeln pro Seite. PayPal (Wunsch 22.08.2026 "sofort auf meinem paypal"): Orders API mit intent=CAPTURE, also sofortiger Einzug statt blosser Reservierung. Gebuehr und Nettobetrag getrennt gespeichert. Betraege durchgehend als Ganzzahl in Cent. Gefaelschte Webhooks werden abgewiesen. Fail closed solange Zugangsdaten fehlen. 28/28 Tests gegen einen nachgebauten PayPal-Server. Datenbank: 15 Tabellen mit Praefix wd_, fachlich vollstaendig vom Universe getrennt. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-08-22 18:06:52 +02:00