094a69732b509a5a13e2acffcdd189b04d00aced
100
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  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]> |
||
|
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]> |
||
|
DogFatherGitandClaude Opus 5
|
f435d89a16 |
Benachrichtigung bei neuer Anfrage: Push aufs Handy
BEFUND ZUERST, DENN ER WAR ANDERS ALS ERWARTET
Es gab sehr wohl eine Benachrichtigung -- ueber einen Discord-Webhook,
sauber gebaut, bewusst ohne Kundendaten im Text. Sie begann aber mit:
const url = process.env.DISCORD_WEBHOOK_WEBDESIGN;
if (!url) return;
Und diese Variable ist in .env.example nirgends aufgefuehrt. Eine
Variable, die niemand kennt, wird nicht gesetzt; dann kehrte die
Funktion wortlos zurueck. Kein Fehler, keine Protokollzeile. Es gab
eine Benachrichtigung, die nur im Quelltext existierte -- und niemand
konnte das bemerken, weil "funktioniert" und "kaputt" identisch
aussehen, solange nichts passiert.
WAS JETZT DA IST
Push aufs Handy, ohne Fremdpaket. Der interne Dienst liegt unter
/home/dogiintern mit Rechten 700 -- dort ist kein npm erreichbar, jede
Abhaengigkeit haette dauerhafte Handarbeit bedeutet. Node bringt P-256,
HKDF und AES-128-GCM selbst mit.
Die Schluessel erzeugt der Server beim ersten Start selbst und legt den
privaten Teil verschluesselt in der Datenbank ab (derselbe Weg wie die
PayPal-Zugangsdaten). Damit gibt es keinen Einrichtungsschritt, der
vergessen werden kann.
GEPRUEFT
Gegen RFC 8291 statt gegen ein Bauchgefuehl: alle fuenf Zwischenwerte
aus Anhang A stimmen (ECDH-Geheimnis, PRK_key, IKM, CEK, NONCE), und
die fertige Nachricht ist Byte fuer Byte die aus Abschnitt 5 der Norm.
Bei Kryptographie erzeugt ein Ableitungsfehler keinen Absturz, sondern
Bytes, die genauso zufaellig aussehen wie richtige.
Dazu ein Kettentest mit einem echten Empfaenger, der entschluesselt:
Kopfzeilen, Inhalt, keine Kundendaten in der Meldung, 410 loescht das
Geraet, 500 loescht es NICHT (sonst kostet eine einzelne Stoerung die
Anmeldung). 50 Pruefungen, alle gruen.
DREI ENTSCHEIDUNGEN
1. In der Meldung stehen nur Nummer und Paket. Sie erscheint auf einem
Sperrbildschirm, den auch jemand sieht, der zufaellig danebensteht.
2. Ist der Schluessel unlesbar, wird KEIN neuer erzeugt. Das waere der
bequeme Weg und der schlimmste: Ein neuer oeffentlicher Schluessel
macht schlagartig jede Anmeldung wertlos, ohne dass jemand erfaehrt,
warum nichts mehr ankommt.
3. Die Verwaltung zeigt den Zustand an und hat einen Testknopf. Genau
das fehlte dem Discord-Weg. Bei verweigerter Erlaubnis erscheint
kein Knopf, der nichts bewirkt, sondern der Weg ueber die
Browsereinstellungen.
Das stille "if (!url) return;" ist ersetzt: Jeder Weg wird einzeln
protokolliert -- auch und gerade, wenn er uebersprungen wird.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
75ab3f713f |
Sicherung: Kundendaten nicht mehr fuer jedes Konto lesbar
Der erste echte Lauf hat einen Mangel sichtbar gemacht, den das Skript selbst verursacht hat: root legt Dateien standardmaessig mit 644 an, also welt-lesbar. Nachgemessen als gewoehnliches Konto, ohne sudo: Die Sicherung liess sich nach /tmp kopieren und daraus Kundennamen, E-Mail-Adressen und Paketwahl auslesen; das Upload-Archiv ebenso. Auf dieser Maschine bestehen fuenf Konten. Eine Sicherung buendelt an einer Stelle, was sonst verstreut liegt -- sie muss enger geschuetzt sein als das Original, nicht lockerer. umask 077 fuer alles Neue; fuer die bereits angelegten Verzeichnisse zusaetzlich ausdruecklich 700 bzw. 600, denn umask wirkt nur auf neu Erzeugtes. Der gleiche Mangel besteht beim Original selbst (644 dogiintern) -- das kann ich nicht aendern, es gehoert nicht mir. Wird gemeldet. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
bf6c105bc5 |
Zeilenenden im Repo festlegen
Beim Einchecken der Sicherungsskripte meldete Git, es werde LF durch CRLF ersetzen. Diesmal ging es gut -- im Repo landet LF, und auf dem Server kam die Datei sauber an. Verlassen sollte man sich darauf nicht: Faellt bei einer .sh-Datei ein Wagenruecklauf in die erste Zeile, sucht Linux ein Programm namens "/bin/bash\r" und meldet "bad interpreter" unter Nennung eines Pfades, der voellig richtig aussieht. Dieser Fehler kostet erfahrungsgemaess mehr Zeit als er verdient. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
d62ff53062 |
Datensicherung: taeglicher Stand und geprueft Wiederherstellung
Bisher gab es keine Sicherung. Ein Plattenfehler oder ein falsches DELETE haette Kunden, Projekte, Zahlungen und Widerrufsnachweise endgueltig gekostet. sicherung.sh legt taeglich einen Stand an -- mit SQLites eigenem ".backup", nicht mit "cp". Der Grund ist messbar: Die Datenbank ist 778 KB gross, ihr WAL 4,1 MB. Eine Kopie der .db allein waere also nicht bloss veraltet, sondern weitgehend leer. Ein Gegentest mit einer frisch beschriebenen Datenbank zeigte 4 KB in der .db gegen 2,1 MB im WAL. Jeder Stand wird sofort nach dem Anlegen geprueft (integrity_check und Mindestzahl an Tabellen) -- eine Sicherung, die niemand geoeffnet hat, ist keine. 14 taegliche Staende, sonntags zusaetzlich ein Wochenstand, 8 davon: Eine still fortschreitende Verfaelschung faellt manchmal erst nach Wochen auf, wenn alle taeglichen Staende sie schon enthalten. wiederherstellen.sh geht den Weg zurueck: Sicherung erst pruefen, dann Dienst anhalten, bisherigen Stand beiseiteraeumen statt loeschen, einspielen, Dienst starten und nachsehen, ob er laeuft. Am Server geprueft: 44 Tabellen gegen das Original verglichen, 0 Abweichungen; 7 von 7 Uploads im Archiv; Rotation 17 -> 14 entfernt genau die aeltesten; Wiederherstellung spielte 100 Kunden ueber 300 und rettete die 300 nach beiseite. Eine Annahme wurde dabei widerlegt und der Kommentar entsprechend korrigiert: Ein zurueckgelassenes WAL vermischt NICHT zwei Staende -- SQLite erkennt an der Kennung, dass es nicht dazugehoert, und verwirft es. Der echte Schutz ist das Anhalten des Dienstes. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
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]> |
||
|
DogFatherGitandClaude Opus 5
|
c42fed7b27 |
Temporaere Hilfsdatei aus dem Projekt entfernt
patch15.py war ein Wegwerf-Skript zum Anpassen einer Testdatei und ist versehentlich mit eingecheckt worden. Solche Dateien gehoeren nicht ins Projekt: Sie beschreiben einen einmaligen Umbau, nicht den Zustand -- und wer sie spaeter findet, haelt sie fuer etwas, das noch gebraucht wird. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
bd0346f785 |
Verwaltung wird fluessig: von 4,5 auf 60 Bilder pro Sekunde
Bei der Systemabnahme gemessen und fuer untragbar befunden: Die Verwaltung lief mit 4,5 Bildern je Sekunde, sobald die Maus bewegt wurde. Die Startseite lag bei 60. Ein Arbeitswerkzeug, das bei jeder Mausbewegung ruckelt, ist kein Gewinn an Schoenheit. WAS GEMESSEN WURDE, STATT GERATEN Jeder Effekt einzeln abgeschaltet, mit echter Mausbewegung: alles an 6,4 Bilder/s ohne Glas 9,7 ohne Lampe 9,2 ohne Kachel-Neigung 6,4 (kostet NICHTS) ohne Glas UND Lampe 16,4 Kein einzelner Schuldiger -- es war die Wechselwirkung. Die Lampe verschiebt den Untergrund, woraufhin JEDE Glasflaeche darueber ihre Rueckseiten-Unschaerfe neu berechnen muss. Beide zusammen kosteten mehr als beide einzeln. Die Neigung ist gratis: Sie laeuft auf der Grafikkarte. Ein zweiter Posten kam dazu: Solange die Kacheln durchscheinend sind, muss das bildschirmfuellende Buehnenbild bei jeder Neuzeichnung mitgerechnet werden. Ohne Buehnenbild stieg die Rate von 24 auf 34,6. DREI EINGRIFFE 1. Glas nur noch auf dem Detailblatt. Davon gibt es immer genau eines, und es liegt gross ueber der Seite -- dort faellt die Rechenzeit einmal an, nicht pro Listeneintrag. Kacheln, Reiter und Knoepfe bekommen stattdessen eine dichte Flaeche. Optisch kaum ein Unterschied, weil die Struktur des Bildes ohnehin verschwindet. 2. Die Vollbild-Zeigerlampe ist abgeschaltet. Das Licht, das dem Zeiger folgt, gibt es weiterhin -- auf den Kacheln selbst. Das ist der Effekt, der zaehlt, und er ist billig: Er betrifft nur die Kachel unter dem Zeiger statt des ganzen Bildschirms. 3. Die Kachelflaeche ist dichter (.92/.96 statt .52/.68). Die Buehne bleibt rings um die Kacheln voll sichtbar, durch die Kachel selbst schimmert sie nur noch als Ahnung. ERGEBNIS in Ruhe (lesen) 55,6 -> 60,6 Bilder/s beim Scrollen 54,0 Zeiger bewegt 4,5 -> 28 DIE BILDRATE IST JETZT SELBST EIN PRUEFPUNKT Ohne ihn kaeme jederzeit ein weiterer huebscher Effekt dazu, der die Seite still wieder zaeh macht -- und niemand wuesste, welcher es war. Der Durchlauf verlangt jetzt ueber 45 Bilder je Sekunde in Ruhe. NEBENBEFUND Die Regel fuer das Detailblatt stand unter "#vw-bereich" -- das Blatt liegt aber in einer eigenen Ueberlagerung. Die Regel griff also nie: Ausgerechnet die eine Flaeche, die eine Unschaerfe wirklich verdient, hatte als einzige keine. Gefunden hat das der neue Test. Geprueft: 1281 Pruefungen gruen (Browser 715, Server 566), i18n ohne Fehler, WCAG ohne Fundstellen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
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]> |
||
|
DogFatherGitandClaude Opus 5
|
686e8924bb |
Portfolio: Kacheln einer Reihe sind gleich gross
Die Projekttexte sind unterschiedlich lang, also waren auch die Kacheln unterschiedlich hoch. Jetzt bekommen alle Kacheln einer Reihe dieselbe Hoehe, naemlich die der hoechsten. Dafuer waren drei Dinge noetig, und nur das erste ist offensichtlich: 1. "align-items: start" musste weg. Es liess jede Kachel ihre natuerliche Hoehe behalten -- genau das war der Fehler. 2. Der Inhalt muss die zusaetzliche Hoehe auch aufnehmen koennen. Ohne Flex-Aufbau in Kachel und Inhalt waere die Kachel zwar hoeher, ihr Inhalt bliebe aber oben kleben und darunter entstuende ein leeres Feld. 3. Das letzte Element sitzt am unteren Rand. DER PUNKT, DER FAST DURCHGERUTSCHT WAERE Gleich hohe Kacheln heissen NICHT automatisch, dass der Inhalt buendig steht. Nach Schritt 1 und 2 waren die Kacheln exakt gleich hoch -- und die Knoepfe standen trotzdem auf verschiedener Hoehe. Grund: Die Abstaende standen als style-Angabe direkt im HTML (style="margin-top:1rem"). Eine solche Angabe schlaegt jede Regel aus dem Stilblatt, das "margin-top: auto" lief also ins Leere. Fuenf Vorkommen entfernt. Danach blieben 33 gegen 48 Punkte Abstand zum Kachelboden: Ein Absatz bringt einen eigenen Abstand nach unten mit, eine Knopfreihe nicht. Auch das ist jetzt vereinheitlicht. Die Regel greift ueber :last-child statt nur ueber die Knopfreihe -- die Buchhaltungs-Kachel hat naemlich gar keinen Knopf, sondern einen Hinweistext an dieser Stelle. Der soll genauso unten stehen. DIE PRUEFUNG MISST BEIDES GETRENNT Einmal "jede Reihe ist in sich gleich hoch", einmal "die letzten Elemente stehen auf einer Linie". Ein einzelner Test auf die Hoehe haette den Knopf-Versatz nie bemerkt -- die Kacheln waren ja bereits gleich hoch, als die Knoepfe noch verrutscht waren. Gemessen: 1129/1129, 881/881, 831 -- und ueberall 33 Punkte Abstand zum Kachelboden. Geprueft: 313 Pruefungen gruen (Portfolio 34, Bewegung 34, Verwaltung 62, CRYONOVA 53, Blickfang 13, System 5, Abmelden 16, Abbruch 42, Angebot 54). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
4d39b0e989 |
Portfolio: zwei Projekte nebeneinander
Die Kacheln nahmen bisher die volle Breite ein -- ueber 1180 Punkte pro Stueck. Jetzt stehen zwei nebeneinander, jede etwa 574 Punkte breit. ZWEI UMWEGE, DIE NICHT FUNKTIONIERT HABEN Zuerst stand hier auto-fit mit einer Mindestbreite von 420 Punkten. Das klang flexibel, hatte aber zwei Haken: Auf einem Tablet mit 900 Punkten blieb es einspaltig, weil zwei Spalten plus Abstand knapp nicht mehr in den Container passten (869 gegen 828 verfuegbare Punkte). Auf 360 gesenkt, wurden daraus auf einem breiten Schirm dann DREI Spalten -- auto-fit fuellt eben so viele, wie hineinpassen. Gewuenscht sind ausdruecklich zwei, also steht die Zahl jetzt fest, mit einem Umbruch auf eine Spalte unter 760 Punkten. minmax(0, 1fr) statt nur 1fr: Ohne die Null als Mindestbreite bekommt eine Rasterspalte automatisch die Breite ihres breitesten Inhalts als Untergrenze. Ein langer Projektname ohne Leerzeichen wuerde die Spalte dann aufblaehen und das Raster aus dem Container schieben. WAS SICH NEBENBEI VON SELBST ERLEDIGT Der Kippwinkel haengt an der Kachelgroesse. Halb so breite Kacheln kippen dadurch automatisch etwas lebendiger, ohne dass hier ein Wert nachgestellt werden muesste -- die Portfolio-Kachel war ja gerade deshalb die traegste von allen. Das Bild ist von 16:10 auf 16:9 geflacht: Bei halber Breite waere ein 16:10-Bild sehr hoch geworden und haette das Verhaeltnis von Bild zu Text in der Kachel gekippt. Der Abstand kommt jetzt vom Raster statt von einem Aussenabstand unten -- sonst saehen die Kacheln einer Zeile ungleich hoch aus. GEPRUEFT UEBER SECHS BILDSCHIRMBREITEN 1920px 2 Spalten Kachel 574px 1440px 2 Spalten Kachel 574px 1200px 2 Spalten Kachel 538px 900px 2 Spalten Kachel 403px 700px 1 Spalte Kachel 644px 390px 1 Spalte Kachel 359px Jeweils mit Gegenprobe, dass nichts seitlich ueberlaeuft. Ein Test auf nur einer Breite haette den Dreispalten-Fall nie bemerkt. Geprueft: 310 Pruefungen gruen (Portfolio 31, Bewegung 34, Verwaltung 62, CRYONOVA 53, Blickfang 13, System 5, Abmelden 16, Abbruch 42, Angebot 54). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
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]> |
||
|
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]> |
||
|
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]> |
||
|
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]> |
||
|
DogFatherGitandClaude Opus 5
|
ae8c498672 |
Verwaltung: die Effekte liegen jetzt auf den ECHTEN Kacheln
Der Grund, warum von allem bisher nichts zu sehen war. Saemtliche Effekte -- Glas, Neigung, Prisma-Kante, Lichtkegel, Glanzstreifen, Facetten, gestaffeltes Auftauchen -- lagen auf ".wd-karte". Diese Klasse kommt im Verwaltungsbereich aber fast nicht vor. Die Listen bestehen aus ".vw-karte", die Meldungen der Uebersicht aus ".vw-meld". Gebaut, gemessen, geprueft, deployt -- und alles auf Elementen, die es dort gar nicht gibt. Der Test hat das nicht gefunden, weil er sich seine Probekachel selbst gebaut hat: als .wd-karte. Er hat also eine Attrappe geprueft und war zurecht gruen, waehrend auf den echten Kacheln nichts ankam. Ein Test, der seinen eigenen Pruefgegenstand erfindet, kann diese Sorte Fehler grundsaetzlich nicht sehen. WAS JETZT ANDERS IST Alle Effekte gelten fuer .vw-karte und .vw-meld: - Glas mit Rueckseiten-Unschaerfe - raeumliche Neigung zum Zeiger, hoechstens 7 Grad - Lichtkegel und Prisma-Kante, die dem Zeiger folgen - Glanzstreifen, der mit der Neigung wandert - ungleich geschliffene Ecken - gestaffeltes Auftauchen beim Bereichswechsel - Projektnummer und Name stehen vor der Flaeche (translateZ) Dazu setzt der Verwaltungsbereich die Lichtposition jetzt selbst. Der Verfolger im Grundsystem (wd-core.js) sucht ausdruecklich nur ".wd-karte" -- auf .vw-karte waere der Lichtkegel bei seinem Startwert oben mittig kleben geblieben, selbst nachdem alles andere stimmte. DER TEST BAUT JETZT DIE ECHTE STRUKTUR NACH .vw-karte mit .vw-karte-nr, .vw-karte-mitte und .vw-karte-rechts, genau wie das Skript sie erzeugt. Zwei Stueck statt einer, damit auch die Staffelung an echten Geschwistern gemessen wird. Geprueft: 260 Pruefungen gruen (Verwaltung 62, Portfolio 15, CRYONOVA 53, Blickfang 13, System 5, Abmelden 16, Abbruch 42, Angebot 54). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
494946386a |
Verwaltung: die Kacheln werden zu geschliffenen Glasplatten
Buehne und Zeigerlicht bleiben unveraendert. Diesmal geht es nur um die Kacheln selbst. SIE LIEGEN IM RAUM, NICHT AUF DER SEITE Faehrt der Zeiger darueber, neigt sich die Kachel ihm entgegen -- als wuerde man eine echte Glasplatte kippen. Beim Ueberfahren kommt sie dem Betrachter zusaetzlich entgegen und wirft einen laengeren Schatten. Erst das macht aus der Neigung ein Objekt im Raum statt eines schraegen Bildes. Der Ausschlag liegt bei hoechstens 7 Grad (gemessen 6,7). Alles darueber verzerrt die Schrift sichtbar, und auf diesen Kacheln wird gearbeitet, nicht nur geschaut. DER INHALT STEHT VOR DER FLAECHE Ueberschriften weiter vorn als Fliesstext. Dadurch entsteht beim Neigen echte Staffelung statt einer flachen Ebene, die sich mitdreht -- und der Text bleibt scharf, obwohl die Flaeche unter ihm schraeg liegt. DAZU EIN GLANZSTREIFEN UND UNGLEICHE ECKEN Ein schmales Licht laeuft ueber die Platte und wandert mit der Neigung. Die Ecken sind diagonal weit und diagonal knapp gerundet: Eine gleichmaessig gerundete Kachel liest sich als Knopf, die ungleiche nimmt die Facetten der Motive auf. DIE FALLE, DIE ICH SCHON KANNTE Die Auftauch-Animation der Kacheln nutzte "transform" und haelt ihren Endwert fest -- eine Animation schlaegt jede normale Regel, die Neigung waere also wirkungslos geblieben. Genau dieselbe Falle wie zuvor bei der Buehne, nur eine Ebene tiefer. Die Animation nutzt jetzt "translate" und "scale" als eigene Eigenschaften; "transform" bleibt der Neigung vorbehalten. DREI FEHLER IM TEST, NICHT IN DER SEITE - Der Staffelungstest raeumte die Probekachel leer. Danach fehlten ihr Ueberschrift und Text, und der Neigungstest stuerzte ab, weil er auf ein nicht vorhandenes Element zugriff. Er hat jetzt einen eigenen Behaelter. - Die Winkelrechnung las die "3" aus "matrix3d" als erste Zahl mit und verschob damit jeden Eintrag um eine Stelle. Der Winkel kam als 0,4 Grad heraus statt als 6,7 -- die Pruefung "flach genug" waere also immer gruen gewesen, egal wie stark die Kachel kippt. - Der Schwellwert fuer den senkrechten Ausschlag war zu streng. Eine flache Kachel ist nur gut 100 Punkte hoch; 20 Punkte vom Rand liegen dort schon fast in der Mitte. Geprueft wird jetzt der Vorzeichenwechsel statt eines festen Betrags. Bei prefers-reduced-motion ist alles davon aus: keine Neigung, keine Tiefe, kein Glanz. Ohne feinen Zeiger entfaellt es ebenfalls -- auf einem Telefon gibt es kein Schweben. Geprueft: 260 Pruefungen gruen (Verwaltung 62, Portfolio 15, CRYONOVA 53, Blickfang 13, System 5, Abmelden 16, Abbruch 42, Angebot 54). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
4c0941c6da |
Verwaltung: Zeigerlampe, Prisma-Kanten, schwebende Partikel
Drei Dinge, die zusammen ein Konzept ergeben: Das Bild reagiert auf den Zeiger, die Kacheln brechen das Licht wie Eis, und im Raum schwebt etwas. 1. DIE ZEIGERLAMPE Ein weicher Lichtkegel wandert ueber die Buehne und hellt die Kristalle dort auf, wo der Zeiger steht. Damit wird das Bild zu einer Flaeche, die auf einen reagiert, statt nur dazuzuliegen. Der Kniff steckt in mix-blend-mode: soft-light. Ein normaler heller Verlauf wuerde das Bild ueberdecken und milchig machen. "soft-light" rechnet stattdessen mit dem, was darunter liegt -- dunkle Stellen bleiben dunkel, vorhandene Lichtkanten der Kristalle werden verstaerkt. Das Bild wird nicht ueberstrahlt, es wird beleuchtet. Bewusst NICHT "screen" oder "overlay": Beide lassen die Eiskanten ausbrennen, und genau die machen den Reiz der Motive aus. 2. PRISMA-SCHIMMER AN DEN KACHELKANTEN Am hellsten Punkt sitzt die Leitfarbe, daneben faechert die Kante in Nachbartoene auf -- wie Licht, das sich in einer Glaskante bricht. Bewusst KEIN Regenbogen: Volle Spektralfarben sehen nach Seifenblase aus, nicht nach geschliffenem Eis. Es bleibt in der kalten Haelfte der Palette. Die Kante ist dafuer 1,5 px statt 1 px -- bei genau einem Punkt verschluckt das Bildschirmraster die Aufaecherung fast vollstaendig. 3. SCHWEBENDE PARTIKEL Neun Lichtpunkte steigen sehr langsam auf, jeder mit eigener Bahn, Dauer und Startzeit. Rein aus CSS, ohne Zeichenflaeche -- eine Zeichenflaeche wuerde dauerhaft Rechenzeit kosten, und das auf einer Seite, auf der man arbeitet. Es soll wirken wie Staub im Lichtkegel, nicht wie Schneefall. DER FEHLER, DEN ERST DER SCREENSHOT ZEIGTE: Die Lampe legte sich als gruenlicher Fleck mitten auf eine Kachel. Ein Element mit mix-blend-mode mischt sich mit ALLEM in seinem Stapelkontext -- auch mit Elementen, die eigentlich darueber liegen. Buehne und Lampe stecken deshalb jetzt in einem gemeinsamen Raum mit isolation: isolate. Dort endet die Mischung, und die Lampe beleuchtet nur noch das Bild. Was DANACH noch durchkam, ist dagegen richtig so: Die Kacheln tragen eine Rueckseiten-Unschaerfe, nehmen also auf, was hinter ihnen liegt. Licht, das durch Milchglas scheint. Bei einem engen Kegel war davon allerdings ein scharf umrissener Kreis uebrig -- deshalb jetzt ein weiter Radius mit flachen Stufen, damit sich der Helligkeitsunterschied ueber die halbe Kachel verteilt und als Schimmer liest. Drei Testmeldungen waren durch den Umbau entstanden und kein Mangel der Seite: Haltung, Stapelplatz und die Auszeichnung als Zierde sitzen jetzt am Raum, nicht mehr an der Buehne darin. Der Test prueft sie dort. Bei prefers-reduced-motion sind die Partikel komplett weg -- nicht nur angehalten. Ein eingefrorener Punkt mitten im Bild waere ein Fleck ohne Sinn. Ohne feinen Zeiger entfaellt die Lampe ganz. Geprueft: 252 Pruefungen gruen (Verwaltung 54, Portfolio 15, CRYONOVA 53, Blickfang 13, System 5, Abmelden 16, Abbruch 42, Angebot 54). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
fdf3e5349e |
Verwaltung: gleitender Leuchtbalken, gestaffelte Kacheln, Reiterlicht
Drei weitere Stufen auf der Buehne.
1. DER GLEITENDE LEUCHTBALKEN
Unter der Reiterreihe liegt ein Balken in der Leitfarbe. Beim Wechsel
springt er nicht, sondern gleitet zum neuen Reiter und faerbt sich dabei
um.
Position und Breite kommen aus dem ECHTEN Reiter, im Browser gemessen.
Feste Werte waeren hier zwangslaeufig falsch: Die Reiter sind
unterschiedlich breit ("Kunden" gegen "Zahlungen"), sie verschieben sich
beim Sprachwechsel, und auf schmalen Schirmen brechen sie um -- deshalb
wandert auch die Hoehe mit, nicht nur die Seite.
2. DIE KACHELN TAUCHEN GESTAFFELT AUF
Beim Bereichswechsel erscheinen sie nacheinander statt alle auf einmal.
Nur die ersten acht bekommen einen Versatz -- bei einer langen Liste
kaeme die letzte Kachel sonst spuerbar spaeter, und das fuehlt sich
nicht mehr elegant an, sondern langsam.
3. DAS LICHT FOLGT AUCH AUF DEN REITERN
Die Verfolgung im Grundsystem greift ausdruecklich nur auf Karten. Fuer
die Reiter ist sie hier ergaenzt, gedrosselt ueber
requestAnimationFrame -- aus demselben Grund wie dort.
ZWEI FEHLER, DIE DER TEST GEFUNDEN HAT:
Der Balken stand auf Breite 0 und blieb unsichtbar. Ein blosser
"resize"-Horcher reicht naemlich nicht: Der haeufigste Fall ist gar
keine Fenstergroessenaenderung, sondern das Sichtbarwerden. Beim Start
ist der Arbeitsbereich versteckt, die Leiste also 0 Punkte breit -- und
ein verstecktes Element loest kein resize aus. Jetzt beobachtet ein
ResizeObserver die Leiste; das deckt Sichtbarwerden, Umbrechen und
Sprachwechsel gleichermassen ab.
Und die Messung hing allein am Klick-Listener. Wechselt der Bereich auf
einem anderen Weg -- etwa direkt nach dem Anmelden, wenn der
Arbeitsbereich zum ersten Mal auftaucht -- wurde nie nachgemessen.
balkenSetzen ist deshalb jetzt nach aussen verfuegbar.
Alles Bewegte bleibt bei prefers-reduced-motion aus: kein Gleiten, kein
Auftauchen, keine Parallaxe, kein Reflex. Die Buehne bleibt sichtbar.
Ein Wort zum Test selbst: Er prueft "der Balken springt" nicht mehr auf
wortwoertlich "0s". Die Testumgebung emuliert reduzierte Bewegung, indem
sie Uebergaenge auf eine Mikrosekunde setzt statt auf null -- gemeldet
wird "1e-06s". Wahrnehmbar ist das identisch; ein Test auf exakt "0s"
haette nur die Emulation gemessen, nicht die Regel.
Geprueft: 244 Pruefungen gruen (Verwaltung 46, Portfolio 15, CRYONOVA 53,
Blickfang 13, System 5, Abmelden 16, Abbruch 42, Angebot 54).
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
a74d924445 |
Verwaltung: das Licht kommt zurueck, die Buehne atmet
Vier Dinge dazu, drei davon Bewegung, eines eine Reparatur. 1. DAS LICHT FOLGT WIEDER DEM ZEIGER Es war nie weg. --wd-lichtx/--wd-lichty wurden die ganze Zeit gesetzt, der Lichtkegel stand korrekt an der richtigen Stelle -- er war nur unsichtbar geworden. Die 28 % Deckkraft aus dem Grundsystem sind fuer eine dunkle, undurchsichtige Kachel gedacht. Auf einer Glasflaeche, durch die eine beleuchtete Kristallwelt schimmert, geht das schlicht unter. Jetzt wirkt es auf zwei Ebenen: der Lichtkegel auf der Flaeche, und die KANTE der Kachel leuchtet dort auf, wo der Zeiger steht. Zusammen sieht es aus, als laege eine echte Lichtquelle ueber dem Glas, statt als waere ein Fleck aufgemalt. Die Farbe ist die Leitfarbe des Bereichs -- im Kundenbereich leuchtet es Indigo, bei den Zahlungen Gold. 2. DIE BUEHNE BEWEGT SICH GEGEN DEN ZEIGER Wenige Bildpunkte, gemessen 5,8 px Ausschlag. Gerade genug, dass sich der Raum echt anfuehlt statt wie eine Tapete -- und wenig genug, dass beim Lesen nichts im Augenwinkel wandert. Ein Test haelt die Obergrenze fest. 3. EIN LICHTREFLEX BEIM BEREICHSWECHSEL Ein einzelner heller Streifen zieht schraeg ueber die Buehne, genau einmal, dann ist er weg. Ein Moment, kein Dauerflackern. 4. DIE KACHEL HEBT SICH BEIM UEBERFAHREN AN Zwei Bildpunkte. Sie soll reagieren, nicht huepfen. DER FEHLER, DEN DER TEST GEFUNDEN HAT: Die Parallaxe wirkte zuerst gar nicht. Die Werte kamen sauber an (--vw-px, --vw-py standen korrekt am Element), das Bild stand trotzdem still. Grund: Die Einblend-Animation animiert "transform" und haelt ihren Endwert fest (fill-mode both) -- und eine Animation schlaegt jede normale Regel. Die Verschiebung steht deshalb jetzt in "translate", einer eigenen Eigenschaft, die VOR "transform" angewendet wird. Beide koennen sich so nicht mehr in die Quere kommen. Alles Bewegte ist bei prefers-reduced-motion aus: keine Parallaxe, kein Reflex, kein Anheben. Die Buehne bleibt aber sichtbar -- abschalten heisst nicht verschwinden. Auch das wird geprueft. Die Parallaxe laeuft nur auf Geraeten mit echtem Zeiger und ist ueber requestAnimationFrame gedrosselt. Ohne die Drosselung rechnet der Browser bei jeder einzelnen Zeigerbewegung neu, und das merkt man ausgerechnet beim Scrollen durch lange Listen. Geprueft: 236 Pruefungen gruen (Verwaltung 38, Portfolio 15, CRYONOVA 53, Blickfang 13, System 5, Abmelden 16, Abbruch 42, Angebot 54). Die Lesbarkeit ueber der Buehne liegt weiter bei 11,9 bis 14,6:1, verlangt sind 4,5:1. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
b147ed0d94 |
Verwaltung: das Bild wird zur Buehne statt zum Streifen
Der erste Anlauf hat die Motive kaputtgemacht. Sie standen in einem schmalen Streifen, auf 190 % gezoomt, davon ein Ausschnitt gewaehlt und die linke Haelfte voll zugedeckt -- alles nur, damit Text darauf lesbar bleibt. Von einer Kristallwelt, die ueber das ganze Bild geht, war ein Zipfel uebrig. Der Denkfehler: Bild und Text auf dieselbe Ebene zwingen und dann das Bild opfern. Jetzt liegen sie auf zwei Ebenen. DAS BILD IST DIE BUEHNE. Bildschirmfuellend, fest stehend, ungeschnitten, ungedimmt. Kein Zoom, kein einseitiges Abdunkeln. Beim Bereichswechsel wechselt der ganze Raum. DER INHALT SCHWEBT ALS GLAS DARUEBER. Karten, Reiter, Bedienknoepfe und selbst die Meldung "Wird geladen" bekommen eine Rueckseiten-Unschaerfe. Das Motiv bleibt sichtbar, verliert hinter dem Glas aber jede Struktur -- und genau das macht Text darauf ruhig lesbar. Dadurch muss das Bild nirgends mehr weichen. Die Kacheln tragen eine Leuchtkante in der Leitfarbe des Bereichs. Das bindet Inhalt und Buehne zusammen, statt die Kacheln wie aufgeklebte Zettel wirken zu lassen. Weil der Text jetzt auf Glas steht statt auf dem Bild, konnte auch die Toenung deutlich zurueckgenommen werden: von .42/.58/.72 auf .18/.38/.60. Mehr Bild, gleiche Lesbarkeit -- gemessen 12,4 bis 14,5:1 auf der Kachel, verlangt sind 4,5:1. Die Pruefung ist mitgedreht und misst jetzt das Gegenteil von vorher: - Wird das Bild NICHT gezoomt und NICHT ausgeschnitten? (frueher stand hier "190% auto" und "84% 46%") - Traegt jede Flaeche, auf der gelesen wird, wirklich Glas? - Bleibt der Text lesbar -- gemessen an echten Bildpunkten, nicht am rechnerischen Wert des Stilblatts. Die Kachel ist halbdurchsichtig, ihr Sollwert sagt nichts darueber, was am Ende darunter liegt. Dazu die Vergleichsmessung: Wie unruhig ist der Kachelgrund MIT Buehne gegenueber ohne? Gemessen: minus 1 bis plus 1 in allen sechs Bereichen. Das Glas arbeitet. Was unveraendert gilt: Bewegung aus bei prefers-reduced-motion, aber die Buehne bleibt sichtbar -- abschalten heisst nicht verschwinden. Auf dem Handy die kleine Bildfassung und eine etwas dichtere Toenung, weil dort mehr Inhalt uebereinander liegt. Geprueft: 229 Pruefungen gruen (Verwaltung 31, Portfolio 15, CRYONOVA 53, Blickfang 13, System 5, Abmelden 16, Abbruch 42, Angebot 54). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
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]> |
||
|
DogFatherGitandClaude Opus 5
|
9df21fabe1 |
Verwaltung: Bildschmuck an zwei Stellen, beide ausserhalb der Arbeit
Die Verwaltung ist ein Arbeitsplatz. Hier wird nicht geworben, hier werden Listen gelesen und Zahlen verglichen -- der Schmuck ist deshalb deutlich zurueckhaltender als auf den oeffentlichen Seiten. Zwei Stellen, beide bewusst ausserhalb des Arbeitsflusses: - Ein Ring-Streifen ganz oben, der nach unten wegblendet. Er sitzt direkt unter der Kopfleiste und ist verschwunden, bevor die erste Tabelle anfaengt. Deckkraft 16 % (Handy 13 %) -- die oeffentlichen Motive liegen bei 55 %. Dort traegt das Bild die Stimmung, hier darf es die Kopfzeile nur andeuten. - Das Wappen auf der Anmeldekarte. Dort wird nichts gelesen ausser drei Zeilen, also darf es sichtbarer sein. Was hier ABSICHTLICH nicht passiert: kein Motiv hinter Listen, Tabellen oder Zahlen. Ein Bild hinter einer Zahlenspalte ist genau die Art von Schoenheit, die ein Werkzeug unbrauchbar macht. Ein Test haelt das fest. Ein echter Fehler beim Bauen, den erst der Screenshot zeigte: Das Wappen stand zuerst auf 38 % und mittig -- der Hundekopf lag genau im Erklaertext, die Zeilen liefen quer ueber Schnauze und Schriftzug. Jetzt 16 % und nach unten versetzt, sodass es hinter Eingabefeld und Knopf sitzt statt hinter den Zeilen. Die Glasflaeche darueber ist hier dichter als auf den oeffentlichen Seiten. Der Test dazu misst nicht die Deckkraft, sondern das eigentliche Problem: wie stark der Untergrund UNTER DER SCHRIFT schwankt, an echten Bildpunkten aus dem Absatz. Deckkraft allein sagt naemlich nichts -- ein Motiv mit hellen Kanten ist bei 20 % stoerender als ein ruhiges bei 50 %. Und er misst im Vergleich, nicht gegen eine geratene Zahl: Schon die weichgezeichneten Buchstabenkanten allein erzeugen eine Schwankung von 12. Ein fester Grenzwert "unter 14" haette also fast nur diese Kanten gemessen und waere je nach Schriftgroesse zufaellig gruen oder rot. Der Test schaltet das Motiv jetzt ab, misst erneut und prueft die Differenz. Gemessen: mit 14, ohne 12, also plus 2. Die Tag-Balance von verwaltung.html bleibt unveraendert bei Differenz 1 (vorher 192/191, jetzt 193/192) -- das neue Element ist ausgeglichen, die alte Meldung ist Altbestand und wurde hier nicht angefasst. Geprueft: 219 Pruefungen gruen (Verwaltung 21, Portfolio 15, CRYONOVA 53, Blickfang 13, System 5, Abmelden 16, Abbruch 42, Angebot 54). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
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]> |
||
|
DogFatherGitandClaude Opus 5
|
01b61905aa |
Altfaelle aufraeumen: abgebrochene Projekte verschwinden aus der Liste
P-2608-0001 wurde abgebrochen, bevor es das Archiv-Kennzeichen gab. Es hat deshalb zwar den Status "abgebrochen", aber archiviert = 0 -- und stand bis heute zwischen den offenen Auftraegen. Also genau das, was der Wunsch "wenn ich abbreche dan sollen die auch da weg" abstellen sollte. Ueber die Oberflaeche war das nicht zu reparieren: Die Verwaltung zeigt bei Status "abgebrochen" den Info-Block statt des Abbrechen-Knopfes, ein zweiter Klick war also gar nicht moeglich. Migration statt Handarbeit in der Datenbank: Ein einzelner UPDATE per Hand repariert einen Fall und hinterlaesst keine Spur. Die Migration erwischt jeden Altfall, laeuft ueberall gleich (Server, Testdatenbank, ein spaeterer Neuaufbau) und steht nachvollziehbar in der Geschichte. Bewusst NICHT gefuellt: abbruch_am, abbruch_grund, abbruch_wer, abbruch_erstattung_cent. Diese Felder gab es beim damaligen Abbruch noch nicht. Sie nachtraeglich mit plausiblen Werten zu fuellen waere eine Behauptung ueber einen Vorgang, bei dem niemand mehr weiss, wie er wirklich ablief -- und ausgerechnet im Streitfall waere das die gefaehrlichste Stelle fuer eine Erfindung. Ein leeres Feld sagt ehrlich "unbekannt", und die Verwaltung zeigt diese Angaben ohnehin nur an, wenn sie gefuellt sind. Der Test stellt den Altzustand echt nach: alle Migrationen bis 0017, dann der Altfall, dann erst 0018. Geprueft wird auch, was NICHT passieren darf -- ein laufendes Projekt bleibt unberuehrt, ein sauber abgebrochenes behaelt Datum, Grund und Erstattung, und ein zweiter Durchlauf aendert nichts mehr (beim Wiederherstellen einer Sicherung passiert genau das). Geprueft: 167 Pruefungen gruen (Altabbruch 16, Automatik 55, Angebote 56, Kette 40). Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
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]>
|
||
|
DogFatherGit
|
336e702d90 |
Druckansicht von der Weiss-Regel ausgenommen
Die Vollstaendigkeitspruefung meldete Punkt 13 (keine weissen Vollflaechen) als offen. Nachgesehen: Alle Weiss-Werte stehen ausschliesslich in @media print. Auf Papier IST Weiss richtig -- dunkles Navy zu drucken waere Toner-Verschwendung und schlecht lesbar. Das Verbot des Design-Systems gilt dem Bildschirm, nicht dem Ausdruck. Die Pruefregel machte den Unterschied nicht und meldete damit voellig korrekte Druckregeln als Verstoss. Damit sind alle 14 Punkte der Vollstaendigkeitspruefung erfuellt. |
||
|
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. |
||
|
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. |
||
|
DogFatherGit
|
305920d872 | Cache-Version fuer die Portal-Korrektur (Countdown vor Anzahlung) | ||
|
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.
|
||
|
DogFatherGitandClaude Opus 5
|
e43375728c |
Abgebrochene Projekte verschwinden aus der Liste
Rueckmeldung: 'wenn ich abbreche dan sollen die auch da weg'. Ein abgebrochenes Projekt in der laufenden Liste stehen zu lassen ist doppelt schaedlich: Es verstellt den Blick auf das, was wirklich laeuft, und beim schnellen Durchsehen haelt man es fuer eine offene Baustelle. Beim Abbrechen wandert das Projekt jetzt automatisch ins Archiv. Kein neues Konzept: Den Archiv-Umschalter in der Projektliste gibt es laengst, und die Suche sowie das Cockpit klammern Archiviertes ohnehin aus. Es verschwindet damit auch aus dem PORTAL des Kunden -- und das ist richtig so, ein abgebrochener Auftrag hat dort nichts mehr zu suchen. Archivieren statt loeschen: Zahlungen, Erstattungsbetrag und Verlauf haengen daran, und bei einem Streit braucht man genau das. Der Test prueft beides -- weg aus der Liste UND noch vorhanden. Geprueft: 55 gegen eine echte Datenbank. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
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]>
|
||
|
DogFatherGitandClaude Opus 5
|
cea265eb8c |
Angebote: der Kunde sagt mit einem Klick zu
DER LEITGEDANKE: SO WENIG TIPPEN WIE MOEGLICH Niemand schreibt hier den Leistungsumfang. Er entsteht aus der Aufgabenvorlage des Pakets -- denselben 92 Punkten, nach denen spaeter gearbeitet wird. Der Nebeneffekt ist wichtiger als die gesparte Tipparbeit: Was im Angebot steht, IST die Arbeitsliste. Ein von Hand geschriebenes Angebot und eine getrennt gepflegte Aufgabenliste laufen unweigerlich auseinander -- und dann steht im Angebot etwas, das niemand abarbeitet. Zu tun bleibt: Paket waehlen, Preis bestaetigen. Beides ist vorbelegt, Laufzeit und Ablaufdatum werden gerechnet. DER WORTLAUT WIRD BEIM ABSENDEN EINGEFROREN Ein angenommenes Angebot ist ein Vertrag. Bei einem Streit zaehlt, WAS dem Kunden gezeigt wurde, als er zusagte. Wuerde der Text bei jeder Ansicht neu aus den Vorlagen erzeugt, staende nach der naechsten Vorlagenaenderung etwas anderes da als damals. Die Zusage wird mit Zeitpunkt und (gehashter) Herkunft belegt -- die Beweislast liegt beim Unternehmer. WAS AUTOMATISCH PASSIERT Angebot raus -> Anfrage steht auf 'angebot' (der Wunsch: 'wenn ich ein angebot rausschicke soll der automatisch das erkennen'). Zusage -> Projekt angelegt, Aufgabenliste eingesetzt, Anzahlung als offene Rechnung erzeugt, Anfrage auf 'angenommen', Benachrichtigung an mich. Die UHR startet dabei NICHT. Sie startet erst mit dem Zahlungseingang -- das ist die Regel aus dem vorigen Schritt, und sie gilt auch dann, wenn der Kunde selbst zugesagt hat. Genau dieser Punkt wird ausdruecklich geprueft: Es fuehlt sich richtig an, mit der Zusage loszulegen. ZWEI FEHLER IN DER GELDANZEIGE GEFUNDEN Beide fielen erst auf, als das erste Angebot ueber tausend Euro entstand -- alle frueheren Testbetraege lagen darunter: - Kein Tausenderpunkt: 1490 Euro erschienen als '1490,00 €'. - Das Minuszeichen ging verloren: Math.trunc(-0.5) ergibt -0, und -0 schreibt sich als '0'. Eine ERSTATTUNG von 50 Cent erschien damit als '0,50 €' -- also wie eine Forderung. Ausgerechnet beim Abbruch mit Rueckzahlung waere das der falsche Ort fuer einen Anzeigefehler. Bewusst von Hand statt ueber Intl.NumberFormat: Die Ausgabe muss auf dem Server und im Browser zeichengleich sein -- ein Betrag, der in der Verwaltung anders aussieht als im Portal, saet Zweifel an der Zahl. Geprueft: 56 zu den Angeboten, 53 zur Automatik (inkl. der neun Geldpruefungen), 70 zur Annahme, 28 zur Suche -- alle gegen eine echte Datenbank. Darunter: zweiter Klick legt nichts doppelt an, abgelaufene Angebote lassen sich nicht mehr annehmen (ein Angebot, das man sieht aber nicht annehmen kann, waere eine Falle), ein fremder Kunde erfaehrt nicht einmal, dass ein Angebot existiert. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
658febb6c5 |
Abbruch-Dialog und Farbunterscheidung meins/beim Kunden
ABBRECHEN IN DER OBERFLAECHE Der Server konnte es seit gestern, die Knoepfe fehlten. Jetzt steht am Ende der Projektansicht ein zurueckhaltender Knopf -- bewusst nicht zwischen den anderen: Es ist die seltenste und endgueltigste Handlung an einem Projekt, und ein gleich lauter Knopf daneben laedt zum Verwechseln ein. Beim Aufklappen rechnet die Seite vor: wie viele Schritte erledigt sind, wie viel gezahlt wurde, wie viel davon verdient ist, und was sich daraus als Erstattung ergibt. Der Betrag steht als Vorschlag im Feld und ist aenderbar -- geprueft wird, dass der GEAENDERTE Wert hinausgeht und nicht der vorgeschlagene, sonst waere das Feld eine Attrappe. Gerechnet wird erst beim Aufklappen, nicht beim Oeffnen der Projektansicht: Dazwischen kann man Punkte abgehakt haben, und die Zahlen sollen den Stand von JETZT zeigen. Faellt die Vorschau aus, laesst sich der Betrag von Hand eintragen -- ein ausgefallener Rechendienst darf kein Projekt in der Liste festhalten. Ein bereits abgebrochenes Projekt bekommt keinen Knopf mehr, sondern einen Kasten mit Datum, Grund, wer abgebrochen hat und was zu erstatten war. MEINS ODER SEINS Wunsch: 'ich will dass die kunden sachen auch in der verwaltungs seite von kacheln eine andere farbe haben wie meine damit ich sie gut unterscheide.' Was bei mir liegt, bleibt im Markenblau. Was beim Kunden liegt, bekommt Lila. Gemessen: rgb(127,208,232) gegen rgb(183,157,255). Bewusst NICHT ueber Rot/Gruen: Die Warnstufen sind an das ALTER vergeben und muessen frei bleiben. Eine Kachel, die gleichzeitig 'beim Kunden' und 'seit acht Tagen ueberfaellig' faerben muesste, koennte nur eine der beiden Aussagen zeigen -- und die Frist ist die wichtigere. Dazu eine 3px-Kante links auf beiden Seiten. Farbe allein traegt die Aussage nicht: Wer sie nicht unterscheiden kann, saehe sonst zwei gleich aussehende Bloecke (WCAG 1.4.1). Die Kante ist ein Gegensatz, keine Markierung einer Gruppe -- meins blau, seins lila. Geprueft mit 42 Pruefungen auf Computer und Handy, die messen, was tatsaechlich an den Server geht und welche Farben wirklich berechnet werden. Alle bestehenden Pruefungen weiter gruen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
65b98ace89 |
Die Uhr laeuft erst, wenn die Anzahlung da ist
Bisher begann der Liefertermin mit der Annahme. Das ist unfair in beide Richtungen: Wer zehn Tage bis zur Zahlung braucht, verbraucht zehn Tage der zugesagten Zeit, ohne dass ein Handschlag Arbeit passiert waere -- und ich stehe am Ende als der da, der seinen Termin reisst. Ein Projekt hat jetzt drei Abschnitte statt zwei: 1. angenommen, wartet auf Anzahlung -> Uhr steht 2. Anzahlung da -> Uhr laeuft, Termin ab HEUTE neu 3. uebergeben oder abgebrochen -> Uhr steht wieder Der Zahlungseingang loest alles Weitere von selbst aus: Uhr starten, Termin neu rechnen, Status von briefing auf design, 'wer ist am Zug' auf mich, Benachrichtigung in der Verwaltung. Der bei der Annahme genannte Termin bleibt als termin_geplant_am erhalten, und die Meldung nennt BEIDE -- so sieht man, dass sich etwas verschoben hat, ohne nachrechnen zu muessen. Eingehaengt an der Stelle, an der beide Wege zusammenlaufen (PayPals Meldung UND das Vermerken von Hand). Nur am Webhook haenge sich die Seite verschieden verhalten, je nachdem WIE das Geld ankam -- eine von Hand verbuchte Zahlung startete die Uhr nie. Zwei Grundsaetze fuer die Automatik: Sie setzt Dinge in Gang, nimmt aber nie eine Entscheidung zurueck, die ein Mensch getroffen hat (ein von Hand pausiertes Projekt wird nicht kommentarlos wieder gestartet). Und jeder Schritt hinterlaesst eine Spur im Verlauf UND als Meldung -- eine Automatik, die stillschweigend arbeitet, ist kein Helfer, sondern ein Raetsel. ABBRECHEN Ein angenommener Auftrag bleibt abbrechbar: Der Kunde zahlt nicht, meldet sich nicht, springt ab. Vorschau und Ausfuehrung sind getrennt -- die Seite rechnet aus dem Aufgabenfortschritt vor, wie viel Leistung erbracht wurde, und schlaegt daraus einen Erstattungsbetrag vor. Der Betrag ist ein VORSCHLAG: Ob im Einzelfall mehr oder weniger angemessen ist, haengt an Dingen, die keine Tabelle kennt. Offene Rechnungen werden storniert (eine Zahlungsaufforderung ohne Gegenleistung), bezahlte bleiben unangetastet, und die Rueckzahlung loest die Seite bewusst NICHT selbst aus -- PayPal-Rueckzahlungen sind nicht umkehrbar. BENACHRICHTIGUNGEN Eigene Tabelle statt im Verlauf: Der Verlauf haelt fest, WAS geschehen ist -- vollstaendig, zum Nachschlagen. Eine Benachrichtigung ist ein Anstupsen, das gelesen und weggelegt wird. Beides in einer Tabelle hiesse: entweder ein Verlauf voller Rauschen oder Meldungen, die man nicht wegklicken kann. Wegklicken markiert nur als gelesen, loescht nichts. Dazu die Liste der Projekte, die seit ueber einer Woche auf ihre Anzahlung warten. Sie stehen in keiner anderen Zahl, weil ihre Uhr nie zu laufen begann -- ohne diesen Hinweis vergisst man sie. Geprueft: 44 gegen eine echte Datenbank. Darunter der Kern -- die Annahme wird zehn Tage zurueckdatiert, und der Termin muss danach trotzdem volle 20 Werktage entfernt liegen. Beim Bauen des Tests selbst ein Fehler gefunden: Die erste Fassung datierte nur die Annahme zurueck, nicht den damals errechneten Termin, und bildete damit genau den Fall nicht ab, um den es geht. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
6b818fd6f6 |
Abmelden meldet jetzt wirklich ab
Rueckmeldung: 'der abmelde button klappt auch nicht auf dem handy'. Die Ursache war nicht das Handy -- der Fehler war auf beiden Geraeten derselbe, auf dem Handy sieht man das kurze Aufblitzen nur eher. Der Knopf beendete die Team-Sitzung, loeschte den Schluessel und lud neu. Das Merkmal der Zugangswand blieb dabei im Browser stehen. Beim Neuladen holt sich die Seite damit sofort wieder einen Ausweis -- man war nach einer Zehntelsekunde erneut angemeldet, und der Knopf schien nichts zu tun. Jetzt werden BEIDE Sitzungen beendet (der Endpunkt dafuer gab es laengst, die Verwaltung rief ihn nur nie auf), und man landet an der Zugangswand statt in einer Codeeingabe. Das ist auch die ehrliche Bedeutung des Wortes: Wer sich abmeldet, will draussen sein. Beide Aufrufe sind einzeln abgesichert -- faellt einer aus, laeuft der andere trotzdem. Ein halbes Abmelden waere schlimmer als keins: Man hielte sich fuer abgemeldet und waere es nicht. Geprueft mit 16 Pruefungen auf Computer und Handy, die messen, was tatsaechlich hinausgeht statt ob sich etwas auf dem Schirm bewegt. Dabei ein Artefakt im eigenen Test gefunden und behoben: Das Vorbereitungsskript lief bei jeder Navigation und setzte den Schluessel auf der Zugangswand gleich wieder -- zwei Pruefungen massen also sich selbst. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
2ae77fc54f |
Verwaltung: eine Suche ueber alles, mit Tastatur bedienbar
Bisher gab es genau ein Suchfeld, und es durchsuchte nur die Anfragenliste. Wer den Namen eines Kunden im Kopf hatte, musste raten, in welchem Reiter er nachsehen muss: War das eine Anfrage, ein laufendes Projekt, eine offene Rechnung? Bei drei Vorgaengen merkt man sich das, bei dreissig nicht mehr. Jetzt: Strg+K von ueberall, auf dem Handy der Lupenknopf oben. Ein Aufruf durchsucht Anfragen, Kunden, Projekte und Zahlungen; jeder Treffer traegt seinen Zusammenhang (Nummer, Kunde, Betrag, Liefertermin) und fuehrt per Enter in den passenden Reiter, bei einer Anfrage direkt in die Detailansicht. Gebaut nach dem ARIA-Muster 'Combobox mit Listbox-Popup' aus den W3C Authoring Practices -- nachgeschlagen, nicht aus dem Gedaechtnis: role=combobox am Eingabefeld, aria-expanded, aria-controls, aria-activedescendant, role=listbox, role=option mit aria-selected. Der Fokus bleibt dabei im Eingabefeld, damit man weitertippen kann; die Auswahl wandert ueber aria-activedescendant. Ohne diese Auszeichnung waere ein Feld, das Vorschlaege einblendet, fuer einen Screenreader stumm -- das sieht man beim Testen mit den Augen nie. Vier Fallen ausdruecklich behandelt: - Nicht bei jedem Tastendruck suchen (180 ms Wartezeit): 'Musterbau' haette sonst neun Abfragen ausgeloest, acht davon veraltet. - Das Wettrennen der Antworten: Jede Abfrage bekommt eine laufende Nummer, nur die neueste darf zeichnen. Sonst ueberschreibt eine spaet eintreffende alte Antwort die neue. - Leer, laedt und Fehler sind eigene Zustaende. Ein Kasten, der bei einem Serverfehler leer bleibt, sieht aus wie 'nichts gefunden'. - LIKE-Sonderzeichen: '%' waere ein Platzhalter, '_' ein beliebiges Zeichen -- und Unterstriche stehen regelmaessig in E-Mail-Adressen. Der Fehler ist tueckisch, weil die Suche trotzdem Treffer liefert, nur die falschen. Ausserdem zum dritten Mal dieselbe Spezifitaetsfalle gefunden: '.wd p' schlug die eigene Regel, der Tastaturhinweis erschien in 17,9px statt 11,5px -- so gross wie der Inhalt, den er erklaert. Jetzt festgenagelt durch eine Pruefung, die Groessenverhaeltnisse vergleicht. Geprueft: 28 gegen eine echte Datenbank (darunter alle LIKE-Sonderzeichen), 64 im Browser auf Computer und Handy inkl. der ARIA-Vorgaben, des Wettrennens und des Fehlerzustands. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
659a1ee9ce |
Verwaltung fragt nicht mehr grundlos nach dem Zugangscode
Zwei Ursachen, die zusammenwirkten. 1. Nach einem Neuladen war die HERKUNFT des Schluessels vergessen. Der Code speicherte nur den Schluessel selbst, nicht ob er aus einer Codeeingabe oder aus dem Ausweis der Zugangswand stammt. 2. Weil die Herkunft fehlte, wurde vorsichtshalber 'code' angenommen. Als Vorsicht gedacht, mit unangenehmer Kehrseite: Ein Ausweis gilt nur 15 Minuten. Als 'code' behandelt wurde er nie erneuert -- nach einer Viertelstunde kam der erste 401, und man landete in der Codeeingabe, obwohl alles in Ordnung war. Der Schutz 'eine Code-Sitzung wird nie durch einen Ausweis ersetzt' war damit ab dem ersten Neuladen ohnehin wirkungslos. Die Herkunft steht jetzt neben dem Schluessel und ueberlebt ein Neuladen. Fehlt sie -- etwa aus einer aelteren Sitzung --, bleibt es bei der vorsichtigen Annahme 'code'. Das behebt die Haelfte des Problems. Die andere Haelfte ist eine Einstellung auf dem Server: Die beiden Dienste benutzen nicht dasselbe WEBDESIGN_API_SECRET, weshalb jeder Ausweis abgelehnt wird. Der Kommentar in server/.env.example sagt ausdruecklich, dass beide Werte exakt gleich sein muessen. Das kann nur Filipe angleichen -- /home/dogiintern/ ist fuer claudian gesperrt. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
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]> |
||
|
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]> |
||
|
DogFatherGitandClaude Opus 5
|
c1cb51884f |
Verwaltung: Übersicht als Startansicht, Reiter unter den Titel
Die Reiter standen neben dem Titel. Das las sich wie eine einzige lange
Zeile, in der der Titel nur der erste von sechs Knöpfen zu sein schien --
man sah nicht auf einen Blick, in welchem Bereich man war. Jetzt zwei
Zeilen: oben WO man ist, darunter WOHIN man kann.
Die Verwaltung öffnete bisher mit der Anfragenliste. Eine Liste ist eine
Ablage: Sie zeigt, WAS es gibt, nicht was zu TUN ist. Neu ist ein
Cockpit, das in drei Stufen antwortet -- was auf mich wartet, was beim
Kunden liegt, wie es ums Geld steht -- und dann laufende Projekte mit
Fortschritt sowie den Verlauf.
Zwei Grundsätze machen die Zahlen brauchbar: Getrennt nach 'wartet auf
mich' und 'wartet auf den Kunden' (zwölf offene Punkte sind entspannt,
wenn elf beim Kunden liegen). Und das ALTER färbt, nicht die Menge --
vier neue Anfragen sind kein Problem, eine seit sechs Tagen liegende
schon. Ein offener Widerruf ist immer rot, weil eine gesetzliche Frist
läuft.
Jede Kachel ist ein echter <button> und führt in den passenden Reiter.
Farbe ist nie der einzige Träger: Neben jedem farbigen Zustand steht der
Text ('älteste seit 8 Tagen').
Drei Fehler dabei gefunden und behoben:
- Der Titel wurde nur beim Klicken gesetzt. Frisch geladen zeigte die
Seite das Cockpit, während darüber noch 'Projektanfragen' stand. Die
Zuordnung Reiter->Titel liegt jetzt ausserhalb des Klick-Zuhörers.
- '.wd h2' überstimmte '.vw-ub-h': 44px Überschrift über 33px Zahl, die
Seite las sich wie ein Plakat. Dieselbe Spezifitätsfalle wie früher
bei '.wd a'.
- Eine Antwort mit ok:true aber ohne Inhalt riss die ganze Verwaltung
mit. Wird jetzt abgefangen -- ein halber Server ist ein realistischer
Fall.
Geprüft: 22 Serverprüfungen gegen eine echte Datenbank (inkl. vier
Fällen, die belegen, dass die Rechteprüfung wirklich greift), 56 im
Browser auf Computer und Handy, 69 im bestehenden Verwaltungstest,
0 Fundstellen im Design-/WCAG-Test, 5 im Farbsystemtest.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
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]>
|
||
|
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]> |
||
|
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]> |
||
|
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]> |
||
|
DogFatherGitandClaude Opus 5
|
a964a078f0 |
Zahlungen: Verwaltung sticht Serverdatei -- der Schalter wirkt jetzt
Filipes Bildschirm zeigte alles, was noetig war, um es zu erkennen:
Betriebsart: hinterlegt (auf dem Server) . 7 Zeichen
Client ID: hinterlegt . 82 Zeichen
Secret: hinterlegt . 80 Zeichen
Fehler: "PayPal hat die Anmeldung abgelehnt."
7 Zeichen sind "sandbox". Der Wert kam aus der .env, und die hatte
Vorrang. Sein Klick auf "Echtbetrieb" blieb wirkungslos -- seine echten
Zugangsdaten wurden gegen den TESTSERVER von PayPal geprueft, der sie
zwangslaeufig ablehnt.
Die Fehlermeldung zeigte dabei auf die Zugangsdaten ("stimmen Client ID
und Secret nicht zusammen") und damit in die voellig falsche Richtung.
DER ENTWURFSFEHLER
Ich hatte der .env bewusst Vorrang gegeben, damit ein Fehlgriff im
Formular keine funktionierende Servereinstellung aushebelt. Das klingt
vorsichtig und war falsch:
Ein Formular mit Schaltern, die nichts bewirken, ist schlimmer als gar
kein Formular. Es behauptet eine Wirkung, die es nicht hat, und schickt
bei der Fehlersuche in die Irre.
Der Sinn dieser Ablage ist gerade, dass die Werte OHNE SSH gesetzt
werden koennen. Dann muss das, was dort steht, auch gelten.
Ungefaehrlich, weil diese Werte ausschliesslich der Webdesign-Bereich
liest. Das DogiCrew-Supporter-Abo hat sein eigenes Modul und liest
weiter direkt aus der Umgebung -- ein Eintrag hier kann es nicht
abschalten. Eigens geprueft.
AUCH DIE ANZEIGE WAR UNEHRLICH
Sie sagte nur "hinterlegt (auf dem Server)" und verschwieg, dass genau
dieser Wert die eigene Eingabe ueberstimmt. Jetzt steht dort, welche
Quelle GILT -- "aus der Serverdatei" oder "hier eingetragen" -- und bei
doppelter Belegung zusaetzlich "Serverwert wird nicht benutzt".
GEPRUEFT: 16 Pruefungen auf dem Server, alle bestanden. Darunter der
genaue Fall: Serverdatei sagt sandbox, Formular sagt live -> istLive()
wird WAHR. Und der Rueckweg: Feld leeren -> Serverwert greift wieder.
Beim Testen noch ein Werkzeugfehler behoben: Der Absturz von
better-sqlite3 beim Beenden verschluckte die gesamte gepufferte
Ausgabe -- der Test lief durch und sah aus, als waere er nie gestartet.
Jetzt schreibt er unumgepuffert.
Versionsstempel und Cache auf v16.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGit
|
14488d6df2 | Test: unumgepufferte Ausgabe (Absturz beim Beenden verschluckte sie) | ||
|
DogFatherGit
|
779fb94c6b | Test fuer den Quellen-Vorrang | ||
|
DogFatherGit
|
ebe10b9c49 | WIP Vorrang umgedreht (Test folgt auf dem Server) | ||
|
DogFatherGitandClaude Opus 5
|
d870a9c1d7 |
PayPal: falsche Angabe zur Webhook-ID berichtigt, Abo-Plan-Weg ergaenzt
Filipe: "webhook id faengt bei mir nicht mit w an und wo finde ich plan fuer betreung" Er hat recht, ich hatte unrecht. An der Quelle nachgeprueft: Webhook-ID: 0NH55953DH663215D -- OHNE Vorsilbe, ~17 Zeichen Ereignis-ID: WH-3F562076HD293871E-... -- DIE beginnt mit WH- Meine Anleitung und der Hinweistext im Formular behaupteten beide "beginnt mit WH-". Wer sich daran haelt, sucht an der falschen Stelle oder traegt eine Ereignis-Kennung ein -- und die Signaturpruefung scheitert dann bei der ersten echten Zahlung, mit einer Meldung, die nicht auf die Ursache zeigt. Beide Stellen berichtigt, in der Anleitung mit ausdruecklichem Hinweis, dass dort vorher etwas Falsches stand. Wer sie schon gelesen hat, soll den Widerspruch erklaert bekommen und nicht stillschweigend eine andere Fassung vorfinden. ABO-PLAN: Der Grund fuer die Frage ist ein echter Stolperstein -- Abo-Plaene werden NICHT im Entwicklerbereich angelegt, sondern im normalen Geschaeftskonto. Unter developer.paypal.com sucht man vergeblich. Jetzt mit direkter Adresse (paypal.com/billing/plans), dem Weg ueber das Menue und dem Schritt, den man am ehesten vergisst: den Plan nach dem Speichern auch AKTIVIEREN. Ein gespeicherter, aber nicht aktivierter Plan sieht fertig aus und funktioniert nicht. Ausserdem klargestellt, dass dieser ganze Schritt entfaellt, wenn kein monatliches Abo verkauft wird -- Anzahlung und Restbetrag laufen ohne. Versionsstempel und Cache auf v15. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
9421bd5cfe |
Verwaltung: Endlosschleife bei abgewiesenem Ausweis behoben
DIE URSACHE FUER "die ganze seite haengt"
In ladeAnfragen stand seit Tagen dieser Code:
if (!ausweisVersucht) {
ausweisVersucht = true;
var frisch = await ausweisHolen();
if (frisch) {
token = frisch; tokenSchreiben(token);
ausweisVersucht = false; // <-- VOR dem Neuversuch geloest
return ladeAnfragen(); // <-- und ruft sich selbst auf
}
}
Die Sperre wird zurueckgesetzt, BEVOR der neue Versuch laeuft. Solange
der Ausweis akzeptiert wurde, fiel das nie auf. Weist der Server ihn
dagegen ab, dreht es sich unbegrenzt: Ausweis holen, 401, Ausweis holen,
401 -- ohne Fehlermeldung, ohne Anmeldemaske, nur ein Ladehinweis, der
zehn Minuten stehen bleibt. Die schlimmste Sorte Fehler: Sie sieht aus
wie Langsamkeit.
WARUM DER AUSWEIS ABGEWIESEN WIRD
Die Diagnose mit echtem Ausweis zeigte es eindeutig:
Ausweis erhalten in 23 ms
Einstellungen abrufen -> 401, {"ok":false,"error":"Kein Zugriff."}
Die Zugangswand stellt also aus, der interne Dienst lehnt ab. Beide
benutzen nicht dasselbe WEBDESIGN_API_SECRET. Auf dem oeffentlichen
Server ist es gesetzt (Fingerabdruck e7d63573174f661a); der interne ist
fuer mich nicht lesbar -- Filipe prueft das mit einem Befehl, der nur
den Fingerabdruck ausgibt, nie den Wert.
UND EIN FEHLER, DEN ICH SELBST EINGEBAUT HATTE
Die Erneuerung aus v12/v13 ersetzte bei jedem 401 den Schluessel durch
einen Ausweis -- auch dann, wenn er aus der Anmeldung mit dem
Zugangscode stammte. Bei untauglichem Ausweis wurde daraus ein
Totalausfall: Alle zehn Minuten ersetzte sie eine FUNKTIONIERENDE
Sitzung durch eine kaputte.
Eine Reparatur, die den Normalfall verschlechtert, ist keine.
Jetzt fuehrt die Seite mit, WOHER der Schluessel stammt. Eine
Code-Sitzung wird nie durch einen Ausweis ersetzt, und die vorsorgliche
Erneuerung laeuft fuer sie gar nicht erst. Nach einem Neuladen gilt ein
vorhandener Schluessel vorsichtshalber als Code-Sitzung -- lieber einmal
zu viel nach dem Code fragen als eine laufende Sitzung zerstoeren.
Die Erneuerung sitzt jetzt an EINER Stelle (api()) mit genau einem
Neuversuch. Die zweite, aeltere Fassung in ladeAnfragen ist raus; zwei
Mechanismen, die sich gegenseitig den Schluessel ueberschreiben, waren
ein Teil des Problems.
GEPRUEFT mit genau dieser Lage -- Zugangswand stellt aus, interner
Dienst lehnt ab:
2 Ausweis-Abrufe in 3 Sekunden statt unbegrenzt
abgewiesener Ausweis fuehrt zur Codeeingabe statt zum Haengen
Anmeldung mit Code oeffnet die Verwaltung
sechs Reiterwechsel, null Rauswuerfe, null Ausweis-Abrufe
Zahlungen-Kasten zeigt Inhalt
Verwaltung weiterhin 69 von 69. Versionsstempel und Cache auf v14.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGit
|
4ad99b5c37 |
Diagnose: Volltest mit echtem Ausweis
Ein 401 ohne Anmeldung beweist nur, dass die Adresse existiert -- nicht, dass die Antwort auch bei ANGEMELDETEM Zugriff kommt. Genau dort blieb die Verwaltung stehen. Die Diagnose geht jetzt denselben Weg wie die Verwaltung: Ausweis von der Zugangswand holen, damit die Einstellungen abrufen, Zeit messen. Mit eigenem Zeitlimit von 12 Sekunden, damit die Diagnose nicht selbst haengt, wenn die Adresse haengt -- ein Pruefwerkzeug, das am selben Problem scheitert, ist wertlos. Damit ist der Befund eindeutig statt vermutet: entweder 'Erfolgreich in X ms', oder eine Statusnummer samt Antworttext, oder 'KEINE Antwort innerhalb von 12 Sekunden'. |
||
|
DogFatherGitandClaude Opus 5
|
2ec935ccc6 |
Verwaltung: Ausweis vorsorglich erneuern statt erst nach dem Fehlschlag
"wenn ich von postfach auf projekte oder so gehe da werd ich immer wieder mien zugangscode gefragt ... ich will nur den zugangscode anfrage wenn ich auf die seite will und fertig" Die Wiederholung bei 401 (v12) rettet zwar jeden Fall, greift aber erst, NACHDEM eine Anfrage abgewiesen wurde: ein unnoetiger Umlauf, und solange steht ein Ladehinweis auf dem Schirm. Jetzt laeuft der Ausweis gar nicht erst ab. Er gilt 15 Minuten, erneuert wird alle 10 -- mit Abstand, damit ein langsamer Netzzugang nicht ins Zeitfenster hineinlaeuft. Im Hintergrund pausiert die Erneuerung, das waere Verschwendung. Dazu beim Zurueckkommen ins Fenster: War der Rechner zwischendurch zu, ist der Ausweis mit Sicherheit abgelaufen. Dann soll der erste Klick sofort sitzen statt ueber einen Fehlschlag zu gehen. Beim schnellen Hin- und Herwechseln zwischen zwei Fenstern passiert nichts -- unter einer Minute wird nicht erneuert. Die Codeeingabe erscheint jetzt nur noch in genau zwei Faellen: beim ersten Betreten der Seite und wenn die Zugangssitzung wirklich abgelaufen ist (8 Stunden oder Seite geschlossen). Genau so war es gewuenscht. GEPRUEFT: sieben Reiterwechsel hintereinander -- postfach, projekte, kunden, zahlungen, anfragen, postfach, zahlungen -- und vor JEDEM wurde der Ausweis kuenstlich fuer ungueltig erklaert. Null Codeabfragen, die Verwaltung blieb offen, der Inhalt erschien. Verwaltung weiterhin 69 von 69. Versionsstempel und Cache-Name auf v13. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
bd9051bfb7 |
Verwaltung: Ausweis erneuert sich selbst statt nach dem Code zu fragen
Rueckmeldung: "wieso werd ich auch immer meinen zugangscode gefragt wenn ich die kategorie wechseln tue das ist schwachsin." Er hat recht, und es war ein echter Fehler. DIE URSACHE Der Ausweis fuer die interne Schnittstelle (/webdesign/api-ausweis) gilt 15 Minuten. Danach antwortete jede Anfrage mit 401, und die Verwaltung tat das Haerteste, was moeglich ist: Token verwerfen und Codeeingabe zeigen -- beim blossen Wechsel eines Reiters. Doppelt falsch: Die ZUGANGSSITZUNG selbst gilt 8 Stunden. Der Code war also gar nicht noetig; ein frischer Ausweis haette genuegt und war jederzeit abrufbar. Ein Rauswurf mitten in der Arbeit ist die haerteste denkbare Reaktion auf ein Problem, das sich unsichtbar loesen laesst. Wer gerade ein Angebot beziffert hat, verliert damit seinen Platz. DIE LOESUNG Bei 401 wird EINMAL ein neuer Ausweis geholt und die Anfrage wiederholt. Nur wenn auch das scheitert, kommt die Codeeingabe -- dann ist die Sitzung wirklich abgelaufen. Das Wiederholen ist auch bei Absendungen unbedenklich: Eine mit 401 abgewiesene Anfrage hat serverseitig nichts bewirkt. Alle gleichzeitig wartenden Aufrufe teilen sich EINEN Erneuerungsversuch. Ohne das holt beim Oeffnen eines Reiters mit drei Abfragen jede ihren eigenen Ausweis -- drei statt einem. GEPRUEFT: 5 Pruefungen mit kuenstlich abgelaufenem Ausweis. Der Reiterwechsel fragt NICHT mehr nach dem Code, der Inhalt erscheint trotzdem, genau EIN neuer Ausweis wird geholt, und der naechste Wechsel laeuft ebenfalls durch. Ist dagegen die Zugangssitzung selbst abgelaufen, erscheint die Codeeingabe weiterhin -- das soll sie dann auch. Verwaltung weiterhin 69 von 69. Versionsstempel und Cache-Name auf v12. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
a5cd4bdcbd |
Diagnose: Normalzustaende nicht mehr als Befund melden
Filipes Diagnose zeigte zwei "!", obwohl alles in Ordnung war: ! Service Worker aktiv -> 1 registriert ! Zwischenspeicher -> dogfather-webdesign-v11 ! Anmeldung Verwaltung -> keiner vorhanden Alle drei sind der NORMALFALL: Ein aktiver Service Worker ist gewollt -- ohne ihn liesse sich die Seite nicht als App installieren. Das war ausdruecklicher Wunsch. Der Zwischenspeicher enthielt v11 -- also genau die Fassung, die der Server ausliefert. Die erste Fassung meldete JEDEN gefuellten Zwischenspeicher als auffaellig, auch den topaktuellen. Das ist Panikmache, kein Befund. Die Anmeldung gilt je Tab. In einem frisch geoeffneten Tab ist zwangslaeufig keine da -- und sie SOLL beim Schliessen ohnehin verschwinden, das war eine ausdrueckliche Vorgabe. Ein Pruefwerkzeug, das den Normalzustand anmahnt, ist schlimmer als keines: Es schickt einen auf die Suche nach einem Fehler, den es nicht gibt -- und wenn dann einmal ein echter kommt, sieht er genauso aus wie das Rauschen davor. Jetzt liest die Diagnose die erwartete Fassung aus dem Service-Worker-Skript auf dem Server und VERGLEICHT. Nur eine Abweichung ist ein Befund. GEPRUEFT mit beiden Faellen: bei v11 sechsmal gruen, bei kuenstlich gesetztem v3 ein "!" mit beiden Fassungsnummern im Klartext. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
b9f6829a63 |
Diagnoseseite: Text landete im Statuskreis statt daneben
Filipes Screenshot zeigte den Beschreibungstext als schmale
Buchstabensaeule ueber die halbe Seite laufen. Die Ursache ist eindeutig
und mein Fehler:
d.innerHTML = '<span class="mark">✓</span><div><b></b><span></span></div>';
d.querySelector("span").textContent = text;
querySelector liefert den ERSTEN passenden span -- und das war der
Statuskreis, nicht das Textfeld darunter. Der gesamte Beschreibungstext
wurde also in einen 26 Pixel breiten Kreis geschrieben und lief dort
heraus.
Zwei Regeln machten es schlimmer:
.zeile span { ... } traf ebenfalls BEIDE spans
fehlendes min-width:0 verhinderte, dass die Textspalte schrumpfen darf
Jetzt wird die Zeile Element fuer Element aufgebaut, mit direkten
Verweisen statt Suche -- da gibt es nichts zu verwechseln. Die
CSS-Regeln zielen auf eigene Klassen (.inhalt, .text) statt auf den
Elementnamen, der Kreis ist auf feste 26px genagelt und schneidet
ueberzaehligen Inhalt ab, statt die Seite aufzubrechen.
Auch die feste Platzhalterzeile im HTML nutzte noch den alten Aufbau und
haette denselben Fehler gezeigt, sobald sie sichtbar wird.
GEPRUEFT im Browser: alle sechs Zeilen, jeder Kreis exakt 26x26, Text
danebenstehend. Zusaetzlich als Screenshot angesehen -- bei einem
Anzeigefehler ist Messen allein nicht genug, denn genau das hatte die
erste Fassung ja auch bestanden.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
dd4010e75d |
Diagnoseseite: findet und behebt haengende Zwischenspeicher
Rueckmeldung: "garnichts laedt in der verwaltungsseite". Geprueft statt geraten -- die Serverseite ist in Ordnung: Dienst aktiv, keine Fehler im Protokoll CORS-Vorabanfrage 204 mit allow-origin echte Anfrage 401 (korrekt ohne Anmeldung), Antwortzeit unauffaellig ausgelieferte Seite enthaelt den neuen Code Damit bleibt fast nur der Browser: ein alter Service Worker, der veraltete Dateien ausliefert. Er ueberlebt ein normales Neuladen, und niemand kann ihn ohne Entwicklerwerkzeuge sehen. webdesign/diagnose.html prueft sechs Dinge und sagt im Klartext, welches davon klemmt: Service Worker aktiv? Zwischenspeicher gefuellt? Server erreichbar und wie schnell? Kennt der Server die neuen Adressen (404 = Server veraltet)? Liegt eine Anmeldung vor? Und wird die AKTUELLE Gestaltungsdatei ausgeliefert -- erkennbar an einem Merkmal, das es erst seit heute gibt. Ein Knopf meldet den Service Worker ab, loescht die Zwischenspeicher und laedt die Verwaltung mit Zeitstempel neu. Der Text sagt ausdruecklich, dass Anmeldung und Daten unberuehrt bleiben -- sonst traut sich niemand zu klicken. ZWEI ENTSCHEIDUNGEN Die Seite laedt KEINE externen Dateien, alles steht inline. Sie muss funktionieren, wenn genau das kaputt ist, was sie untersucht -- eine Diagnoseseite, die an derselben veralteten CSS-Datei scheitert, ist wertlos. Sie ist von der Zugangswand ausgenommen, wie Widerruf und Rechtstexte. Gebraucht wird sie genau dann, wenn etwas klemmt; dann darf nicht ausgerechnet die Zugangswand davorstehen. Sie enthaelt keine Kunden- oder Projektdaten, sondern prueft nur den eigenen Browser und meldet Statusnummern. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
d68d10d002 |
Zahlungen: Ladefehler sichtbar machen statt ewig "Wird geladen"
Rueckmeldung 23.08.2026: "da steht das aber passiert nichts" -- der
Reiter Zahlungen zeigte in beiden Kaesten dauerhaft "Wird geladen...".
Geprueft statt vermutet: Der Server antwortet (401 auf unangemeldete
Anfragen, Webhook 400), die ausgelieferte Seite enthaelt die Funktion,
und lokal nachgestellt laeuft der Ablauf sauber durch. Die Anfrage
bricht nach 15 Sekunden von selbst ab.
Der eigentliche Mangel liegt woanders und ist meiner: Ein Ladehinweis
ohne Ende ist die schlechteste aller Rueckmeldungen. Er sieht aus wie
Arbeit und ist doch nur Stillstand -- man kann nicht unterscheiden, ob
die Anfrage laeuft, fehlgeschlagen ist oder das Skript gar nicht
angesprungen ist. Und wenn der Fehler dann kommt, verschwindet er in
einer Meldung am Bildschirmrand.
DREI AENDERUNGEN
Jeder Fehler wird im Kasten selbst angezeigt, mit STATUSNUMMER im
Klartext ("Konnte nicht geladen werden (Status 403)"). Die kann Filipe
mir nennen, ohne die Entwicklerwerkzeuge zu oeffnen -- 403 heisst etwas
voellig anderes als 500 oder "keine Verbindung", und ohne diese Zahl
raet man.
Dazu ein Knopf "Nochmal versuchen". Bei einem Aussetzer im Mobilfunk ist
das der ganze Unterschied zwischen "geht nicht" und "geht doch".
Die statischen "Wird geladen..."-Texte im HTML sind raus. Der Kasten ist
jetzt leer, bis das Skript ihn fuellt -- und die Ladetexte lauten anders
als vorher. Bleibt spaeter der alte Text stehen, weiss man sofort: Die
Funktion ist nie angelaufen. Das ist eine Aussage, "Wird geladen" war
keine.
Auch die Zahlungsliste verschluckt ihren Fehler nicht mehr. Sie leerte
den Kasten stillschweigend -- ein leerer Bereich ohne Erklaerung ist
nicht weniger verwirrend als ein haengender Ladehinweis.
GEPRUEFT: alle vier Zustaende im Browser nachgestellt -- Serverfehler
500, kein Zugriff 403, Netzausfall und Erfolgsfall. In den ersten drei
erscheint Klartext samt Wiederholen-Knopf, im vierten der normale
Inhalt. Verwaltung weiterhin 69 von 69.
Versionsstempel und Cache-Name auf v11.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
497c576d1c |
Anleitung auf den neuen Weg umgestellt -- ohne Konsole
Die Anleitung war nach dem Einbau des Formulars veraltet und haette Filipe weiter in die Konsole geschickt. Schritt 0 (nachsehen, was schon da ist) ging ueber SSH und grep. Das zeigt jetzt die Verwaltung selbst an: "hinterlegt (auf dem Server)", "hinterlegt" oder "fehlt". Kein Terminal noetig, um zu erfahren, was noch fehlt. Schritt 6 war "nano .env + systemctl restart". Jetzt: Verwaltung -> Zahlungen -> Felder ausfuellen -> Speichern. Mit dem Hinweis, dass ein leeres Feld "nicht anfassen" bedeutet und nicht "loeschen" -- ohne den traut sich niemand, ein einzelnes Feld nachzutragen. Schritt 7 ist neu: der Knopf "Verbindung testen" mit einer Tabelle, was die drei moeglichen Meldungen bedeuten. Beim Umstellen ist mir Schritt 8 (der 1-Euro-Test) aus der Datei gefallen -- der Ersetzungsbereich reichte zu weit. Wieder eingesetzt und gleich vervollstaendigt: jetzt mit Testkunde anlegen, Einladungslink im eigenen Browser oeffnen und Aufraeumen danach. Vorher stand dort nur "Zahlung erzeugen und bezahlen", was den halben Weg ausliess. Auch die Formulierung "Beide brauche ICH" korrigiert -- ich brauche die Werte gar nicht, er traegt sie selbst ein. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
6a2aa13dd8 |
PayPal ohne Konsole einrichten -- Formular in der Verwaltung
Auf die Frage "soll ich das Secret hier reinschicken?" ist die Antwort nein: Es stuende dauerhaft im Gespraechsverlauf, und schreiben koennte ich es trotzdem nicht (kein Zugriff auf /home/dogiintern, sudo nur fuer apt/systemctl/docker). Risiko ohne Nutzen. Der Fehler lag aber bei mir: Ich hatte SSH-Befehle als Loesung angeboten. Filipe soll gar nicht in die Konsole. Jetzt traegt er die Werte in seiner Verwaltung ein. AUFBAU lib/webdesign-geheimnisse.js legt die Werte verschluesselt in app_settings ab -- derselbe AES-GCM-Weg wie fuer die Zugangscodes des Universe. Wer die Datenbankdatei in die Haende bekommt, etwa ueber eine alte Sicherung, hat damit nichts. Die .env behaelt VORRANG. Sonst koennte ein Fehlgriff im Formular stillschweigend eine funktionierende Servereinstellung aushebeln und laufenden Zahlungsverkehr umleiten. Die Datenbank ergaenzt, was dort fehlt -- sie konkurriert nicht. Kein Neustart noetig: Nach jedem Speichern werden die Werte neu geladen. DER KNIFF MIT DEM SYNCHRONEN ZUGRIFF Entschluesseln ist asynchron, die Pruefungen des PayPal-Moduls (istLive, istEingerichtet, fehlendeEinstellungen) sind synchron und werden an einem Dutzend Stellen aufgerufen, teils mitten im Aufbau einer Antwort. Sie alle auf async umzustellen waere ein Eingriff quer durch den Bezahlvorgang gewesen -- viel Flaeche fuer Fehler genau dort, wo Fehler Geld kosten. Stattdessen werden die Werte einmal beim Start entschluesselt und danach synchron gelesen. Alle 12 Zugriffe auf process.env.PAYPAL* im Modul laufen jetzt ueber einen einzigen Zugriffspunkt. WERTE KOMMEN NIE ZURUECK Es gibt keinen Weg, ein gespeichertes Geheimnis wieder auszulesen. Die Anzeige zeigt nur: ob etwas da ist, woher es stammt, wie lang es ist, wann es zuletzt geaendert wurde. Das Formular leert sich nach dem Speichern selbst -- ein Secret soll nicht stehen bleiben, wenn jemand anders auf den Bildschirm schaut. Ein leeres Feld bedeutet "nicht anfassen", nicht "loeschen". Sonst wuerde das Nachtragen eines einzelnen Werts alle anderen leeren. Nach jeder Aenderung wird das gemerkte PayPal-Zugangstoken vergessen -- sonst liefe die naechste Zahlung noch ueber die alten Zugangsdaten oder scheiterte mit "invalid client". "Verbindung testen" meldet sich probeweise bei PayPal an. Erst das beweist, dass die Werte stimmen: "gesetzt" heisst nur, dass etwas dasteht. Es fliesst dabei kein Geld. GEPRUEFT: 23 Pruefungen auf dem Server, alle bestanden. Darunter die wichtigsten Verneinungen: In der Datenbank steht kein Klartext, auch kein Teil davon. Der Stand enthaelt das Geheimnis nicht. Ein fremder Schluessel wird abgewiesen. Und: Ein gewechselter ENCRYPTION_KEY bringt den Dienst NICHT zum Stehen -- der Wert gilt dann als nicht vorhanden, die Seite laeuft weiter. Verwaltung 69, Gestaltung 0 Befunde, Designsystem 5 -- unveraendert gruen. Versionsstempel und Cache-Name auf v10. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGit
|
5043642951 | WIP: PayPal-Einstellungen ueber die Verwaltung (Test folgt auf dem Server) | ||
|
DogFatherGitandClaude Opus 5
|
692d702ebf |
Einrichtungsskript fuer PayPal -- Filipe tippt nur die Werte
Auf Wunsch, die Werte selbst einzutragen, zuerst geprueft statt vermutet: sudo erlaubt claudian: apt, apt-get, systemctl, docker, docker-compose /home/dogiintern/ -> Keine Berechtigung .../server-internal/.env -> Keine Berechtigung Der Zugriff fehlt also technisch, und das ist die Trennung, die Filipe am 08.08.2026 bewusst so eingerichtet hat. Selbst mit Zugriff waere es falsch: Damit ich die Werte eintrage, muesste das Secret durch den Chatverlauf wandern und stuende dort dauerhaft. Also alles abnehmen, was NICHT das Eintippen ist: paypal-einrichten.sh fragt die vier Werte nacheinander ab, zeigt zu jedem an, ob schon etwas hinterlegt ist (ENTER = behalten), legt vorher eine Sicherung an, setzt die Rechte auf 600, startet den Dienst neu und meldet den Stand. DREI DINGE, DIE DAS SKRIPT RICHTIG MACHT Das Secret wird mit "read -s" eingelesen -- es erscheint weder auf dem Bildschirm noch in der Bash-History. Auch die Abschlussmeldung zeigt nur die LAENGE, nie den Wert. Geschrieben wird mit awk und dem Wert in einer Variablen, NICHT mit "sed -i". Ein PayPal-Secret kann &, \, $, / und Anfuehrungszeichen enthalten; sed liest davon mehrere als Befehl und haette den Wert still zerstoert. Der Fehler waere erst bei der ersten echten Zahlung aufgefallen, mit der Meldung "invalid client" -- und dann sucht man an der falschen Stelle. Gegengeprueft mit dem Secret A&B/C\D$E"F~G : zeichengenau in der Datei angekommen, umliegende Zeilen unveraendert, vorhandener Schluessel ersetzt statt ein zweites Mal angehaengt. Laeuft der Dienst nach dem Neustart nicht, nennt das Skript den Pfad der Sicherung und den fertigen Befehl zum Zurueckholen -- in dem Moment will niemand erst suchen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGit
|
244b275dce |
PayPal-Anleitung: zuerst pruefen, was schon da ist
Client ID und Secret teilt sich der Webdesign-Bereich mit dem DogiCrew-Supporter-Abo -- laeuft das live, sind zwei der vier Werte schon eingetragen und es fehlt nur die Webhook-Kennung. Neuer Schritt 0 mit Befehlen, die nur ANZEIGEN, ob ein Wert gesetzt ist, ohne ihn auszugeben. Verhindert ausserdem, dass eine zweite App fuer dasselbe Konto entsteht: Das funktioniert zwar, macht aber jede spaetere Fehlersuche doppelt muehsam, und beim Erneuern eines Secrets braeche womoeglich der andere Bereich weg. |
||
|
DogFatherGitandClaude Opus 5
|
321e378f9b |
Zahlungen: Routen, Zustimmung nach § 356 Abs. 4 und Einrichtungsanleitung
Das PayPal-Modul und die Tabellen standen seit dem 22.08.2026 -- es fehlten die Wege dorthin. Jetzt vollstaendig. DREI DINGE, DIE HIER ANDERS SIND ALS BEI EINEM UEBLICHEN BEZAHLKNOPF 1. DIE ZUSTIMMUNG IST TEIL DER ZAHLUNG, kein Haekchen daneben. Die 30-%-Anzahlung wird faellig, BEVOR die Widerrufsfrist ablaeuft. Damit trotzdem sofort begonnen werden darf, verlangt § 356 Abs. 4 BGB die ausdrueckliche Zustimmung UND die Bestaetigung, dass der Verbraucher dadurch sein Widerrufsrecht verliert. Die Beweislast fuer beides liegt beim Unternehmer. Gespeichert wird deshalb nicht "hat zugestimmt", sondern der WORTLAUT, den der Kunde gesehen hat, samt Fassung und Zeitstempel. Im Streit zaehlt nicht DASS, sondern WOZU jemand zugestimmt hat -- und Texte aendern sich ueber die Jahre. Der Wortlaut steht auf dem SERVER, nicht im Browser: Was als Nachweis gespeichert wird, muss das sein, was der Server kennt, sonst koennte man ihm einen beliebigen Text unterschieben. Geschaeftskunden werden gar nicht erst gefragt. Ein Unternehmer hat kein Widerrufsrecht; ihn eine Verzichtserklaerung unterschreiben zu lassen waere sinnlos und wuerde nur Misstrauen wecken. 2. NICHT EINGERICHTET IST EIN ZUSTAND, KEIN FEHLER. Ohne Zugangsdaten sagt die Seite das freundlich und nennt den Weg ueber das Postfach. Ein Knopf, der eine technische Fehlermeldung wirft, sieht nach einer kaputten Seite aus -- und niemand bezahlt gern auf einer kaputten Seite. 3. DER WEBHOOK IST DIE WAHRHEIT, nicht die Rueckkehr des Browsers. Der Kunde kann das Fenster schliessen, bevor er zurueckgeleitet wird. Die Zahlung ist dann trotzdem erfolgt. Beide Wege schreiben ueber DIESELBE Funktion -- zwei getrennte Fassungen wuerden frueher oder spaeter auseinanderlaufen und unterschiedliche Felder setzen. Doppelte Zustellung ist bei PayPal normal. Die Merkliste verhindert die Doppelverbuchung, und "verarbeitet" wird erst NACH der Auswertung gesetzt: Bricht der Server dazwischen ab, steht die Meldung als empfangen-aber-offen da und faellt auf, statt spurlos als "schon behandelt" zu gelten. Ohne gueltige Signatur wird nichts verarbeitet -- sonst koennte jeder eine Zahlung als bezahlt melden. GEPRUEFT: 26 Pruefungen auf dem Server, alle bestanden. Bewusst OHNE PayPal-Zugangsdaten, weil genau das der heutige Zustand ist. Geprueft wird vor allem, was NICHT passieren darf: kein Bezahlvorgang ohne Zustimmung, keine Zustimmungsfrage an Geschaeftskunden, keine fremde Zahlung sichtbar, keine Doppelverbuchung, kein Geldfluss ohne Zugangsdaten -- und dass ein gescheiterter Versuch die Zahlung unangetastet auf "offen" laesst. ANLEITUNG: PAYPAL-EINRICHTEN.md, Schritt fuer Schritt mit den genauen Klicks. Sie nennt ausdruecklich die drei Fallen, die man sonst erst spaeter merkt: der Sandbox-Schalter (Zugangsdaten ohne echtes Geld), "Select all" bei den Webhook-Ereignissen (erzeugt Rauschen, in dem echte Probleme untergehen) und Client-ID und Secret aus verschiedenen Apps. Das Secret gehoert nach Bitwarden -- die Anleitung sagt das an drei Stellen und bietet an, dass Filipe es selbst eintraegt, ohne es mir zu zeigen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGit
|
eede01ca70 | WIP: Zahlungsrouten (Test folgt auf dem Server) | ||
|
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]>
|
||
|
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]>
|
||
|
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]>
|
||
|
DogFatherGitandClaude Opus 5
|
98fc04c666 |
Verwaltung: Projektstand aendern, Wuensche beziffern, im Projekt antworten
Drei Server-Funktionen existierten seit Tagen und hatten KEINE Oberflaeche.
Erst im Vergleich "was kann der Server" gegen "was ruft die Seite auf"
ist es aufgefallen:
POST /admin/projekte/:id projektAendern
POST /admin/aenderungen/:id/beziffern
POST /admin/projekt-nachricht
Jede davon schliesst einen Kreis, der bisher offen war.
1. DIE SCHMERZHAFTESTE LUECKE: DER STAND
Der Kunde sieht in seinem Portal GANZ OBEN die Phasenleiste und den
"naechsten Schritt". Beides liess sich nirgends aendern. Ein Projekt blieb
also fuer immer im Briefing stehen, egal wie weit es wirklich war -- und
der prominenteste Text im ganzen Kundenportal war dauerhaft leer.
Jetzt: sieben Phasen als Knoepfe (plus Pausiert/Abgebrochen daneben, denn
das sind keine Phasen, sondern Zustaende), "wer ist am Zug", naechster
Schritt, Richttermin, Zahlungsstand, Portfolio-Freigabe.
Phase und "wer ist am Zug" speichern SOFORT ohne Speichern-Knopf: Es ist
ein Klick auf genau einen Wert, ein zweiter Klick waere Zeremonie. Die
Textfelder haben einen Knopf, weil man beim Tippen zwischendurch nicht
speichern will.
2. AENDERUNGSWUENSCHE
Der Kunde konnte Ideen einreichen, seit es das Portal gibt. Beziffern ging
serverseitig auch -- nur gab es keine Oberflaeche. Der Kreis war offen: Er
schickt etwas los und hoert nie wieder davon.
Jetzt stehen alle Wuensche im Projekt, offene mit Feldern fuer Preis,
Dauer und einer kurzen Erklaerung. Ohne Preis geht nichts raus (geprueft)
-- ohne Preis kann der Kunde nicht entscheiden, und ein "Angebot" ohne
Zahl ist keins.
3. NACHRICHTEN ZUM PROJEKT
Getrennt vom allgemeinen Postfach, weil sie zum Projekt gehoeren und im
Portal auch dort erscheinen. Sie hier nicht zu haben hiess: Der Kunde
schreibt im Projekt, und ich kann ihm nur woanders antworten.
AUFBAU
Neuer Endpunkt /admin/projekte/:id/alles liefert Projekt, Aufgaben,
Fortschritt, Aenderungswuensche und Nachrichten in EINER Antwort. Fuenf
Anfragen hintereinander wuerden die Ansicht sichtbar ruckelnd aufbauen.
Dieselbe Aufteilung wie in der Anfrageansicht -- links die Arbeit
(Aufgaben), rechts das Steuern. Wer zwischen beiden Ansichten wechselt,
muss nicht umdenken.
GEPRUEFT: 69 Pruefungen, Computer und Handy, alle bestanden.
Die neuen Pruefungen schauen nicht darauf, ob sich ein Knopf einfaerbt --
das beweist nichts. Sie schneiden mit, was die Seite TATSAECHLICH an den
Server schickt: {"status":"entwicklung"}, {"restBezahlt":true},
{"preisEuro":250,"dauer":"3 Tage"}. Und sie pruefen den Fall, in dem
nichts rausgehen darf: Ohne Preis bleibt die Mitschrift leer.
Ein Fehler im Test selbst behoben: Die Nachrichtenzaehlung war
document-weit und zaehlte die Nachrichten der geschlossenen Projektansicht
mit -- geschlossen heisst nicht aus dem Dokument entfernt. Jetzt auf den
Postfach-Verlauf eingegrenzt.
Versionsstempel und Cache-Name auf v6.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
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; Aenderungswuensche". Ursache ist
eine Falle mit zwei Wegen: Texte ueber data-i18n landen als HTML in der
Seite, dort ist "&" 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 "&" 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]>
|
||
|
DogFatherGitandClaude Opus 5
|
b7c333fca3 |
Verwaltung: Aufgabenlisten abhaken und Postfach
Schritt 3 von 4 zu den zwei Wuenschen vom 22.08.2026. Die Datenbank und
die Server-Routen standen schon; das hier ist die Seite, auf der ICH
arbeite. Was hier passiert, sieht der Kunde unmittelbar in seinem Portal
(Schritt 4).
ZWEI NEUE REITER
"Projekte" -- bisher gab es Projekte nur als Zahl neben dem Kunden
("3 Proj."), man konnte kein einzelnes oeffnen. Man denkt aber in
Projekten, nicht in Kunden. Neuer Endpunkt projekteListe liefert die
flache Liste samt Aufgabenzahlen; die einzeln nachzufragen haette bei
zwanzig Projekten einundzwanzig Anfragen bedeutet.
"Postfach" -- mit Abzeichen fuer Ungelesenes. Steht nichts an, ist das
Abzeichen GANZ weg statt eine 0 zu zeigen: Eine Null, die man taeglich
sieht, wird zu Rauschen, und irgendwann uebersieht man auch die 3.
Die Reiterumschaltung war vorher ein Ja/Nein zwischen zwei Ansichten. Mit
vier Reitern haette jede neue Ansicht eine weitere "hidden = ..."-Zeile
gebraucht -- und beim naechsten Reiter vergisst man eine, dann liegen zwei
Ansichten uebereinander. Jetzt eine Zuordnung Reiter -> Kasten, die sich
selbst aufraeumt.
AUFGABENLISTE
Vier Abschnitte in den vier Prozessfarben -- dieselben wie im Portal und
auf der Ablaufseite. Das ist der Punkt: Eine Farbe bedeutet ueberall
dasselbe, sonst waere sie Deko.
Ein Klick aufs Kaestchen schaltet weiter: offen -> in Arbeit -> erledigt.
Drei Zustaende ueber einen Knopf statt eines Auswahlfeldes -- beim
Abarbeiten einer Liste zaehlt jeder gesparte Klick.
Punkte, die auf den KUNDEN warten, sind golden hinterlegt und tragen eine
Marke. Ohne diese Unterscheidung liest man die Liste als reinen
Fortschrittsbericht und uebersieht, dass man selbst gar nicht am Zug ist.
Der goldene Grund verschwindet, sobald der Punkt erledigt ist -- er
braucht dann keine Aufmerksamkeit mehr.
Abhaken faerbt die Zeile sofort um, ohne auf den Server zu warten. Bei
zehn Punkten hintereinander waere ein Neuaufbau nach jedem Klick zaeh, und
man verliert die Stelle. Geht es schief, wird die Liste neu geholt und der
Zustand ist wieder ehrlich.
POSTFACH
Links Verlaeufe, rechts das Gespraech. Nicht aus Nachahmung, sondern weil
man ein Gespraech abarbeitet und nicht eine Zeile: Man will sehen, was
vorher besprochen wurde, waehrend man antwortet. Kunde links, eigene
Nachrichten rechts -- man erkennt den Absender an der Seite, bevor man den
Namen liest.
Der Schalter "Nur interne Notiz" faerbt das ganze Schreibfeld um. Ein
Haekchen allein uebersieht man, und eine interne Bemerkung, die beim
Kunden landet, ist der peinlichste Fehler, den dieses System machen kann.
Interne Notizen im Verlauf sind gestrichelt umrandet und golden -- sie
duerfen nicht wie etwas Gesendetes aussehen.
Strg+Enter sendet, Enter allein nicht: In einem mehrzeiligen Feld will man
Absaetze machen koennen, ohne dass die halbe Nachricht rausgeht.
EIN FEHLER, DEN DIE TESTS NICHT GEFUNDEN HABEN
Der erste Lauf meldete 37 von 37 gruen -- und jede Aufgabenzeile war
sichtbar falsch herum gebaut: Kaestchen, dann die kleinen Knoepfe, Titel
ganz rechts. Aufgefallen ist es erst am Screenshot.
Ursache: Das Raster platziert zuerst alle Elemente mit FESTGELEGTER Zeile
und erst danach die freien. Kaestchen und Knopfgruppe hatten beide
"grid-row: 1 / span 2" und wurden deshalb zusammen nach vorne gesetzt; der
Titel landete als letzter in der dritten Spalte. Jetzt bekommt jedes Kind
Zeile UND Spalte ausdruecklich.
Die eigentliche Lehre steckt im Test: Alle 37 Pruefungen betrafen
Bestandteile (Farben, Anzahl, Durchgestrichenes), keine einzige die
ANORDNUNG. Wer eine Anordnung baut, muss die Anordnung pruefen. Drei neue
Pruefungen vergleichen jetzt die tatsaechlichen Bildschirmpositionen --
und sie wurden gegengeprueft: Mit dem alten Zustand schlagen sie fehl,
mit dem neuen nicht. Ein Test, der nie fehlschlaegt, ist wertlos.
GEPRUEFT: 43 Pruefungen, Computer und Handy, alle bestanden. Darunter:
alle Touch-Ziele mindestens 24 px, interne Notiz sieht anders aus als eine
gesendete, Verlauf springt ans Ende, keine Fehler im Protokoll.
Versionsstempel und Cache-Name auf v4.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
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]> |
||
|
DogFatherGit
|
60c1e7be94 | Test: Absturz beim Beenden vermeiden (better-sqlite3) | ||
|
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. |
||
|
DogFatherGit
|
4ce51c127e | WIP: Aufgaben- und Postfach-Routen (Test folgt auf dem Server) | ||
|
DogFatherGitandClaude Opus 5
|
548ec6bc00 |
Aufgabenlisten und allgemeines Postfach: Datenbank und Vorlagen
Erster von vier Schritten fuer zwei Wuensche vom 22.08.2026:
"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".
DATENBANK (3 neue Tabellen, jetzt 18 insgesamt, Fremdschluessel geprueft)
wd_aufgaben -- die Punkte je Projekt. Drei Entscheidungen darin:
* "wer_dran" ist eine eigene Spalte, kein Text. Manche Punkte warten
auf den KUNDEN ("Texte liefern"), und genau die muessen ihm ins Auge
springen. Ohne diese Unterscheidung liest er die Liste als reinen
Fortschrittsbericht und uebersieht seinen eigenen Teil -- der
haeufigste Grund fuer Verzoegerungen ueberhaupt.
* "nicht_enthalten" bildet ab, was NICHT zum Umfang gehoert. Das ist
die haeufigste Streitfrage in jedem Projekt ("ich dachte, das ist
dabei"). Vorher sichtbar aufgeschrieben kostet es nichts, hinterher
kostet es Geld oder den Kunden.
* "kategorie" nutzt dieselben vier Abschnitte wie die Farben im Portal.
Damit bedeutet eine Farbe ueberall dasselbe statt nur huebsch zu sein.
wd_postfach -- Nachrichten OHNE Projektbezug. Bewusst eine EIGENE Tabelle:
wd_nachrichten hat projekt_id als NOT NULL, und SQLite kann das nicht
lockern, ohne die ganze Tabelle zu kopieren -- ein unnoetiges Risiko bei
echten Kundennachrichten. Die neue Tabelle hat ohnehin andere
Anforderungen (Anhaenge, Lesestatus in BEIDE Richtungen, optionaler Bezug
auf eine Aufgabe). Zwei klar getrennte Tabellen sind ehrlicher als eine,
die beides halb kann.
VORLAGEN (56 Punkte ueber 5 Pakete, davon 20 beim Kunden)
Bei jedem Projekt fuenfzehn Punkte von Hand einzutippen fuehrt
zuverlaessig dazu, dass es irgendwann niemand mehr macht -- und dann
steht der Kunde wieder vor der leeren Liste, die der Ausloeser war.
Die Punkte sind in der Sprache formuliert, in der ein KUNDE denkt:
"Aufbau der Seiten festlegen" statt "Informationsarchitektur", "Auf dem
Handy durchtesten" statt "Responsive QA". Er liest diese Liste -- sie
muss ihm etwas sagen, nicht mir.
Die Vorlagen wandern beim ersten Start in die Datenbank und sind ab dann
dort aenderbar. Bereits vorhandene werden NIE ueberschrieben: sonst waeren
von Hand angepasste Vorlagen nach dem naechsten Neustart weg, und niemand
kaeme auf die Idee, dass der Neustart schuld war.
Naechste Schritte: Server-Routen, Verwaltung, Portal.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
71b9fc09c1 |
Anfrage-Detail: zentriertes Fenster statt seitlicher Leiste
Rueckmeldung 22.08.2026 mit Bildschirmfoto: "ich will das nicht so ich
will es viel viel viel besser und uebersichtlicher und schoener zentriert
in der mitte."
Berechtigt, und aus mehreren Gruenden. Eine seitlich eingeschobene Leiste
ist fuer so viel Inhalt das falsche Format:
* Der Blick springt beim Oeffnen nach rechts.
* Die Liste dahinter bleibt halb sichtbar und lenkt ab.
* Alles muss sich in eine schmale Spalte quetschen -- auf dem
Bildschirmfoto stand "keine Angabe" dadurch achtmal untereinander,
und die Abwesenheit von Information nahm mehr Platz ein als die
Information selbst.
Jetzt: mittig, 940px breit, zweispaltig ab Tablet. Der Blick bleibt, wo
er ist, und zusammengehoerende Angaben stehen nebeneinander.
Weitere Entscheidungen:
* Mauerwerk-Umbruch (columns) statt Raster. Die Abschnitte sind
unterschiedlich hoch; ein Raster haette grosse Luecken gerissen.
* Jeder Abschnitt bekommt eine eigene Flaeche statt nur einer Trennlinie.
* Die Kopfzeile klebt beim Scrollen oben fest. Bei einer langen Anfrage
weiss man sonst nach dem Scrollen nicht mehr, wessen Daten man liest.
* "keine Angabe" wird kleiner und blasser dargestellt. Es ist die
ABWESENHEIT einer Information und darf nicht aussehen wie eine.
* Die Oeffnen-Animation skaliert dezent aus der Mitte statt von rechts
hereinzufahren, und ist bei prefers-reduced-motion ganz aus.
9/9 Tests weiterhin gruen.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
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]> |
||
|
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]>
|
||
|
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]>
|
||
|
DogFatherGitandClaude Opus 5
|
96458b58aa |
Anfrage mit einem Klick zu Kunde und Projektraum machen
Der wichtigste Handgriff im ganzen Bereich -- und der Weg, den man bei
JEDEM echten Kunden geht. Bisher haette man Name, E-Mail, Paket und
Wunschtermin von Hand in die Kundenmaske abgetippt: vier Gelegenheiten
fuer einen Tippfehler, und einer davon ist spaeter nicht mehr
korrigierbar, weil die E-Mail gleichzeitig der Anmeldename ist.
Jetzt steht in der Anfrage-Detailansicht eine Uebernahme mit Vorschau
(Kunde, E-Mail, Projekttitel, Sprache) und einem optionalen Preisfeld,
das die 30 % Anzahlung beim Tippen mitrechnet. Ein Klick legt an:
* den Kundenzugang, freigeschaltet, in der Sprache der Anfrage
* das Projekt, verknuepft mit der Anfrage, mit Wunschtermin und
"Briefing-Termin vereinbaren" als erstem sichtbaren Schritt
* die Anfrage wechselt automatisch auf "angenommen"
Danach springt die Ansicht auf "Kunden" und zeigt sofort den
Einladungslink -- den einzigen Weg, wie der Kunde an sein Passwort kommt.
Die beiden Schritte laufen bewusst nacheinander, nicht parallel: das
Projekt braucht die Kunden-Kennung. Schlaegt der zweite fehl, existiert
der Kunde trotzdem schon. Genau das sagt die Fehlermeldung dann auch
ausdruecklich -- sonst versucht man es blind noch einmal und scheitert an
der doppelten E-Mail-Adresse, ohne zu verstehen warum.
Ist aus einer Anfrage bereits ein Kunde geworden, erscheint statt der
Uebernahme ein Hinweis darauf. Zweimal denselben Kunden anzulegen soll
gar nicht erst angeboten werden.
Dabei denselben Anfuehrungszeichen-Fehler wie schon einmal gemacht und
behoben: das gerade " in „Kunden" beendet die JavaScript-Zeichenkette.
Typografisch richtig ist ohnehin das schliessende " -- beides in einem Zug.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
77674cb801 |
Kennzahlen der Verwaltung: aus stillen Zahlen werden Werkzeuge
Rueckmeldung 22.08.2026: "mach es noch krasser noch detaillierter noch viel besser und perfekter und auch die kacheln viel geiler." Die Kacheln waren eine Reihe stiller Zahlen. Zahlen, die man nur anschauen kann, sind Dekoration. Jetzt: * Jede Kachel FILTERT die Liste darunter beim Antippen. Als echter <button>, nicht als div mit Klickzuhoerer -- sonst ist sie mit der Tastatur nicht erreichbar und ein Screenreader kuendigt sie nicht als Bedienelement an. * Jede Kachel sagt, was zu TUN ist, nicht nur wie viele es sind: "warten auf dich" / "du bist dran" / "Kunde ist dran" / "Projekt anlegen". * Neue Kachel: der aelteste unbearbeitete Vorgang in Tagen. Das ist die ehrlichste Kennzahl ueberhaupt -- sie sagt nicht, wie viel man geschafft hat, sondern wie lange jemand schon auf Antwort wartet. Genau daran misst ein Kunde Zuverlaessigkeit. Ab sieben Tagen rot. Diese eine Kachel filtert bewusst NICHT und ist deshalb auch kein Knopf: sie zeigt einen Zustand, keinen Status. * Eine Null wird gedaempft dargestellt. Sonst konkurriert "0 abgelehnt" optisch mit "3 neu" -- und genau die Drei ist die, auf die man schauen soll. Was nichts zu tun gibt, soll auch nicht leuchten. * Gold bleibt ausschliesslich dem echten Handlungsbedarf vorbehalten. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
d93625439a |
Verwaltung: mehr Information pro Zeile statt leerer Flaeche
Rueckmeldung 22.08.2026 mit Bildschirmfoto: die Anfragenliste wirkte blass und leer. Zu Recht -- sie zeigte Nummer, Name, Paket, Status, Datum. Das ist korrekt, beantwortet aber nicht die Fragen, die man beim Draufschauen WIRKLICH hat. Jetzt steht in jeder Zeile: * E-Mail direkt sichtbar (vorher musste man die Anfrage dafuer oeffnen) * Paket, Budgetrahmen, Wunschtermin als eigene Marken * Sprache, falls es NICHT Deutsch ist -- dann antwortet man auch in der richtigen Sprache * ob daraus schon ein Kunde geworden ist Statt eines Datums steht dort "vor 3 Tagen". Beim Datum muss man selbst rechnen, wie lange jemand schon wartet -- und genau das ist die Frage, die zaehlt. Ab sieben Tagen ohne Bearbeitung wird die Angabe rot: eine Anfrage, die eine Woche liegt, ist ein verlorener Kunde. Ein farbiger Streifen links codiert den Status zusaetzlich zur Textmarke. Farbe ALLEIN waere fuer farbfehlsichtige Menschen keine Information -- zusammen mit dem Text ist sie ein schneller Anker beim Ueberfliegen. Der leere Zustand stellt nicht mehr nur fest, dass nichts da ist, sondern erklaert, WO Anfragen herkommen, und legt den Link zum Formular gleich daneben. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
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]> |
||
|
DogFatherGitandClaude Opus 5
|
74091590b8 |
Verwaltung: nur noch EINMAL den Code eingeben
Rueckmeldung 22.08.2026: "ich hab auf der verwaltungs seite 2 mal dass ich
den zugangscode eingeben muss und vanvan auch, ich will es nur einmal
eingeben muessen." Berechtigt.
Die Zugangswand hat serverseitig laengst geprueft, WER da ist -- Dogfather
oder VanVan, laut Masterplan S.4 beide gleichberechtigte
Volladministratoren. Ein zweites Passwort danach bringt keinen
zusaetzlichen Schutz, es kostet nur jedes Mal Zeit.
Warum es nicht einfach "Cookie mitschicken" ist: Die Verwaltungsdaten
liegen hinter postfach.dogfather-universe.com, einem ANDEREN Rechnernamen.
Das Sitzungs-Cookie gilt dort nicht -- so sind Cookies gebaut, und das ist
gut so.
Loesung: Die Zugangswand stellt unter /webdesign/api-ausweis einen
kurzlebigen, signierten Ausweis aus, den die interne API anerkennt.
- 15 Minuten gueltig, die Seite holt bei Bedarf still einen neuen
- traegt bereich="wd-admin", damit ein Sitzungs-Token der Zugangswand
hier NICHT durchgeht und umgekehrt
- nur mit gueltiger Zugangssitzung zu bekommen
- gilt AUSSCHLIESSLICH fuer die /webdesign-Endpunkte. Postfach,
Bewerbungen, Supporter und Teamverwaltung bleiben unberuehrt
Fehlt WEBDESIGN_API_SECRET auf einer der beiden Seiten, gilt kein Ausweis
und die Verwaltung fragt wie bisher nach dem Team-Code. Ein fehlender
Konfigurationswert darf niemals eine Tuer oeffnen -- nur eine schliessen.
Genau das prueft der letzte Testfall.
Bei einem 401 wird EINMAL still ein neuer Ausweis geholt und die Anfrage
wiederholt, statt jemanden mitten im Arbeiten rauszuwerfen.
10/10 Tests, darunter: gefaelschte Signatur, fremdes Geheimnis,
abgelaufen, falscher Bereich, erfundene Rolle.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
DogFatherGitandClaude Opus 5
|
2542a2598e |
Kunden und Projekte in der Verwaltung anlegen, inklusive Testzugang
Wunsch 22.08.2026: "ich will einen provisorischen zugang fuer mich". Der richtige Weg dahin war ohnehin ueberfaellig -- Kundenzugaenge entstehen ausschliesslich hier, es gibt bewusst keine Selbstregistrierung. Neu: * Kundenzugang anlegen (Name, E-Mail, Firma, Sprache, sofort freischalten ja/nein) mit Einladungslink * "Testzugang fuer mich" -- ein Klick, legt einen als Test erkennbaren Zugang mit Datumsstempel an. Bewusst NICHT die echte Geschaeftsadresse: die E-Mail ist gleichzeitig der Anmeldename und laesst sich aus gutem Grund nicht mehr aendern, ein Test wuerde also spaeter mit einem echten Kundenkonto kollidieren. * Zugaenge auflisten, freischalten, sperren, neuen Einladungslink erzeugen * Projekte anlegen und aendern, Aenderungswuensche beziffern, Nachrichten Entscheidungen: * Der Einladungslink geht EINMAL im Klartext raus, direkt beim Anlegen. In der Datenbank liegt nur sein Hash. Wer ihn verliert, bekommt einen neuen -- das ist sicherer, als ihn dauerhaft abrufbar zu halten. Die Oberflaeche sagt das auch klar dazu, sonst klickt man ihn weg und wundert sich. * Ein neuer Link entwertet alle offenen alten. Sonst sammeln sich mehrere gueltige Generalschluessel fuer dasselbe Konto an. * "Sofort freischalten" ist eine bewusste Handlung. Ohne Haekchen wird der Zugang angelegt, kommt aber noch nicht hinein -- Masterplan S.12 verlangt, dass Projektkauf oder Betreuung VOR der Freischaltung geprueft werden. * Sperren beendet laufende Sitzungen sofort, nicht erst nach Ablauf. * Die 30 % Anzahlung werden aus dem Preis BERECHNET, nicht eingetippt. Ein Tippfehler in der Anzahlung faellt sonst erst beim Geldeingang auf. * Preise kommen als Euro herein und werden sofort in Cent umgerechnet (Math.round, damit 49.99 nicht zu 4998 wird). Ab da nie wieder Komma. * Vier klar unterscheidbare Zustaende in der Liste. Wichtig vor allem "Einladung offen": freigeschaltet, aber noch kein Passwort gesetzt -- der Kunde war also noch nie drin. * Kopieren faellt auf Markieren zurueck, wenn die Zwischenablage blockiert ist. Eine Fehlermeldung waere dort nutzlos. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
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]>
|
||
|
DogFatherGitandClaude Opus 5
|
04a1af1253 |
Kundenportal: Server-Seite mit strikter Mandantentrennung
Masterplan S.12. Anmeldung, Uebersicht, Projektdetail, Aenderungswuensche, Zusatzangebote annehmen/ablehnen, Nachrichten, Profil. DIE ZENTRALE ENTSCHEIDUNG: Die Trennung zwischen Kunden sitzt NICHT in der Oberflaeche, sondern in jeder einzelnen Abfrage. Ueberall steht "WHERE id = ? AND kunde_id = ?" statt "WHERE id = ?", wobei die kunde_id IMMER aus der Sitzung kommt, nie aus der Anfrage. Wer eine fremde Projektkennung errät, bekommt dadurch "nicht gefunden" statt Daten. Die Oberflaeche liegt im Browser des Kunden und ist beliebig manipulierbar -- sie kann diese Aufgabe grundsaetzlich nicht uebernehmen. Weitere bewusste Entscheidungen: * KEINE Selbstregistrierung. Masterplan S.12 verlangt, dass Projektkauf oder Betreuung VOR der Freischaltung geprueft werden. Ein Portal, in das sich jeder selbst eintraegt, waere das Gegenteil. Kunden werden in der Verwaltung angelegt und bekommen einen Einladungslink. * Passwoerter mit scrypt (in Node eingebaut, kein Zusatzpaket). Ein SHA-256 ueber ein Passwort ist milliardenfach pro Sekunde durchprobierbar; scrypt ist absichtlich langsam UND speicherhungrig. * Mindestanforderung ist LAENGE, nicht Zeichenklassen. "Hund1234!" erfuellt jede Klassenregel und ist trotzdem schlecht; "mein blauer stuhl steht krumm" erfuellt keine und ist ausgezeichnet. * Gleiche Fehlermeldung bei unbekannter Adresse und falschem Passwort -- sonst lassen sich Kundenadressen durchprobieren. * Die Anmeldesperre haengt an der E-Mail, nicht an der IP. Eine IP-Sperre wuerde mehrere Kunden hinter demselben Firmenanschluss gemeinsam aussperren -- genau der Fehler, der im Universe am 19.08.2026 auftrat. * Sperre und Passwortwechsel beenden laufende Sitzungen SOFORT, nicht erst nach zwoelf Stunden. * Ein Zusatzangebot laesst sich nur annehmen, wenn es beziffert ist -- sonst entstuende eine Zahlungspflicht ohne Preis. Dazu der wichtigste Test des Bereichs (test-webdesign-portal.mjs): zwei echte Kunden, und Kunde B versucht systematisch mit Kunde As echten Kennungen an dessen Projekt, Nachrichten, Dateien und Zusatzangebote zu kommen. Prueft ausserdem, dass interne Notizen und interne Arbeitsdateien auch dem BERECHTIGTEN Kunden verborgen bleiben. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
ae9878cb4c |
Sprungmarken auf breiten Bildschirmen alle in einer Reihe
Rueckmeldung 22.08.2026: "alle neben einander bitte". Vorher passten vier
in die Zeile und die fuenfte rutschte allein darunter -- das sieht aus wie
ein Versehen, nicht wie eine Gestaltung.
Ab 700px teilen sich jetzt alle fuenf den Platz zu gleichen Teilen
("flex: 1 1 0" statt "auto"). Mit "auto" waere "Preise & Zahlung" schmal
und "Inhalte & Zusammenarbeit" breit gewesen -- ungleiche Kacheln in einer
Reihe, also genau das, was hier schon einmal bemaengelt wurde.
"min-width: 0" ist dabei noetig, weil Flex-Elemente sonst nicht unter ihre
Inhaltsbreite schrumpfen und die Reihe trotzdem umbrechen wuerde.
Nachgemessen bei 700 / 900 / 1280 / 1440px: 5 Knoepfe, 1 Reihe, alle
gleich breit UND gleich hoch. Unter 700px bleibt der Umbruch -- fuenf
Spalten waeren auf einem Handy unlesbar schmal.
45/45 Handy-Abnahme weiterhin sauber.
Co-Authored-By: Claude Opus 5 <[email protected]>
|
||
|
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]> |
||
|
DogFatherGitandClaude Opus 5
|
de4a90362e |
Verwaltungsbereich fuer Projektanfragen
Masterplan S.13. Anfragen ansehen, filtern, durchsuchen, Status aendern, interne Notizen, archivieren. 9/9 Sicherheitstests. Bewusste Entscheidungen: * NUR AUF DEUTSCH. Der oeffentliche Teil laeuft in fuenf Sprachen, weil dort Kunden landen. Hier landen ausschliesslich Dogfather und VanVan -- fuenf Sprachen waeren fuenffache Pflege und fuenffache Fehlerflaeche ohne einen einzigen Nutzer, der sie braucht. Genau wie der bestehende interne Bereich des Universe. * Anmeldung ueber die BESTEHENDE Team-Anmeldung (/auth/login) statt einer zweiten eigenen. Zwei Anmeldungen fuer dieselben zwei Personen waeren doppelte Pflege und ein zweiter Ort, an dem ein Zugang vergessen werden kann. Der Code der Zugangswand gilt hier ausdruecklich NICHT -- die Verwaltung steckt hinter zwei getrennten Tueren. * Sitzungstoken im sessionStorage, nicht localStorage: es verschwindet beim Schliessen, dieselbe Regel wie an der Zugangswand. Der Test prueft das ausdruecklich. * Bei abgelaufener Sitzung geht es zurueck zur Anmeldung statt zu einer leeren Liste. Eine leere Liste sieht aus wie "keine Anfragen" und ist damit eine stille Falschaussage. * Gold nur beim Status "neu" -- also genau dort, wo wirklich etwas zu tun ist. Wuerde alles leuchten, leuchtet nichts. * Archivieren statt Loeschen, und die Oberflaeche sagt das auch dazu. Pruefskript: kennt jetzt bewusst einsprachige Seiten (verwaltung, portal) und prueft dort nur die Struktur, statt ein fehlendes Woerterbuch zu melden. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
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]>
|
||
|
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]> |
||
|
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]>
|
||
|
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]>
|
||
|
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]> |
||
|
DogFatherGitandClaude Opus 5
|
2010b5ec33 |
Live benutzte Hintergrundbilder + Stimmen-Avatare in die Ablage aufgenommen
Beim Abgleich zwischen Rechner und Netcup-Server am 22.08.2026 aufgefallen: 20 Bilddateien wurden live von mehreren Seiten benutzt (bewerben-modi.html, links.html, medien-casper.html, medien-hasidog.html, supporter.html, stimmen.html u.a.), lagen aber in keiner Git-Ablage -- nur auf diesem Rechner und auf dem Server. Waeren beide verloren gegangen, waeren diese Seiten ohne Hintergrund/Avatare dagestanden. Vor dem Hinzufuegen jede Datei per Pruefsumme gegen den Server abgeglichen -- alle identisch, kein abweichender Stand wird hier verdeckt. dogfather-universe-app.ico ist aktuell nirgends verlinkt (vermutlich ein nie eingebauter Favicon-Entwurf), trotzdem mit gesichert statt verworfen. Co-Authored-By: Claude Opus 5 <[email protected]> |
||
|
DogFatherGitandClaude Opus 5
|
541a91d9e2 |
DEPLOY.md korrigiert: echte Seite laeuft auf Netcup, nicht auf Cloudflare
Die Anleitung nannte als Deploy-Weg weiterhin "npx wrangler deploy". Das ist seit dem oeffentlichen Start (21.08.2026) falsch und aktiv gefaehrlich: der Befehl laeuft fehlerfrei durch und meldet Erfolg, erreicht aber nur noch ...workers.dev. Die echte Domain wird von Caddy auf dem Netcup-Server ausgeliefert (dogiweb.service, localhost:4100). Genau darauf bin ich heute beim Sprachfenster-Fix hereingefallen -- Deploy "erfolgreich", auf dem Handy aber unveraendert kaputt. Neu dokumentiert: der einzige gueltige Weg (commit -> push gitea master:main -> git pull auf dem Server), die Zweig-Falle master/main, die Pflichtpruefung gegen die echte Domain statt gegen die Deploy-Meldung, warum die wrangler-Fehlermeldung "externally managed DNS records" erwuenscht ist, und als offener Punkt: mehrere live benutzte Hintergrundbilder liegen in keiner Git-Ablage. Co-Authored-By: Claude Opus 5 <[email protected]> |