ad58ab99d32ce3a64ff7fe7213846dafc3832eb0
14
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  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
|
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
|
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]> |