Fix für gemeldetes Problem: VanVans Code funktionierte nicht auf der Verwaltungsseite. Ursache
war ein dritter, komplett separater, gemeinsamer Code (6GAM4AST), den sich niemand gemerkt
hatte — VanVan gab stattdessen ihren normalen persönlichen Zugangscode ein, der dort aber nicht
galt. Jetzt auf ausdrücklichen Wunsch vereinheitlicht: die Verwaltungsseite prüft denselben
persönlichen Code wie der normale Seitenzugang (SITE_ACCESS_CODE_QCIGA/_VANVAN). Die tägliche
Neueingabe-Pflicht bleibt bestehen (eigene Sitzung mit 24h statt 90 Tagen Gültigkeit) — nur der
geprüfte Code ist jetzt kein separater dritter mehr. Das alte Secret VERWALTUNG_ACCESS_CODE wird
nicht mehr verwendet. Lokal mit wrangler pages dev end-to-end getestet (beide Codes + alter Code
korrekt abgelehnt).
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Auf ausdrücklichen Wunsch NUR diese eine Zugangsseite (öffentliche Startseite und die
eingeloggte Verwaltung selbst bleiben unangetastet): zwei groß und gegenläufig rotierende,
warm golden bzw. violett eingefärbte Van's-Logo-Wasserzeichen im gesamten Fensterhintergrund,
plus das echte Logo als sich drehendes "Siegel" im Kästchen mit pulsierendem Glanz-Kreis und
drei zeitversetzt aufblitzenden Funkel-Emojis. Ziel: die tägliche Pflicht-Eingabe soll Freude
machen statt trockene Sicherheitsabfrage zu sein. Alle Animationen respektieren weiterhin
prefers-reduced-motion. Reine Design-Änderung, Formular-/Auth-Logik unverändert.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Technisches Accessibility-Audit ergab sechs behebbare Punkte, alle jetzt gefixt:
- Skip-to-Content-Link ganz oben auf jeder Seite (WCAG 2.4.1)
- Fehler-/Statusmeldungen (Checkout, Login, Rezension, Gate-/Verwaltungs-Code) jetzt mit
role="alert"/aria-live, damit Screenreader sie automatisch ansagen (WCAG 4.1.3)
- Warenkorb-Icon hatte fälschlich das "Konto"-Label geerbt, sagt jetzt korrekt "Warenkorb"
(WCAG 4.1.2/2.4.4), dafür t.nav.cart in allen 4 Sprachen neu ergänzt
- Sichtbarer Fokus-Ring beim Mengenfeld auf der Produktseite wiederhergestellt (WCAG 2.4.7)
- Placeholder-only Formularfelder (Gate-Zugangscode, Verwaltungs-Suche/Filter/Tracking) haben
jetzt echte Labels (sichtbar per sr-only-Klasse oder aria-label) statt nur Platzhaltertext
(WCAG 1.3.1/3.3.2)
- Übersprungene Überschriften-Ebenen (h1→h3 ohne h2) in Checkout, Warenkorb, Kontakt, Konto
korrigiert (WCAG 1.3.1)
Reine Accessibility-Nachrüstung, keine funktionale Änderung. Kleinstunternehmer-Ausnahme
(§3 Abs.3 BFSG) greift hier vermutlich, aber vorsorglich sauber umgesetzt.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Der Name "Tages-Code" konnte fälschlich als sich täglich änderndem/rotierendem Code
verstanden werden. Tatsächlich bleibt der Code dauerhaft gleich (6GAM4AST) — nur die
24h-Sitzung läuft ab, wodurch derselbe Code einmal pro Tag erneut eingegeben werden
muss. Reine Text-/Kommentar-Korrektur, keine Verhaltensänderung.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Auf ausdrücklichen Wunsch: /verwaltung/ + /api/verwaltung/* verlangen jetzt ZUSÄTZLICH zum
normalen 90-Tage-Seitenzugang einen zweiten, eigenen Code, den nur qciga und VanVan kennen —
und der nach 24 Stunden automatisch abläuft (muss also einmal täglich neu eingegeben werden).
Der Rest der Seite ist davon unberührt, nur die Bestellübersicht ist betroffen.
Bewusst als eigenständiges System (eigenes Cookie vandiy_verwaltung_session, eigenes Geheimnis
VERWALTUNG_SESSION_SECRET, eigener HMAC-Signaturcode statt geteiltem mit dem normalen
Seitenzugang) — gleiches Trennungsprinzip wie bei den Kundenkonten: ein Leck bei einer
Sitzungsart darf nie die andere gefährden.
Neue Dateien: functions/_shared/verwaltung-auth.js (Session-Logik), public/verwaltung-code.html
(Eingabemaske im selben Stil wie die Haupt-Zugangsseite). functions/_middleware.js prüft nach
erfolgreicher Haupt-Sitzung zusätzlich diese zweite Sitzung für /verwaltung*-Pfade. Beide
API-Routen (orders.js, orders/[id].js) prüfen die zweite Schranke zusätzlich eigenständig,
nach demselben Verteidigungs-in-der-Tiefe-Prinzip wie die bestehende Haupt-Prüfung.
Lokal vollständig durchgetestet (wrangler pages dev): kompletter Ablauf ohne jeden Zugang ->
Haupt-Gate -> Redirect zum Tages-Code -> falscher Code abgelehnt -> richtiger Code setzt
24-Stunden-Cookie -> Seite und API danach erreichbar. Bestätigt: der Rest der Seite bleibt
unberührt (kein Tages-Code nötig), UND dass VanVan mit nur dem Haupt-Zugang (ohne Tages-Code)
ebenfalls noch ausgesperrt bleibt, wie gewünscht.
Zwei neue Cloudflare-Secrets in Produktion gesetzt: VERWALTUNG_SESSION_SECRET (zufällig
erzeugt) und VERWALTUNG_ACCESS_CODE (der eigentliche Tages-Code, an qciga und VanVan zu
verteilen).
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Auf ausdrücklichen Wunsch: statt der vagen Ersatzformulierung "Teddy aus einer früheren
Einlösung" zeigt die Liste "Diese Teddys hast du schon bekommen" jetzt fuer JEDEN Eintrag
den echten Produktnamen + eine kleine Vorschau — auch fuer Einloesungen von vor diesem
Feature, bei denen kein Name gespeichert war. Das geht zuverlaessig, weil es je Groesse
aktuell nur EIN konfiguriertes Teddy-Produkt gibt (aboEinstellungen.kleinTeddySlug/
grossTeddySlug) — es gibt also keine Mehrdeutigkeit, welcher Teddy es war.
Mini-Foto: echtes Produktfoto, sobald VanVan eins im Adminbereich hochlaedt (automatisch,
ohne Code-Aenderung) — bis dahin ein gestalteter Platzhalter statt eines kaputten Bildes,
da beide Teddy-Produkte aktuell noch kein Foto hinterlegt haben.
Dabei einen echten Datenfehler gefunden und behoben: der KLEINE Teddy trug auf Englisch
"Large Teddy" und auf Schweizerdeutsch "Grosse Teddy" (Kopierfehler vom grossen Teddy) —
war nicht nur in dieser Liste sichtbar, sondern auch auf der Produktseite selbst in allen
nicht-deutschen Sprachen. Jetzt korrekt "Small Teddy" / "Chliine Teddy" / "Petit ours en peluche".
Getestet (Browser): genau der Fall aus der Rückmeldung nachgestellt (2 alte Einlösungen ohne
Namensverlauf) — zeigt jetzt Name + Link statt "unbekannt". Gemischter Fall (echter + alter
Eintrag) korrekt sortiert. Vorhandenes Foto ersetzt den Platzhalter automatisch. Korrigierte
Produktnamen in allen 4 Sprachen bestätigt.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Auf ausdrücklichen Wunsch: die Visa-/Mastercard-Badges in der unteren Hälfte sehen jetzt genauso
"fertig" aus wie das PayPal-Badge oben — größer (48x48 statt 40x27), mit demselben weichen
Glanz-Verlauf, kräftigem Schlagschatten in der jeweiligen Markenfarbe und Lift-Effekt beim
Hovern. Die Markenfarben selbst bleiben unverändert (Visa weiß, Mastercard schwarz).
Die untere Hälfte hat jetzt außerdem eine EIGENE Farbgebung statt eines Blau-Abklatschs der
PayPal-Hälfte darüber: dezentes Visa-Blau unten links, Mastercard-Orange/Rot oben rechts,
beide nur angedeutet (niedrige Deckkraft) auf dunklem Grund, damit Text und Karten weiterhin
klar lesbar bleiben.
Getestet: Breiten-Sweep 390–1440px ohne Überlappung mit der Radio-Markierung (die Karten sind
jetzt größer, deshalb erneut geprüft), Screenshots Desktop + Mobil, Markup in allen 4 Sprachen
bestätigt.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Auf ausdrücklichen Wunsch: die PayPal-Zahlungsoption ist jetzt eine "besondere" Kachel statt
der schlichten Icon-Zeile — exakt in der Mitte horizontal geteilt, obere Hälfte PayPal-
Markenverlauf mit Logo + zweifarbiger Wortmarke, untere Hälfte die Visa-/Mastercard-Hinweise.
Animierter Verlaufsrand, leuchtender Mittelsteg, Glanzeffekt und Glitzer-Akzente — dieselbe
Formsprache wie die anderen "besonderen" Karten der Seite (z.B. .account-head). Alle 4 Sprachen.
Feste Höhe (statt min-height) auf der Kachel, damit die Trennlinie IMMER exakt mittig sitzt,
unabhängig vom Inhalt jeder Hälfte — mit auto-Höhe hätte der Flex-Container sich sonst am
längeren Inhalt orientiert und die Linie wäre verrutscht (nachgemessen: vorher 106,6px oben vs.
141px unten, jetzt 109px/109px exakt).
Dabei zwei echte Bugs gefunden und behoben:
1. Eine generische Farb-Regel (".pay-card:has(input:checked) .pay-option span:not(.pay-icon)")
hätte die neue zweifarbige Wortmarke und den Kartenhinweis auf die einfarbige Markenfarbe
umgefärbt und auf dem blauen Verlaufshintergrund fast unlesbar gemacht — mit gezielt
spezifischeren Regeln überschrieben.
2. Die Radio-Markierung überlappte bei bestimmten Fensterbreiten (ca. 800–1000px) die
Mastercard-Karte, weil zwei VERSCHACHTELTE Zweispalten-Layouts (.checkout-layout und
.checkout-split) bei ZU ÄHNLICHEN Umbruchpunkten (800px bzw. 760px) gleichzeitig aktiv
blieben und die Zahlungsspalte auf ca. 90px zusammenquetschten — ein vorbestehender
Layout-Fehler, der die ganze Zahlungsspalte betraf, nicht nur die neue Kachel. Behoben,
indem die innere Spalte jetzt deutlich früher umbricht (1024px statt 760px), lange bevor
die äußere Spalte eng wird.
Getestet (Browser, alle 4 Sprachen): Kontrastprüfung im markierten Zustand, Geometrie der
Trennlinie, Breiten-Sweep von 390px bis 1600px ohne Überlappung mehr, Mobil-Ansicht.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Auf ausdrücklichen Wunsch: der Knopf war bisher unter allen aktuellen Bestellungen platziert.
Jetzt steht er direkt unter der Überschrift "Meine Bestellungen", noch vor der neuesten
Bestellung — beim Aufklappen erscheinen Suchfeld und ältere Bestellungen also ganz oben,
noch vor der aktuellen Liste. Alle 4 Sprachen.
Rein eine Markup-Verschiebung (das <div class="order-archive"> wandert vor <div id="order-list">
im DOM) — die JavaScript-Logik, die ältere Karten per appendChild() in den Aufklappbereich
verschiebt, funktioniert unabhängig von der Position weiter, da sie über getElementById auf
beide Container zugreift. CSS entsprechend angepasst: margin-top wurde zu margin-bottom, weil
der Abstand jetzt VOR der ersten Bestellkarte gebraucht wird statt danach.
Getestet (Browser): DOM-Reihenfolge in allen 4 Sprachen bestätigt (order-archive vor
order-list), Auf-/Zuklappen weiterhin funktionsfähig, Karten wandern korrekt in den
Archiv-Bereich und wieder zurück, Sichtprüfung per Screenshot.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Statt "Bereits erhalten: 1x kleiner Teddy, 1x grosser Teddy" steht im Abo-Bereich jetzt eine
Liste mit dem tatsaechlichen Teddy-Namen, dem Einloesedatum und einem Link zum Produkt —
damit Kundinnen sehen, welchen Teddy sie schon besitzen, und keinen doppelt waehlen.
Dafuer haelt das Konto beim Einloesen fest, WELCHER Teddy vergeben wurde (neues Feld
abo.erhalteneTeddys mit Slug, Name und Datum). Bewusst als Verlauf gespeichert statt aus der
aktuellen Abo-Einstellung abgeleitet: VanVan kann die hinterlegten Teddy-Produkte jederzeit im
Adminbereich austauschen — eine nachtraeglich berechnete Liste wuerde dann einen Teddy
anzeigen, den die Kundin nie bekommen hat. Die Anzeige nimmt den aktuellen, uebersetzten
Produktnamen und faellt auf den gespeicherten Namen zurueck, falls das Produkt spaeter
umbenannt oder entfernt wird.
Nebenbei behoben: Beim Einloesen wanderte der Teddy in den Warenkorb, BEVOR geprueft wurde, ob
ueberhaupt eine Praemie offen ist. Bei einem zweiten Klick landete er dadurch erneut gratis im
Warenkorb, ohne im Konto gezaehlt zu werden. Jetzt wird zuerst geprueft.
Ausserdem sichert getAccount() nun auch die Listenfelder gegen kaputte Speicherwerte ab.
Getestet (Browser): Leerzustand, Einloesen beider Arten, Speicherung im Konto, zweiter Klick
ohne offene Praemie, Altkonto ohne Namensliste (ehrlicher Ersatztext) und entferntes Produkt
(gespeicherter Name greift). Beschriftungen in allen 4 Sprachen geprueft.
Co-Authored-By: Claude Opus 5 <[email protected]>
Impressum, Datenschutz, AGB, Widerruf und Muster-Widerrufsformular liegen jetzt vor der
Zugangsschranke. Grund: PayPal prueft vor der Freischaltung von "Log in with PayPal" die
angegebene Datenschutz- und AGB-Adresse tatsaechlich nach — hinter der Schranke haette deren
Pruefteam nur die Code-Eingabe gesehen und die Freischaltung waere gescheitert. Google verlangt
beim Veroeffentlichen ebenfalls eine erreichbare Datenschutzerklaerung. Rechtlich ist das
ohnehin die saubere Seite; diese Seiten enthalten keine Shop- oder Kundendaten.
Bewusst eng gefasst: feste Liste der fuenf Seiten (kein Praefix-Match), dazu nur Stylesheets
und Logo/Favicons, damit die Seiten beim Pruefteam gestaltet ankommen. Die JS-Buendel aus
/_astro/ bleiben gesperrt — darin stecken u.a. die Produktdaten.
Lokal geprueft: die fuenf Rechtstexte + CSS + Logo liefern 200, waehrend Startseite, Shop,
Warenkorb, Checkout, Konto, Verwaltung, Produktseiten und alle JS-Buendel weiterhin auf die
Zugangscode-Seite umleiten und /api/verwaltung/ weiterhin 401 liefert.
Co-Authored-By: Claude Opus 5 <[email protected]>
Im Kundenbereich stehen jetzt nur noch Bestellungen aus dem letzten Monat direkt in der Liste.
Aeltere werden gebuendelt hinter einem kleinen Knopf "Aeltere Bestellungen (N)" gezeigt und
lassen sich dort nach Bestellnummer, Artikel oder Datum durchsuchen. Alle 4 Sprachen.
Die Monatsgrenze wird bewusst ERST IM BROWSER berechnet (echte Kalendermonate, nicht "30 Tage"):
Die Seite ist statisch vorgebaut, eine schon beim Bauen gezogene Grenze waere ab dem naechsten
Tag falsch. Bestelldatum steht dafuer jetzt als ISO-Datum in den Daten, die Anzeige wird daraus
abgeleitet — nur noch eine Quelle fuers Datum.
Nebenbei gefunden und behoben: getAccount() hat gespeicherte Kontodaten reind flach mit den
Standardwerten zusammengefuehrt. Stand im Speicher ein kaputtes/fehlendes abo-Objekt (null),
hat das den Standardwert ueberschrieben und jeder Zugriff wie a.abo.bezahltBisDatum warf einen
Fehler, der das GESAMTE Konto-Dashboard lahmgelegt hat (keine Bestellungen, keine Tabs mehr).
Das verschachtelte abo-Objekt wird jetzt ausdruecklich mit Standardwerten aufgefuellt.
Getestet (Browser, alle Faelle): Aufteilung nach Datum, Auf-/Zuklappen, Suche nach Artikel und
nach Bestellnummer, Suche ohne Treffer, Zusammenspiel mit den Tabs "Offene Sendungen"/
"Bestellungen", sowie Markup und Uebersetzungen in allen 4 Sprachen.
Co-Authored-By: Claude Opus 5 <[email protected]>
Konto- und Sprachmenü hatten feste Breiten (190px bzw. 168px). Die passen nie zu jedem Fall,
weil der Konto-Knopf je nach Länge des Benutzernamens unterschiedlich breit ist: Bei einem
kurzen Namen wie "qciga" ragte die Kiste sichtbar über den Knopf hinaus.
Jetzt: min-width 100% (nie schmaler als der Knopf) + width max-content (sonst genau so breit
wie der Inhalt). Passt sich damit automatisch an Name und Sprache an.
Nachgemessen, Überstand pro Seite:
Konto "qciga" 27,6px -> 8,6px
Konto "Van Van" 22,4px -> 3,4px
Konto langer Name 0px
Sprache DE/FR 0px (EN 1,8px, CH 0,3px)
Alle weiterhin exakt mittig (Versatz 0), auch mobil innerhalb des Fensters.
Co-Authored-By: Claude Opus 5 <[email protected]>
Das Konto-Aufklappmenü war mit min-width 190px fest breiter gesetzt als sein Inhalt braucht
(~130px) und ragte dadurch sichtbar weiter über den Knopf hinaus als das Sprachmenü daneben.
Jetzt beide 168px — die Kopfzeilen-Menüs sehen gleich aus.
Nachgemessen: Überstand pro Seite vorher 33,4px (Konto) vs 20,7px (Sprache),
jetzt 22,4px vs 20,7px; beide weiterhin exakt mittig (Versatz 0).
Co-Authored-By: Claude Opus 5 <[email protected]>
Das Sprach-Aufklappmenü hing sichtbar nach links versetzt unter seinem Knopf, weil es mit
"right: 0" an dessen rechter Kante ausgerichtet war und breiter ist als der Knopf selbst.
Jetzt echt zentriert (left: 50% + translateX(-50%)) — dasselbe Muster wie auf der
Dogfather-Referenzseite (.nav-dropdown) und wie beim Konto-Menü, das das schon hatte.
Nachgemessen bei 1440/1024/390 px: Versatz jeweils exakt 0 px, kein Überlauf am Bildrand.
Co-Authored-By: Claude Opus 5 <[email protected]>
Kundenkonten sind jetzt genauso echt wie die PayPal-Zahlung: server-geprüftes OAuth 2.0 mit
PKCE für Google und "Log in with PayPal" (functions/_shared/oauth.js, oauth-handlers.js),
neue D1-Tabelle "customers" (bewusst ohne Passwort-Feld), eigene von der Zugangscode-Schranke
getrennte Sitzungs-Logik (customer-auth.js). Echte DSGVO-Rechte direkt im Kontobereich:
Daten herunterladen (Art. 15/20) und Konto unwiderruflich löschen (Art. 17), Bestellungen
bleiben aus gesetzlichen Gründen erhalten. Datenschutzerklärung entsprechend ergänzt.
Ohne echte Google-/PayPal-Zugangsdaten zeigt der Login-Button ehrlich einen
"noch nicht eingerichtet"-Hinweis statt eine Anmeldung vorzutäuschen.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Auf ausdrücklichen Wunsch, mit Fokus auf rechtliche Absicherung:
- Klarna komplett entfernt (hätte eigene Händlerprüfung + Bonitätsprüfungs-
Pflichten nach der neuen EU-Verbraucherkreditrichtlinie vorausgesetzt).
- Eigene Kreditkarten-Eingabemaske komplett entfernt (wäre PCI-DSS-pflichtig
gewesen — für einen kleinen Shop praktisch nicht stemmbar). Kartenzahlung
bleibt möglich: PayPals eigener, PCI-zertifizierter Gast-Checkout bietet
Kredit-/Debitkarte an, ohne dass Kartendaten je unsere Seite berühren.
- PayPal ist jetzt ECHT server-seitig verifiziert statt dem Browser blind zu
vertrauen: eigener Cloudflare-Function-Flow (functions/_shared/paypal.js +
functions/api/paypal/) legt die PayPal-Bestellung server-seitig an, zieht
die Zahlung nach Bestätigung server-seitig ein und prüft den eingezogenen
Betrag gegen die Bestellsumme — die Bestellung wird ausschließlich bei
bestätigter, betragsgleicher Zahlung angelegt. /api/orders lehnt direkte
PayPal-Bestellungen jetzt ausdrücklich ab (verhindert vorgetäuschte
"bezahlte" Bestellungen ohne echte Zahlung).
- Neuer, ehrlicherer Bestellstatus "zahlungOffen": Überweisungs-Bestellungen
starten jetzt so (Geld noch nicht da) statt fälschlich sofort "bezahlt" zu
heißen — Schutz vor Warenversand, bevor das Geld wirklich angekommen ist.
Eigene Kachel/Filter/Badge-Farbe in der Verwaltung, Umsatz-/Auswertungs-
Zahlen zählen "zahlungOffen" bewusst nicht mit.
- Rechtstexte (AGB, Datenschutzerklärung, FAQ, Versand & Zahlung) auf allen
4 Sprachen aktualisiert: nur noch PayPal + Überweisung erwähnt, inkl. DSGVO-
Hinweis zur internationalen Datenübertragung an PayPal (Data Privacy
Framework-Zertifizierung).
- D1-Migration 0003: neue Spalte paypal_order_id (Zahlungsbeleg) + erweiterter
Status-Wertebereich, auf Live-Datenbank angewendet, bestehende Daten intakt.
Mit echten Testbestellungen lokal verifiziert: Überweisung legt korrekt
"zahlungOffen" an, direkter PayPal-Bypass-Versuch an /api/orders wird
abgelehnt, PayPal-Route meldet sauber "noch nicht eingerichtet" ohne
Zugangsdaten. Checkout-UI zeigt nur noch 2 Zahlungsarten, Bestellknopf ist bei
PayPal ausgeblendet (Zahlung läuft exklusiv über den echten PayPal-Button).
Für den echten Zahlungseingang fehlt noch VanVans eigenes PayPal-Business-
Konto (Client-ID + Secret) — Details in der Vault-Dokumentation.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Auf ausdrücklichen Wunsch: "Mit Apple anmelden" raus aus allen 4 Sprachversionen
der Kontoseite (Buttons, Übersetzungsstrings, Kommentare). Bleiben: Google +
PayPal, beide ohne laufende Kosten nutzbar — anders als Apple, das zwingend das
kostenpflichtige Apple Developer Program (99 $/Jahr) fürs Web-Login voraussetzt.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Jede der 6 Kisten (Bestellstatus, Kennzahlen, Bestseller je Kategorie, Herkunft,
Stammkundschaft, Alle Bestellungen) bekommt jetzt:
- einen schimmernden Aurora-Rand in der eigenen Box-Farbe (derselbe Verlaufs-
Trick wie beim Hero-Kopf, nur pro Kiste individuell eingefärbt)
- ihr eigenes Icon riesig und ganz dezent als Wasserzeichen im Hintergrund
- einen "Radar-Ping"-Ring, der leise vom Icon-Abzeichen ausgeht
- eine kleine farbige Eyebrow-Kennzeichnung über dem Titel (z.B. "TOP-VERKÄUFE",
"GEOGRAFIE", "TREUE & WIEDERKEHR")
Die Kennzahlen-Kacheln bekommen zusätzlich einen Lichtstreif, der beim Hover
einmal quer durchläuft. Alles respektiert prefers-reduced-motion.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Gleiche Ursache wie beim vorherigen Fix: "Alle Bestellungen" steckte noch in
einer eigenen <section>, deren Innenabstand sich mit dem der Auswertungs-
Section addiert hat. Jetzt alles eine Section — Abstand jetzt einheitlich
~22px wie zwischen allen anderen Kisten.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Bisher gab es nur "Heute"/"Letzte 7 Tage" — der ganze aktuelle Kalendermonat
fehlte. Neue Kachel zeigt Bestellanzahl + Umsatz diesen Monat, anklickbar wie
die anderen Kennzahlen-Kacheln (filtert die Bestellliste direkt danach). Auch
als neue Option "Dieser Monat" im Zeitraum-Dropdown ergänzt — bewusst als
echter Kalendermonat (ab dem 1.) berechnet, nicht einfach "letzte 30 Tage".
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Die Auswertungs-Kisten steckten in einer eigenen <section>, deren Innenabstand
sich mit dem der vorherigen Section zu einem viel zu großen Zwischenraum
addierte. Jetzt in derselben Section wie Bestellstatus/Kennzahlen — Abstand
zwischen allen Kisten jetzt einheitlich ~22px statt teils 150px+.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
Der separate "Auswertung anzeigen"-Knopf war nicht der Plan — stattdessen sind
jetzt die drei Kisten (Bestseller je Kategorie / Herkunft der Bestellungen /
Stammkundschaft) selbst klickbar und klappen unabhängig voneinander ihren
eigenen Inhalt auf, per sanfter CSS-Grid-Animation und rotierendem Chevron.
Startzustand: alle drei eingeklappt (nur Kopfzeile sichtbar).
Co-Authored-By: Claude Sonnet 5 <[email protected]>
