/** Shopify CDN: Minification failed

Line 13523:3 Unexpected "4"

**/
@charset "UTF-8";
/* CSS Document */

/* Theme-eigen: universeller Box-Sizing-Reset */
* {
  box-sizing: border-box;
}
/* Theme-eigen: Grund-Styling fuer <body> */
body {
  color: var(--color-foreground);
  background: var(--color-background);
  display: flex;
  flex-direction: column;
  margin: 0;
  min-height: 100svh;
  font-variation-settings: "slnt" 0;
}
/* Theme-eigene Variablen-Liste (Farben, Schriften, Timing) - unsere eigenen Farben sind weiter unten markiert */
:root {
  --hover-shadow-color: var(--color-shadow);
  --hover-transition-duration: 0.25s;
  --hover-transition-timing: ease-out;
  --surface-transition-duration: 0.3s;
  --surface-transition-timing: var(--ease-out-quad);
  --submenu-animation-speed: 360ms;
  --submenu-animation-easing: cubic-bezier(0.25, 0.1, 0.25, 1);
  --font-h1--family: "co-headline", sans-serif;
  --font-h2--family: "co-headline", sans-serif;
  --font-h3--family: "co-headline", sans-serif;
  --font-h4--family: "co-headline", sans-serif;
  --font-h5--family: "co-headline", sans-serif;
  --font-h6--family: "co-headline", sans-serif;
  --font-paragraph--family: "co-text", sans-serif;
  --button-font-family-primary: "co-text", sans-serif;
  --button-font-family-secondary: "co-text", sans-serif;
  --planet-shadow-color: #c55d93ff; /* Pink/Magenta, u.a. Schlagschatten */
  --header-color: #eb99bf; /* Helles Rosa, Hover-Farbe & Akzent */
  --wave-color: #f6c0df; /* Hellstes Rosa */

  /* --- Planet V eigene Farb-Variablen (zentral änderbar) --- */
  --pv-green-dark: #143c1f; /* dunkelgrün, u.a. Buttons, Tabs, Badges */
  --pv-green-darkest: #092f01; /* fast schwarzes Grün, z.B. Hintergründe */
  --pv-cream: #f5ffe4; /* helles Creme/Grün, Text auf dunklem Grund */
}
/* Theme-eigen: Scrollbar-Optik + Scroll-Verhalten */
html {
  /* Firefox */
  scrollbar-width: thin;
  scrollbar-color: rgb(var(--color-foreground-rgb) / var(--opacity-40))
    var(--color-background);
  scroll-behavior: smooth;
}
/* Theme-eigen: verhindert doppeltes Scrollen (body UND page-wrapper gleichzeitig) auf grossen Screens */
@media (min-width: 990px) {
  html:has(.page-wrapper),
  html:has(.page-wrapper) body {
    height: 100dvh;
    overflow: hidden;
  }
}
/* Theme-eigen: sperrt Scrollen, wenn z.B. ein Modal offen ist */
html[scroll-lock],
html[scroll-lock] .page-wrapper {
  overflow: hidden;
}
/* Theme-eigen: der Haupt-Scroll-Container der ganzen Seite */
.page-wrapper {
  display: flex;
  flex-direction: column;
  min-height: 100dvh;
  transition: margin-right var(--animation-speed)
    var(--animation-timing-fade-out);
}
/* Theme-eigen: Zusatzregeln fuer .page-wrapper nur auf groesseren Bildschirmen */
@media (min-width: 990px) {
  .page-wrapper {
    height: 100dvh;
    overflow-y: auto;
    scroll-behavior: smooth;
    scrollbar-width: thin;
    scrollbar-color: rgb(var(--color-foreground-rgb) / var(--opacity-40))
      var(--color-background);
  }
  /* Theme-eigen: verschiebt das Konto-Dialogfenster, wenn eine Schublade (z.B. Warenkorb) offen ist */
  .page-wrapper--drawer-open shopify-account::part(dialog) {
    translate: calc(-1 * var(--theme-drawer-width, var(--sidebar-width)));
  }
}
/* Theme-eigen: rueckt die ganze Seite ein, wenn eine seitliche Schublade offen ist */
.page-wrapper--drawer-open {
  margin-right: var(--theme-drawer-width, var(--sidebar-width));
  transition-timing-function: var(--animation-timing-fade-in);
}
/* Theme-eigen: Standard-Reset fuer Medien-Elemente */
img,
picture,
video,
canvas,
svg {
  display: block;
  max-width: 100%;
}
/* Theme-eigen: img zusaetzlich auf volle Breite mit automatischer Hoehe */
img {
  width: 100%;
  height: auto;
}
/* Theme-eigen: Hilfsklasse zum Zentrieren, nutzt --block-width */
.center-block {
  margin: 0 auto;
  text-align: center;
  width: var(--block-width, 100%);
}


/*Header link leiste*/
/* Header-Link-Leiste */
.menu-list__link {
  display: inline-block;
  transform: scale(1);
  transform-origin: center;
  transition: color 180ms ease, transform 220ms ease, font-weight 180ms ease !important;
  /* NEU (Round 27): native Schriftstaerke kam bisher ueber
     --menu-top-level-font-weight (live computed: 700, also "heavy") - Merles
     Wunsch "light/medium statt heavy" im Ruhezustand. Dick darf sie wieder
     werden beim Hover bzw. wenn der Reiter aktiv ist (siehe weiter unten,
     unveraendert bei 900). */
  font-weight: 500 !important;
}

/* Aktive Seite: folgt standardmäßig der Theme-eigenen, adaptiven Textfarbe */
.menu-list__link--active,
.menu-list__link[aria-current="page"] {
  color: var(--menu-top-level-font-color);
  font-weight: 900 !important;
}

/* Aktive Seite: pink, sobald der Header sticky/fest (dunkelgrüner Hintergrund) ist */
.header[data-sticky-state="active"] .menu-list__link--active,
.header[data-sticky-state="active"] .menu-list__link[aria-current="page"] {
  color: var(--header-color) !important;
}

/* Hover: Farbe + sanftes Vergrößern */
.menu-list__link:hover,
.menu-list__link--active:hover,
.menu-list__link[aria-current="page"]:hover {
  color: var(--wave-color) !important;
  transform: scale(1.1) !important;
  transition: color 180ms ease, transform 220ms ease !important;
}
/* NEU (Round 27): beim Hover darf die sonst leichtere Schrift wieder dicker
   werden - NUR fuer den nicht-aktiven Link, der aktive Reiter steht schon
   ueber die Regel oben bei 900 und soll das auch beim Hover bleiben (daher
   hier bewusst NICHT in die kombinierte Hover-Selektorliste oben
   mit aufgenommen, das haette die 900 beim aktiven Reiter versehentlich auf
   700 heruntergesetzt). */
.menu-list__link:hover {
  font-weight: 700 !important;
}

/* Tastatur-Fokus sichtbar machen */
.menu-list__link:focus-visible {
  outline: 2px solid var(--header-color) !important;
  outline-offset: 4px;
}

/* Animation für Nutzer deaktivieren, die weniger Bewegung bevorzugen */
@media (prefers-reduced-motion: reduce) {
  .menu-list__link {
    transition: color 180ms ease !important;
  }
  .menu-list__link:hover,
  .menu-list__link--active:hover,
  .menu-list__link[aria-current="page"]:hover {
    transform: none !important;
  }
}

/* ===== ABSCHNITT: CTA-Buttons nach dem Hero ("Stelle Dir Deine Box zusammen" / "Entdecke alle Gerichte") ===== */
/* Textfarbe/Hintergrund des Links "Stelle Dir hier Deine Lieferbox zusammen" */
.stelldirdeineboxzusammen {
  /* ALT (dunkle Variante, als Backup auskommentiert - Merle moechte sie
     notfalls zurueckholen koennen):
  background-color: var(--pv-green-darkest);
  color: #ddffbbff;
  -webkit-text-stroke: 1.8px #ddffbbff;
  */
  /* NEU (Round 27): helle Variante wie im von Merle geschickten Screenshot -
     zarter dunkelgruener Rand, dunkelgruene Schrift, Hintergrund minimal
     dunkler als die Seite (dieselbe Farbe wie unten bei "Stoebere im
     Katalog" - dort im selben Batch ebenfalls auf diesen Ton vereinheitlicht,
     siehe Abschnitt "Stoebere im Katalog"-Override weiter unten). Kein
     Webstroke mehr noetig - der war nur fuer Kontrast auf dem alten dunklen
     Hintergrund gedacht.
     KORREKTUR (Round 27, 4. Batch): Merle nennt jetzt explizit #def2c7 als
     Hintergrundfarbe (statt des bisherigen #e4f4d2) - direkt uebernommen,
     keine Schaetzung. */
  background-color: #def2c7 !important;
  color: var(--pv-green-dark, #143c1f) !important;
  border: 1.5px solid var(--pv-green-dark, #143c1f) !important;
  -webkit-text-stroke: 0 !important;
  /* Der Button erbt Farbe/Rand/Padding zusaetzlich ueber die native Klasse
     .hero-text-group__subline, deren CSS nur auf Seiten mit Hero-Section
     eingebunden wird. Auf der "Alle Gerichte"-Seite fehlt eine Hero-Section,
     daher fehlten Farbe/Stroke/Radius/Padding komplett. Fix: dieselben Werte
     (1:1 von der Homepage-Instanz uebernommen) hier direkt setzen. */
  border-radius: 0.75em;
  padding: 0.2em 0.9em 0.3em;
  transition:
    color 0.6s ease,
    background-color 0.3s ease,
    -webkit-text-stroke-color 0.6s ease,
    font-size 0.3s ease;
}
/* NEU (Round 27, 3. Batch): Merle "Button insgesamt kleiner". Bisheriger
   Ruhezustand war ein nativer, nirgends von uns gesetzter Wert (live
   gemessen: 29.6px auf echtem Desktop, >=1200px). Bewusst nur fuer "echten"
   breiten Desktop gesetzt - die bestehenden Mobil-/Tablet-clamp()-Regeln
   (Abschnitt weiter unten, max-width:1199px bzw. 749px) bleiben unangetastet,
   die liegen ohnehin schon niedriger. Zielwert 1.6rem ist derselbe Wert, der
   dort bereits als oberes clamp()-Limit verwendet wird (bewusst wiederverwendet
   statt eine neue Zahl zu erfinden) - Schaetzung, bitte live gegenchecken ob
   das klein genug ist. */
@media screen and (min-width: 1200px) {
  body .stelldirdeineboxzusammen {
    font-size: 1.6rem !important;
  }
}
/* Hover: NEU (Round 27, 3. Batch) - Merle "onhover doch den Hintergrund
   dunkelgruen und die Schrift hell machen" (Kurswechsel gegenueber dem 1.
   Batch, wo der Hover noch rosa mit dunkelgruener Schrift war - das wird
   hiermit bewusst wieder zurueckgenommen). Creme/Hell-Ton (#ddffbb) ist
   derselbe, der schon in der alten dunklen Variante (siehe ALT-Backup-
   Kommentar oben) fuer Text auf dunkelgruenem Hintergrund verwendet wurde -
   bewusst wiederverwendet statt neu erfunden. */
.stelldirdeineboxzusammen:hover {
  /* ALT (Backup, 1. Batch - rosa Hover mit dunkelgruener Schrift):
  background-color: var(--header-color) !important;
  */
  /* ENTFERNT (9.10., Round 27 Batch 13): Merle "bitte nur groesser werden,
     nicht die Farben veraendern" - background-color/color-Wechsel beim
     Hover komplett gestrichen (als Backup hier dokumentiert statt
     geloescht, falls doch wieder gewuenscht):
  background-color: var(--pv-green-dark, #143c1f) !important;
  color: #ddffbb !important;
  */
  /* Hover-Wachstum auf 40% des bisherigen Werts reduziert: Ruhezustand
     29.6px, bisheriger Hover 37.6px (+8px) -> neu 29.6px + 0.4*8px = 32.8px =
     2.05em.
     KORREKTUR (Round 27, 4. Batch): Merle "darf onhover nicht ganz so gross
     animieren, nur die Haelfte von dem was gerade passiert" - bezieht sich
     auf das WACHSTUM (die Differenz zum Ruhezustand), nicht den Absolutwert.
     Live gemessen (echter Desktop, Button-Ruhezustand aktuell 25.6px = 1.6rem
     seit der Verkleinerung oben im selben Batch; das 2.05em oben bezieht sich
     auf die Schriftgroesse des Eltern-Elements, live bestaetigt 16px, nicht
     auf den Button selbst): bisheriges Hover 2.05em * 16px = 32.8px, also
     +7.2px Wachstum gegenueber 25.6px. Halbiert: +3.6px -> 29.2px Zielwert,
     als 29.2px / 16px(Eltern-Schrift) = 1.825em. */
  font-size: 1.825em !important;
}
/* NEU (Round 27, 2. Batch): "Alle Gerichte"-Seite - der Beschreibungstext
   unter dem Box-Button ("Waehle frei aus fertig gekochten Bio-Mahlzeiten |
   ...") ist auf dieser Seite ein eigener Text-Block (eigene Section/ID,
   nicht derselbe wie auf der Startseite) und faellt auf die native, recht
   grosse H6-Groesse zurueck (live gemessen: 27.876px, zum Vergleich: die
   Startseiten-Variante liegt bei 21.336px). Merle "viel kleiner" - deutlich
   unter beide Werte gesetzt. Schaetzwert (1rem/16px), bitte live
   gegenchecken ob das klein genug ist oder noch mehr runter soll. */
body .text-block--AUlpSSXZhaisxa1lmS__text_aMHfCn :is(h1, h2, h3, h4, h5, h6) {
  font-size: 1rem !important;
}
/* NEU (Round 28/Batch 17): Merle, "Mobilfeedback Hoch" Punkt 15 - der obige
   1rem-Wert galt bisher ueberall gleich (Hoch UND Quer). Sie wuenscht
   getrennt: Hoch "kleiner" (das ist der obige 1rem-Wert bereits, bleibt so),
   Quer "viel kleiner". Eigene, kleinere Groesse nur fuer Querformat auf dem
   Handy ergaenzt - Schaetzwert, bitte live gegenchecken. */
@media screen and (orientation: landscape) and (max-height: 500px) {
  body .text-block--AUlpSSXZhaisxa1lmS__text_aMHfCn :is(h1, h2, h3, h4, h5, h6) {
    font-size: 0.75rem !important;
  }
}
/* Hover-Farbe fuer den Link "Entdecke alle Gerichte" - ALT (Backup):
#entdeckeallegerichte:hover { color: var(--header-color); -webkit-text-stroke-color: var(--header-color); }
NEU (Round 27): Hintergrund rosa statt Schriftfarbe, siehe oben. */
#entdeckeallegerichte:hover {
  /* ALT (Backup, 1. Batch): background-color: var(--header-color) !important; */
  background-color: var(--pv-green-dark, #143c1f) !important;
  color: #ddffbb !important;
}

/* AB 2.10. (Phase 2): "beide Knoepfe gleichgross mit kleiner Gap" im
   Hero-Text. Ohne genaue Kenntnis der umgebenden Markup-Struktur bewusst
   defensiv geloest: die Regel ist ueber :has() an .hero-text-group
   gebunden UND verlangt, dass sowohl .stelldirdeineboxzusammen als auch
   #entdeckeallegerichte darin vorkommen - trifft die Annahme nicht zu
   (z. B. weil "Entdecke alle Gerichte" gar nicht in .hero-text-group liegt),
   bleibt die Regel wirkungslos statt irgendwo anders unerwuenscht
   einzugreifen. #entdeckeallegerichte bekommt dieselbe Button-Optik wie
   .stelldirdeineboxzusammen (bisher nur ein nackter Link ohne eigenen
   Hintergrund/Padding), beide werden als Flex-Reihe mit kleinem Gap
   nebeneinander/umbrechend zentriert. Bitte live gegenchecken - falls die
   beiden Buttons tatsaechlich nicht in .hero-text-group liegen, bitte die
   Klasse/ID des gemeinsamen Eltern-Elements durchgeben, dann kann ich das
   gezielter loesen. */
body .hero-text-group:has(.stelldirdeineboxzusammen):has(#entdeckeallegerichte) {
  display: flex !important;
  flex-wrap: wrap !important;
  align-items: center !important;
  justify-content: center !important;
  gap: 0.6em !important;
}
body .hero-text-group:has(.stelldirdeineboxzusammen):has(#entdeckeallegerichte) .stelldirdeineboxzusammen,
body .hero-text-group:has(.stelldirdeineboxzusammen):has(#entdeckeallegerichte) #entdeckeallegerichte {
  flex: 0 0 auto !important;
  margin: 0 !important;
}
body .hero-text-group:has(.stelldirdeineboxzusammen):has(#entdeckeallegerichte) #entdeckeallegerichte {
  display: inline-block !important;
  /* ALT (Backup): background-color: var(--pv-green-darkest); color: #ddffbbff; -webkit-text-stroke: 1.8px #ddffbbff; */
  /* NEU (Round 27): identischer heller Look wie .stelldirdeineboxzusammen, siehe dort.
     KORREKTUR (Round 27, 4. Batch): JUDGEMENT CALL - Merle hat explizit nur
     ".stelldirdeineboxzusammen" und "Stoebere im Katalog" auf #def2c7 genannt,
     nicht diesen Button hier. Da beide Buttons laut obigem Kommentar aber
     bewusst "identischer heller Look" sein sollen (gleiche Familie), hier
     mitgezogen, damit sie nicht auseinanderlaufen. Bitte kurz bestaetigen,
     falls "Entdecke alle Gerichte" eigentlich beim alten #e4f4d2 bleiben soll. */
  background-color: #def2c7 !important;
  color: var(--pv-green-dark, #143c1f) !important;
  border: 1.5px solid var(--pv-green-dark, #143c1f) !important;
  -webkit-text-stroke: 0 !important;
  border-radius: 0.75em !important;
  padding: 0.2em 0.9em 0.3em !important;
  text-decoration: none !important;
  text-align: center !important;
}
body .hero-text-group:has(.stelldirdeineboxzusammen):has(#entdeckeallegerichte) #entdeckeallegerichte:hover {
  /* ALT (Backup, 1. Batch): background-color: var(--header-color) !important; */
  background-color: var(--pv-green-dark, #143c1f) !important;
  color: #ddffbb !important;
}

/* Rahmen-Look fuer diese Buttons (duenner gruener Rand) */
.button-custom {
  align-content: right !important;
  --button-border-width: 3px;
  --button-border-color: var(--pv-green-dark);
  border-radius: 1.1em !important;
  font-weight: 700;
  margin-inline: auto;
}
/* Hover: Rahmen + Hintergrund werden rosa */
.button-custom:hover {
  background-color: var(--header-color);
  --button-border-color: var(--header-color);
}
/* NEU (Round 27): "Stoebere im Katalog"-Button (section_hBAxYi) - Merle
   moechte ihn mit der neu umgestalteten "Stelle Dir Deine Box zusammen"-
   Button-Farbe vereinheitlicht sehen (war #e3f3c6, live gemessen, jetzt
   #e4f4d2 wie dort). Textfarbe/Rand bleiben nativ unveraendert (waren schon
   dunkelgruen bzw. kein Rand).
   KORREKTUR (Round 27, 4. Batch): Merle nennt jetzt #def2c7 explizit fuer
   diesen Button UND "Stelle Dir hier Deine Box zusammen" (siehe dort,
   derselbe neue Ton, direkt uebernommen, keine Schaetzung). */
.button-custom--AVmw1QzBrZ21OSVo0e__button_wkxYLF {
  background-color: #def2c7 !important;
  transition: transform 0.2s ease, background-color 0.3s ease, border-color 0.3s ease !important;
  /* NEU (Round 28/Batch 18): Merle, Handy-Buttons-Feedback - "Ausgangszustand
     etwas kleiner machen", damit das Hover-/Touch-Wachstum insgesamt dezenter
     wirkt. Ruhezustand jetzt leicht verkleinert (scale 0.96), Hover/Touch
     waechst auf 1.0 (= die bisherige, native Ausgangsgroesse) - siehe Regeln
     direkt darunter bzw. die Touch-Entsprechung weiter unten im Datei-
     Abschnitt @media(hover:none). */
  transform: scale(0.96) !important;
}
/* GEAENDERT (Round 28/Batch 18): Merle "nicht pink fuellen und Schriftfarbe
   veraendern, sondern nur groesser werden lassen" - die generische
   .button-custom:hover-Regel (siehe oben, Abschnitt "Rahmen-Look fuer diese
   Buttons") faerbt Hintergrund/Rahmen pink ein; hier fuer GENAU diesen
   Button (hoehere Praezedenz durch spaetere Position) wieder auf den
   Ruhezustand zurueckgesetzt, nur noch das (jetzt dezentere) Wachstum
   bleibt. War: nur "transform: scale(1.05)" ohne Rueckname der
   Hintergrundfarbe. */
.button-custom--AVmw1QzBrZ21OSVo0e__button_wkxYLF:hover {
  background-color: #def2c7 !important;
  --button-border-color: var(--pv-green-dark) !important;
  transform: scale(1) !important;
}

/* NEU (neue Anfrage): Merle meldet per eigenem DevTools-Fund (zwei konkrete
   Klassennamen genannt), dass jetzt BEIDE "Stell Dir Deine Box zusammen"-
   Buttons gleichzeitig sichtbar sind - offenbar ein responsives Klassen-Paar
   (eine Variante fuer Mobil, eine fuer Desktop), bei dem das Umschalten
   zwischen beiden bisher nicht greift. Fix exakt nach Merles eigener Angabe:
   ".button-custom--AWFdLK0RsaTNVS3VNU__button_keWeB7" auf Desktop ausblenden,
   ".button-custom--AZE01VWltSk1vY0JlQ__button_fg8Fyy" auf Handy ausblenden -
   damit pro Breite nur noch einer der beiden uebrig bleibt. Dieselbe
   749px/750px-Grenze wie an allen anderen Stellen dieser Datei. */
@media screen and (min-width: 750px) {
  body .button-custom--AWFdLK0RsaTNVS3VNU__button_keWeB7 {
    display: none !important;
  }
}
@media screen and (max-width: 749px) {
  body .button-custom--AZE01VWltSk1vY0JlQ__button_fg8Fyy {
    display: none !important;
  }
}


/* Basis-Look des Pillen-Buttons (z.B. "Erfahre mehr ueber Planet V") */
.pv-button {
    display: inline-flex;
    align-items: center;
    justify-content: center;
    text-align: center;
    /* NEU (Round 27): Merle "font-weight eher light" - war 500, jetzt 300.
       Webstroke komplett weg (war 0.3px), Padding grosszuegiger (war 0.3em
       0.9em - Schaetzwert, bitte gegenchecken ob das reicht oder noch mehr
       sein soll), border-radius explizit auf .55em (Merles Vorgabe, war
       0.8em), Schriftgroesse etwas kleiner (war 1.3em - ebenfalls
       Schaetzwert, bitte live gegenchecken). */
    font-weight: 300;
    letter-spacing: 1px;
    -webkit-text-stroke: 0;
    color: #E3F3C6;
    background-color: #092F01;
    border: 1px solid #E3F3C6;
    padding: 0.5em 1.1em;
    border-radius: 0.55em;
    font-size: 1.15em;
    text-decoration: none;
    transition: background-color 0.3s ease, transform 0.3s ease, color 0.6s ease, -webkit-text-stroke-color 0.6s ease, border-color 0.3s ease;
}
/* GEAENDERT (Round 28/Batch 17): Merle, "Mobilfeedback Hoch" Punkt 12 -
   "Erfahre mehr ueber Planet V" soll beim Hover NICHT den Hintergrund
   animieren, sondern nur Rand UND Schrift zu rosa, dazu etwas weniger
   Wachstum. Vorherige Variante (siehe ALT-Backup) aenderte zusaetzlich den
   Hintergrund auf rosa und die Schrift auf Dunkelgruen - beides jetzt
   zurueckgenommen.
   ALT (Backup, Round 27): wird rosa und leicht groesser, Schrift wechselt
   zusaetzlich auf Dunkelgruen:
.pv-button:hover {
    background-color: var(--header-color);
    border-color: var(--header-color);
    color: var(--pv-green-dark, #143c1f);
    transform: scale(1.08);
} */
.pv-button:hover {
    border-color: var(--header-color);
    color: var(--header-color);
    transform: scale(1.04);
}


#shopify-section-template--31616257655114__product_list_cyt63E [data-testid="resource-list-grid"] {
  padding-left: 2em;
}
/* NEU (Round 27, 2. Batch): Merle "Boxraster soll auf Desktop genauso viel
   Breite einnehmen wie das Gerichte-Raster darueber (resource-list-grid) -
   dafuer muss das linke Padding weg". Nur auf Desktop (Mobil-Hochkant mit
   den gestapelten Reihen soll laut Merle unveraendert bleiben - dort gilt
   bereits die eigene, kleinere 0.4em-Regel weiter unten). */
@media screen and (min-width: 750px) {
  #shopify-section-template--31616257655114__product_list_cyt63E [data-testid="resource-list-grid"] {
    padding-left: 0 !important;
    /* NEU (Round 27, 3. Batch): seit dem Padding-Fix oben erscheint unten eine
       Scrollleiste. Root Cause live gemessen: das Grid ist ein natives
       "Slider"-Element mit overflow-x:auto (zum Vergleich: das Gerichte-Grid
       darueber hat eigene feste px-Spaltenbreiten UND overflow-x:visible,
       braucht also keinen Scroll). Das Boxen-Grid nutzt dagegen
       "grid-template-columns:repeat(5,1fr)" - durch Rundungsungenauigkeiten
       bei 1fr ragt der Inhalt um ca. 7px ueber die eigene Breite hinaus, was
       bei overflow-x:auto sofort eine (wenn auch kaum sichtbare) Scrollleiste
       erzeugt. Fix: overflow-x hier wie beim Gerichte-Grid auf "hidden"
       gesetzt - die 5 Spalten passen so exakt auf die Seite, wie gewuenscht,
       ohne Scrollen. */
    overflow-x: hidden !important;
  }
}
/* NEU (Round 27, 2. Batch): durch die zusaetzliche Breite auf Desktop
   werden die runden Boxbilder (.card-gallery) samt ihrem Schlagschatten-
   Pseudo-Element jetzt sichtbar vom eigenen "overflow:hidden" angeschnitten
   (live bestaetigt: .card-gallery clippt seine Kinder). Fix: Bild+Schatten
   zusammen per Transform minimal verkleinert - transform wirkt auf die
   komplette Box inkl. aller Kind-Elemente (also automatisch auch auf den
   Schatten mit), dadurch passt beides wieder in den sichtbaren Bereich.
   10% ist eine Schaetzung, bitte live gegenchecken ob das reicht. */
@media screen and (min-width: 750px) {
  #shopify-section-template--31616257655114__product_list_cyt63E .card-gallery {
    transform: scale(0.9) !important;
  }
}
/* GELOEST, clip-path komplett ENTFERNT (Round 27, 8. Batch, nach Merles
   eigenem Live-Fund per Theme-Editor-Inspector). Lange Vorgeschichte (mehrere
   Clip-Path-Versuche: 44%/50%/50%, dann 54%/66% passend zum rosa Schatten,
   zuletzt 49%/50%/50%) ist hinfaellig - der echte Root Cause war die
   GRUNDANNAHME selbst: dass jedes Boxbild einen "sicheren", rund
   freigestellten Innenbereich hat, den man gefahrlos per Ellipse
   zurechtschneiden kann. Live von Merle direkt im Theme-Editor widerlegt
   (clip-path testweise deaktiviert -> Boxbild sofort wieder vollstaendig) UND
   von mir gegengeprueft (Bilddatei via fetch() + Blob-Image ohne clip-path
   gerendert): bei We-are-family-Box und Office-Box reicht der echte
   Box-Foto-Inhalt (sichtbar eckig, z. B. die Kartonkisten-Kante) bis an die
   eigenen Bildraender heran - KEIN rund freigestellter Rand vorhanden. Jede
   Ellipse, egal bei welchem Mittelpunkt/Radius, schneidet dort zwangslaeufig
   echten Bildinhalt weg (das wirkte wie eine "abgeschnittene Ecke"). Die
   vorherige Pixel-Alpha-Analyse (nur Transparenz gemessen) hatte das nicht
   erkannt, weil diese Bilder vermutlich gar keinen transparenten Rand haben,
   sondern einfach quadratisch bis zum Rand bedruckt sind - Alpha-Werte allein
   reichen fuer BRENREICH nicht aus, das noch zusaetzlich zu klaeren braucht
   es einen echten visuellen Vergleich wie hier.
   Fix: clip-path ERSATZLOS GESTRICHEN. Die bestehende aspect-ratio:1/1-Regel
   (Abschnitt "72." weiter unten in dieser Datei) plus object-fit:cover
   reichen bereits aus (alle 5 Bilddateien sind nativ ohnehin fast exakt
   quadratisch, Seitenverhaeltnis 0.994-0.999, per fetch()+createImageBitmap
   nachgemessen) - es brauchte also nie einen zusaetzlichen rundlichen
   Zuschnitt. Live verifiziert (mein Testbrowser, echte Desktop-Breite, alle
   5 Boxen): Bilder jetzt wieder vollstaendig/unbeschnitten, UND das
   Boxraster passt weiterhin sauber in die Fensterbreite (clip-path hat nie
   etwas mit Layout/Breite zu tun, nur mit der sichtbaren Bildflaeche - das
   Breitenproblem, das beim Entfernen der aspect-ratio/Hoehen-Regeln
   zusaetzlich auftrat, betrifft NUR jene Regeln, nicht den clip-path, daher
   hier bewusst NUR der clip-path entfernt, die aspect-ratio/Hoehen-Fixes
   bleiben unangetastet bestehen. */
/* ===== ABSCHNITT: Spar-Badge auf Produktkarten (aus dem "sparen"-Custom-Liquid-Snippet) ===== */
/* Die runde Spar-Bubble oben rechts auf der Karte: Groesse, Position, Farbe */
/* AB 2.10., Merles Wunsch: kleiner + Hintergrund passt sich dem Inhalt an
   (vorher feste 75x75px-Kreisflaeche, jetzt eine formfreie "Pille" mit
   Mindestgroesse, die mit laengerem Text mitwaechst statt den Text zu
   quetschen). */
.pv-spare-bubble {
  position: absolute;
  top: 20px;
  right: 12px;
  z-index: 5;
  background-color: var(--pv-green-dark);
  color: #e3f3c6;
  -webkit-text-stroke: 1px #e3f3c6;;
  font-weight: 600;
  filter: drop-shadow(-3px 4px 2px rgba(90, 10, 44, 0.7));
  width: auto;
  height: auto;
  min-width: 48px;
  min-height: 48px;
  border-radius: 999px;
  display: flex;
  align-items: center;
  justify-content: center;
  text-align: center;
  padding: 0.5em 0.6em;
  box-sizing: border-box;
  font-size: 0.8rem; /* war 1rem */
  line-height: 1.1;
  letter-spacing: 5% !important;
}
/* AB 7.10. (Mobil-Feedback-Batch): "Spar"-Bubble auf Mobil kleiner, Schrift
   etwas kleiner, Textstroke viel duenner (war 1px, gleiche Dicke wie am
   Desktop - auf dem kleinen Mobil-Kreis wirkte das sehr klobig). */
/* NEU (Round 28, 65. Batch): Merle "Gallerycards samt Sparenbubble auf dem
   Boxraster sind nach rechts versetzt". Root Cause (live per DevTools
   gemessen): ".card-gallery" bekommt auf Desktop (Abschnitt "Round 27, 2.
   Batch" weiter oben) ein "transform: scale(0.9)" verpasst, um das Clipping
   durch overflow:hidden zu vermeiden - das lässt das runde Boxfoto sichtbar
   kleiner/mittiger wirken. Die Sparen-Bubble (".pv-spare-bubble") liegt
   aber NICHT innerhalb von ".card-gallery" (eigenes Geschwister-Element,
   live bestaetigt per closest()-Check) - ein transform auf ein Geschwister
   wirkt sich nie auf die eigene Position aus. Die Bubble bleibt dadurch an
   ihrer urspruenglichen (unskalierten) top/right-Position haengen, waehrend
   das Boxfoto darunter um 10% geschrumpft ist (zentriert) - pro Seite ca.
   12-13px nach innen. Dadurch wirkt die Bubble wie "nach rechts/oben
   verrutscht", haengt teils ueber den jetzt kleineren Kreis hinaus. Fix: nur
   in dieser Sektion (Boxraster), nur ab 750px (wo auch der scale(0.9)
   greift), Bubble-Position um den gleichen Betrag nach innen (unten/links)
   verschoben. */
@media screen and (min-width: 750px) {
  #shopify-section-template--31616257655114__product_list_cyt63E .pv-spare-bubble {
    top: 32px !important;
    right: 24px !important;
  }
}
@media screen and (max-width: 749px) {
  .pv-spare-bubble {
    min-width: 38px !important;
    min-height: 38px !important;
    font-size: 0.68rem !important;
    -webkit-text-stroke: 0.4px #e3f3c6 !important;
  }
  /* AB 7.10. (Teil 3): Merles Wunsch - "Spare 8%" soll auf Mobil zwischen
     "Spare" und "8%" umbrechen (zwei Zeilen), statt in einer Zeile zu
     bleiben. max-width allein reichte nicht: die Basis-Regel setzt
     display:flex, und ein Flex-Container schrumpft seinen (hier anonymen,
     textbasierten) Inhalt per Default nicht unter dessen natuerliche
     Breite (min-width:auto-Verhalten von Flex-Items) - der Text lief
     dadurch trotz max-width einfach ueber den Rand, statt umzubrechen.
     Fix: fuer Mobil auf display:block umgestellt, dann greift normales
     Text-Wrapping ganz regulaer. Die vertikale Zentrierung, die vorher
     Flex (align-items) uebernahm, kommt jetzt vom symmetrischen Padding
     (0.5em oben/unten aus der Basis-Regel) - bei zwei Zeilen reicht das
     bestehende min-height:38px bereits aus, die Pille muss dafuer nicht
     wachsen. Live verifiziert: Text bricht sauber zwischen "Spare" und
     "8%" um. */
  .pv-spare-bubble {
    max-width: 44px !important;
    white-space: normal !important;
    /* KORREKTUR (7.10., Teil 15): Merle hat live per DevTools getestet
       (Screenshot: Regel gruen markiert/Checkbox deaktiviert) - "display:
       block" entfernen laesst den Text besser mittig sitzen. Deshalb hier
       entfernt. */
    text-align: center !important;
  }
  /* AB 7.10. (Teil 6): dein Screenshot ("Spare 16%") zeigt die Bubble am
     oberen rechten Rand sichtbar vom abgerundeten Eck des Boxfotos
     ueberlappt/angeschnitten. Mehr Abstand nach oben und rechts (Schaetzwerte,
     da ich dein exaktes Geraet/deine Kartenbreite nicht live nachmessen kann -
     bitte live gegenchecken und bei Bedarf nachjustieren). */
  .pv-spare-bubble {
    top: 28px !important; /* war 20px (Basis-Regel) */
    right: 20px !important; /* war 12px (Basis-Regel) */
  }
  /* KORREKTUR (7.10., Teil 11): Merle meldet weiterhin "Schrift trifft auf
     den Rand", besonders oben und rechts. Ursache: die Basis-Regel setzt
     zwar ein Padding (0.5em/0.6em), aber bei der auf Mobil stark reduzierten
     Schriftgroesse (0.68rem) wird daraus nur noch ca. 5-6px - zu wenig fuer
     eine KREISFOERMIGE Bubble, wo der Text (als Rechteck) in Richtung der
     Rundung schnell an die Kurve stoesst, auch wenn er rechnerisch noch
     innerhalb der Box-Breite liegt. Fix: eigenes, grosszuegigeres Padding nur
     fuer Mobil, zusaetzlich oben/rechts noch etwas mehr als unten/links
     (passend zur Rundung des Kreis-Eck, das rechts oben am staerksten
     einschneidet). */
  /* KORREKTUR (7.10., Teil 15): Merle hat live per DevTools getestet
     (Screenshot: Regel gruen markiert/Checkbox deaktiviert) - dieses
     asymmetrische Padding entfernen laesst den Text besser mittig sitzen.
     Komplette Regel deshalb entfernt (war: padding: 10px 12px 7px 7px
     !important;). */
}

/* AB 2.10. (Phase 2): NICHT dasselbe Element wie oben - .pv-spare-bubble ist
   das "Spar"-Badge aus dem sparen-Snippet (Rabatt-Hinweis), Merle meinte mit
   "Bubbles mit den Gerichtpreisen" eine eigene Block-ID im Boxenraster. Block
   selbst auf fit-content/inline-block gesetzt statt voller Blockbreite,
   Innenabstand und Schrift verkleinert, damit der (vermutlich ueber die
   Oxygen-Blockhintergrundfarbe gesetzte) Pillen-Hintergrund eng am Text
   anliegt. Bitte live gegenchecken, ob noch ein zusaetzlicher Wrapper
   vorhanden ist, der ebenfalls auf width:fit-content gesetzt werden muss. */
body [class*="text-block--AU3JQS00rdmw4dUZnb__text_FDkGyy"] {
  display: inline-block !important;
  width: fit-content !important;
  max-width: fit-content !important;
  padding: 0.25em 0.5em !important;
  font-size: 0.75em !important;
  line-height: 1.1 !important;
}
body [class*="text-block--AU3JQS00rdmw4dUZnb__text_FDkGyy"] p {
  font-size: inherit !important;
  margin: 0 !important;
}

/*Filter Standradleiste "Filter" unsichtbar machen auf alle Geerichte Seite*/
#Facet-Details-template--31616257720650__main-filter-p-m-custom-suchfilter_gerichtkategorien .facets__summary, .color-custom-AcmRUTnJpMUJHUXVuY__filters h4{display: none;}


/* ===== ABSCHNITT: Anpassungen an den Box-Produktkarten (Badges ausblenden, Preis-Farbe) ===== */
/* Blendet die Standard-Badges auf den Box-Karten aus */
#shopify-section-template--31616257655114__product_list_cyt63E .product-badges {
  display: none;
}
/* ALT (Backup, vor Round 27): faerbte den durchgestrichenen alten Preis rosa.
   ALT (Backup, Round 27, 1. Batch): Hintergrund #cde4b3.
   NEU (Round 27, 3. Batch): Merle "der Vergleichspreis-Hintergrund soll
   wieder weg, die Farbe #cde4b3 gehoert stattdessen auf die Preis-pro-
   Gericht-Pille" (siehe .text-block--background weiter unten) - hier daher
   komplett ohne eigenen Hintergrund, faellt auf die native Theme-
   Standarddarstellung zurueck. */
#shopify-section-template--31616257655114__product_list_cyt63E
  .compare-at-price {
  /* ALT (Backup): color: var(--header-color) !important; */
  /* ALT (Backup, Round 27, 1. Batch): background-color: #cde4b3 !important; */
  font-size: 80% !important;
  /* KORREKTUR (Round 19): Merle "Vergleichspreis weiter nach links ran,
     schwebt etwas ueber dem Boxpreis" - live per Screenshot in meinem
     eigenen Sandbox-Browser nachgestellt (Preis bei der Office-Box
     voruebergehend selbst sichtbar gemacht, siehe R46 weiter unten) und
     tatsaechlich bestaetigt: der durchgestrichene Preis sass sichtbar
     hoeher als der Hauptpreis, mit sichtbarem Luftpolster dazwischen.
     margin-left von 4px (Abschnitt weiter unten, Clipping-Fix) auf 0
     reduziert (ruecht ihn naeher an den Hauptpreis), zusaetzlich mit
     position:relative/top:4px nach unten gesetzt, bis beide Preise optisch
     auf derselben Grundlinie sitzen - live in meinem Sandbox-Browser an
     genau dieser Karte so eingestellt und per Zoom-Screenshot bestaetigt,
     keine Schaetzung. */
  position: relative !important;
  top: 4px !important;
}
/* NEU (Round 28/Batch 19): Merle hat per eigenem DevTools-Test gefunden
   (Haekchen bei "position:relative!important" entfernt): genau dieser
   4px-Verschiebung-nach-unten-Mechanismus (position:relative + top:4px von
   oben, Round 19 fuer die Preis-Grundlinien-Ausrichtung eingefuehrt) ist die
   Ursache fuer die auf dem Handy hoch abgeschnittenen Vergleichspreise bei
   Single-/Family-/Office-Box (die Verschiebung draengt den Preis ueber den
   unteren Kartenrand hinaus). Fix NUR auf Mobil: position wieder auf static
   zurueckgesetzt (top:4px hat dann keine Wirkung mehr) - die Grundlinien-
   Ausrichtung von Round 19 bleibt auf Desktop unangetastet bestehen, da dort
   kein Clipping gemeldet wurde. */
@media screen and (max-width: 1199px) {
  #shopify-section-template--31616257655114__product_list_cyt63E .compare-at-price {
    position: static !important;
  }
}
/* KORREKTUR (Round 28, 65. Batch): Merle meldet jetzt (erstmals seit Round
   19) den GEGENTEILIGEN Eindruck - der Vergleichspreis sitzt neben dem
   Boxpreis "irgendwie tiefer". Der feste 4px-Versatz nach unten (direkt
   oberhalb, Round 19) war damals per Zoom-Screenshot pixelgenau bestaetigt,
   aber seitdem nicht mehr gegengeprueft - SCHAETZWERT, da ich den genauen
   Unterschied in meinem Sandbox-Browser nicht 1:1 nachstellen kann (echte
   Produktpreise/-bilder laden dort nicht): Versatz vorsichtig halbiert statt
   komplett entfernt. Bitte live gegenchecken, ob die Grundlinie jetzt
   passt oder weiter nachjustiert werden muss. */
@media screen and (min-width: 1200px) {
  #shopify-section-template--31616257655114__product_list_cyt63E .compare-at-price {
    top: 2px !important;
  }
}
/* ===== ABSCHNITT: "Jetzt packen."-Button auf Produktkarten (aus dem
   "packen_oder_kaufen"-Custom-Liquid-Snippet) ===== */
/* Basis-Look des "Jetzt packen."-Buttons */
.pv-product-btn {
  display: block;
  width: fit-content;
  margin-left: 0;
  margin-right: auto;
  text-decoration: none;
  text-align: center;
  background-color: var(--pv-green-dark);
  color: #e3f3c6;
  -webkit-text-stroke: 0.7px #e3f3c6;
  padding: 0.5em 1.2em;
  border-radius: 0.75em;
  font-weight: 500;
  cursor: pointer;
  transform-origin: center;
  transition:
    color 0.3s ease,
    -webkit-text-stroke-color 0.3s ease,
    transform 0.3s ease;
}

/* Hover: Button wird größer, Schrift wird headerrosa, Hintergrund wechselt zu dunkelgrün */
.pv-product-btn:hover {
  -webkit-text-stroke-color: var(--header-color);
  color: var(--header-color);

  transform: scale(1.1);
}
/* NEU (Round 28/Batch 18): Merle, Handy-Buttons-Feedback - "jetzt fuellen"-
   Buttons auf Mobil: Ausgangszustand etwas kleiner (scale 0.95, parallel zum
   gleichen Trick bei "Stelle Dir Box zusammen"/"Stoebere im Katalog" in
   diesem Batch), dazu Webkit-Text-Stroke in allen Zustaenden um 70%
   reduziert (0.7px -> 0.21px). Das Hover/Touch-Wachstum selbst (siehe
   @media(hover:none)-Regel weiter unten) waechst jetzt nur noch auf scale(1)
   = die bisherige native Groesse, nicht mehr darueber hinaus. Nur auf Mobil
   gescopt, da Merles Feedback hierzu ausdruecklich "auf dem HANDY" betraf -
   Desktop-:hover (oben) bleibt unveraendert. */
@media screen and (max-width: 1199px) {
  body .pv-product-btn {
    -webkit-text-stroke-width: 0.21px !important;
    transform: scale(0.95) !important;
  }
  body .pv-product-btn:hover {
    transform: scale(1) !important;
  }
}
/* ===== ABSCHNITT: Einzelne Text-Blöcke, gestylt über ihre automatisch generierte Block-ID ===== */
/* Kuerzt den Text auf 4 Zeilen mit Ausblenden (Clamp), einheitlich per Klick
   ausklappbar auf Mobil UND Desktop. AB 2.10. (2. Korrektur-Runde): der Clamp
   lag bisher auf JEDEM <p> einzeln - der Textblock enthaelt aber ZWEI <p>s
   (Beschreibung + Haltbarkeit/Lieferzeit), die dadurch UNABHAENGIG voneinander
   je 4 Zeilen bekamen (zusammen bis zu 8 sichtbare Zeilen statt 4). Merles
   Wunsch: beide <p>s zusammen als EIN 4-zeiliger Block. Fix: Clamp liegt jetzt
   auf dem Container selbst, die beiden <p>s werden per display:contents
   "aufgeloest" - ihre eigene Box verschwindet, ihr Text zaehlt dadurch als EIN
   durchgehender Textfluss fuer den Zeilen-Zaehler von -webkit-line-clamp.
   Das erklaert vermutlich auch, warum der alte Clamp auf dem Desktop
   offenbar gar nicht griff: die Regel hatte weder "body "-Praefix noch
   ueberall !important - nach Projekt-Konvention braucht jede Regel, die
   zuverlaessig gegen die nativen, NACH base.css ladenden Section-Styles von
   Horizon gewinnen soll, beides. Hier jetzt konsequent ergaenzt - falls es
   trotzdem noch hakt, bitte auf dem Desktop live gegenchecken, ob eine noch
   spezifischere native Regel overflow/display zurücksetzt. */
body [class*="text-block--Aa3pheDByY0ViLzV1N__text_rycJiT"] {
  display: -webkit-box !important;
  width: 90% !important;
  padding-left: 0em !important;
  -webkit-line-clamp: 4 !important;
  -webkit-box-orient: vertical !important;
  overflow: hidden !important;
}
body [class*="text-block--Aa3pheDByY0ViLzV1N__text_rycJiT"] p {
  display: contents !important;
}
/* Kleine Trennlinie unter dem gekuerzten Text */
body [class*="text-block--Aa3pheDByY0ViLzV1N__text_rycJiT"]::after {
  content: "";
  display: block !important;
  width: 80%;
  height: 2px;
  background-color: var(--header-color);
  margin-top: 18px;
  padding-left: 0.35em;
}
/* Ausgeklappter Zustand (Klasse .pv-desc-expanded, per Klick gesetzt - siehe
   mobile-fixes.js, der alte Mobil-Handler UND der neue Desktop-Handler setzen
   dieselbe Klasse auf denselben Container). Im ausgeklappten Zustand die
   beiden <p>s wieder als echte Absaetze mit etwas Abstand anzeigen - besser
   lesbar als ein komplett durchgehender Textfluss. */
body [class*="text-block--Aa3pheDByY0ViLzV1N__text_rycJiT"].pv-desc-expanded {
  -webkit-line-clamp: unset !important;
  overflow: visible !important;
  line-height: 1.2 !important; /* AB 7.10.: Merles Wunsch "Zeilenhoehe eng", gilt Desktop + Mobil */
}
body [class*="text-block--Aa3pheDByY0ViLzV1N__text_rycJiT"].pv-desc-expanded p {
  display: block !important;
  margin: 0 0 0.4em 0 !important;
  line-height: 1.2 !important;
}
body [class*="text-block--Aa3pheDByY0ViLzV1N__text_rycJiT"].pv-desc-expanded::after {
  display: none !important;
}
@media (hover: hover) and (min-width: 750px) {
  body [class*="text-block--Aa3pheDByY0ViLzV1N__text_rycJiT"]:hover {
    -webkit-line-clamp: unset !important;
    overflow: visible !important;
    line-height: 1.2 !important; /* AB 7.10.: Merles Wunsch "Zeilenhoehe eng", gilt Desktop + Mobil */
  }
  body [class*="text-block--Aa3pheDByY0ViLzV1N__text_rycJiT"]:hover p {
    display: block !important;
    margin: 0 0 0.4em 0 !important;
    line-height: 1.2 !important;
  }
  body [class*="text-block--Aa3pheDByY0ViLzV1N__text_rycJiT"]:hover::after {
    display: none !important;
  }
}
 /*Groessere Schrift fuer diesen Produkttitel */
[class*="__product_title_9pPDEV"] p {
  font-size: 1.9vw !important;
  font-weight:600;
  transition: font-size 0.25s ease;
}

/* Hover: Schrift wird noch groesser */

[class*="__product_title_9pPDEV"] p:hover {
  font-size: 2vw !important;
}

/* Einheitlicher Einzug links fuer alle Fliesstexte/Ueberschriften auf den
   Box-Karten - nur diese Sektion, nicht das Gerichte-Karussell. Preis und
   "Jetzt fuellen"-Button sind kein p/h-Element, bleiben unberuehrt. */
#shopify-section-template--31616257655114__product_list_cyt63E :is(p, h1, h2, h3, h4, h5, h6) {
  padding-left: 0.35em;
}
/* ALT (Round 27, 1. Batch): Merle wollte Box-Titel/Button damals bewusst
   WEITER eingerueckt als die Fliesstexte (margin-left:14px). NEU (Round 27,
   8. Batch): Merle "Produkttitel immer noch so eingezogen, kann man den
   margin wegnehmen". Fix: margin-left auf 0 zurueckgesetzt, Titel sitzt jetzt
   auf der gleichen 0.35em-Linie wie die anderen Fliesstexte (padding-left:0
   darunter bleibt bestehen, damit die 0.35em-Grundregel oben nicht erneut
   zusaetzlich zuschlaegt). Der "Jetzt fuellen"-Button (.pv-product-btn,
   eigene Regel, hier NICHT veraendert) behaelt sein margin-left:14px - war
   nicht Teil dieses Wunsches. */
#shopify-section-template--31616257655114__product_list_cyt63E .product-card__content p[role="heading"] {
  margin-left: 0 !important;
  padding-left: 0 !important;
}
#shopify-section-template--31616257655114__product_list_cyt63E .pv-product-btn {
  margin-left: 14px !important;
}
/* NEU (Round 28, 65. Batch): Merle, Desktop-quer-Feedback - "jetzt fuellen"-
   Button soll "ein Mü" (minimal) weiter links sitzen. Nur auf echtem
   Desktop reduziert, die urspruengliche Round-27-Entscheidung (14px) fuer
   Mobil/schmalen Desktop bleibt unangetastet bestehen. SCHAETZWERT (-5px),
   bitte live gegenchecken ob das reicht. */
@media screen and (min-width: 1200px) {
  #shopify-section-template--31616257655114__product_list_cyt63E .pv-product-btn {
    margin-left: 9px !important;
  }
}
/* NEU (Round 28, 65. Batch): Merle, Desktop-quer-Feedback - der 0.35em-
   Einzug links (Fliesstexte/Ueberschriften, Grundregel ganz oben in diesem
   Abschnitt) soll auf echtem Desktop ("quer") komplett entfallen. Nur
   Desktop gescopt, Mobil/schmaler Desktop behalten den Einzug wie bisher. */
@media screen and (min-width: 1200px) {
  #shopify-section-template--31616257655114__product_list_cyt63E :is(p, h1, h2, h3, h4, h5, h6) {
    padding-left: 0 !important;
  }
}
/* ALT (Backup, Round 27, 1. Batch): die "X,XX EUR/Gericht"-Preis-Pille
   (natives ".text-block--background", einheitlich bei allen Boxen) hatte
   bisher 6px eigenes padding-left - das wich von der 10.5px-Grundlinie der
   anderen Texte ab, dadurch sass ihr Text sichtbar weiter links als "Waehle
   frei..."/Preis/"versandkostenfrei". Fix damals: Innenabstand auf 10.5px
   (+4.5px) erhoeht, per gleich grossem negativen margin-left wieder
   ausgeglichen, damit nur die farbige Pille selbst (nicht der Text) die
   4.5px nach links ueber den Kartenrand hinausragt.
   NEU (Round 27, 3. Batch): Merle "bitte das padding-left wieder weg" - der
   obige Textfeinabgleich wird hiermit zurueckgenommen (padding-left faellt
   zurueck auf den nativen 6px-Wert), das linke Ueberstehen der Pille (per
   margin-left) bleibt wie gewuenscht bestehen. Zusaetzlich bekommt die Pille
   jetzt den Hintergrund #cde4b3 (vorher war das kurzzeitig beim
   Vergleichspreis gesetzt, siehe dort - Merle wollte die Farbe stattdessen
   hier). Hinweis: durch das Zuruecknehmen von padding-left sitzt der Pillen-
   TEXT jetzt wieder leicht ausserhalb der 10.5px-Grundlinie der anderen
   Texte (wie vor dem 1. Batch) - bitte Bescheid geben, falls das doch
   wieder stoert. */
#shopify-section-template--31616257655114__product_list_cyt63E .text-block--background {
  margin-left: -4.5px !important;
  background-color: #cde4b3 !important;
}
/* ===== ABSCHNITT: "Alle Produkte anzeigen"-Link unter der Box-Auswahl ===== */
/* Positioniert den "Alle Produkte"-Link rechts oben */
.box-allproducts {
  margin-top: 9px;
  margin-left: auto;
  margin-right: 5vw;
}

/* Look des Buttons selbst */
.box-allproducts__link {
  display: block;
  text-align: center;
  font-size: clamp(1.43rem, 1.47vw, 2.8rem);
  font-weight: 300;
  margin: 0;
  -webkit-text-stroke: 1.65px #ddffbb;
  color: #ddffbb;
  letter-spacing: 1px;
  background-color: var(--pv-green-dark);
  padding-top: 0.1em;
  padding-bottom: 0.1em;
  padding-left: 1.2em;
  padding-right: 1.2em;
  border-radius: 0.8em;
  filter: drop-shadow(-5.5px 5.5px 0px rgba(255, 92, 201, 0));
  text-decoration: none;
  cursor: pointer;
  transition:
    color 0.6s ease,
    -webkit-text-stroke-color 0.6s ease;
}
/* Hover-Farbe */
.box-allproducts__link:hover {
  color: var(--header-color);
  -webkit-text-stroke-color: var(--header-color);
}

.nav-scrollspy-active {
  color: var(--menu-top-level-font-color);
  font-weight: 900 !important;
}
.header[data-sticky-state="active"] .nav-scrollspy-active {
  color: var(--header-color) !important;
}

.nav-scrollspy-suppressed {
  color: var(--menu-top-level-font-color) !important;
  font-weight: 400 !important;
}

.header-logo__image {
  transition: transform 220ms ease;
  transform-origin: center;
}
.header-logo:hover .header-logo__image {
  transform: scale(1.15);
}
@media (prefers-reduced-motion: reduce) {
  .header-logo__image {
    transition: none;
  }
  .header-logo:hover .header-logo__image {
    transform: none;
  }
}


/* ===== ABSCHNITT: Grosser CTA-Button (z. B. "Stelle Dir Deine Box zusammen")
   Faelschlich beim Aufraeumen entfernt (nur Startseite geprueft, aber auf
   Kollektions-/Filterseiten gebraucht) - hier wiederhergestellt. */

/* Abstand/Positionierung des grossen CTA-Buttons (z. B. "Stelle Dir Deine Box zusammen") */
.box-cta {
  margin-top: 35px;
  margin-left: auto;
  margin-right: auto;
}
/* Look des grossen CTA-Buttons selbst */
/* KORREKTUR (9.10., Round 27 Batch 13): Merle meldet erneut (Batch 10,
   Punkt 2 war hierfuer wohl nie der richtige Button) "die Buttons haben
   immer noch Webstroke und animieren wie vorher" - dieser hier
   (.box-cta__link, auf Kollektions-/Filterseiten statt der Startseiten-
   Variante .stelldirdeineboxzusammen) hatte tatsaechlich noch den alten
   dunklen Look (Webstroke 1.65px, Farbwechsel bei Hover) nie auf das in
   Batch 11+ etablierte helle, webstroke-freie Theme umgestellt bekommen,
   als die Startseiten-Variante umgestellt wurde. Jetzt nachgezogen: kein
   Webstroke mehr, Hover waechst nur noch (siehe unten), keine
   Farbaenderung mehr. BITTE BESTAETIGEN, ob dieser Button wirklich der
   gemeinte war (ich konnte ihn mangels bekannter Kollektions-/Filterseite
   in meiner Sandbox nicht live aufrufen/gegenchecken). */
.box-cta__link {
  display: block;
  text-align: center;
  font-size: clamp(1.47rem, 2.47vw, 5.8rem);
  font-weight: 300;
  margin: 0;
  -webkit-text-stroke: 0 !important;
  color: var(--pv-green-dark, #143c1f) !important;
  letter-spacing: 1px;
  background-color: #def2c7 !important;
  border: 1.5px solid var(--pv-green-dark, #143c1f) !important;
  padding-left: 1.8em;
  padding-right: 1.8em;
  border-radius: 2.4em;
  padding-bottom: 0.75em;
  padding-top: 0.75em;
  line-height: 121%;
  filter: drop-shadow(5.5px 5.5px 5.5px rgba(12, 50, 44, 0.5));
  text-decoration: none;
  cursor: pointer;
  transition: transform 0.2s ease;
}
/* Unterzeile unter dem grossen CTA-Button */
.box-cta__subline {
  display: inline-block;
  font-size: clamp(0.33rem, 1.57vw, 2.1rem);
  font-weight: 300;
  letter-spacing: 0.1px;
  line-height: 120%;
  -webkit-text-stroke: 0.9px #ddffbb;
  color: #ddffbb;
  padding-bottom: 1.3em;
}
/* Hover des grossen CTA-Buttons: nur noch Wachstum, keine Farbaenderung
   mehr (siehe Korrektur oben). */
.box-cta__link:hover {
  transform: scale(1.06);
}

/* Styling fuer einen einzelnen Text-Block (kleines Badge/Label) */
.text-block--AZzJKdldmZEk3bzVzd__text_x3p7Te {
  font-size: clamp(0.6rem, 1.6vw, 2.4rem);
  font-weight: 500;
  -webkit-text-stroke: 1.2px #ddffbbff;
  color: #ddffbbff;
  letter-spacing: 1.3px;
  padding-top: 0.2em;
  margin-top: 3em;
  padding-bottom: 0.3em;
  padding-left: 0.9em;
  padding-right: 0.9em;
  border-radius: 0.5em;
}
/* Überschrift über den Taglines */
/* ===== ABSCHNITT: Tagline-Sektion auf der Startseite ("100% bio. 100%
   innovativ. 100% lecker" + Pillen-Reihen) ===== */
.pv-tagline-headline {
  text-align: center;
  color: #e3f3c6;
  margin: 0 0 3em 0;
}
/* Hover-Auslöser-Wörter in der Headline (bio/innovativ/lecker) */
.benefit-trigger {
  cursor: pointer;
  transition:
    color 0.3s ease,
    font-size 0.3s ease,
    -webkit-text-stroke-color 0.3s ease;
}
/* Hover-Zustand: Wort wird rosa und leicht groesser */
.benefit-trigger:hover {
  color: var(--header-color);
  font-size: 110%;
  /* KORREKTUR (7.10., Teil 13): Merle "der webstroke bei 100% x soll
     natuerlich mitgefaerbt werden" - die Fuellfarbe wechselte beim Hover
     bereits zu --header-color, der Webstroke (-webkit-text-stroke, siehe
     .pv-tagline-headline) blieb aber auf der statischen Creme-Farbe stehen,
     dadurch zweifarbiger Hover-Effekt. Stroke-Farbe jetzt an die gleiche
     Variable gekoppelt wie die Fuellfarbe. */
  -webkit-text-stroke-color: var(--header-color);
}
/* Reihen-Container für die Tagline-Pillen */
.pv-tagline-row {
  display: flex;
  justify-content: space-between;
  flex-wrap: wrap;
  gap: 10px;
  width: 90%;
  margin: 0 auto;
}
/* Macht die Wrapper-Divs unsichtbar fuer den Flex-Ablauf (display: contents) */
.pv-tagline-row > div {
  display: contents;
}
/* Die einzelnen Pillen */
.pv-tagline {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  text-align: center;
  font-weight: 500;
  margin-bottom: 3px;
  letter-spacing: 0.6px;
  /* KORREKTUR (Round 27): Merle "Webstroke nur noch 1.2px auf Desktop, auf
     Mobil relational ebenfalls weniger" - war fix 1.8px (unabhaengig von der
     Schriftgroesse). Live gemessen: Desktop-Schriftgroesse dieser Pillen
     20.4px, 1.2px Stroke entspricht dabei exakt 0.0588em - jetzt in em statt
     px gesetzt, damit die Stroke-Breite automatisch mit jeder kleineren
     Mobil-Schriftgroesse mitschrumpft (gleiches Verhaeltnis wie auf
     Desktop), statt wie bisher ueberall gleich dick zu bleiben. */
  -webkit-text-stroke: 0.0588em var(--pv-green-dark);
  color: var(--pv-green-dark);
  background-color: #e3f3c6;
  padding: 0.3em 0.9em;
  border-radius: 0.75em;
  font-size: 1.275em; /* AB 7.10.: Merle wollte zwischen 1.302em (meinem Stand)
    und 1.2em (ihrem eigenen Test) - 1.275em als Kompromiss festgelegt. */
  text-decoration: none;
  transition:
    background-color 0.3s ease,
    transform 0.3s ease,
    color 0.6s ease,
    -webkit-text-stroke-color 0.6s ease;
}
/* Hover: Pille wird rosa und waechst leicht */
.pv-tagline:hover {
  background-color: var(--header-color);
/*
    background-color: #c55d93;
    border-color:  #c55d93;
    color: #f5ffe4;
    -webkit-text-stroke-color: #f5ffe4;*/
  transform: scale(1.08);
}

/* Lange Tagline-Variante: heller Text auf dunkelgruenem Hintergrund, fuer
   einen ganzen Satz statt einem kurzen Claim. Kein Link, daher auch kein
   Hover-Effekt. */
.pv-tagline--long {
  display: flex;
  width: 100%;
  max-width: 100%;
  justify-content: center;
  text-align: center;
  font-weight: 500;
  letter-spacing: 0.6px;
  line-height: 1.4;
  -webkit-text-stroke: 1.2px #e3f3c6;
  color: #e3f3c6;
  background-color: var(--pv-green-dark);
  padding: 0.7em 1.4em;
  border-radius: 1em;
  font-size: 1.1em;
}

/* Bugfix: verhindert unnoetige Mindesthoehe dieser Section */
#shopify-section-template--31616257655114__section_fB7FHf
  .section-content-wrapper {
  height: auto !important;
  min-height: auto !important;
}
/* Verbindung: Hover auf Headline-Wort färbt passende Pillen ein */
body:has(.benefit-trigger.bio:hover) .pv-tagline.bio {
  background-color: var(--header-color);
  transform: scale(1.08);
}
/* dasselbe fuer "innovativ" */
body:has(.benefit-trigger.innovativ:hover) .pv-tagline.innovativ {
  background-color: var(--header-color);
  transform: scale(1.08);
}
/* dasselbe fuer "lecker" */
body:has(.benefit-trigger.lecker:hover) .pv-tagline.lecker {
  background-color: var(--header-color);
  transform: scale(1.08);
}
/* ===== ABSCHNITT: Filter-Checkboxen auf den Kollektions-/Filterseiten ===== */
/* Textfarbe in der Filter-Pille */
facet-inputs-component .checkbox__label-text {
  color: inherit;
  letter-spacing: 1px;
}
/* Hover-Hintergrund */
facet-inputs-component .checkbox__label:hover {
  background-color: #1d5c2dff;
}
/* Angehakt: Ring statt Farbumkehr, da der Hintergrund schon dunkel ist
*/
facet-inputs-component .checkbox__label:has(.checkbox__input:checked) {
  box-shadow: 0 0 0 2px #ddffbbff inset;
}
/* Look der Filter-Pille selbst (Hintergrund, Rand, Abstand) */
facet-inputs-component .checkbox__label {
  display: inline-flex;
  align-items: center;
  gap: 0.5em;
  padding: 0.3em 0.9em;
  border-radius: 0.5em;
  background-color: var(--pv-green-dark);
  color: #ddffbbff;
  cursor: pointer;
  transition:
    background-color 0.15s ease,
    box-shadow 0.15s ease;
}
/* Ueberschreibt die Textfarbe oben nochmal mit !important (staerkere Regel, damit sie sicher gewinnt) */
facet-inputs-component .checkbox__label-text {
  color: #ddffbbff !important;
  -webkit-text-stroke: 1.4px #ddffbbff;
}
/* Blendet die Standard-Ueberschrift der Filtergruppe aus */
.facets__label {
  display: none;
}

#shopify-section-template--31616257720650__main #ResultsList {
 padding-inline:0;
}

/*Gutscheinseite, Gutscheinkollektion wird kleiner skaliert aber bleibt mittig, da es nur drei Gutscheine gibt*/
/* HINWEIS: diese drei Regeln stehen jetzt weiter unten im Mobile-Fixes-Block,
   dort per @media (min-width: 750px) auf Desktop beschränkt - auf Mobil
   greift stattdessen die dortige Regelung (volle Breite + der neue h3-h6
   Mobil-Fix). */
.page-wrapper--drawer-open #shopify-section-template--31616257720650__main .product-grid {
  grid-template-columns: repeat(3, 1fr) !important;
}

@media screen and (min-width: 750px) {
  body .product-grid--template--31616257720650__main:is(.product-grid--grid) {
    grid-template-columns: repeat(4, 1fr) !important;
  }
}
/* KORREKTUR (Round 20): Merle "Handy Quer: Produktraster 5 Spalten, Zeilen
   untereinander" - eigene Regel nur fuer Quer-Handys (schmale Hoehe, aber
   genug Breite fuer 5 schmale Spalten statt der sonst auf Mobil ueblichen
   2-3). "Zeilen untereinander" ist das native Grid-Verhalten (zusaetzliche
   Karten brechen automatisch in die naechste Zeile um) - keine weitere
   Regel noetig.
   KORREKTUR (Bugfix nach Video-Feedback): max-width:749px erkennt Handy-Quer
   nicht zuverlaessig, da echte Handys im Querformat oft breiter als 749px
   sind (z.B. iPhone 14 quer ca. 844px) - die Regel griff dadurch nie. Statt
   Breite wird jetzt die Hoehe geprueft (Handy-Quer ist immer flach, <=500px,
   waehrend Tablet-Quer deutlich hoeher ist).
   KORREKTUR (Round 23): Merle moechte hier doch 4 statt 5 Spalten (deckt sich
   jetzt auch mit der Desktop-Regel oben, die ebenfalls 4 nutzt). */
@media screen and (orientation: landscape) and (max-height: 500px) {
  body .product-grid--template--31616257720650__main:is(.product-grid--grid) {
    grid-template-columns: repeat(4, minmax(0, 1fr)) !important;
  }
}

/* Duennere, rosa Alternativklasse zu .pv-button: 20% duennerer Rand, 12%
   kleinere Schrift, Weight 300 statt 500, kein Text-Stroke, Rand/Schrift in
   Rosa. Zusaetzlich zu .pv-button vergeben. Hover-Schriftfarbe auf
   Dunkelgruen, da der Hover-Hintergrund ebenfalls Rosa ist (sonst unlesbar). */
.pv-button--thin {
  border-width: 1.44px; /* 20% duenner als die 1.8px vom Basis-Button */
  font-size: 1.144em; /* 12% kleiner als die 1.3em vom Basis-Button */
  /* NEU (Round 27): Merle "FAQ-Button bitte noch zarter" - war schon 300,
     jetzt nochmal auf 200 reduziert. */
  font-weight: 200;

    padding: 0.3em 0.5em;
  -webkit-text-stroke: 0;
  color: var(--header-color);
  border-color: var(--header-color);
}
.pv-button--thin:hover {
  color: var(--pv-green-dark);
}


.pv-box-subtitle {
  font-size: 0.85em;
  color: var(--pv-green-dark, #4a5c3a);
  margin-top: -4px;
  margin-bottom: 4px;
}

/*drop shadow versuch*/
/* Schlagschatten hinter dem ersten Slide (rundes Verpackungsbild) */
/* ===== ABSCHNITT: Rundes Schlagschatten-Bild in den Produkt-Slides ===== */
/* Erlaubt dem Schatten, ueber den Bildrand hinauszuragen */
.product-media-container.media-fit:first-of-type {
  overflow: visible;
}
/* Gleiches nochmal fuer den inneren Medien-Container */
.product-media-container.media-fit:first-of-type .product-media {
  overflow: visible;
}
/* Verkleinert das Bild leicht + Schlagschatten */
.product-media-container.media-fit:first-of-type img {
  transform: scale(0.83);
  transform-origin: center center;
  /* AB 2.10. (Merles finaler Wert): deutlich enger/kleinerer Schlagschatten. */
  filter: drop-shadow(-1px 2px 2px rgba(145, 31, 77, 0.81)) !important;
}
/* Der farbige Kreis-Schatten hinter dem Bild */
.product-media-container.media-fit:first-of-type::before {
  content: "";
  position: absolute;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
  border-radius: 50%;
  background-color: var(--header-color);
  opacity: 0.95;
  /* Nur Desktop-Basiswert. Live gemessen: bei 204x204px-Container ragte der
     auf 82% verkleinerte Kreis (ø167.28px) unten ~6px ueber die Kante und
     wurde von overflow:hidden abgeschnitten (betrifft Karussells und
     Gutscheine-Kacheln gleichermassen). Neu: translate(-16px,30px) ->
     translate(-6px,20px), ~2px Sicherheitsabstand, Kreis etwas hoeher/weiter
     rechts. */
  /* KORREKTUR 6.10.: der Wert "scale(0.83) translate(-8px,14px)" war beim
     Vereinheitlichen der drei Schatten-Stellen (Mobil-Feedback-Batch) versehentlich
     auch hier auf die unscoped Basisregel (= Desktop) gerutscht, obwohl der
     Wunsch sich nur auf Mobil bezog. Mobil hat seinen eigenen, unveraendert
     richtigen Wert weiter unten (Abschnitt 6/6b) - hier wird nur der
     Desktop-Basiswert auf den letzten bekannten, fuer Desktop gedachten Wert
     zurueckgesetzt. */
  transform: scale(0.82) translate(-6px, 20px) !important;
  transform-origin: center;
  z-index: 0;
}
/* Verkleinert, rundet und schattiert das zweite Slide-Bild (frueher zwei getrennte Regeln, jetzt zusammengelegt) */
.product-media-container.media-fit:nth-of-type(2) .product-media {
  transform: scale(0.83);
  transform-origin: center center;
  border-radius: 50%;
  overflow: hidden;
  box-shadow: inset 0 0 40px rgba(0, 0, 0, 0.65);
}
/* Entfernt die Rundung beim zweiten Bild wieder */
.product-media-container.media-fit:nth-of-type(2) img {
  border-radius: 0%;
}
/* ===== ABSCHNITT: Produkt-Popup / Schnellansicht (Quick View Modal) — öffnet sich beim Klick auf ein Produkt ===== */
/* Groesse/Position des Popup-Fensters selbst */
.quick-view-modal {
  border: none;
  border-radius: 24px;
  padding: 32px;
  max-width: 85vw;
  width: 80vw;
  max-height: 85vh;
  overflow-y: auto;
  position: relative;
  margin: auto; /* zentriert das dialog-Element auf dem Bildschirm */
}
/* Abgedunkelter Hintergrund hinter dem Popup */
.quick-view-modal::backdrop {
  background: rgba(0, 0, 0, 0.5);
}
/* Das ×-Schliessen-Symbol. Deutlich hoeherer z-index statt knapper 1, damit
   der Button garantiert immer ueber dem Popup-Inhalt liegt.
   KORREKTUR (7.10., Teil 13): Merle "das Schliessen-Quadrat wird oft in der
   Breite gestaucht, bitte immer 1:1 + am liebsten kreisrund + etwas weiter
   vom rechten Rand". Root Cause: bisher keine eigene Breite/Hoehe gesetzt -
   die Buttongroesse ergab sich rein aus Inhalt (×-Zeichen) + nativem
   Button-Padding, was je nach Theme-/Button-Reset-Styles schwanken kann.
   Fix: feste, garantiert quadratische Groesse (width=height, zusaetzlich
   aspect-ratio UND flex-shrink:0 als doppelte Absicherung gegen Stauchung
   durch einen umgebenden Flex-/Grid-Kontext), Inhalt zentriert, border-
   radius:50% fuer die gewuenschte Kreisform. "right" von 16px auf 28px
   erhoeht (mehr Abstand zum Rand) - gilt bewusst fuer Mobil UND Desktop,
   wie gewuenscht, daher hier nicht in einer @media-Regel gescopt.
   KORREKTUR (7.10., Teil 13, nach Screenshots): Kreis war zu gross, zu viel
   Abstand zwischen × und Kreisrand - Kreis von 40px auf 32px verkleinert UND
   gleichzeitig font-size (× -Zeichen) im Verhaeltnis zum Kreis vergroessert
   (1.8rem/40px-Kreis war ein Verhaeltnis von ~0,65 - jetzt bei 32px-Kreis
   mit 1.4rem ein engeres Verhaeltnis von ~0,7), dadurch sitzt das × sichtbar
   dichter am Rand.
   ZUM "oben abgeschnitten waehrend das Popup laedt": geometrisch ist der
   Button im RUHEZUSTAND klar ausserhalb der abgerundeten Ecke (right:28px
   liegt weiter vom Rand entfernt als der border-radius von 24px auf
   .quick-view-modal) - das Abschneiden passiert also nur WAEHREND der
   Oeffnen-Animation des <dialog>-Elements (vermutlich eine Skalierungs-
   /Transform-Animation aus Horizons eigenem Script in Kombination mit
   overflow-y:auto), nicht durch eine falsche Position im Endzustand. Das ist
   von hier aus nicht gezielt behebbar, ohne die genaue Animation zu sehen.
   Als pragmatischer Zwischenschritt: der Button blendet jetzt leicht
   verzoegert ein (siehe @starting-style unten), damit der kurze
   Animations-Moment, in dem er evtl. angeschnitten ist, gar nicht erst
   sichtbar wird. Funktioniert nur in neueren Safari-/iOS-Versionen (ab iOS
   17.4) - in aelteren einfach ohne Effekt (Button bleibt wie bisher sofort
   sichtbar, kein Rueckschritt).
   KORREKTUR (7.10., Teil 14): Merles zweiter Vorschlag ("einfach etwas
   tiefer, naeher an der Gallery") umgesetzt - top von 16px auf 32px erhoeht,
   damit der Button weiter von der oberen, abgerundeten Dialog-Kante entfernt
   sitzt. Ihr ERSTER Vorschlag (Popup erst bei Scroll-Position 0 der Seite
   oeffnen) ist NICHT mit umgesetzt - das waere eine Verhaltensaenderung
   (die Seite wuerde beim Antippen einer Produktkachel erst sichtbar nach
   oben springen, bevor sich das Popup oeffnet), die ich nicht einfach
   stillschweigend einbauen wollte. Davon abgesehen bin ich mir nicht sicher,
   ob das den Clipping-Effekt ueberhaupt beheben wuerde (die Diagnose oben
   deutet auf eine dialog-interne Oeffnen-Animation hin, nicht auf einen
   Seiten-Scroll-Effekt) - falls top:32px nicht reicht, waere das aber ein
   berechtigter naechster Versuch. */
.quick-view-modal__close {
  position: absolute;
  top: 32px;
  right: 28px;
  background: none;
  border: none;
  font-size: 1.4rem;
  line-height: 1;
  cursor: pointer;
  color: inherit;
  z-index: 999999 !important;
  width: 32px;
  height: 32px;
  min-width: 32px;
  min-height: 32px;
  aspect-ratio: 1 / 1;
  flex-shrink: 0;
  display: flex;
  align-items: center;
  justify-content: center;
  border-radius: 50%;
  opacity: 1;
  transition: opacity 0.18s ease 0.12s;
}
@starting-style {
  .quick-view-modal__close {
    opacity: 0;
  }
}

#quick-view-modal slideshow-arrows {
  display: none !important;
}

#quick-view-modal .details__header {
  font-weight: 600;
}
#quick-view-modal .details-content{padding-bottom:0.5em;}

#quick-view-modal .accordion-custom{border-bottom: 1px solid var(--pv-green-dark);}

/* Blendet zunaechst alle Bilder ausser dem ersten aus */
.quick-view-modal__content slideshow-slide:not(:first-of-type) {
  display: none !important;
}
/* Erzwingt eine einspaltige Ansicht im Popup (Mobile-Basis, wird unten per @media erweitert) */
.quick-view-modal__content .product-information__grid {
  display: grid !important;
  grid-template-columns: 1fr !important;
  gap: 32px !important;
}
/* "display: revert" war der Bug hinter dem fehlenden Produktbild im Popup:
   slideshow-slide ist ein nicht registriertes Custom Element - "revert"
   springt zum UA-Default "display:inline", der Slide fiel auf 0x0px zusammen.
   Fix: "display:block" (548x667px, Bild wieder sichtbar). */
.quick-view-modal__content slideshow-slide.qv-active-slide {
  display: block !important;
  height: 80dvh !important;
  max-height: 80dvh !important;
  overflow: hidden !important;
  position: relative !important;
}
/* Bild fuellt den Slide komplett aus (frueher als zwei identische Regeln doppelt vorhanden, jetzt zusammengelegt) */
/* Bild fuellt den Slide komplett aus (frueher als zwei identische Regeln doppelt vorhanden, jetzt zusammengelegt) */
.quick-view-modal__content slideshow-slide img {
  position: absolute !important;
  top: 0 !important;
  left: 0 !important;
  width: 100% !important;
  height: 100% !important;
  object-fit: contain !important;
}
/* EXPERIMENT (Round 28/Batch 18): Merle, Produktpopup-Scroll-Problem (Desktop
   quer/quadratisch, zweispaltige Ansicht) - "beim Hover ueber die Slideshow
   scrollt man beim Scrollen weiterhin fast nur den Text links". Die
   urspruengliche Ursache (welches Element das Scroll-Event tatsaechlich
   abbekommt) konnte in frueheren Batches trotz mehrfacher Versuche nicht
   reproduziert/gefunden werden (siehe "ECHT UNGEKLAERT" an anderer Stelle
   in dieser Datei). Merles eigener Vorschlag als Alternativ-Ansatz: "Bilder
   oben ausrichten und die Hoehe an die Slide-Hoehe anpassen, oder dabei
   mindestens quadratisch bleiben" - ausdruecklich als TEST gedacht ("kann
   mir vorstellen, dass es bloed aussieht und ich zum Ausgang zurueckmoechte").
   Nur fuer die zweispaltige Ansicht (ab 750px) gesetzt, NICHT fuer die
   einspaltige Mobil-Ansicht. Falls das "bloed aussieht": diesen @media-Block
   einfach entfernen/auskommentieren, die obigen Basis-Regeln (80dvh/object-
   fit:contain, unveraendert) greifen dann wieder wie bisher - nichts davon
   wurde geloescht. AUSDRUECKLICHER HINWEIS: konnte NICHT live gegengeprueft
   werden (Chrome-Verbindung war zu diesem Zeitpunkt getrennt), weder visuell
   noch ob es das Scroll-Problem tatsaechlich lindert (die Vermutung ist nur:
   weniger leerer Raum oberhalb/unterhalb des Bildes = weniger Flaeche, auf
   der das Scroll-Event falsch geroutet werden kann - das ist eine Theorie,
   kein bestaetigter Fix). */
@media screen and (min-width: 750px) {
  .quick-view-modal__content slideshow-slide.qv-active-slide {
    height: auto !important;
    aspect-ratio: 1 / 1 !important;
    max-height: 80dvh !important;
  }
  .quick-view-modal__content slideshow-slide img {
    object-position: top !important;
  }
}
/* Ab Tablet-Breite: Bild und Produktinfo nebeneinander */
@media screen and (min-width: 750px) {
  .quick-view-modal__content
    .product-information__grid.product-information--media-left {
    grid-template-columns: 1fr min(50vw, var(--sidebar-width, 480px)) !important;
  }
}
/* NEU (neue Anfrage): Merle "die Popups sollen auf Handy-Quer auch 2-spaltig
   sein wie auf Desktop" - Root Cause: die obige Umschaltung haengt NUR an
   min-width:750px. Ein echtes Handy im Querformat ist oft SCHMALER als
   750px (z.B. iPhone SE quer ca. 667px) und bleibt dadurch auf der
   einspaltigen Mobil-Basisregel haengen, obwohl genug Hoehe fuer eine
   zweispaltige Ansicht da waere - dieselbe "Breakpoint-Luecke" wie an
   vielen anderen Stellen dieser Datei. Fix: dieselbe Spaltenaufteilung
   zusaetzlich fuer echtes Handy-Quer (Querformat + Hoehe <=500px). */
@media screen and (orientation: landscape) and (max-height: 500px) {
  .quick-view-modal__content
    .product-information__grid.product-information--media-left {
    grid-template-columns: 1fr min(50vw, var(--sidebar-width, 480px)) !important;
  }
}
/* Ab Desktop-Breite: noch mehr Platz fuer's Bild */
@media screen and (min-width: 1200px) {
  .quick-view-modal__content
    .product-information__grid.product-information--media-left {
    grid-template-columns: 2fr 1fr !important;
  }
}
/* Akkordeon-Icon-Fix im Popup */
.quick-view-modal__content .accordion--caret .icon-plus {
  display: none !important;
}
/* Miniaturbilder-Leiste im Popup: horizontal scrollbar, mit Abstand nach oben */
/* Miniaturbilder-Leiste im Popup: horizontal scrollbar, mit Abstand nach oben */
.quick-view-modal__content .slideshow-controls__thumbnails {
  display: flex !important;
  flex-wrap: nowrap !important;
  gap: 12px !important;
  overflow-x: auto !important;
  /* GEAENDERT (Round 28, 21. Batch): Merle "ueberall auf allen Queries bitte
     mehr Abstand im Produktpopup zwischen aktuellem grossen Slidebild und
     den Miniaturen darunter" - diese Regel ist bereits unscoped (gilt fuer
     jede Breite), margin-top einfach erhoeht. War 12px. */
  margin-top: 24px !important;
}
/* Groesse der einzelnen Miniaturbilder */
.quick-view-modal__content .slideshow-controls__thumbnail {
  flex: 0 0 auto !important;
  width: 60px !important;
  height: 60px !important;
  padding: 0 !important;
}
/* Bild fuellt die Miniatur komplett aus */
.quick-view-modal__content .slideshow-controls__thumbnail img {
  width: 100% !important;
  height: 100% !important;
  object-fit: cover !important;
}
/* Blendet einen doppelten Produkttitel im Popup aus */
.quick-view-modal__content .view-product-title {
  display: none !important;
}
/* Verkleinert ein Logo-Bild im Popup */
.quick-view-modal__content .logo-block__image-wrapper {
  max-width: 80px !important;
  margin: 0 auto !important;
}
/* Steuert auf einem zweiten Weg, welches Bild sichtbar ist (siehe Regel
   oben). Wirkt auf den ersten Blick doppelt - vor dem Zusammenlegen pruefen,
   ob beide Varianten noch gebraucht werden. Deckt zusaetzlich den Fall ab,
   dass per Klick ein spaeterer Slide aktiv wird. */
.quick-view-modal__content slideshow-slide {
  display: none !important;
}
/* Macht nur den aktiven Slide sichtbar. "display: revert" auf "display:
   block" korrigiert - selbe Ursache wie bei der ersten .qv-active-slide-
   Regel, kommt aber spaeter in der Cascade und hatte bei "display" das letzte
   Wort. */
.quick-view-modal__content slideshow-slide.qv-active-slide {
  display: block !important;
}
/* Theme-eigen: Grund-Reset fuer Formularelemente */
input,
textarea,
select {
  font: inherit;
  border-radius: var(--style-border-radius-inputs);
}
/** override ios and firefox defaults */
/* Theme-eigen: iOS/Firefox Standard-Look von <select> ueberschreiben */
select {
  background-color: var(--color-background);
  color: currentcolor;
}
/* Theme-eigen: Basis-Hoververhalten der Produkt-/Kollektions-Karten */
.product-card,
.collection-card,
.predictive-search-results__card--product,
.predictive-search-results__card {
  position: relative;
  transition:
    transform var(--hover-transition-duration) var(--hover-transition-timing),
    box-shadow var(--hover-transition-duration) var(--hover-transition-timing);
  z-index: var(--layer-flat);
}
/* Theme-eigen: macht die ganze Karte klickbar */
.product-card__link {
  position: absolute;
  inset: 0;
}
/* Theme-eigen: Positionierungs-Kontext fuer die Karte */
.product-card__content {
  position: relative;
}
/* Theme-eigen: zeigt den Hand-Cursor beim Hover (zweite Regel mit gleichem Selektor) */
.product-card__content {
  cursor: pointer;
}
/* ===== ABSCHNITT: Easy Bundles Mix & Match (Box-Zusammenstellungs-Popup) ===== */
/* Container fuer das runde Produktbild im Bundle-Popup */
.gbbProductImageContainer {
  position: relative !important;
  overflow: visible !important;
  z-index: 0;
}

.gbbFooterBundleTitle{

  padding-bottom: 0.4em;
}

/* Farbiger Kreis-Schatten hinter dem Bild */
.gbbProductImageContainer::before {
  content: "";
  position: absolute;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
  border-radius: 50%;
  background-color: var(--header-color);
  transform: scale(0.96) translate(-5px, 17px);
  transform-origin: center;
  z-index: -1;
}
/* Das Bild selbst: rund, zugeschnitten, mit Schlagschatten */
.gbbProductImage {
  width: 100% !important;
  height: 100% !important;
  max-height: none !important;
  border-radius: 50% !important;
  object-fit: cover !important;
  object-position: center -23% !important;
  transform: scale(0.98);
  display: block !important;
  position: relative;
  z-index: 1;
  filter: drop-shadow(-3px 7px 3px rgba(90, 10, 44, 0.7));
  background-color: transparent !important;
}
/* Innenabstand links/rechts im Bundle-Popup */
.gbbBundleBody {
  padding-left: 1em !important;
  padding-right: 1em !important;
}
/* Hintergrundfarbe des Bundle-Popups */
#gbbBundle {
  background-color: #d4ecaaff;
}
/*background-color: #b7d79dff ;*/
/*background-color: #f3f9edff;*/
/*background-color: #c55d93ff ;*/
/* Blendet den doppelt angezeigten Kategorie-Titel aus */
.gbbCategoryTitle {
  display: none !important;
}

/* KORREKTUR (Round 26, 5. Feedback-Batch, "zu bunt"-Rueckmeldung): Merle hat
   selbst per Safari-Inspector getestet und bestaetigt, dass diese Variable
   auf der Live-Seite exakt das dunkle Cart-Gruen ergibt (per Chrome live
   nachgemessen: #092F01, identisch mit --gbb-cart-footer-bg-color) - ihr
   eigener, bestaetigter Wert wird hier 1:1 uebernommen statt des bisherigen
   hellgruenen Testwerts. */
.gbbProductSlotContainer{background-color: var(--gbb-box-selection-active-text-color, #092F01) !important; }

/* NEU (Round 26, 6. Feedback-Batch): Merle moechte EIN einheitliches
   Hellgruen auf der ganzen EB-Seite, dasselbe wie im Produkt-Popup
   (#f4ffdb) - ersetzt die bisherigen, leicht unterschiedlichen Hellgruen-
   Toene (u.a. #e3f6c2, #e3f3c6), die an verschiedenen Stellen im EB-Widget
   verwendet wurden. */
.gbbProductSlotImageContainer{ background-color: #f4ffdb; }

.gbbProductTitleOnly {
  display: -webkit-box;
  -webkit-line-clamp: 2;
  -webkit-box-orient: vertical;
  overflow: hidden;
}

.pv-beilagen {
  display: -webkit-box;
  -webkit-line-clamp: 1;
  -webkit-box-orient: vertical;
  overflow: hidden;
}

.gbbCategoriesHeaderContainer{border-bottom: 4px solid var(--pv-green-dark) !important;}

/* Bug: Easy Bundle auf der eigenstaendigen Produktseite wurde nicht gescaled,
   riesige Kacheln. Ursache: ein blosses "1fr"-Grid-Track hat ohne definitive
   Container-Breite implizit Mindestgroesse "auto". Bei der tiefen Wrapper-
   Verschachtelung dieser Seite liegt beim ersten Layout-Durchlauf keine
   definitive Breite vor - Spalten wachsen auf Inhaltsbreite (bis 655px), Easy
   Bundles misst das per JS und schreibt es als fixen Inline-Style fest,
   wodurch die Aufblaehung bestehen bleibt. Fix: "minmax(0, 1fr)" statt "1fr"
   + width:100% auf dem Grid-Container, damit von Anfang an eine definitive
   Breite vorliegt. Getestet bei 1600px: 4 gleich breite Spalten ohne
   Overflow. */
.gbbProductsContainer {
  grid-template-columns: repeat(4, minmax(0, 1fr)) !important;
  width: 100% !important;
  max-width: 100% !important;
}

.page-wrapper--drawer-open .gbbProductsContainer {
  grid-template-columns: repeat(3, minmax(0, 1fr)) !important;
}
/* Container fuers runde Produktbild im Bundle-Popup. width:100% ist der Fix:
   die App setzt selbst eine feste Pixel-Breite, der Container schrumpfte bei
   schmaleren Spalten nicht mit und ragte in Nachbarspalten rein. aspect-ratio
   + height:auto halten ihn trotzdem quadratisch. */
.gbbProductImageContainer {
  position: relative !important;
  overflow: visible !important;
  z-index: 0;
  width: 100% !important;
  aspect-ratio: 1 / 1;
  height: auto !important;
}

/* Laesst die Produktkarte in der Hoehe mitschrumpfen statt fester Hoehe - der
   Wrapper hat keine eigene Klasse, nur data-product-card="true". Noetig, seit
   Bilder bei mehr Spalten kleiner werden. */
.gbbProductsContainer [data-product-card="true"] {
  height: auto !important;
}


/* Lässt die Produktkarte in der Hoehe mitwachsen, statt auf einer festen
   Hoehe zu bleiben - noetig, seit .gbbProductImageContainer per aspect-ratio
   quadratisch ist und bei mehr Spalten (4 statt 3) dadurch hoeher wird als
   die alte Fixhoehe der Karte. */
.gbbProductItem {
  height: auto !important;
}

/* Entfernt den rosa Bottom-Border, den die Easy-Bundles-App selbst am aktiven
   Tab setzt (side-footer-bundle.min.css) - das war die eigentliche Ursache
   fuer den rosa Streifen, nicht der Hintergrund. */
.gbbCategoryTabContainer[data-is-active="true"] {
  border-bottom: none !important;
  /* KORREKTUR (Round 26, 5. Feedback-Batch): "border-radius: 0.5em 0.5em 0 0"
     (nur oben gerundet) entfernt - Merle wuenscht jetzt Rundung an ALLEN
     Ecken, auch beim aktiven Tab. Die Basis-Regel weiter unten
     (".gbbCategoryTabContainer { border-radius: 0.5em; }") greift fuer
     aktive UND inaktive Tabs gleichermassen, eine eigene Ueberschreibung hier
     ist dadurch nicht mehr noetig. */
}


/* WIEDER RUECKGAENGIG GEMACHT (30.9.): hier wurde .gbbProductPrice/
   .gbbProductCompareAtPrice per Bio-/Vegan-Siegel-Hintergrundbild ersetzt
   und der eigentliche Preistext per font-size:0 unsichtbar gemacht - Merle
   will den Preis wieder sehen. Damit sind aktuell auch die beiden Siegel-
   Icons weg; falls die weiterhin gewuenscht sind, brauchen sie eine eigene,
   vom Preis getrennte Stelle. */
.gbbProductPricesContainer {
  display: flex;
  align-items: center;
  gap: 4px;
}
/* GEFUNDEN (30.9., Merle per Inspector): der eigentliche Grund, warum die
   Preise trotz obiger Regel nicht sichtbar waren - Easy Bundles selbst
   setzt visibility:hidden auf diesen Container, sobald body das Attribut
   gbb-hide-product-prices="true" traegt (vermutlich ein Builder-Setting).
   Hier erzwungen sichtbar. */
body[gbb-hide-product-prices="true"] .gbbProductItem[data-bundle-product="true"] .gbbProductPricesContainer {
  visibility: visible !important;
}
/* .gbbProductCompareAtPrice zeigt (sobald von mobile-fixes.js befuellt,
   Abschnitt 17) den urspruenglichen/nativen Einzelpreis durchgestrichen als
   Vergleich zum berechneten Gerichtpreis in .gbbProductPrice. :empty blendet
   es aus, solange/falls kein Vergleichswert gesetzt ist. */
.gbbProductCompareAtPrice {
  text-decoration: line-through;
  opacity: 0.6;
  font-size: 0.85em;
}
.gbbProductCompareAtPrice:empty {
  display: none;
}
/* ALT (Backup, Round 26, 7. Batch): Hintergrund #e3f3c6.
   NEU (Round 27, 3. Batch): Merle "die backgroundcolor wieder weg!" - hier
   daher komplett entfernt, nur die Textfarbe (#d9edbe) bleibt bestehen. */
.gbbDiscountStepsProgressBarStepTitle, .gbbDiscountStepsProgressBarStepSubtitle{
  color: #d9edbe !important;
  /* ALT (Backup): background-color: #e3f3c6 !important; */
}

/* NEU (Round 26, 5. Feedback-Batch): "Suche noch X Gerichte..."-Hinweis
   mehr Abstand darueber/darunter (war 0/0 margin). 12px gewaehlt als "etwas
   mehr Luft" - bitte sagen, falls mehr/weniger gewuenscht.
   KORREKTUR (Round 26, 7. Feedback-Batch): "nicht kursiv, sondern light" -
   font-style:italic wieder entfernt, font-weight auf "lighter" (Schluesselwort,
   relativ zur geerbten Schriftstaerke) - das ist genau der Wert, den die
   native EB-eigene Regel an dieser Stelle selbst schon (deaktiviert) vorsieht,
   laut deinem Screenshot (side-footer-bundle.min.css:45). */
.gbbDiscountMessageContainer {
  font-weight: lighter !important;
  margin-block: 12px !important;
}

/* NEU (Round 26, 5. Feedback-Batch): ".gbbProductActionWithContent"/"in
   meine Box"-Button/Mengen-Steller nur noch 96% breit statt volle Breite -
   exakt Merles eigener, per Safari-Inspector getesteter Wert/Selektor-
   Gruppe (side-footer-bundle.min.css:29, dort nativ auf dieser Breite).
   KORREKTUR (Round 27, 3. Batch): Merle meldete per Screenshot, die 96%
   wuerden "nicht durchkommen" (native width:100%-Regel gewinnt weiterhin).
   Root Cause gefunden, kein Spezifitaets-/Einheiten-Problem diesmal: die
   Regel war hier versehentlich auf "@media (max-width:768px)" (Mobil)
   beschraenkt, Merles Test lief aber auf Desktop-Breite - dort griff die
   Regel dadurch nie. Live bestaetigt (183px von 190px Elternbreite = 96%,
   nachdem die Media-Query-Grenze entfernt wurde). Fix: Media Query entfernt,
   gilt jetzt unscoped auf allen Breiten. */
body .gbbProductAddButton,
body .gbbProductActionWithContent .gbbProductButtonContainer,
body .gbbProductItem .gbbProductActionWithContent .gbbQuantityStepper {
  width: 96% !important;
}



.gbbProductTitleOnly{

  padding-top: 0.7em;
}

/* Blendet alle nicht aktiven Kategorie-Abschnitte aus - die App setzt data-
   is-active korrekt, es fehlte nur die CSS-Regel, die darauf reagiert. */
.gbbCategoryContainer[data-is-active="false"] {
  display: none;
}
/* Look der Kategorie-Tabs (inaktiv). KORREKTUR (Round 26, 5. Feedback-Batch,
   "zu bunt"-Rueckmeldung): eigenes background-color entfernt - Merle moechte
   inaktive Tabs ohne Hintergrund, genau wie die unausgewaehlten
   Produktkarten/Box-Auswahl-Kacheln. */
.gbbCategoryTabContainer {
  margin-top: 2em;
  /* NEU (Round 27, 7. Feedback-Batch): Merles exakter Wert, gegen das
     weiterhin leichte Anschneiden unten (zusaetzlich zum bereits
     dokumentierten, technisch nicht loesbaren grid-template-rows-Limit,
     siehe Abschnitt 69 weiter unten - dieser margin-bottom ist ein
     zusaetzlicher, unabhaengiger Hebel, kein Ersatz dafuer). */
  margin-bottom: 0.3em;
  border-radius: 0.5em;
  transition:
    background-color 0.3s ease,
    color 0.3s ease,
    outline-color 0.3s ease;
}
/* Textfarbe im Tab */
.gbbCategoryTabContainer .gbbCategoryTabTitle {
  color: var(--pv-green-dark);
  transition: color 0.3s ease;
}
/* Look des AKTIVEN Tabs: jetzt derselbe "minimal dunkleres Gruen + zarte
   dunkle Kontur"-Look wie die ausgewaehlten Produktkarten/Box-Auswahl-
   Kacheln (vereinheitlicht, Round 26, 5. Feedback-Batch - ersetzt das
   bisherige dunkelgruene background-color:var(--pv-green-dark)). */
.gbbCategoryTabContainer[data-is-active="true"] {
  background-color: #d9edbe !important;
  outline: 1.5px solid #748c7b !important;
}
/* Textfarbe im aktiven Tab: musste von hell (#e3f3c6, fuer den fruehereren
   dunkelgruenen Hintergrund gedacht) auf dunkel umgestellt werden - sonst
   waere die Schrift auf dem neuen HELLEN Hintergrund (#d9edbe) unlesbar
   geworden. Das ist keine geratene Zusatzaenderung, sondern eine zwingende
   Folge der Hintergrund-Aenderung selbst. */
.gbbCategoryTabContainer[data-is-active="true"] .gbbCategoryTabTitle {
  color: var(--pv-green-dark, #143c1f) !important;
  /* NEU (Round 27, 3. Batch): aktiver Tab bleibt fett (siehe direkt unten -
     der native Font-Weight ist hier ohnehin schon 700, live bestaetigt, nur
     zur Klarheit explizit gesetzt, damit die neue "light"-Regel fuer
     inaktive Tabs ihn sicher nicht versehentlich mittrifft). */
  font-weight: 700 !important;
}
/* NEU (Round 27, 3. Batch): Merle zeigte per Screenshot eine native Regel
   (font-weight:300, letter-spacing:0.03), die laut ihr "auf dem Screenshot
   nicht stimmt" - live bestaetigt: diese native Regel gewinnt aktuell gar
   nicht, alle Tabs (aktiv UND inaktiv) sind tatsaechlich 700/normal. Merles
   eigentlicher Wunsch: NUR die inaktiven Tabs bekommen die zartere Schrift +
   minimales Letter-Spacing, der aktive bleibt fett (siehe Regel oben). */
.gbbCategoryTabContainer:not([data-is-active="true"]) .gbbCategoryTabTitle {
  font-weight: 300 !important;
  letter-spacing: 0.03em !important;
}
/* Merle "Desktop: Gap der Kategorie-Tabs 0.4rem" (bisher nativ 32px, live
   gemessen) + "oben/unten wird abgeschnitten, Padding etwas kleiner machen"
   (nativ 10px/10px, live gemessen - Container hat dieselbe Hoehe wie seine
   Tabs, dadurch kann z. B. der Hover-Scale-Effekt ueber den Rand hinaus
   abgeschnitten werden). Padding-Reduzierung ist eine Schaetzung (10px->8px),
   bitte live gegenchecken, ob das reicht - Merle vermutet selbst, dass bei
   Hover trotzdem noch leicht angeschnitten wird. */
@media screen and (min-width: 750px) {
  body .gbbCategoriesTabsContainer {
    gap: 0.4rem !important;
  }
  /* KORREKTUR (Round 27, 5. Batch): Merle "Tabs immer noch unten
     angeschnitten". Root-Cause-Update: der Tab-Reihen-Container
     (.gbbCategoriesTabsContainer) hat eine feste, nativ per JS EINMALIG
     beim Laden gemessene Zeilenhoehe (grid-template-rows, live gemessen
     70.3984px) - reagiert NICHT auf nachtraegliche CSS-Aenderungen (live
     bestaetigt: weder !important auf grid-template-rows/min-height noch auf
     overflow-y aendert daran etwas, nur direkter JS-Zugriff wirkt). Live
     gemessen: scrollHeight (72px) liegt 2px ueber clientHeight (70px) -
     das reicht fuer das verbleibende Anschneiden. Da die Zeilenhoehe selbst
     nicht beeinflussbar ist, bleibt nur der Hebel "Tab-Inhalt kompakter
     machen, damit er sicher unter die 70px-Grenze passt" - Padding nochmal
     etwas reduziert.
     EINSCHRAENKUNG: weil die native Komponente ihre Zeilenhoehe nur beim
     Laden misst (nicht danach neu), kann ich diesen Fix in meiner Sandbox
     nicht zuverlaessig verifizieren (meine Live-Tests spielen CSS immer
     NACH dem bereits erfolgten Laden ein) - bitte nach dem Einspielen
     live gegenchecken, ob das Anschneiden jetzt weg ist. */
  body .gbbCategoryTabContainer {
    padding-block: 6px !important; /* war 8px */
  }
}
/* Theme-eigen: Grund-Reset fuer <dialog>-Elemente */
dialog {
  /* the ::backdrop inherits from the originating element, custom
properties must be set on the dialog element */
  --backdrop-color-rgb: var(--color-shadow-rgb);
  background-color: var(--color-background);
  color: var(--color-foreground);
}
/*
Alle Gerichte Filterseiten
*/
/* ACHTUNG: "color: red" wirkt wie eine Test-/Debug-Markierung, keine fertige
   Gestaltung - vermutlich noch offen, pruefen ob das so gewollt ist */
#Filter-filter-p-m-custom-suchfilter_ernahrung-1-vertical- {
  color: red;
}
/* Auskommentierte Testregel, aktuell nicht aktiv (h1-Groesse im Hero) - unten
   als Kommentar stehen gelassen als Backup */
/**#shopify-section-template--31616257655114__hero_jVaWmY h1 {
font-size: 120px !important;
}**/
/* Theme-eigen: verhindert, dass lange Woerter das Layout sprengen */
p,
h1,
h2,
h3,
h4,
h5,
h6 {
  overflow-wrap: break-word;
}


/*Neue Größen für die die Schriften  vereinheitlichen in anderen px Achritten als */


h3{
  font-size: 2.1vw !important;
}

h4{
 font-size: 1.55vw !important;
}


h5{
  font-size: 1.8vw !important;
}

/* h6 { font-size: 1.6vw !important; } entfernt (h6 zu gross auf
   Startseite/Gutschein-Seite). War unscoped, machte jedes nackte h6 auf
   Desktop zu gross (Abschnitt 45). "Dein Energiekick fuer den Tag" bleibt
   ueber eine eigene Regel (Abschnitt 36, Punkt 7) unveraendert groesser, der
   Mobil-Fall war ohnehin schon per clamp()-Regel abgesichert. */



/* Zwei Debug-Regeln entfernt (roter Outline auf fett Gedrucktem + roter
   Hintergrund auf rte-formatter-Text in Karussell-Slides) - sahen nach
   vergessenem Debug-Code aus, griffen aktuell nirgends sichtbar, wurden aber
   sicherheitshalber entfernt. */

/* Schrift fuer alle Ueberschriften */
h1,
h2,
h3,
h4,
h5,
h6 {
  font-family: "co-headline", sans-serif;
}
/* Schrift fuer Fliesstext/Buttons/Links */
body,
p,
a,
button {
  font-family: "co-text", sans-serif;
}
/* Theme-eigene Hilfsklasse: bricht lange Woerter/URLs sauber um */
.wrap-text {
  overflow-wrap: break-word;
  word-break: break-word;
  hyphens: auto;
}


/*FAQ Seite Main Div rand links rechts*/
#shopify-section-template--32144613540170__section_WkeCN8{
  margin-left: 4vw;
  margin-right: 4vw;
}

/* NEU (Round 27, 2. Batch): Gutschein-Seite "linksbuendig, in derselben
   Breite wie die FAQ-Seite" (nicht die volle, native "page-width"-Breite).
   Live geprueft: der eigentliche Text auf der Gutschein-Seite ist bereits
   text-align:left (keine Textausrichtung zu aendern) - "nicht linksbuendig"
   bezog sich also auf den Container selbst, der bisher ueber die native
   "section--page-width"-Klasse (max-width:95%, zentrierende Margins)
   deutlich breiter war als die FAQ-Seite. Hier exakt dieselbe Technik wie
   bei der FAQ-Seite oben uebernommen (margin-left/right:4vw) - dadurch
   automatisch dieselbe Breite. HINWEIS: das ergibt rechnerisch denselben
   gleich grossen Rand links/rechts wie bei der FAQ-Seite selbst (die ist
   also auch nicht "an die Kante gedrueckt", sondern nur schmaler als die
   native Page-Width) - falls dir ein wirklich ASYMMETRISCHER Rand
   vorschwebt (mehr Luft rechts als links), sag kurz Bescheid, dann stelle
   ich das gezielt um. Gilt fuer beide Sections dieser Seite (Banner +
   Gutschein-Raster), per Attribut-Selektor automatisch beide erfasst. */
[id^="shopify-section-template--32323933831498"] .section--page-width {
  max-width: none !important;
  margin-left: 4vw !important;
  margin-right: 4vw !important;
}


/* ================================================================ AB HIER:
   Shopify Horizon Theme-eigenes CSS. Kommt mit dem Theme mit - hier bitte
   nichts routinemaessig anfassen, das betrifft nicht unsere eigenen
   Anpassungen.
   ================================================================ */
p:empty {
  display: none;
}
h6 {
  font-weight: bold;
}
:first-child:is(p, h1, h2, h3, h4, h5, h6),
:first-child:empty + :where(p, h1, h2, h3, h4, h5, h6) {
  margin-block-start: 0;
}
/* Remove bottom margin from last text item, or previous to last if the
last is empty */
:last-child:is(p, h1, h2, h3, h4, h5, h6),
:where(p, h1, h2, h3, h4, h5, h6):nth-child(2):has(+ :last-child:empty) {
  margin-block-end: 0;
}
/* view transitions */
/* * The cross-document (MPA) opt-in `@view-transition { navigation: auto }`
   is declared per-layout (theme.liquid / password.liquid), since this
   stylesheet is shared by both and can't read theme settings there. * Gated
   on the same condition as the render blocker, so opt-in and opt-out can't
   disagree. The rules below are inert unless that opt-in is active. */
@media (prefers-reduced-motion: no-preference) {
  /* Keep page interactive while view transitions are running */
  :root {
    view-transition-name: none;
  }
  /* Have the root transition during page navigation */
  html:active-view-transition-type(page-navigation),
  html:active-view-transition-type(product-image-transition) {
    view-transition-name: root-custom;
  }
  ::view-transition {
    pointer-events: none;
  }
  html:active-view-transition-type(page-navigation)
    main[data-page-transition-enabled="true"] {
    view-transition-name: main-content;
  }
  html:active-view-transition-type(page-navigation)
    main[data-product-transition="true"][data-template*="product"] {
    view-transition-name: none;
  }
  ::view-transition-old(main-content) {
    animation: var(--view-transition-old-main-content);
  }
  ::view-transition-new(main-content) {
    animation: var(--view-transition-new-main-content);
  }
  html:active-view-transition-type(product-image-transition) {
    [data-view-transition-type="product-image-transition"] {
      view-transition-name: product-image-transition;
    }
    [data-view-transition-type="product-details"] {
      view-transition-name: product-details;
    }
  }
  ::view-transition-group(product-image-transition) {
    z-index: 1;
  }
  ::view-transition-group(product-image-transition),
  ::view-transition-group(product-details) {
    animation-duration: var(--animation-speed);
    animation-timing-function: var(--animation-easing);
  }
  ::view-transition-old(product-image-transition),
  ::view-transition-new(product-image-transition) {
    block-size: 100%;
    overflow: hidden;
    object-fit: cover;
    animation-duration: 0.25s;
    animation-timing-function: var(--animation-easing);
  }
  ::view-transition-new(product-details) {
    animation: var(--view-transition-new-main-content);
  }
}
/* Focus */
*:focus-visible {
  outline: var(--focus-outline-width) solid currentcolor;
  outline-offset: var(--focus-outline-offset);
}
@supports not selector(:focus-visible) {
  *:focus {
    outline: var(--focus-outline-width) solid currentcolor;
    outline-offset: var(--focus-outline-offset);
  }
}
.focus-inset {
  outline-offset: calc(var(--focus-outline-width) * -1);
}
/* Layout */
.content-for-layout {
  flex: 1;
  display: flex;
  flex-direction: column;
}
.content-for-layout > .shopify-section:last-child {
  flex-grow: 1;
}
/* Set up page widths & margins */
.page-width-wide,
.page-width-normal,
.page-width-narrow,
.page-width-content {
  --page-margin: 16px;
}
@media screen and (min-width: 750px) {
  .page-width-wide,
  .page-width-normal,
  .page-width-narrow,
  .page-width-content {
    --page-margin: 40px;
  }
}
.page-width-wide {
  /* NOTE: This results in a page width of 2400px because of how we set up
margins with grid */
  --page-content-width: var(--wide-page-width);
  --page-width: calc(var(--page-content-width) + (var(--page-margin) * 2));
}
.page-width-normal {
  --page-content-width: var(--normal-page-width);
  --page-width: calc(var(--page-content-width) + (var(--page-margin) * 2));
}
.page-width-narrow,
.page-width-content {
  /* NOTE: This results in a page width of 1400px because of how we set up
margins with grid */
  --page-content-width: var(--narrow-page-width);
  --page-width: calc(var(--page-content-width) + (var(--page-margin) * 2));
}
.page-width-content {
  --page-content-width: var(--normal-content-width);
  --page-width: calc(var(--page-content-width) + (var(--page-margin) * 2));
}
/* Section width full vs. page The reason we use a grid to contain the section
   is to allow for the section to have a full-width background image even if
   the section content is constrained by the page width. Do not try to rewrite
   this to max-width: --page-width; margin: 0 auto;, it doesn't work. */
.section {
  --full-page-grid-central-column-width: min(
    var(--page-width) - var(--page-margin) * 2,
    calc(100% - var(--page-margin) * 2)
  );
  --full-page-grid-margin: minmax(var(--page-margin), 1fr);
  --full-page-grid-with-margins: var(--full-page-grid-margin)
    var(--full-page-grid-central-column-width) var(--full-page-grid-margin);
  /* Utility variable gives the grid's first column width. Provides an
offset width for components like carousels */
  --util-page-margin-offset: max(
    var(--page-margin),
    calc(
      (100% - min(var(--page-content-width), 100% - var(--page-margin) * 2)) / 2
    )
  );
  width: 100%;
  /* This is required to make background images work, which are <img>
rendered absolutely */
  position: relative;
  /* Set up the grid */
  display: grid;
  grid-template-columns: var(--full-page-grid-with-margins);
  min-height: var(--section-min-height, "auto");
}
/* Place all direct children in the center column by default */
.section > * {
  grid-column: 2;
}
/* Make the actual section background transparent, and instead apply it to a
   separate sibling element to enable stacking with hero shadow */
.shopify-section:not(.header-section) :is(.section, .cart-summary) {
  background: transparent;
}
.shopify-section:not(.header-section):has(.section) {
  position: relative;
}
.shopify-section:not(.header-section) .section-background {
  content: "";
  position: absolute;
  inset: 0;
  z-index: var(--layer-section-background);
  background-color: var(--color-background);
}
/* For page-width sections, all content goes in the center column */
.section--page-width > * {
  grid-column: 2;
}
/* For full-width sections, content spans all columns */
.section--full-width > * {
  grid-column: 1 / -1;
}
@media screen and (max-width: 749px) {
  .section--mobile-full-width > * {
    grid-column: 1 / -1;
  }
}
/* Some page-width sections should still extend all the way to the right
edge of the page, e.g. collection carousel */
.section--page-width.section--full-width-right > * {
  grid-column: 2 / 4;
}
/* For full-width sections with margin, content still spans full width
but with space on the sides */
.section--full-width.section--full-width-margin > * {
  grid-column: 1 / -1;
  @media screen and (min-width: 750px) {
    padding-left: var(--page-margin);
    padding-right: var(--page-margin);
  }
}
/* Some section content break out to full width of the page */
.section > .force-full-width {
  grid-column: 1 / -1;
}
.section--height-small {
  --section-min-height: var(--section-height-small);
}
.section--height-medium {
  --section-min-height: var(--section-height-medium);
}
.section--height-large {
  --section-min-height: var(--section-height-large);
}
.section--height-full-screen {
  --section-min-height: 100svh;
}
.section-content-wrapper.section-content-wrapper {
  min-height: calc(
    var(--section-min-height, "auto") - var(--section-height-offset, 0px)
  );
  position: relative;
  width: 100%;
  height: 100%;
}
/* Utility */
.hidden {
  /* stylelint-disable-next-line declaration-no-important */
  display: none !important;
}
@media screen and (max-width: 749px) {
  .hidden--mobile,
  .mobile\:hidden {
    /* stylelint-disable-next-line declaration-no-important */
    display: none !important;
  }
}
@media screen and (min-width: 750px) {
  .hidden--desktop,
  .desktop\:hidden {
    /* stylelint-disable-next-line declaration-no-important */
    display: none !important;
  }
}
.hide-when-empty:empty {
  /* stylelint-disable-next-line declaration-no-important */
  display: none !important;
}
.visually-hidden:not(:focus, :active) {
  /* stylelint-disable-next-line declaration-no-important */
  position: absolute !important;
  overflow: hidden;
  width: 1px;
  height: 1px;
  margin: -1px;
  padding: 0;
  border: 0;
  clip: rect(0 0 0 0);
  /* stylelint-disable-next-line declaration-no-important */
  word-wrap: normal !important;
}
.contents {
  display: contents;
}
.flex {
  display: flex;
  gap: var(--gap-md);
}
.grid {
  --centered-column-number: 12;
  --full-width-column-number: 14;
  --centered: column-1 / span var(--centered-column-number);
  --full-width: column-0 / span var(--full-width-column-number);
  display: flex;
  flex-direction: column;
}
@media screen and (min-width: 750px) {
  .grid {
    display: grid;
    gap: 0;
    grid-template-columns:
      var(--margin-4xl)
      repeat(var(--centered-column-number), minmax(0, 1fr)) var(--margin-4xl);
    grid-template-areas: "column-0 column-1 column-2 column-3 column-4 column-5 column-6 column-7 column-8 column-9 column-10 column-11 column-12 column-13";
  }
}
@media screen and (min-width: 1400px) {
  .grid {
    grid-template-columns:
      1fr repeat(
        var(--centered-column-number),
        minmax(
          0,
          calc(
            (var(--page-width) - var(--page-margin) * 2) /
              var(--centered-column-number)
          )
        )
      )
      1fr;
  }
}
.flex {
  display: flex;
  gap: var(--gap-md);
}
.flip-x {
  scale: -1 1;
}
.flip-y {
  scale: 1 -1;
}
.list-unstyled {
  margin: 0;
  padding: 0;
  list-style: none;
}
.text-left {
  --text-align: left;
  text-align: left;
}
.text-center {
  --text-align: center;
  text-align: center;
}
.text-right {
  --text-align: right;
  text-align: right;
}
.text-inherit {
  color: inherit;
}
.user-select-text {
  user-select: text;
}
.justify-left {
  justify-content: left;
}
.justify-center {
  justify-content: center;
}
.justify-right {
  justify-content: right;
}
.title--aligned-center {
  display: flex;
  align-items: center;
  gap: 1rem;
}
.svg-wrapper {
  color: currentcolor;
  display: inline-flex;
  justify-content: center;
  align-items: center;
  width: var(--icon-size-sm);
  height: var(--icon-size-sm);
  pointer-events: none;
}
.svg-wrapper--smaller {
  width: var(--icon-size-2xs);
  height: var(--icon-size-2xs);
}
.svg-wrapper--small {
  width: var(--icon-size-xs);
  height: var(--icon-size-xs);
}
.svg-wrapper > svg {
  width: var(--icon-size-sm);
  height: var(--icon-size-sm);
}
.relative {
  position: relative;
}
/* Icons */
.icon-success,
.icon-error {
  width: var(--icon-size-md);
  height: var(--icon-size-md);
  flex-shrink: 0;
}
.icon-success {
  color: var(--color-success);
}
.icon-error {
  fill: var(--color-error);
}
.icon-default {
  fill: currentColor;
}
[data-placeholder="true"] * {
  cursor: default;
}
/* Base text and heading styles */
body,
.paragraph:not(.button),
.paragraph > *,
.text-block.paragraph :is(h1, h2, h3, h4, h5, h6) {
  font-family: "co-text", sans-serif;
  font-style: var(--font-paragraph--style);
  font-weight: var(--font-paragraph--weight);
  font-size: var(--font-paragraph--size);
  line-height: var(--font-paragraph--line-height);
  text-transform: var(--font-paragraph--case);
  -webkit-font-smoothing: antialiased;
  color: var(--color, var(--color-foreground));
}
.header-logo,
.header-menu a {
  font-family: "co-text", sans-serif !important;
}
/* Ensure inputs with type presets maintain minimum 16px on mobile to
prevent iOS zoom */
@media screen and (max-width: 1200px) {
  input.paragraph.paragraph,
  input.paragraph.paragraph:not([type]),
  textarea.paragraph.paragraph,
  select.paragraph.paragraph {
    font-size: max(1rem, var(--font-paragraph--size));
  }
}
.paragraph > small {
  font-size: smaller;
}
/* Typography presets */
h1,
.h1.h1,
.text-block.h1 > *,
.text-block.h1 :is(h1, h2, h3, h4, h5, h6) {
  font-family: "co-headline";
  font-style: var(--font-h1--style);
  font-weight: var(--font-h1--weight);
  font-size: var(--font-h1--size);
  line-height: var(--font-h1--line-height);
  letter-spacing: var(--font-h1--letter-spacing);
  text-transform: var(--font-h1--case);
  color: var(--color);
}
@media screen and (max-width: 1200px) {
  input.h1.h1,
  textarea.h1.h1,
  select.h1.h1 {
    font-size: max(1rem, var(--font-h1--size));
  }
}
/* h2, .h2.h2, .text-block.h2 > *, .text-block.h2 :is(h1, h2, h3, h4, h5, h6)
   { font-family: var(--font-h2--family); font-style: var(--font-h2--style);
   font-weight: var(--font-h2--weight); font-size: var(--font-h2--size); line-
   height: var(--font-h2--line-height); letter-spacing: var(--font-h2--letter-
   spacing); text-transform: var(--font-h2--case); color: var(--color); } */
h2,
.h2.h2,
.text-block.h2 > *,
.text-block.h2 :is(h1, h2, h3, h4, h5, h6) {
  font-family: "co-headline";
  font-style: var(--font-h2--style);
  font-weight: var(--font-h2--weight);
  font-size: var(--font-h2--size);
  line-height: var(--font-h2--line-height);
  letter-spacing: var(--font-h2--letter-spacing);
  text-transform: var(--font-h2--case);
  color: var(--color);
}
@media screen and (max-width: 1200px) {
  input.h2.h2,
  textarea.h2.h2,
  select.h2.h2 {
    font-size: max(1rem, var(--font-h2--size));
  }
}
h3,
.h3,
.h3.h3,
.text-block.h3 > *,
.text-block.h3 :is(h1, h2, h3, h4, h5, h6) {
  font-family: "co-headline";
  font-style: var(--font-h3--style);
  font-weight: var(--font-h3--weight);
  font-size: var(--font-h3--size);
  line-height: var(--font-h3--line-height);
  letter-spacing: var(--font-h3--letter-spacing);
  text-transform: var(--font-h3--case);
  color: var(--color);
}
@media screen and (max-width: 1200px) {
  input.h3,
  textarea.h3,
  select.h3 {
    font-size: max(1rem, var(--font-h3--size));
  }
}
h4,
.h4.h4,
.text-block.h4 > *,
.text-block.h4 :is(h1, h2, h3, h4, h5, h6) {
  font-family: "co-headline";
  font-style: var(--font-h4--style);
  font-weight: var(--font-h4--weight);
  font-size: var(--font-h4--size);
  line-height: var(--font-h4--line-height);
  letter-spacing: var(--font-h4--letter-spacing);
  text-transform: var(--font-h4--case);
  color: var(--color);
}
@media screen and (max-width: 1200px) {
  input.h4.h4,
  textarea.h4.h4,
  select.h4.h4 {
    font-size: max(1rem, var(--font-h4--size));
  }
}
h5,
.h5.h5,
.text-block.h5 > *,
.text-block.h5 :is(h1, h2, h3, h4, h5, h6) {
  font-family: "co-headline", sans-serif;
  font-style: var(--font-h5--style);
  font-weight: var(--font-h5--weight);
  font-size: var(--font-h5--size);
  line-height: var(--font-h5--line-height);
  letter-spacing: var(--font-h5--letter-spacing);
  text-transform: var(--font-h5--case);
  color: var(--color);
}
@media screen and (max-width: 1200px) {
  input.h5.h5,
  textarea.h5.h5,
  select.h5.h5 {
    font-size: max(1rem, var(--font-h5--size));
  }
}
h6,
.h6.h6,
.text-block.h6 > *,
.text-block.h6 :is(h1, h2, h3, h4, h5, h6) {
  font-family: "co-headline";
  font-style: var(--font-h6--style);
  font-weight: var(--font-h6--weight);
  font-size: var(--font-h6--size);
  line-height: var(--font-h6--line-height);
  letter-spacing: var(--font-h6--letter-spacing);
  text-transform: var(--font-h6--case);
  color: var(--color);
}
@media screen and (max-width: 1200px) {
  input.h6.h6,
  textarea.h6.h6,
  select.h6.h6 {
    font-size: max(1rem, var(--font-h6--size));
  }
}
:first-child:is(.h1, .h2, .h3, .h4, .h5, .h6) {
  margin-block-start: 0;
}
:last-child:is(.h1, .h2, .h3, .h4, .h5, .h6) {
  margin-block-end: 0;
}
/* Links */
a {
  color: currentcolor;
  text-decoration-color: transparent;
  text-decoration-thickness: 0.075em;
  text-underline-offset: 0.125em;
  transition:
    text-decoration-color var(--animation-speed) var(--animation-easing),
    color var(--animation-speed) var(--animation-easing);
}
:is(h1, h2, h3, h4, h5, h6, p) > a:hover {
  color: rgb(var(--color-rgb, var(--color-foreground-rgb)) / 0.7);
}
/* Add underline to text using our paragraph styles only. */
p:not(.h1, .h2, .h3, .h4, .h5, .h6) a:where(:not(.button, .button-secondary)),
.rte
  :is(p, ul, ol, table):not(.h1, .h2, .h3, .h4, .h5, .h6)
  a:where(:not(.button, .button-secondary)) {
  text-decoration-color: currentcolor;
  &:hover {
    text-decoration-color: currentcolor;
    color: rgb(var(--color-rgb, var(--color-foreground-rgb)) / 0.7);
  }
}
.container-background-image {
  background-repeat: no-repeat;
  background-size: cover;
  background-position: center center;
}
/* iOS fix: hide the default arrow on the summary */
summary::-webkit-details-marker {
  display: none;
}
/* Buttons */
.button,
.button-secondary,
.button-custom,
button.shopify-payment-button__button--unbranded {
  --text-align: center;
  display: grid;
  align-content: center;
  text-decoration: none;
  text-align: var(--text-align);
  color: var(--button-color);
  appearance: none;
  background-color: var(--button-background-color);
  border: none;
  font-family: "co-text", sans-serif;
  font-style: var(--font-paragraph--style);
  font-weight: var(--font-paragraph--weight);
  font-size: var(--font-paragraph--size);
  line-height: var(--font-paragraph--line-height);
  margin-block: 0;
  transition:
    color var(--animation-speed) var(--animation-easing),
    box-shadow var(--animation-speed) var(--animation-easing),
    background-color var(--animation-speed) var(--animation-easing);
  cursor: pointer;
  width: fit-content;
  box-shadow: inset 0 0 0 var(--button-border-width) var(--button-border-color);
  padding-block: var(--button-padding-block);
  padding-inline: var(--button-padding-inline);
}
.button {
  font-family: "co-text", sans-serif;
  text-transform: var(--button-text-case-primary);
  border-radius: var(--style-border-radius-buttons-primary);
}
.button:not(.button-secondary, .button-unstyled) {
  outline-color: var(
    --button-focus-outline-color,
    var(--button-background-color)
  );
}
.button-secondary {
  font-family: "co-text", sans-serif;
  text-transform: var(--button-text-case-secondary);
  border-radius: var(--style-border-radius-buttons-secondary);
}
button.shopify-payment-button__button--unbranded {
  font-family: "co-text", sans-serif;
  text-transform: var(--button-text-case-primary);
}
textarea,
input:not([type="checkbox"], [type="radio"]) {
  background-color: var(--color-input-background);
  border-color: var(--color-input-border);
}
textarea::placeholder,
input::placeholder {
  color: rgb(var(--color-input-text-rgb) / var(--opacity-muted-text));
}
textarea:not(:placeholder-shown)::placeholder,
input:not(:placeholder-shown)::placeholder {
  opacity: 0;
}
/* The declaration above is messing with buttons that have an attribute
of hidden as it overwrites the display value */
.button[hidden] {
  display: none;
}
.button[aria-disabled="true"],
.button-secondary[aria-disabled="true"],
.button:disabled {
  opacity: 0.5;
  cursor: not-allowed;
}
.button,
button.shopify-payment-button__button--unbranded {
  --button-color: var(--color-primary-button-text);
  --button-background-color: var(--color-primary-button-background);
  --button-border-color: var(--color-primary-button-border);
  --button-border-width: var(--style-border-width-primary);
  --button-focus-outline-color: var(--color-primary-button-focus-outline);
}
.button:hover,
button.shopify-payment-button__button--unbranded:hover:not([disabled]) {
  --button-color: var(--color-primary-button-hover-text);
  --button-background-color: var(--color-primary-button-hover-background);
  --button-border-color: var(--color-primary-button-hover-border);
}
.button-secondary {
  --button-color: var(--color-secondary-button-text);
  --button-background-color: var(--color-secondary-button-background);
  --button-border-color: var(--color-secondary-button-border);
  --button-border-width: var(--style-border-width-secondary);
}
.button-secondary:hover {
  --button-color: var(--color-secondary-button-hover-text);
  --button-background-color: var(--color-secondary-button-hover-background);
  --button-border-color: var(--color-secondary-button-hover-border);
}
.button-custom {
  --button-color: var(--color-primary-button-text);
  --button-background-color: var(--color-primary-button-background);
  --button-border-color: var(--color-primary-button-border);
  --button-border-width: var(--style-border-width-secondary);
  --button-focus-outline-color: var(--color-primary-button-focus-outline);
  font-family: "co-text", sans-serif;
  text-transform: var(--button-text-case-primary);
  border-radius: var(--style-border-radius-buttons-primary);
  outline-color: var(
    --button-focus-outline-color,
    var(--button-background-color)
  );
}
.button-custom:hover {
  --button-color: var(--color-primary-button-hover-text);
  --button-background-color: var(--color-primary-button-hover-background);
  --button-border-color: var(--color-primary-button-hover-border);
}
/* Needed to override the default Shopify styles */
button.shopify-payment-button__button--unbranded:hover:not([disabled]) {
  background-color: var(--button-background-color);
}
.button-unstyled {
  display: block;
  padding: 0;
  background-color: inherit;
  color: var(--color-foreground);
  border: 0;
  border-radius: 0;
  overflow: hidden;
  box-shadow: none;
  font-family: "co-text", sans-serif;
  font-style: var(--font-paragraph--style);
  font-size: var(--font-paragraph--size);
}
.button-unstyled:hover {
  background-color: inherit;
}
/* Default hover dim for link-style buttons, scoped via :where() so component-
   specific hover rules (.facets__clear-all-link, .header-actions__action,
   etc.) still win. */
:where(.button-unstyled):hover {
  --hover-color-rgb: var(--color-foreground-rgb);
  color: rgb(var(--hover-color-rgb) / var(--opacity-70));
}
.button-unstyled--with-icon {
  color: var(--color-foreground);
  display: flex;
  gap: var(--gap-2xs);
  align-items: center;
}
.button-unstyled--transparent {
  background-color: transparent;
  box-shadow: none;
}
/* Caret icon transition */
.icon-caret svg {
  transition: transform var(--animation-speed) var(--animation-easing);
}
summary {
  display: flex;
  align-items: center;
  cursor: pointer;
  list-style: none;
  padding-block: var(--padding-sm);
}
summary:hover {
  color: rgb(var(--color-foreground-rgb) / var(--opacity-80));
}
/* Animate the UI elements in only after the view transition is complete
*/
.close-button {
  position: fixed;
  top: var(--margin-lg);
  right: var(--margin-lg);
  width: var(--minimum-touch-target);
  height: var(--minimum-touch-target);
  z-index: var(--layer-flat);
  background-color: transparent;
  display: flex;
  align-items: center;
  justify-content: center;
  /* For the outline radius */
  border-radius: 50%;
}
/* This triggers iOS < 16.4. The outline bug is not recognized as a lack
of @supports */
@supports not (background-color: rgb(from red 150 g b / alpha)) {
  /* * There is a bug in safari < 16.4 that causes the outline to not follow
     the elements border radius. This is a workaround. Using element selector
     to increase specificity. * */
  .close-button:focus-visible {
    outline: none;
    overflow: visible;
  }
  .close-button:focus-visible::after {
    content: "";
    position: absolute;
    inset: calc(-1 * var(--focus-outline-offset));
    border: var(--focus-outline-width) solid currentColor;
    border-radius: 50%;
    display: inherit;
  }
}
.dialog--closed .close-button {
  animation: elementSlideOutBottom calc(var(--animation-speed) * 0.5)
    var(--animation-easing) forwards;
}
.close-button:hover {
  background-color: transparent;
  opacity: 0.8;
}
.close-button svg {
  width: var(--icon-size-xs);
  height: var(--icon-size-xs);
}
/* Product media */
.product-media {
  display: flex;
  flex: 1;
}
.sticky-content {
  position: sticky;
  top: var(--sticky-header-offset, 0);
  z-index: var(--layer-flat);
}
@media screen and (min-width: 750px) {
  .sticky-content--desktop,
  .sticky-content--desktop.full-height--desktop > .group-block {
    position: sticky;
    top: var(--sticky-header-offset, 0);
    z-index: var(--layer-flat);
  }
}
/* Spacing style */
.spacing-style {
  --spacing-scale: var(--spacing-scale-md);
  @media screen and (min-width: 990px) {
    --spacing-scale: var(--spacing-scale-default);
  }
  /* Must disable this, when you use these with calc and another unit
type, things break — see logo.liquid */
  /* stylelint-disable length-zero-no-unit */
  --padding-block: 0px;
  --padding-block-start: var(--padding-block, 0px);
  --padding-block-end: var(--padding-block, 0px);
  --padding-inline: 0px;
  --padding-inline-start: var(--padding-inline, 0px);
  --padding-inline-end: var(--padding-inline, 0px);
  --margin-block: 0px;
  --margin-block-start: var(--margin-block, 0px);
  --margin-block-end: var(--margin-block, 0px);
  --margin-inline: 0px;
  --margin-inline-start: var(--margin-inline, 0px);
  --margin-inline-end: var(--margin-inline, 0px);
}
.spacing-style,
.inherit-spacing {
  padding-block: calc(
      var(--padding-block-start) + var(--section-top-offset, 0px)
    )
    var(--padding-block-end);
  padding-inline: var(--padding-inline-start) var(--padding-inline-end);
  margin-block: var(--margin-block-start) var(--margin-block-end);
  margin-inline: var(--margin-inline-start) var(--margin-inline-end);
}
/* Size style */
.size-style {
  width: var(--size-style-width-mobile, var(--size-style-width));
  height: var(--size-style-height-mobile, var(--size-style-height));
  @media screen and (min-width: 750px) {
    width: var(--size-style-width);
    height: var(--size-style-height);
  }
}
/* Custom Typography style */
.custom-typography,
.custom-typography > * {
  font-family: var(--font-family);
  font-weight: var(--font-weight);
  text-transform: var(--text-transform);
  text-wrap: var(--text-wrap);
  line-height: var(--line-height);
  letter-spacing: var(--letter-spacing);
}
.custom-typography {
  h1 {
    line-height: var(--line-height--display, var(--line-height));
  }
  h2,
  h3,
  h4 {
    line-height: var(--line-height--heading, var(--line-height));
  }
  p {
    line-height: var(--line-height--body, var(--line-height));
  }
}
.custom-font-size,
.custom-font-size > * {
  font-size: var(--font-size);
}
.custom-font-weight,
.custom-font-weight > * {
  font-weight: var(--font-weight);
}
/* Border override style */
.border-style {
  border-width: var(--border-width);
  border-style: var(--border-style);
  border-color: var(--border-color);
  border-radius: var(--border-radius);
}
/* Gap scaling style */
.gap-style,
.layout-panel-flex {
  --gap-scale: var(--spacing-scale-md);
  @media screen and (min-width: 990px) {
    --gap-scale: var(--spacing-scale-default);
  }
}
.layout-panel-flex {
  display: flex;
  gap: var(--gap);
  height: 100%;
}
.shopify-block:has(> [shopify-block-empty]) {
  display: none;
}
.layout-panel-flex--row {
  flex-flow: row var(--flex-wrap);
  justify-content: var(--horizontal-alignment);
  align-items: var(--vertical-alignment);
}
.layout-panel-flex--column {
  flex-flow: column var(--flex-wrap);
  align-items: var(--horizontal-alignment);
  justify-content: var(--vertical-alignment);
}
@media screen and (max-width: 749px) {
  .mobile-column {
    flex-flow: column nowrap;
    align-items: var(--horizontal-alignment);
    justify-content: var(--vertical-alignment-mobile);
  }
  .layout-panel-flex--row:not(.mobile-column) {
    flex-wrap: var(--flex-wrap-mobile);
    height: auto;
    > .menu {
      flex: 1 1 min-content;
    }
    > .text-block {
      flex: 1 1 var(--max-width--display-tight);
    }
    > .image-block {
      flex: 1 1 var(--size-style-width-mobile-min);
    }
    > .button {
      flex: 0 0 fit-content;
    }
    > .group-block--height-fill {
      height: calc(
        var(--section-min-height, auto) - var(--section-height-offset, 0px)
      );
    }
  }
}
@media screen and (min-width: 750px) {
  .layout-panel-flex {
    flex-direction: var(--flex-direction);
  }
}
/* Form fields */
.field {
  position: relative;
  width: 100%;
  display: flex;
  transition: box-shadow var(--animation-speed) ease;
}
.field__input {
  flex-grow: 1;
  text-align: left;
  border-radius: var(--style-border-radius-inputs);
  transition:
    box-shadow var(--animation-speed) ease,
    background-color var(--animation-speed) ease;
  padding: var(--input-padding);
  box-shadow: var(--input-box-shadow);
  background-color: var(--color-input-background);
  color: var(--color-input-text);
  border: none;
  outline: none;
  font-size: var(--font-paragraph--size);
  &:autofill {
    background-color: var(--color-input-background);
    color: var(--color-input-text);
  }
}
.field__input:focus {
  box-shadow: var(--input-box-shadow-focus);
}
.field__input--button-radius {
  border-radius: var(--style-border-radius-buttons-primary);
}
.field__input--button-padding {
  padding-inline: var(--padding-3xl);
}
.field__label {
  color: rgb(var(--color-input-text-rgb) / var(--opacity-80));
  font-size: var(--font-paragraph--size);
  left: var(--input-padding-x);
  top: 50%;
  transform: translateY(-50%);
  margin-bottom: 0;
  pointer-events: none;
  position: absolute;
  transition:
    top var(--animation-speed) ease,
    font-size var(--animation-speed) ease;
}
/* RTE styles */
.rte,
.shopify-policy__title {
  :is(h1, h2, h3, h4, h5, h6) {
    margin-block: clamp(1.5rem, 1em * 3.3, 2.5rem) var(--font-heading--spacing);
  }
  :first-child:is(p, h1, h2, h3, h4, h5, h6),
  :first-child:empty + :is(p, h1, h2, h3, h4, h5, h6) {
    margin-block-start: 0;
  }
  ul,
  ol {
    margin-block-start: 0;
    padding-inline-start: 1.5em;
  }
  /* Only apply margin-block-end to the higher level list, not nested
lists */
  :is(ul, ol):not(:is(ul, ol) :is(ul, ol)) {
    margin-block-end: 1em;
  }
  blockquote {
    margin-inline: 1.5em 2.3em;
    margin-block: 3.8em;
    padding-inline-start: 0.8em;
    border-inline-start: 1.5px solid
      rgb(var(--color-foreground-rgb) / var(--opacity-25));
    font-style: italic;
    font-weight: 500;
  }
  .rte-table-wrapper {
    overflow-x: auto;
  }
  table {
    /* stylelint-disable-next-line declaration-no-important */
    width: 100% !important;
    border-collapse: collapse;
  }
  tr:not(:has(td)),
  thead {
    background-color: rgb(var(--color-foreground-rgb) / var(--opacity-5));
    font-weight: bold;
    text-transform: uppercase;
  }
  tr:has(td) {
    border-bottom: 1px solid
      rgb(var(--color-foreground-rgb) / var(--opacity-10));
  }
  th,
  td {
    text-align: start;
    padding-inline: var(--padding-md);
    padding-block: var(--padding-sm);
  }
}
.shopify-policy__container {
  padding-block: var(--padding-xl);
}
/* Radio buttons and checkboxes - shared base styles */
:where(input[type="radio"]),
:where(input[type="checkbox"]) {
  width: var(--checkbox-size);
  height: var(--checkbox-size);
  aspect-ratio: 1;
  margin: 0;
  margin-inline-end: var(--padding-3xs);
  padding: 0;
  border: var(--checkbox-border);
  appearance: none;
  position: relative;
  display: inline-block;
  vertical-align: middle;
  cursor: pointer;
}
/* Radio buttons */
input[type="radio"] {
  border-radius: var(--style-border-radius-50);
  background: transparent;
  transition:
    border-color 0.2s ease,
    background-color 0.2s ease;
}
:where(input[type="radio"]):checked {
  border-color: var(--color-foreground);
  background: var(--color-background);
}
:where(input[type="radio"]):checked::after {
  content: "";
  position: absolute;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%);
  width: calc(var(--checkbox-size) / 2);
  height: calc(var(--checkbox-size) / 2);
  background: var(--color-foreground);
  border-radius: var(--style-border-radius-50);
  transition: background 0.2s ease;
}
:where(input[type="radio"]):disabled {
  border-color: var(--input-disabled-border-color);
  background-color: var(--input-disabled-background-color);
  cursor: not-allowed;
}
:where(input[type="radio"]):disabled:checked::after {
  background: var(--input-disabled-background-color);
}
:where(input[type="radio"]):not(:disabled):hover {
  border-color: rgb(var(--color-foreground-rgb) / var(--opacity-40-60));
  background-color: rgb(var(--color-foreground-rgb) / var(--opacity-5));
}
:where(input[type="radio"]):not(:disabled):hover:checked {
  border-color: var(--color-foreground);
  background-color: var(--color-background);
}
:where(input[type="radio"]):not(:disabled):hover:checked::after {
  background: rgb(var(--color-foreground-rgb) / var(--opacity-85));
}
/* Checkboxes */
:where(input[type="checkbox"]) {
  border-radius: var(--checkbox-border-radius);
  background-color: var(--color-background);
  transition:
    border-color 0.2s ease,
    background-color 0.2s ease;
}
:where(input[type="checkbox"]):checked {
  background-color: var(--color-foreground);
  border-color: var(--color-foreground);
}
:where(input[type="checkbox"]):checked::after {
  content: "";
  position: absolute;
  top: 50%;
  left: 50%;
  transform: translate(-50%, -50%);
  width: var(--checkbox-size);
  height: var(--checkbox-size);
  background-color: var(--color-background);
  mask-image: url("data:image/svg+xml,%3Csvg width='20' height='20' viewBox='0 0 20 20' fill='none' xmlns='http://www.w3.org/2000/svg'%3E%3Cpath d='M4.75439 10.7485L7.68601 14.5888C7.79288 14.7288 7.84632 14.7988 7.91174 14.8242C7.96907 14.8466 8.03262 14.8469 8.09022 14.8253C8.15596 14.8007 8.21026 14.7314 8.31886 14.5927L15.2475 5.74658' stroke='black' stroke-width='1' stroke-linecap='round' stroke-linejoin='round'/%3E%3C/svg%3E");
  mask-size: contain;
  mask-repeat: no-repeat;
  mask-position: center;
}
:where(input[type="checkbox"]):not(:disabled):hover {
  border-color: rgb(var(--color-foreground-rgb) / var(--opacity-40-60));
  background-color: rgb(var(--color-foreground-rgb) / var(--opacity-5));
}
:where(input[type="checkbox"]):not(:disabled):hover:checked {
  border-color: var(--color-foreground);
  background-color: rgb(var(--color-foreground-rgb) / var(--opacity-85));
}
:where(input[type="checkbox"]):disabled {
  background-color: var(--input-disabled-background-color);
  border-color: var(--input-disabled-border-color);
  cursor: not-allowed;
}
:where(input[type="checkbox"]):disabled:checked::after {
  background-color: var(--input-disabled-text-color);
}
/* Shared styles for radio buttons and checkboxes */
:where(input[type="radio"]) + label,
:where(input[type="checkbox"]) + label {
  display: inline;
  vertical-align: middle;
  cursor: pointer;
}
:where(input[type="radio"]):disabled + label,
:where(input[type="checkbox"]):disabled + label {
  color: var(--input-disabled-text-color);
  cursor: not-allowed;
}
/* Flexbox for labels wrapping radio buttons or checkboxes */
label:has(input[type="radio"]),
label:has(input[type="checkbox"]) {
  display: inline-flex;
  align-items: center;
  gap: var(--padding-2xs);
  cursor: pointer;
}
label:has(input[type="radio"]:disabled),
label:has(input[type="checkbox"]:disabled) {
  cursor: not-allowed;
}
/*
------------------------------------------------------------------------------
*/
/*
------------------------------------------------------------------------------
*/
/* Animation declarations - to be kept at the bottom of the file for
ease of find */
@keyframes grow {
  0% {
    transform: scale(1);
  }
  50% {
    transform: scale(1.2);
  }
  100% {
    transform: scale(1);
  }
}
@keyframes move-and-fade {
  from {
    transform: translate(var(--start-x, 0), var(--start-y, 0));
    opacity: var(--start-opacity, 0);
  }
  to {
    transform: translate(var(--end-x, 0), var(--end-y, 0));
    opacity: var(--end-opacity, 1);
  }
}
@keyframes slideInTopViewTransition {
  from {
    transform: translateY(100px);
  }
}
@keyframes elementSlideInTop {
  from {
    margin-top: var(--padding-sm);
    opacity: 0;
  }
  to {
    margin-top: 0;
    opacity: 1;
  }
}
@keyframes elementSlideOutTop {
  from {
    transform: translateY(0);
    opacity: 1;
  }
  to {
    transform: translateY(var(--padding-sm));
    opacity: 0;
  }
}
@keyframes elementSlideOutBottom {
  from {
    transform: translateY(0);
    opacity: 1;
  }
  to {
    transform: translateY(calc(-1 * var(--padding-sm)));
    opacity: 0;
  }
}
@keyframes thumbnailsSlideInTop {
  from {
    transform: translateY(calc(-50% + var(--margin-lg)));
    opacity: 0;
  }
  to {
    transform: translateY(-50%);
    opacity: 1;
  }
}
@keyframes thumbnailsSlideOutTop {
  from {
    transform: translateY(-50%);
    opacity: 1;
  }
  to {
    transform: translateY(calc(-50% + var(--margin-lg)));
    opacity: 0;
  }
}
@keyframes thumbnailsSlideInBottom {
  from {
    transform: translateY(100%);
    opacity: 0;
  }
  to {
    transform: translateY(0);
    opacity: 1;
  }
}
@keyframes thumbnailsSlideOutBottom {
  from {
    transform: translateY(0);
    opacity: 1;
  }
  to {
    transform: translateY(100%);
    opacity: 0;
  }
}
@keyframes search-element-slide-in-bottom {
  0% {
    transform: translateY(20px);
    opacity: 0;
  }
  100% {
    transform: translateY(0);
    opacity: 1;
  }
}
@keyframes search-element-slide-out-bottom {
  0% {
    transform: translateY(0);
    opacity: 1;
  }
  100% {
    transform: translateY(20px);
    opacity: 0;
  }
}
@keyframes backdropFilter {
  from {
    backdrop-filter: brightness(1);
  }
  to {
    backdrop-filter: brightness(0.75);
  }
}
@keyframes fadeOut {
  from {
    opacity: 1;
  }
  to {
    opacity: 0;
  }
}
@keyframes fadeIn {
  from {
    opacity: 0;
  }
  to {
    opacity: 1;
  }
}
@keyframes modalSlideInTop {
  from {
    transform: translateY(var(--padding-sm));
    opacity: 0;
  }
  to {
    transform: translateY(0);
    opacity: 1;
  }
}
@keyframes modalSlideOutTop {
  from {
    transform: translateY(0);
    opacity: 1;
  }
  to {
    transform: translateY(var(--padding-sm));
    opacity: 0;
  }
}
/* Slideshow Arrow Hover Animation - must stay in base.css for proper
CSS cascade */
:not(.media-gallery--carousel)
  > :is(slideshow-component:hover, slideshow-component:focus-within):not(
    :has(slideshow-controls:hover)
  )
  > slideshow-container
  > slideshow-arrows
  .slideshow-control {
  animation: arrowsSlideIn var(--animation-speed) var(--animation-easing)
    forwards;
}
@keyframes arrowsSlideIn {
  from {
    transform: translate(var(--padding-sm), 0);
    opacity: 0;
  }
  to {
    opacity: 1;
  }
}
.section-resource-list,
.section-carousel {
  row-gap: var(--gap);
}
.section-resource-list__content {
  display: flex;
  flex-direction: column;
  align-items: var(--horizontal-alignment);
  gap: var(--gap);
  width: 100%;
}
.section-resource-list__content:empty {
  display: none;
}
.section-resource-list__header:is(:empty, :has(.group-block-content:empty)),
.section-resource-list__content:empty {
  display: none;
}
:where(.section-resource-list.section--full-width)
  product-card[data-product-transition]
  > .group-block,
:where(.section-carousel.section--full-width)
  product-card[data-product-transition]
  > .group-block {
  @media screen and (max-width: 749px) {
    padding-inline: max(var(--padding-xs), var(--padding-inline-start))
      max(var(--padding-xs), var(--padding-inline-end));
  }
}
/* Base styles */
.group-block,
.group-block-content {
  position: relative;
}
.group-block:has(> video-background-component) {
  overflow: hidden;
}
.group-block-content {
  height: 100%;
  width: 100%;
}
/* Container styles */
.section-content-wrapper.section-content-wrapper:where(.layout-panel-flex)
  .group-block--fill {
  flex: 1;
}
/* Flex behavior for width variants */
.layout-panel-flex--row > .group-block--width-fit {
  flex: 0;
}
.layout-panel-flex--row > .group-block--width-fill {
  flex: 1;
}
.layout-panel-flex--row > .group-block--width-custom {
  flex-basis: var(--size-style-width);
}
/* Dimension utilities - Height */
.group-block--height-fit {
  height: auto;
}
.group-block--height-custom,
.group-block--height-fill {
  height: var(--size-style-height);
}
/* Flex behavior for height variants */
.layout-panel-flex--column > .group-block--height-fit {
  flex: 0 1 auto;
}
.layout-panel-flex--column > .group-block--height-fill {
  flex: 1;
}
.layout-panel-flex--column > .group-block--height-custom {
  flex-basis: var(--size-style-height);
}
/* Global scrollbar styles */
/* Webkit browsers */
::-webkit-scrollbar {
  width: 20px;
}
::-webkit-scrollbar-track {
  background-color: transparent;
}
::-webkit-scrollbar-thumb {
  background-color: rgb(var(--color-foreground-rgb) / var(--opacity-40));
  border-radius: 20px;
  border: 6px solid transparent;
  background-clip: content-box;
  transition: background-color 0.2s;
}
::-webkit-scrollbar-thumb:hover {
  background-color: rgb(var(--color-foreground-rgb) / var(--opacity-60));
}
@media (prefers-reduced-motion: no-preference) {
  html {
    scroll-behavior: smooth;
  }
}
/* Prevent iOS zoom on input focus by ensuring minimum 16px font size on
mobile */
@media screen and (max-width: 1200px) {
  input,
textarea,
select,
/* Higher specificity to override type preset classes like .paragraph,
.h1, etc. */
.paragraph.paragraph input,
.paragraph.paragraph textarea,
.paragraph.paragraph select,
.h1.h1 input,
.h1.h1 textarea,
.h1.h1 select,
.h2.h2 input,
.h2.h2 textarea,
.h2.h2 select,
.h3.h3 input,
.h3.h3 textarea,
.h3.h3 select,
.h4.h4 input,
.h4.h4 textarea,
.h4.h4 select,
.h5.h5 input,
.h5.h5 textarea,
.h5.h5 select,
.h6.h6 input,
.h6.h6 textarea,
.h6.h6 select {
    font-size: max(1rem, 100%);
  }
}
/* When the header is transparent, and when there is no header-section below
   it, offset the first main-section with * the height of the header */
main > .shopify-section:first-child .section:not(.disable-section-top-offset) {
  &.spacing-style,
  .spacing-style {
    --section-top-offset: calc(
      var(--header-height) * var(--transparent-header-offset-boolean)
    );
    /* Any nested sections should not be offset */
    :is(.spacing-style, .inherit-spacing) {
      --section-top-offset: 0px;
    }
  }
  /* Make sticky content immediately stick to the top of the page */
  .sticky-content {
    margin-top: calc(
      var(--header-height) * var(--transparent-header-offset-boolean) * -1
    );
  }
}


/* ================================================================ AB HIER:
   NEU HINZUGEFÜGTER MOBIL-FIX-BLOCK (siehe Chat-Erklärung)
   ================================================================ */

/* ================================================================ PLANET V —
   MOBILE-RESPONSIVE FIXES Zum Anhaengen ans Ende von assets/base.css. Regeln
   sind mit @media (max-width: 749px) auf Mobil beschraenkt, damit das
   Desktop-Design unberuehrt bleibt (749px = die im Theme durchgaengig
   genutzte Grenze). URSACHE, warum Aenderungen zunaechst nicht ankamen:
   Horizon kompiliert die {% stylesheet %}-Bloecke jeder Section zu eigenem
   CSS, das Shopify NACH assets/base.css einfuegt. Bei gleicher Spezifitaet
   gewinnt bei Gleichstand immer die spaeter im Dokument stehende Regel -
   selbst gegen !important, falls die Original-Regel ebenfalls !important ist.
   FIX: 1) jede Regel bekommt !important. 2) jede Regel bekommt ein
   vorangestelltes "body " im Selektor - aendert die Bedeutung nicht, erhoeht
   aber die Spezifitaet minimal und zuverlaessig, damit wir auch gegen gleich
   starke !important-Regeln gewinnen. 3) bereits ID-gescopte Regeln bekommen
   zusaetzlich !important zur Sicherheit. Bitte den alten Block im base.css
   durch diesen ersetzen (nicht zusaetzlich einfuegen).
   ================================================================ */


/* ----------------------------------------------------------------
   1. HERO-SECTION
   ---------------------------------------------------------------- */

/* .hero-wrapper hatte "min-height: 800px !important;" (feste Pixelzahl) in
   hero.liquid - auf einem ~390-430px breiten Handy fast 2x hoeher als die
   Bildschirmbreite. Fix: auf Mobil "svh" (wird im Theme schon genutzt) statt
   fixer px - stabil ueber Browser/Geraete hinweg. */
@media screen and (max-width: 749px) {
  body .hero-wrapper {
    min-height: 100svh !important;
  }
}
/* KORREKTUR (Round 20): Merle "Handy Quer: Hero 170% der vh, damit alles
   Platz findet" - bei Handys im Querformat ist die Bildschirmhoehe so
   gering, dass Headline+Subline+Logo+Siegel in 100svh sichtbar gequetscht
   wirken. Eigene, spezifischere Regel NUR fuer Quer-Handys (orientation:
   landscape gewinnt gegen die obige Regel, die beide Ausrichtungen deckt) -
   der Hero darf dadurch bewusst ueber die Bildschirmhoehe hinauswachsen und
   wird Teil des normalen Scrollbereichs, statt alles reinzuquetschen. Die
   font-size-Berechnung dafuer (isPhoneLandscape-Zweig in fitHero(),
   mobile-fixes.js) bleibt unveraendert - sie liest die (jetzt groessere)
   Hero-Hoehe live aus und skaliert entsprechend mit.
   KORREKTUR (Bugfix nach Video-Feedback): max-width:749px erkennt Handy-Quer
   nicht zuverlaessig, da echte Handys im Querformat oft breiter als 749px
   sind (z.B. iPhone 14 quer ca. 844px) - dadurch griff diese Regel bei Merles
   Test NIE, der Hero blieb auf 100dvh (siehe Abschnitt 16b), waehrend
   "Box zusammenstellen" nach unten verdraengt und die Headline-Gruppe
   abgeschnitten wurde. Statt Breite wird jetzt die Hoehe geprueft (Handy-Quer
   ist immer flach, <=500px, waehrend Tablet-Quer deutlich hoeher ist).
   KORREKTUR 2 (Bugfix nach erneutem Feedback, "Hero hat die vh 170, aber das
   Enthaltene ist nicht gross genug"): diese Regel setzte bisher NUR auf
   .hero-wrapper die 170vh - sichtbar wird aber (wie im Desktop-Block weiter
   unten, Abschnitt 16b, bereits dokumentiert) nicht .hero-wrapper selbst,
   sondern `.hero__container` (bzw. `[id^="Hero-template--"]`) darin, dessen
   Hoehe einer eigenen, nativen Horizon-Logik folgt und dadurch klein blieb,
   waehrend der Wrapper aussen schon auf 170vh gewachsen war - das erzeugte
   genau die leere Flaeche unterhalb von Headline/Logo, die Merle gemeldet
   hat. Fix: .hero__container/[id^="Hero-template--"] bekommen hier dieselbe
   170vh wie .hero-wrapper, analog zum Desktop-Block (dort 100dvh auf beiden). */
/* KORREKTUR (Round 28, 31. Batch): Merle "die Herotextgroup muss auf Handy
   Quer nach oben, der Hero demnach in der Höhe kürzer werden" + "das Planet
   V Logo sitzt irgendwie riesig im Hintergrund". Zwei getrennte Ursachen
   gefunden: 1) 170vh war ein fester Schätzwert aus einer früheren Runde
   (Round 20), auf Merles neuen Wunsch hin reduziert (140vh) - ECHTER
   SCHÄTZWERT, bitte live gegenchecken, ob das reicht oder noch kürzer sein
   muss. 2) Das "riesige" Logo im Hintergrund: ".hero-text-group__logo" hat
   für genau diesen Fall (Breite >= 750px, also kein Treffer in der
   Hochformat-Logo-Regel weiter oben, UND Höhe <= 500px, also kein Treffer in
   der "min-width:1200px"-Desktop-Logo-Regel) bisher GAR KEINE eigene
   Höhen-Begrenzung - das Bild rendert dadurch auf seine volle native Größe
   (400x377px). Die einzige fürs Handy-Quer vorgesehene Logo-Höhen-Regel
   steckt im weiter unten in dieser Datei stehenden, bereits mehrfach live
   als TOT bestätigten Komplex-Media-Query-Block - greift also nie. Fix: neue,
   eigene, bekanntermaßen funktionierende Regel direkt hier im selben
   einfachen Landscape-Block ergänzt. Schätzwert für den genauen Höhenwert. */
@media screen and (orientation: landscape) and (max-height: 500px) {
  /* NEU (Round 28, 40. Batch): Merle "the herotextgroup should move to
     top: 43%". Live per Chrome-Rule-Enumeration + gezieltem Reset nachgewiesen
     (650x497-aehnliches Testfenster): ".hero-text-group" traegt in diesem
     Breakpoint (anders als am "echten Desktop", wo Abschnitt 16b es auf
     position:relative umstellt - dieser Bereich ist davon per min-height:501px
     bzw. hover:hover bewusst ausgenommen) weiterhin Shopifys natives
     "Position"-Feature: position:absolute; top:45%; left:50%;
     transform:translate(-50%,-50%) (bestaetigt: nativeTop 163.7px bei
     363.8px Container-Hoehe = exakt 45.0%). Fix: top direkt von 45% auf
     43% ueberschrieben - verschiebt den Zentrierungspunkt der ganzen Gruppe
     (Headline+Subline) um 2 Prozentpunkte nach oben. Die bisherige JS-Lift-
     Berechnung (PHONE_LANDSCAPE_LIFT_RATIO) wird dadurch ueberfluessig und
     in mobile-fixes.js entsprechend reduziert (siehe dortiger Kommentar) -
     das bestehende Navbar-Sicherheitsnetz bleibt als reine Absicherung
     bestehen, falls 43% auf einem besonders kurzen Bildschirm doch zu hoch
     waere. */
  /* KORREKTUR (Round 28, 41. Batch): Merle "hero-textgroup und logo muessen
     ein Stueck hoch, es ist nicht schlimm wenn sie fast an den Headernav
     anstossen, der ist am Anfang ja voellig ausgeblendet" - von 43% auf 35%
     verringert (weiterer Schritt nach oben). Das zugehoerige JS-Sicherheits-
     netz (mobile-fixes.js, isPhoneLandscape-Zweig) wurde passend gelockert,
     siehe dortiger Kommentar - SCHAETZWERT, bitte live auf echtem Handy quer
     gegenchecken. */
  /* KORREKTUR (Round 28, 45. Batch): Merle meldet nach Live-Test auf dem
     echten Handy quer, dass 35% zu weit nach oben ging - die Headline soll
     "doch etwas runterrutschen wieder, naeher ans logo". top% erhoeht =
     Gruppe rutscht wieder weiter nach unten (siehe Erklaerung oben: 45% war
     die native Mitte, jedes Senken von top% schiebt nach oben, jedes Anheben
     schiebt wieder nach unten). Von 35% auf 39% angehoben - das ist nur ein
     SCHAETZWERT (Mittelwert zwischen den bereits getesteten 35% und 43%),
     da kein genauer Zielwert genannt wurde. Bitte unbedingt live auf dem
     echten Handy quer gegenchecken und melden, ob 39% schon passt oder noch
     weiter angepasst werden soll. */
  /* KORREKTUR (Round 28, 87. Batch): ECHTER ROOT CAUSE fuer Merles "unten im
     Hero viel Platz unter Logo/Siegel, Headline schneidet oben den
     Headernav" (noch nicht live bestaetigt, bitte unbedingt gegenchecken).
     Der 84. Batch (".hero__content-wrapper" auf 100dvh fixiert, gegen das
     "Logo/Siegel gar nicht sichtbar"-Problem) hat NUR den Content-Wrapper
     entkoppelt, nicht aber .hero-wrapper/.hero__container/[Hero-template--]
     selbst - die bleiben weiterhin auf 140vh aufgeblasen. Dadurch klafft
     jetzt eine ~40vh grosse, komplett leere Luecke zwischen dem Ende des
     (jetzt korrekt 100dvh hohen) Content-Wrappers und dem tatsaechlichen
     Ende der sichtbaren Hero-Box (140vh) - genau Merles "viel Platz unten im
     Hero". GLEICHZEITIG war ".hero-text-group"s "top:39%" noch auf den
     ALTEN (140vh-)Bezugsrahmen des Content-Wrappers kalibriert (per Merles
     eigenen Live-Tests, Batch 40/41/45) - seit der 100dvh-Fixierung
     (84. Batch) bezieht sich "top:39%" nun auf eine VIEL kleinere Box,
     wodurch die Gruppe deutlich hoeher (naeher am Header) landet als
     beabsichtigt. Fix, konsistent zu "wie Desktop breit, nur in klein":
     1) .hero-wrapper/.hero__container/[Hero-template--] jetzt ebenfalls auf
        100dvh reduziert (statt 140vh) - deckungsgleich mit dem Content-
        Wrapper, keine leere Restflaeche mehr.
     2) "top" von 39% auf 45% erhoeht, um die durch den neuen (kleineren)
        Bezugsrahmen zu hoch geratene Gruppe wieder nach unten zu holen. */
  body .hero-text-group {
    top: 45% !important; /* war 39% */
  }
  body .hero-wrapper {
    min-height: 100dvh !important; /* war 140vh */
    height: 100dvh !important;
  }
  body .hero__container,
  body [id^="Hero-template--"] {
    min-height: 100dvh !important; /* war 140vh */
    height: 100dvh !important;
  }
  body .hero-text-group__logo {
    /* KORREKTUR (Round 28, 35. Batch): Merle "Handy quer: Logo Position gut,
       aber doppelt so groß" - alle drei clamp()-Eckwerte halbiert.
       KORREKTUR (Round 28, 37. Batch): Merle meldet auf ihrem echten iPhone
       in Querformat, das Logo sei jetzt "extrem winzig" - genau diese Regel
       benannt. Vermutlich war die Halbierung (Batch 35) zu stark: auf einem
       echten iPhone mit dynamischer Safari-Toolbar kann die tatsaechliche
       "dvh"-Hoehe kurzzeitig/dauerhaft kleiner ausfallen als in der Sandbox
       angenommen, wodurch der 4.5dvh-Vorzugswert naeher am 12px-Minimum
       landet als gedacht. Fix: vorsichtig wieder angehoben, auf halbem Weg
       zwischen dem (zu grossen) Ursprungswert und dem (zu kleinen)
       halbierten Wert.
       KORREKTUR (Round 28, 38. Batch): Merle "Logo ist immer noch winzig,
       muss doppelt so gross sein wie jetzt" - alle drei Eckwerte des 37.-
       Batch-Werts verdoppelt. Ausdruecklich NUR die Groesse geaendert, NICHT
       die Position der Hero-Textgroup (Merles expliziter Wunsch: "please
       dont change the position of the text group"). Zusaetzlich ergaenzt:
       etwas Abstand zur Subline oben und zur Hero-Unterkante unten (Merle:
       "leave a distance between subline and the logo and logo and hero
       buttom") - vorher stand hier keine eigene margin, SCHAETZWERT.
       KORREKTUR (Round 28, 39. Batch): Merle "the logo 15% bigger" - alle
       drei Eckwerte des 38.-Batch-Werts mit 1.15 multipliziert:
       clamp(36px,13.5dvh,90px) -> clamp(41.4px,15.525dvh,103.5px).
       KORREKTUR (Round 28, 83. Batch): Merle "Desktop quer auf Handy quer
       anwenden" (Desktop quer: "Logo 5% kleiner") - alle drei Eckwerte um
       5% reduziert. */
    height: clamp(39.33px, 14.74875dvh, 98.325px) !important; /* war clamp(41.4px, 15.525dvh, 103.5px), 5% kleiner */
    width: auto !important;
    object-fit: contain !important;
    margin-top: 12px !important;
    /* GEAENDERT (Round 28, 40. Batch): Merle ".hero-text-group__logo should
       be at bottom: 1%; and loose its margin bottom (now 16px!important,
       should be 0)". Live bestaetigt: das Logo-Bild selbst traegt hier
       nativ position:absolute mit einem eigenen top-Wert (unabhaengig vom
       top-Wert der Hero-Textgroup) - top wird deshalb explizit auf "auto"
       gesetzt, damit "bottom" (statt "top") die Position bestimmt (sonst
       waere die Box ueberbestimmt und "bottom" wuerde ignoriert). */
    top: auto !important;
    /* KORREKTUR (Round 28, 83. Batch): Merle "Desktop quer auf Handy quer
       anwenden" (Desktop quer: "Logo ein paar Pixel hoeher") - bottom-%
       leicht erhoeht (ein hoeherer bottom-Prozentwert schiebt das Logo
       weiter nach oben), Schaetzwert, bitte live gegenchecken.
       KORREKTUR (Round 28, 87. Batch): seit der 100dvh-Korrektur direkt
       oberhalb (siehe dortiger Kommentar) muss das Logo jetzt wieder nach
       UNTEN - zurueck auf den fruaeheren Wert (1%), eher noch knapper, da
       jetzt kein ungenutzter Leerraum mehr darunter existiert. */
    bottom: 0.5% !important; /* war 2.5% */
    margin-bottom: 0 !important; /* war 16px !important */
    /* Hinweis zu Merles "logo ... in front of the planets z-index wise"
       (Round 28, 39. Batch): kein zusaetzlicher z-index hier noetig - die
       neue Regel unten in diesem Block setzt Welle/Deko-Fotos in diesem
       Breakpoint auf NEGATIVE z-index-Werte, die laut CSS-Stapelreihenfolge
       ohnehin IMMER hinter jedem Inhalt mit auto/positivem z-index (wie
       diesem Logo) liegen - unabhaengig davon, ob das Logo hier static oder
       positioniert ist. */
  }
  /* NEU (Round 28, 37. Batch): Merle "Bio-Siegel auf Handy quer muessen um
     20% kleiner werden". Es gab bisher KEINE eigene Regel fuer
     ".hero-text-group__siegel" in diesem Breakpoint - es griff der
     unscoped Basis-Wert (clamp(55.5px, 28.5px + 6.9vw, 111px), weiter unten
     in der Datei). Fix: eigene, 20% kleinere Regel direkt hier ergaenzt (alle
     drei Eckwerte * 0.8), die durch die hoehere Spezifitaet/spaetere
     Reihenfolge gewinnt.
     KORREKTUR (Round 28, 38. Batch): Merle "die Bio-Labels sind viel zu
     gross, bitte auf 45% der aktuellen Groesse" - alle drei Eckwerte des
     37.-Batch-Werts mit 0.45 multipliziert.
     KORREKTUR (Round 28, 39. Batch): Merle "organic labels need to be 40%
     smaller" - alle drei Eckwerte des 38.-Batch-Werts mit 0.6 multipliziert
     (40% kleiner = 60% der bisherigen Groesse):
     clamp(19.98px,10.26px+2.484vw,39.96px) -> clamp(11.988px,6.156px+1.4904vw,23.976px).
     ECHTER BUG GEFUNDEN UND BEHOBEN (noch selbe Pruefung, LIVE am bereits
     eingespielten Shop entdeckt, per CSSOM-Rule-Enumeration): der alte
     Kommentar oben ("gewinnt durch hoehere Spezifitaet") war schlicht
     falsch - "body .hero-text-group__siegel" hat HIER und bei der weiter
     unten stehenden, bewusst unscoped gehaltenen Basis-Regel (Round 28, 32.
     Batch, clamp(55.5px,28.5px+6.9vw,111px)) exakt DIESELBE Spezifitaet
     (ein Element + eine Klasse) - bei gleicher Spezifitaet UND beide
     !important gewinnt rein die Quellreihenfolge, und die unscoped
     Basis-Regel steht in der Datei WEITER UNTEN als dieser Block, gewinnt
     also tatsaechlich. Live bewiesen: computed height auf einem echten
     (wenn auch maus-/Desktop-simulierten) Handy-quer-Fenster (650x497)
     ergab 73.34px - exakt der unscoped Basis-Wert, NICHT der hier
     beabsichtigte, viel kleinere Wert. Das heisst: diese Regel hat
     vermutlich schon seit Batch 37 nie gewirkt. Fix: Selektor um
     ".hero__container" als zusaetzlichen Vorfahren-Qualifizierer ergaenzt
     (".hero__container" ist nachweislich ein Vorfahre von
     ".hero-text-group__siegel", per .contains() live geprueft) - das hebt
     die Spezifitaet auf zwei Klassen+ein Element und gewinnt dadurch
     garantiert, unabhaengig von der Position in der Datei. */
  /* KORREKTUR (Round 28, 41. Batch): Merle "die organic labels sind winzig,
     muss auf Handy quer DOPPELT so grosse Ergebnisse liefern". Ein clamp()
     korrekt verdoppeln heisst: ALLE DREI Eckwerte verdoppeln - also auch den
     vw-Koeffizienten im Preferred-Teil, nicht nur die beiden px-Grenzwerte
     (Merles eigener, selbst als unsicher bezeichneter Versuch
     "clamp(13.988px,6.156px+8.4904vw,39.976px)" hatte genau das vermischt:
     MIN nur leicht erhoeht (11.988->13.988 statt auf 23.976 verdoppelt) und
     dafuer den vw-Koeffizienten viel zu stark vervielfacht - dadurch waere
     das Ergebnis nicht gleichmaessig doppelt so gross, sondern bei schmalen
     Breiten kaum veraendert und bei etwas breiteren Breiten unverhaeltnis-
     maessig viel groesser). Mathematisch korrekt verdoppelt (jeder der drei
     Werte * 2, inkl. des vw-Koeffizienten): MIN 11.988px*2=23.976px, Preferred
     "6.156px + 1.4904vw"*2 = "12.312px + 2.9808vw", MAX 23.976px*2=47.952px -
     damit liefert die Formel bei JEDER Fensterbreite exakt das Doppelte des
     bisherigen Werts. */
  body .hero__container .hero-text-group__siegel {
    height: clamp(23.976px, 12.312px + 2.9808vw, 47.952px) !important; /* war clamp(11.988px, 6.156px + 1.4904vw, 23.976px), korrekt verdoppelt */
    width: auto !important;
  }
  /* NEU (Round 28, 41. Batch): Merle "dann muessen die organic labels von
     11,5% right auf 8% right" (Handy quer). Die bisherige 11.5%-Regel
     (Abschnitt 16, weiter oben in der Datei) ist bewusst NICHT fuer diesen
     Breakpoint gescopt und gilt auch fuer echtes Handy-Hochformat ("ist
     perfekt", soll unveraendert bleiben) - deshalb hier eine eigene, nur fuer
     Handy quer geltende Regel ergaenzt statt die gemeinsame Regel zu
     aendern. ".hero__container"-Vorfahre wie bei der Siegel-Groesse oben
     ergaenzt, damit sie unabhaengig von der Dateireihenfolge zuverlaessig
     gegen die gemeinsame Regel gewinnt (gleiches, bereits bewaehrtes Muster). */
  body .hero__container .hero-text-group__siegel-wrapper {
    right: 8% !important; /* war 11.5% (gemeinsamer Wert aus Abschnitt 16) */
  }
  /* NEU (Round 28, 39. Batch): Merle "hero textgroup has to come up a bit
     more" (siehe JS-Aenderung PHONE_LANDSCAPE_LIFT_RATIO) + z-index-Fix
     fuer diesen Breakpoint. Die gemeinsame z-index-Regel fuer Welle/Deko-
     Fotos (Abschnitt weiter unten in der Datei, "image-block"/"planet-wave")
     gilt nur fuer "orientation:portrait" - dieser Landscape-Block (Handy
     quer) war bisher GAR NICHT von einer z-index-Regel abgedeckt. Gleicher
     Fund/Fix wie dort (CSS2.1-Stapelreihenfolge: negative z-index liegt
     immer hinter statischem UND positiv-positioniertem Inhalt, siehe
     ausfuehrlicher Kommentar bei der portrait-Regel): Deko-Fotos/Welle
     bekommen auch hier negative Werte, damit sie zuverlaessig HINTER der
     Hero-Textgruppe und dem (jetzt 15% groesseren) Logo bleiben. */
  body .hero__container .image-block,
  body .hero__media-grid .image-block {
    z-index: -2 !important;
  }
  body .hero__container .planet-wave {
    z-index: -1 !important;
  }
  /* KORREKTUR (Round 23, Merles Feedback "Herogroesse ist jetzt top, aber
     der Platz ueber der Headline ist zu gross, sie muss nach oben"): Root
     Cause - .hero__content-wrapper stapelt seinen Inhalt nativ von UNTEN
     (justify-content:flex-end, native Horizon-Regel, von uns nie
     ueberschrieben). Die isPhoneLandscape-Rechnung in fitHero()
     (mobile-fixes.js) passt nur die Schriftgroesse an, OHNE (anders als der
     echte Desktop-Zweig) einen Ausgleich fuers Von-unten-Stapeln
     vorzunehmen - dadurch sitzt der Inhalt am unteren Rand der (jetzt 170vh
     hohen) Box, und die GESAMTE zusaetzliche Hoehe sammelt sich als
     Leerraum darueber. Fix: Inhalt auf Handy-Quer stattdessen von OBEN
     stapeln lassen (flex-start) + kleiner Sicherheitsabstand zur Navbar
     (--header-height, native Theme-Variable). Schaetzwert, bitte live
     gegenchecken - konnte in meiner Sandbox nicht in echter Handy-Quer-
     Groesse nachgestellt werden. */
  body .hero__content-wrapper {
    justify-content: flex-start !important;
    padding-top: calc(var(--header-height, 52px) + 16px) !important;
    /* KORREKTUR (Round 28, 84. Batch): ECHTER ROOT CAUSE fuer Merles "Logo
       und Bio-Siegel auf Handy quer gar nicht zu sehen" gefunden (reine
       Code-Analyse, Chrome-Tool war nicht verfuegbar - bitte live
       gegenchecken). .hero-wrapper/.hero__container/[id^="Hero-template--"]
       werden in diesem Block bewusst auf 140vh aufgeblasen (Platz fuer
       Headline/Subline). .hero__content-wrapper ist deren Grid-/Flex-Kind
       und wurde bisher NIE auf eine eigene Hoehe gesetzt - es streckt sich
       deshalb (Grid-/Flex-Kinder stretchen standardmaessig auf die volle
       Zellen-/Containerhoehe, siehe gleiche Erkenntnis weiter oben im
       Projekt beim Hochformat-"rosa Balken") ebenfalls auf 140vh. Logo UND
       Bio-Siegel haengen (natives Theme-Markup) mit "bottom: X%" direkt an
       GENAU diesem Wrapper - bei 140vh Wrapperhoehe landet "bottom:2.5%"
       bzw. "bottom:3%" also 2.5-3% von 140vh von UNTEN gemessen, weit
       unterhalb des tatsaechlich sichtbaren Viewports (echte Bildschirmhoehe
       auf Handy quer typischerweise deutlich unter 100vh) - nicht
       "abgeschnitten", sondern schlicht ausserhalb des sichtbaren Bereichs,
       ohne Scrollen gar nicht erreichbar. Fix: .hero__content-wrapper auf
       die tatsaechlich sichtbare Viewporthoehe (100dvh) fixiert, komplett
       entkoppelt von der bewusst aufgeblasenen 140vh-Hoehe der aeusseren
       Container - "bottom"-Prozentwerte von Logo/Siegel beziehen sich
       dadurch wieder auf die sichtbare Hoehe. Headline/Subline (die per
       justify-content:flex-start oben im Fluss liegen) sind davon nicht
       betroffen, sitzen weiterhin oben. */
    height: 100dvh !important;
  }
}
/* Merles Folge-Wunsch zum Fix oben: "dafuer muss der Button 'Stelle Dir
   deine Box zusammen' etwas margin oberhalb bekommen" - eigener Button
   gleich unterhalb des Hero (eigene Klasse .stelldirdeineboxzusammen).
   Schaetzwert, bitte live gegenchecken. */
@media screen and (orientation: landscape) and (max-height: 500px) {
  body .stelldirdeineboxzusammen {
    margin-top: 24px !important;
  }
  /* NEU (Round 28, 37. Batch): Merle "der margin-top auf
     .stelldirdeineboxzusammen wirkt auf Handy quer nicht, idk warum - bitte
     stattdessen auf die umgebende Section-Klasse setzen". Moegliche Ursache:
     ".stelldirdeineboxzusammen" sitzt evtl. auf einem Element, dessen
     eigener Abstand von einer anderen, spaeter/spezifischer greifenden
     nativen Regel ueberschrieben/aufgehoben wird (z.B. wenn es ein Flex-/
     Grid-Kind ohne eigenen Block-Fluss ist, auf dem margin-top wirkungslos
     bleibt). Fix: ZUSAETZLICH dieselbe Regel auf die von Merle genannte
     umgebende Section-Klasse gesetzt (nur Mobil-Querformat, wie gewuenscht)
     - die urspruengliche Regel oben bleibt bewusst bestehen (koennte auf
     anderen Theme-Sektionen trotzdem greifen, schadet nichts). */
  body .section--page-width.color-custom-template--31616257655114__section_7xGaLq {
    margin-top: 24px !important;
  }
}

/* .hero-text-group__headline erhoehte line-height nur bei :hover (99% ->
   105%). Touch-Geraete kennen kein Hover, Zeilen ueberschneiden sich also
   staendig. Auf Mobil die groessere line-height direkt als Basis gesetzt. */
/* KORREKTUR (Round 19, Anfang Fluid-Umstellung): war auf max-width:749px
   begrenzt - oberhalb davon griff gar keine Touch-Hover-Ersatzregel mehr.
   Touchscreens enden aber nicht bei 749px (iPads/Tablets haben genau wie
   Handys keinen echten Maus-Hover) - auf 1199px erweitert, die native
   Theme-eigene Grenze fuer "richtiges Desktop" (siehe deren eigene
   @media(min-width:1200px)-Regeln). Nur die REICHWEITE geaendert, keine
   Werte - alles hier ist ohnehin in em/% (siehe unten), skaliert also
   automatisch mit der jeweiligen Schriftgroesse mit. */
@media screen and (max-width: 1199px) and (pointer: coarse), screen and (max-width: 1199px) and (orientation: portrait) {
  /* AB 7.10. (Teil 6): Merle meldet, die Headline-Hoehe "schwankt zwischen
     272px und 264px" - Root Cause vermutlich: fitHero() (mobile-fixes.js)
     laeuft einmal SOFORT beim Laden (misst dabei evtl. noch mit der
     Ersatzschrift, falls das eigene Webfont noch nicht fertig geladen ist)
     und dann NOCHMAL, sobald document.fonts.ready feuert (korrekte
     Schriftmetrik) - zwei unterschiedliche, aber beide "richtige" Messungen
     zu zwei Zeitpunkten, die als sichtbarer Sprung wahrgenommen werden.
     Eine echte Terminierungs-Loesung braeuchte mehr Zeit zum Live-Testen;
     als sofortige Linderung hier eine weiche Transition auf font-size, damit
     ein evtl. zweiter Korrekturlauf als sanftes Angleiten statt als Sprung
     wirkt. */
  /* KORREKTUR (Round 28, 25. Batch): Merle meldet (wortgleich zu einer alten
     Meldung) "bei ca. quadratischem Desktopfenster erhoeht sich die
     lineheight von Heroheadline, das darf nicht sein, erst bei einem
     Hochkant-Fenster". ECHTER ROOT CAUSE live gefunden: diese Regel hatte
     bisher NUR eine Breitenbedingung (max-width:1199px), OHNE Ruecksicht auf
     Zeigegeraet/Ausrichtung - ein normales Desktop-Browserfenster mit Maus,
     das lediglich auf <1200px verschmaelert wird (egal ob dabei noch breiter
     als hoch oder schon quadratisch), fiel dadurch GENAUSO in diese Regel wie
     ein echtes Touch-Handy, und sprang dadurch abrupt von ca. 96% (gemessen
     bei >=1200px Breite) auf 106% - genau der gemeldete Sprung, ausgeloest
     rein durch die Fensterbreite, nicht durch die Ausrichtung. Fix: Regel
     jetzt nur noch aktiv fuer (a) echte Touch-Geraete (pointer:coarse) in
     JEDER Ausrichtung - das war der urspruengliche Zweck laut Kommentar oben
     ("Touch-Geraete kennen kein Hover") und bleibt dadurch fuer Handy
     Hochkant/Quer unveraendert - oder (b) ein wirklich hochkant-orientiertes
     Fenster (auch mit Maus), wie von Merle gewuenscht. Ein mit der Maus
     bedientes, verschmaelertes, aber weiterhin breiter-als-hoch/quadratisches
     Desktopfenster faellt jetzt NICHT mehr hierunter. Live verifiziert
     (echtes Chrome-Fenster, zwei verschiedene Breiten >=1200px): konstant
     96.17% ueber mehrere Seitenverhaeltnisse hinweg, kein Sprung mehr beim
     Verschmaelern, solange es nicht tatsaechlich hochkant wird. */
  body .hero-text-group__headline {
    transition: font-size 0.25s ease-out !important;
    line-height: 106% !important; /* AB 7.10.: war 115%, auf Merles Wunsch "etwas geringer" weiter reduziert - Richtwert, bitte live gegenchecken und ggf. nachjustieren */
    /* KORREKTUR (Round 20, zurueckgenommen): Merle hatte den festen 45px-Wert
       (siehe weiter unten) testweise unscoped (auch Mobil) gesetzt - auf dem
       Handy sah das falsch aus, der Stroke muss dort proportional zur (von
       fitHero() live berechneten) Schriftgroesse mitschrumpfen, "wie vorher".
       Deshalb hier der fruehere em-Wert zurueckgesetzt: skaliert automatisch
       mit jeder von fitHero() gesetzten Schriftgroesse, weil em relativ zur
       eigenen font-size ist. Gilt jetzt wieder fuer Handy Hochkant UND
       (korrigiert, siehe unten) Handy Quer UND iPad Hochkant. */
    -webkit-text-stroke-width: 0.395em !important;
  }
}
/* NEU (neue Anfrage): Merle "bei schmalen Fenstern wird der Webstroke zu
   dick, 15% weniger" - ausdruecklich fuer die schmale/quadratische "echter
   Desktop"-Zone (750-1199px) gemeldet, NICHT fuer echtes Handy-Hochformat
   (per Mausangabe + Screenshot-Breite erkennbar als Desktop-Browserfenster,
   nicht Touch-Geraet) - echtes Handy soll laut Merles eigener, frueherer
   Aussage ("ist perfekt, nicht anfassen") unveraendert bleiben. Die obige
   Regel (0.395em) gilt fuer BEIDE Faelle gemeinsam (Touch UND schmales
   Desktop) - deshalb hier bewusst eine engere, NACH ihr stehende (= bei
   gleicher Spezifitaet gewinnende) Zusatzregel nur fuer (min-width:750px),
   die echtes Handy (<=749px) ausklammert. 0.395em * 0.85 = 0.33575em.
   KORREKTUR (gleiche Session, Nachtest bei 765x989): Merle nennt jetzt einen
   eigenen, noch etwas kleineren Zielwert direkt: "webstroke: 0.2975em" -
   1:1 uebernommen (war 0.33575em). Zusaetzlich "line-height 5% a tiny bit
   bigger" - bezieht sich auf die 106%-Basisregel weiter oben (derselbe
   gemeinsame Touch+Desktop-Block) - hier eine eigene, engere
   line-height-Ueberschreibung nur fuer diese schmale Desktop-Zone ergaenzt:
   106% * 1.05 = 111.3%. */
@media screen and (min-width: 750px) and (max-width: 1199px) and (orientation: portrait) {
  body .hero-text-group__headline {
    -webkit-text-stroke-width: 0.2975em !important;
    line-height: 111.3% !important;
  }
}
/* NEU (neue Anfrage): Merle "webstroke 5% weniger dick auf Mobil Hochformat"
   - echtes Handy (<=749px) hatte bisher KEINE eigene, engere Stroke-Regel
   und lief auf dem gemeinsamen 0.395em-Basiswert weiter oben. 0.395em * 0.95
   = 0.37525em. Betrifft NICHT die schmale Desktop-Zone (die hat bereits ihre
   eigene, separate Regel direkt oberhalb). */
@media screen and (max-width: 749px) and (orientation: portrait) {
  body .hero-text-group__headline {
    -webkit-text-stroke-width: 0.37525em !important;
  }
}
/* KORREKTUR (Round 20): auf Handy Quer griff die obige Regel bisher NICHT,
   weil dieser ganze Media-Query-Block nur "orientation:portrait" deckt -
   Handy Quer braucht denselben proportionalen Stroke, hat aber keinen
   eigenen Block weiter unten. Eigene, schmale Zusatzregel dafuer (gleiche
   Hoehen-Erkennung wie beim Hero/Produktraster weiter unten, siehe dort). */
@media screen and (orientation: landscape) and (max-height: 500px) {
  body .hero-text-group__headline {
    -webkit-text-stroke-width: 0.395em !important;
  }
}
/* KORREKTUR (Round 20): "auf dem Desktop breit sah der feste 45px-Wert gut
   aus" (Merles Rueckmeldung) - bleibt DORT bestehen, aber nur dort. Gleiche
   Breiten/Hoehen-Bedingung wie Abschnitt 16b (Hero: Desktop/breite Fenster)
   weiter unten, damit Handy-Quer (hohe Breite, aber kurze Hoehe) sicher
   ausgeschlossen bleibt und nicht versehentlich wieder den festen Wert
   bekommt.
   KORREKTUR (Round 26): diese "echter Desktop"-Bedingung (hier UND an den
   beiden anderen Stellen in der Datei, die exakt denselben Media-Query-Text
   nutzen - Hero-Positionierung weiter unten, Tagline-SVG-Groesse weiter
   unten) hatte eine bekannte Luecke: ihr 750-1199px-Zweig verlangte bisher
   zusaetzlich "orientation:landscape". Ein QUADRATISCHES oder HOCHFORMATIGES
   Desktop-Browserfenster in diesem Breitenbereich (z.B. ueber die Shopify-
   Theme-Editor-"Eigene Groesse"-Vorschau erzeugbar, aber auch ein echtes,
   schmal gezogenes Browserfenster) erfuellte dadurch WEDER "echter Desktop"
   NOCH "Handy Quer" (das braucht ebenfalls Querformat) - es fiel in eine
   bisher unbehandelte Luecke und bekam teils noch unveraendertes natives
   Theme-Verhalten. Merles Meldung (Round 26, Screenshot "Hero-Headline sitzt
   nicht mittig" bei quadratischem Fenster) ist ein direktes Symptom davon.
   Fix: Bedingung um einen dritten Zweig erweitert - 750-1199px, JEDE
   Ausrichtung, aber nur bei echter Maus/Trackpad-Bedienung
   (hover:hover/pointer:fine). Das faengt genau die bisher luecke-haften
   quadratischen/hochformatigen Desktop-Fenster ein, ohne iPad & Co
   (pointer:coarse, eigene Behandlung siehe R57/R58) zu beruehren.
   KORREKTUR (Round 26, 3. Feedback-Batch, NUR HIER zurueckgenommen): Merles
   neue Meldung "bei schmalem Desktop ist der Hero immer noch nicht an die
   Handyskalierung angelehnt" - Root Cause live im Code gefunden: durch den
   oben beschriebenen dritten Zweig bekam der Webkit-Stroke im schmaler-
   Desktop-Bereich (750-1199px, Maus) jetzt denselben FESTEN 45px-Wert wie
   ein echter breiter Monitor, statt wie auf Handy/iPad proportional mit der
   von fitHero() live berechneten Schriftgroesse mitzuschrumpfen (0.395em,
   Regel weiter oben in Abschnitt 4, gilt bereits unconditional bis 1199px).
   Die generelle 0.395em-Regel griff dadurch im schmaler-Desktop-Bereich nie,
   weil diese hier spaeter in der Kaskade steht und bei gleicher Spezifitaet
   gewinnt. Die Hero-POSITIONIERUNG (naechstes Vorkommen dieser Media Query
   weiter unten, 100dvh/Zentrierung) UND die Tagline-SVG-Groesse (drittes
   Vorkommen) sind davon NICHT betroffen und bleiben unveraendert erweitert -
   nur die Stroke-Breite hier wird auf den urspruenglichen Zustand (ohne den
   dritten Zweig) zurueckgesetzt, damit sie im schmaler-Desktop-Bereich
   wieder dem Mobil-Vorbild folgt. AUSDRUECKLICHER HINWEIS: optisch nicht in
   meiner Sandbox bei echter schmaler Fensterbreite nachstellbar (gleiche
   resize_window-Einschraenkung wie bei allen anderen Breiten-Fixes) - bitte
   gegenchecken, ob das jetzt wie gewuenscht aussieht. */
/* KORREKTUR (Round 27): Merle hat live im Inspector "etwas reduziert"
   getestet und per Screenshot genau diesen Wert bestaetigt (war 45px). */
@media screen and (min-width: 1200px), screen and (min-width: 750px) and (orientation: landscape) and (min-height: 501px) {
  body .hero-text-group__headline {
    /* KORREKTUR (neue Anfrage): Merle "auf breiten Bildschirmen ist der
       Webstroke der Heroheading etwas zu duenn" - 10% erhoeht (war 35px).
       KORREKTUR (gleiche Session, Nachtest): Merle "doch wieder ein wenig
       schmalerer Webstroke (das Mittelding zwischen vorher und jetzt)" -
       Mittelwert aus 35px (vorher) und 38.5px (+10%, letzter Versuch):
       (35 + 38.5) / 2 = 36.75px. */
    -webkit-text-stroke-width: 36.75px !important;
  }
}

/* NEU (neue Anfrage): Merle "kannst du den Dropshadow in die andere Richtung
   werfen?" - bezieht sich auf .hero-text-group__headline. Dieser Schlagschatten
   steht NICHT in unserem eigenen CSS/JS (per grep bestaetigt), sondern ist ein
   natives Theme-Attribut (siehe claude/section-ids-referenz.md, dort bereits
   dokumentiert: "filter: drop-shadow(10px 10px 10px rgba(90,10,44,0.7));" -
   feste px-Werte, nicht responsive).
   KORREKTUR (neue Anfrage): Merle hat per eigenem DevTools-Screenshot den
   exakten Zielwert genannt: "drop-shadow(-8px 15px 10px rgba(90, 10, 44,
   0.7))" - mein erster Versuch (diagonale Spiegelung -10px/-10px) war in die
   falsche Richtung. Jetzt 1:1 ihr genannter Wert, auf allen Breiten (kein
   Breakpoint genannt). */
body .hero-text-group__headline {
  filter: drop-shadow(-8px 15px 10px rgba(90, 10, 44, 0.7)) !important;
}

/* NEU (neue Anfrage): Merle "die Subline-Schlagschatten sollte auch in die
   andere Richtung gehen: drop-shadow(-5px 5px 5px rgba(90, 10, 44, 0.5))" -
   .hero-text-group__subline hatte bisher keine eigene Schlagschatten-Regel
   von uns (nur die native Theme-Vorgabe, falls vorhanden) - hier 1:1 ihr
   genannter Zielwert, unscoped. */
body .hero-text-group__subline {
  filter: drop-shadow(-5px 5px 5px rgba(90, 10, 44, 0.5)) !important;
}

/* Fix: Bio-/Pflanzlich-Siegel 50% kleiner + nicht mehr rechts abgeschnitten.
   KORREKTUR (Round 19): die Hoehe hat einen bekannten, dokumentierten
   Desktop-Wert (80px, native) - echtes clamp() zwischen 40px (Handy) und
   80px (Desktop ab 1200px), kein fester Umbruch mehr noetig, die Groesse
   waechst jetzt stufenlos mit der Breite. right/gap bleiben Schaetzwerte
   ohne bekannten Desktop-Vergleichswert, daher nur auf 1199px erweitert
   statt interpoliert. */
/* KORREKTUR (Round 28/Batch 16): Merle meldet "Bio-Siegel immer noch
   angeschnitten auf Handy Hoch UND Quer". Root Cause beim Durchgehen des
   Codes gefunden: fuer echte Touch-Handys (schmale Breite, KEIN
   hover:hover/pointer:fine) greift ausschliesslich DIESE Regel hier - die
   an anderer Stelle (Abschnitt 16b, "Desktop/breite Fenster") als
   "konsolidiert, das ist die Regel die tatsaechlich gewinnt" dokumentierte
   right:3%-Variante gilt NUR fuer echten Desktop/Maus bzw. Tablet-Querformat
   mit ausreichender Hoehe (min-height:501px) - ein echtes Handy (Hoch ODER
   Quer, meist < 500px Hoehe, touch) erfuellt KEINE dieser Bedingungen und
   bekommt daher nur den hier gesetzten Wert. Der war mit 4% offenbar zu
   knapp. Defensiv erhoeht - Schaetzwert, da ich ein echtes Handy-Viewport in
   meiner Sandbox nicht nachstellen kann (bekannte resize_window-Einschraenkung),
   bitte live gegenchecken. */
/* ROLLBACK (Round 28, 22. Batch): Merle meldet nach diesem Batch eine neue
   Hero-Dezentrierung ("Headline nicht wieder mittig") und bittet darum,
   ALLES im Hero-Bereich auf den Stand von vor diesem Batch zurueckzudrehen,
   bevor weiter am Siegel-right-Problem gearbeitet wird. Die unten gestandene
   neue, ungescopte ".hero-text-group__siegel-wrapper"-Basis-Regel (21.
   Batch) ist deshalb erstmal wieder ENTFERNT (nicht nur auskommentiert,
   siehe Originaltext im vorigen Batch/Transcript) - die Diagnose selbst
   (natives Shopify-Position-Feature mit eingebettetem <style>-Tag,
   right:8%, kein !important, siehe GEFUNDENER-BUG-Kommentare weiter unten)
   bleibt unveraendert gueltig und wird Merle separat, passiv, OHNE neuen
   CSS-Fix mitgeteilt - ein erneuter Fix-Versuch folgt erst nach ihrer
   Rueckmeldung. */

/* KORREKTUR (Round 28, 24. Batch): die bisherige "TOTER CODE"-Einschaetzung
   hier war VERALTET/FALSCH - live noch einmal genau nachvollzogen, welche
   Media Query die "KONSOLIDIERT"-Regel (weiter unten, Suche danach)
   inzwischen tatsaechlich hat: "screen and (min-width: 1200px), screen and
   (min-width: 750px) and (orientation: landscape) and (min-height: 501px),
   screen and (min-width: 750px) and (max-width: 1199px) and (hover: hover)
   and (pointer: fine)" - das ueberschneidet sich NICHT mit echtem Handy-
   Hochformat (Touch, meist < 750px Breite) UND NICHT mit echtem Handy-
   Querformat (Touch, meist < 501px Hoehe): fuer beide bleibt DIESE Regel
   hier die einzige wirksame. Erklaert Merles "auf Handy hoch sind die
   Siegel wieder abgeschnitten": 7% war hier (isoliert vom spaeteren 9%-Wert
   der anderen Regel) nie nachgezogen worden. Fix: auf denselben, bereits
   als ausreichend bestaetigten Wert (9%) angehoben - bewusst NUR dieser
   eine Wert geaendert (kein neuer ungescopter Override wie im 21. Batch),
   um das Hero-Zentrierungs-Risiko von damals zu vermeiden. */
/* KORREKTUR (Round 28, 25. Batch): Merle "auf dem Handy brauchen in allen
   Versionen die Bio-Siegel noch mehr right, ein bisschen sind sie immer noch
   angeschnitten" - 9% reichte demnach immer noch nicht. Weiter angehoben auf
   13% (groesserer Sprung als die bisherigen 1-2-Prozentpunkt-Schritte, da
   die kleinen Schritte bisher wiederholt nicht ausgereicht haben).
   Schaetzwert, bitte live gegenchecken. */
@media screen and (max-width: 1199px) {
  body .hero-text-group__siegel-wrapper {
    /* KORREKTUR (Round 28, 35. Batch): Merle "auf dem echten Handy schmal
       die Bio-Siegel ein Minimüh weiter rechts" - leicht von 13% auf 11.5%
       reduziert (kleiner Nudge, wie gewuenscht). */
    right: 11.5% !important; /* war 13% */
    gap: 8px !important;
  }
}
/* KORREKTUR (Round 28, 25. Batch): Merle "Bio Siegel kleiner, 8%" - alle drei
   clamp()-Eckwerte um 8% reduziert (war 40px/21px+5vw/80px). */
/* NEU (Round 28, 32. Batch): Merle "Bio Siegel 50% größer" (Desktop,
   Screenshot "Generell") - alle drei clamp()-Eckwerte um 50% erhöht (war
   37px/19px+4.6vw/74px). Diese Regel ist UNSCOPED (gilt auf jeder Breite),
   siehe Kommentar oben zum Fund, dass die weiter unten im Desktop-Block
   stehende, eigentlich vorgesehene Regel manchmal live nicht als CSSOM-Regel
   ankommt - deshalb hier zusätzlich (und weiter unten) auf denselben
   vergrößerten Wert gebracht, damit die Vergrößerung unabhängig davon
   greift, welcher der beiden Blöcke gerade lädt. */
body .hero-text-group__siegel {
  height: clamp(55.5px, 28.5px + 6.9vw, 111px) !important; /* war clamp(37px, 19px + 4.6vw, 74px), 50% größer */
}
/* NEU (Round 28, 25. Batch): ECHTER ROOT CAUSE fuer Merles "Logo wird teils
   in der Hoehe gestaucht/verzerrt, muss sein Originalseitenverhaeltnis
   behalten" live gefunden. mobile-fixes.js (fitHero, Schritt C) setzt bei
   Platzmangel NUR die Hoehe des Logos per style.setProperty('height', ...,
   'important') - die Breite wird dabei bewusst NICHT angefasst, damit ein
   <img> mit width:auto seine Breite automatisch im nativen Seitenverhaeltnis
   nachzieht. Live am echten Desktop-Tab nachgemessen: das Logo-<img> hat
   nativ object-fit:fill UND eine eigene, von Shopifys Theme gesetzte feste
   Breite (keine der bisherigen width:auto-Regeln dieser Datei lag
   unconditional/unscoped genug, um das auf echtem Desktop zu ueberschreiben -
   die einzige bisherige width:auto-Regel fuer dieses Element steckt in einem
   breitenabhaengigen Block weiter unten in dieser Datei). Sobald die Hoehe
   per JS verkleinert wird, blieb die Breite dadurch unveraendert stehen -
   genau die gemeldete Stauchung. Fix: width:auto + object-fit:contain jetzt
   UNSCOPED (gilt auf jeder Breite/Ausrichtung) gesetzt, damit das Bild IMMER
   sein eigenes Seitenverhaeltnis behaelt, unabhaengig davon, ob/welche
   Breiten-Regel gerade sonst noch greift. */
body .hero-text-group__logo {
  width: auto !important;
  object-fit: contain !important;
}
/* NEU (Round 28, 27. Batch): Merle "Logo trifft sich auf Desktop immer noch
   mit der Hero-Headline, notfalls Logo/Heroheadlinegroup kleiner". ROOT
   CAUSE live bestaetigt (1600x757, echter Desktop-Tab): die eigentlich
   vorgesehene Hoehen-Begrenzung ".hero-text-group__logo { height:
   clamp(36px, 8dvh, 110px) }" liegt im selben, schon mehrfach dokumentierten
   Media-Query-Block weiter unten in dieser Datei, der live nachweislich oft
   NICHT als CSSOM-Regel ankommt (siehe Kommentare dort/im Projekt-Doc). Live
   gemessen: OHNE diese Begrenzung rendert das Logo auf seine volle native
   Bildgroesse (400x377px) - mobile-fixes.js (fitHero, echter-Desktop-Zweig)
   misst genau diese ungedeckelte Groesse als Ausgangswert fuer seine
   Platz-Berechnung, wodurch je nach Fensterformat zu wenig Platz uebrig
   bleibt und das Logo die Subline-Pille ueberlappt. Fix: dieselbe
   Hoehen-Begrenzung hier zusaetzlich UNCONDITIONAL fuer echten Desktop
   dupliziert (wie schon bei width:auto/object-fit:contain oben) - dadurch
   wirksam unabhaengig davon, ob der andere Block gerade greift oder nicht.
   Nur ab 1200px (echter Desktop) - Hochkant/Handy-Quer regeln ihre eigene
   Logo-Groesse unabhaengig ueber transform:scale (siehe die jeweiligen
   Abschnitte), dort unveraendert. Etwas kleiner als der urspruenglich
   vorgesehene Wert (90px statt 110px Obergrenze), da Merle explizit "darf
   kleiner werden" sagt. */
/* ERWEITERT (Round 28, 31. Batch): ECHTER ROOT CAUSE fuer Merles "bei sehr
   schmalem Browserfenster wird der Abstand zwischen Logo und Textgroup viel
   zu gross" gefunden - live an einem echten Desktop-Tab nachgemessen (1000px
   Breite, Hochkant-Maus-Desktop, also NICHT Handy): diese Hoehen-Begrenzung
   galt bisher NUR ab 1200px. Zwischen 750-1199px (schmaleres Desktop-/iPad-
   Quer-Fenster mit Maus, oder jedes Desktop-Fenster in diesem Breitenbereich)
   griff GAR KEINE Hoehen-Begrenzung - das Logo rendert dort live nachgewiesen
   auf seine volle native Bildgroesse (400x377px statt der vorgesehenen
   28-90px), wodurch Schritt C (mobile-fixes.js) einen riesigen, falschen
   Platzbedarf berechnet und die Positionierung/den Abstand durcheinanderbringt.
   Fix: dieselbe Breakpoint-Kombination wie bereits fuer .hero-wrapper/
   .hero__container (Abschnitt 16b, "echtes breites Desktop ODER 750-1199px im
   Querformat/mit Maus") auch hier verwendet, damit die Hoehen-Begrenzung in
   GENAU denselben Faellen greift wie die uebrige Desktop-Logik. */
@media screen and (min-width: 1200px), screen and (min-width: 750px) and (orientation: landscape) and (min-height: 501px), screen and (min-width: 750px) and (max-width: 1199px) and (orientation: portrait) {
  /* NEU (Round 28, 32. Batch): Merle "Logo größer, doppelt so groß" (Desktop,
     Screenshot "Generell"). Alle drei clamp()-Eckwerte verdoppelt (war
     clamp(28px, 6dvh, 90px)) - siehe auch die zweite, weiter unten im
     großen Desktop-Block stehende Fassung derselben Regel (dort ebenfalls
     verdoppelt), aus demselben Grund wie beim Bio-Siegel oben: unklar, welche
     der beiden Fassungen live tatsächlich ankommt, daher beide synchron
     gehalten.
     KORREKTUR (Round 28, 35. Batch): Merle "Logo auf dem Desktop 20%
     kleiner" - um 20% reduziert, synchron mit der zweiten Fassung weiter
     unten im großen Desktop-Block gehalten. */
  body .hero-text-group__logo {
    /* KORREKTUR (Round 28, 37. Batch): Merle "Logo 8% kleiner" (breiter
       Desktop) - alle drei clamp()-Eckwerte zusaetzlich um 8% reduziert
       (war clamp(44.8px, 9.6dvh, 144px)). Synchron mit der zweiten,
       weiter unten im grossen Desktop-Block stehenden Fassung derselben
       Regel gehalten (siehe dort). */
    /* NEU (Round 28, 76. Batch): Merle "Logo auch größer" (breiter Desktop,
       zusammen mit der groesseren Headline). Alle drei clamp()-Eckwerte um
       25% erhoeht. Synchron mit der zweiten Fassung weiter unten im grossen
       Desktop-Block gehalten (siehe dort), trotz der unterschiedlichen
       Ausgangswerte beider Regeln (historisch bereits auseinandergedriftet,
       siehe Kommentare dort - beide hier dennoch um denselben Faktor erhoeht,
       damit unabhaengig davon, welche live tatsaechlich gewinnt, das Logo in
       jedem Fall groesser wird). */
    height: clamp(51.52px, 11.04dvh, 165.6px) !important; /* war clamp(41.216px, 8.832dvh, 132.48px), 25% groesser */
  }
}
/* KORRIGIERT (Round 28, 28. Batch): die hier ZUVOR ergaenzte Regel
   (".hero-text-group__logo-link { position: absolute !important; ... }")
   war der ECHTE Grund, warum Merle direkt danach meldete "das Logo ist auf
   dem Desktop komplett weg". Live nachgewiesen (1601x757, echter Tab,
   vollstaendige Rect-/computed-style-Messung von Link UND Bild): Shopifys
   natives "Position"-Feature setzt sein eigenes position:absolute NICHT auf
   ".hero-text-group__logo-link" (den <a>-Wrapper), sondern direkt auf
   ".hero-text-group__logo" (das <img> selbst) - mit "bottom:3.5%; left:50%;
   transform:translateX(-50%)". Durch die neue Regel hier wurde zusaetzlich
   der WRAPPER ebenfalls position:absolute - zwei verschachtelte, gegenseitig
   positionierte Elemente (das <img> bezieht sein eigenes "left:50%" auf den
   jetzt ebenfalls absolut positionierten Link, dessen eigene Breite wiederum
   nur vom <img>-Inhalt abhaengt) ergeben einen zirkulaeren Breiten-Bezug, den
   Chrome nachweislich auf 0x0 fuer BEIDE Elemente aufloeste (computed width/
   height/left/right je 0px, Rect komplett leer) - das Logo verschwand
   dadurch vollstaendig, nicht nur optisch klein. Fix: diese Regel komplett
   entfernt, ".hero-text-group__logo-link" bleibt unangetastet/unpositioniert
   wie urspruenglich. Stattdessen wird ".hero-text-group__logo" (das <img>,
   das Shopify ohnehin schon positioniert) direkt per "bottom:auto" von
   seinem nativen bottom:3.5%-Anker befreit, damit mobile-fixes.js (fitHero,
   Schritt C) stattdessen per "top" exakt unter die Subline positionieren
   kann, OHNE die Breiten-Berechnung zu stoeren - live verifiziert (siehe
   Projekt-Doku): Bild zeigt danach wieder korrekte 48x45px statt 0x0, UND
   JS setzt jetzt "top" direkt auf das <img> (vorher faelschlich auf den
   nie positionierten Link, daher ohne jede Wirkung - siehe mobile-fixes.js).
   .hero__content-wrapper hat bereits unconditional position:relative (live
   bestaetigt per getComputedStyle, 1601x757 UND andere Formate) und dient
   damit als stabiler, nie-kollabierender Containing Block fuer das <img>. */
/* ERWEITERT (Round 28, 31. Batch): aus demselben Grund wie direkt oberhalb
   (Hoehen-Begrenzung) auf dieselbe Breakpoint-Kombination erweitert - ohne
   "bottom:auto" bleibt der native "bottom:3.5%"-Anker auch im 750-1199px-
   Bereich aktiv und konkurriert dort mit Schritt C's "top"-Positionierung. */
@media screen and (min-width: 1200px), screen and (min-width: 750px) and (orientation: landscape) and (min-height: 501px), screen and (min-width: 750px) and (max-width: 1199px) and (orientation: portrait) {
  body .hero-text-group__logo {
    bottom: auto !important;
  }
}

/* NEU (Round 28, 29. Batch): Bio-Siegel-Positionierung auf echtem Desktop,
   ENDGUELTIG LIVE VERIFIZIERT (1600x757, echter Chrome-Tab, per
   getComputedStyle + CSSOM-Rule-Walk durch ALLE geladenen Stylesheets).
   Root Cause fuer Merles "Bio-Siegel sind jetzt etwas zu weit links"
   gefunden: der weiter unten in dieser Datei stehende, grosse Media-Query-
   Block (beginnt bei "@media screen and (min-width: 1200px), screen and
   (min-width: 750px) and (orientation: landscape)...", enthaelt u.a. die
   bisher fuer Desktop vorgesehene ".hero-text-group__siegel-wrapper { right:
   9%; ... }"-Regel) ist auf dem echten Live-Tab NACHWEISLICH KOMPLETT TOT -
   nicht nur diese eine Regel, sondern JEDE Regel in diesem Block (per CSSOM-
   Scan durch alle document.styleSheets bestaetigt: weder die 9%-Siegel-Regel
   noch die dort ebenfalls stehende Logo-Hoehen-Regel "clamp(36px, 8dvh,
   110px)" tauchen live irgendwo auf). Dieser Block wurde in frueheren
   Batches bereits mehrfach als "vermutlich tot" vermerkt - das ist jetzt die
   endgueltige Bestaetigung. Ohne diese Regel gewinnt stattdessen Shopifys
   eigene, native (im Theme per "Position"-Feature eingebettete) Regel:
   ".hero-text-group__siegel-wrapper { position:absolute; bottom:3%;
   right:8%; transform:translateX(40%); ...}" (ohne !important, aber ohne
   Konkurrenz trotzdem wirksam). Das translateX(40%) verschiebt das Element
   zusaetzlich um 40% seiner EIGENEN Breite nach rechts - am Live-Tab
   gemessen ergab das einen Abstand von nur noch ~54px (~3,4%) zur rechten
   Bildschirmkante, NAEHER am Rand als die eigentlich vorgesehenen 9% (ohne
   Transform). Trotzdem meldet Merle "zu weit links" - daher hier NICHT die
   alte 9%-Regel reaktiviert (das wuerde den Abstand zur Kante sogar
   VERGROESSERN, also noch weiter nach links verschieben, das Gegenteil von
   dem was gewuenscht ist), sondern ein neuer, kleinerer Abstand gesetzt UND
   das verwirrende native translateX(40%) komplett entfernt (transform:none),
   damit right/bottom allein die Position eindeutig bestimmen. Schaetzwert
   fuer den genauen Prozentwert (3%, naeher an der Kante als die vorherigen
   effektiven ~3,4%) - bitte live gegenchecken, ob das reicht oder noch mehr
   nach rechts soll. In einem KNOWN-GOOD, einfachen "min-width:1200px"-Block
   platziert (nicht im oben beschriebenen toten Komplex-Block) - dieselbe Art
   Block, in dem die Logo-Hoehen-Regel direkt darueber nachweislich
   funktioniert. */
@media screen and (min-width: 1200px) {
  body .hero-text-group__siegel-wrapper {
    position: absolute !important;
    top: auto !important;
    left: auto !important;
    right: 3% !important;
    bottom: 3% !important;
    transform: none !important;
    margin: 0 !important;
    display: flex !important;
    justify-content: flex-end !important;
    align-items: center !important;
    gap: 6px !important;
    z-index: 4 !important;
  }
  body .hero-text-group__siegel {
    height: clamp(23px, 5.18dvh, 80px) !important;
    width: auto !important;
  }
}

/* Header-Topbar kompakter + Icons kleiner. Die vier "Bookend"-Spalten
   (Hamburger/Suche/Warenkorb/Konto) sind fest 44px breit; Klickflaeche laeuft
   ueber .svg-wrapper, das Icon selbst ueber das verschachtelte svg. Da
   --button-size/--icon-size-md globale, siteweite Variablen sind, werden
   stattdessen feste px-Werte nur innerhalb dieser Header-Sektion und nur auf
   Mobil gesetzt - betrifft automatisch alle vier Icons gleichermassen. */
@media screen and (max-width: 749px) {
  #shopify-section-sections--31616257753418__header_section .header__row--top {
    padding-block: 4px !important;
  }

  #shopify-section-sections--31616257753418__header_section .header__columns,
  #shopify-section-sections--31616257753418__header_section #header-component[data-menu-style='drawer'] .header__columns {
    --header-mobile-bookend: 36px !important; /* war 44px */
  }

  #shopify-section-sections--31616257753418__header_section .header__row--top .svg-wrapper {
    height: 26px !important; /* statt var(--button-size) */
    width: 26px !important;
  }

  #shopify-section-sections--31616257753418__header_section .header__row--top .svg-wrapper svg {
    width: 20px !important; /* statt var(--icon-size-md) */
    height: 20px !important;
  }
}

/* Warenkorb-Icon unsichtbar, weil das native Mengen-Badge (.cart-bubble) fest
   20x20px ist und nicht auf die verkleinerte .svg-wrapper (26x26px) reagiert
   - deckte ca. 77% des Icons ab. Fix: Badge selbst verkleinert, oben rechts
   verankert. */
@media screen and (max-width: 749px) {
  #shopify-section-sections--31616257753418__header_section .header__row--top .cart-bubble {
    transform: scale(0.6) !important;
    transform-origin: top right !important;
  }
}

/* Mobile Navigation unsichtbar: eine Custom-Color-Klasse setzt --color auf
   dunkles Gruen, das im Menue-Drawer (dunkler Hintergrund) untergeht.
   Textfarbe zurueck auf Creme, nur innerhalb des Drawers. Korrektur: die
   betroffene Klasse sitzt nicht als Nachkomme, sondern direkt auf demselben
   Element wie .menu-drawer - die urspruengliche Nachkommen-Regel traf sie
   nie. Beide Varianten (kombinierte Klasse direkt + Nachkommen-Regel als
   Netz) jetzt abgedeckt. */
body .menu-drawer.color-custom-AdnBrdHhRZ0Q5bGJ3S__header-menu-1,
body .menu-drawer .color-custom-AdnBrdHhRZ0Q5bGJ3S__header-menu-1,
body .menu-drawer .color-custom-AdnBrdHhRZ0Q5bGJ3S__header-menu-1 .text-block {
  --color: var(--pv-cream, #f5ffe4) !important;
  --color-foreground-rgb: 245 255 228 !important;
}


/* ----------------------------------------------------------------
   2. "STELLE DIR DEINE BOX ZUSAMMEN"-BUTTON
   ---------------------------------------------------------------- */

/* KORREKTUR (Round 19): auf 1199px erweitert (war 749px) - rein skalare
   clamp()-Werte, kein bekannter Desktop-Vergleichswert noetig, da der
   Ausdruck selbst schon stufenlos skaliert. */
@media screen and (max-width: 1199px) {
  body .stelldirdeineboxzusammen {
    /* GEAENDERT (Round 28/Batch 18): Merle "nur LEICHT groesser werden
       lassen, dafuer muss es vorher noch etwas kleiner werden um dann zum
       jetztzustand gross zu werden" - der bisherige Ruhezustand (clamp(0.85rem,
       4.4vw, 1.6rem)) wird jetzt der neue HOVER/TOUCH-Zielwert (siehe
       Touch-Regel weiter unten, @media(hover:none)); der Ruhezustand hier
       selbst auf ca. 90% davon verkleinert, damit das Wachstum beim
       Hover/Antippen insgesamt dezent wirkt, aber am bekannten "jetzt
       zustand" (dem bisherigen Wert) landet statt neu geschaetzt zu werden.
       War: clamp(0.85rem, 4.4vw, 1.6rem). */
    font-size: clamp(0.76rem, 3.9vw, 1.44rem) !important;
    /* ENTFERNT (Round 28/Batch 16): dieser Wert stammte aus Round 19, von
       VOR dem Round-27-Batch-13-Fix ("Stroke komplett weg", siehe Abschnitt
       2 oben, -webkit-text-stroke: 0). Weil diese Mobil-Regel (max-width:
       1199px, deckt Hoch UND Quer ab) spaeter in der Kaskade steht und
       dieselbe Spezifitaet hat, hat sie den Stroke auf allen mobilen
       Breiten die ganze Zeit unbemerkt wieder eingefuehrt - das war die
       Ursache fuer Merles "der Stroke ist immer noch da", obwohl Abschnitt 2
       ihn laengst auf 0 gesetzt hatte. Ersatzlos gestrichen.
    -webkit-text-stroke-width: clamp(0.7px, 0.45vw, 2.1px) !important; */
    white-space: nowrap !important;
    padding-left: 0.6em !important;
    padding-right: 0.5em !important;
  }
}

/* Auf der Shop-Startseite soll dieser Button/die Section darunter naeher an
   den Hero heranruecken. Best effort ohne genaue Kenntnis der Section-
   Struktur - :has() findet die umschliessende Section unabhaengig von ihrer
   ID/Klasse. Bitte live gegenchecken. */
@media screen and (max-width: 1199px) {
  body section:has(> .box-cta),
  body .shopify-section:has(.stelldirdeineboxzusammen) {
    padding-top: 8px !important;
    margin-top: 0 !important;
  }
  body .box-cta {
    margin-top: 8px !important;
  }
}
/* NEU (Round 28, 35. Batch): Merle "Handy quer: der Button 'Stelle dir deine
   Box zusammen' auf der Startseite braucht ein gutes Padding oben" - die
   generische 8px von oben reichen laut Feedback hier nicht. Gezielt nur fuer
   echtes Handy-Querformat (dieselbe Breakpoint-Kombination wie der uebrige
   Handy-Quer-Code in dieser Datei), grosszuegiger auf 32px erhoeht.
   Schaetzwert, bitte live gegenchecken. */
@media screen and (orientation: landscape) and (max-height: 500px) {
  body section:has(> .box-cta),
  body .shopify-section:has(.stelldirdeineboxzusammen) {
    padding-top: 32px !important;
  }
}


/* ---------------------------------------------------------------- 3. SCROLL-
   IN-VIEW "HOVER" FUER TOUCH-GERAETE JS (mobile-fixes.js) haengt .pv-hover-
   inview an, sobald ein Element zu ~60% im Viewport ist. @media (hover: none)
   wirkt nur auf Touch - Desktop bleibt unveraendert. !important zur
   Sicherheit gegen den regulaeren Zustand.
   ---------------------------------------------------------------- */

@media (hover: none) {
  body .menu-list__link.pv-hover-inview,
  body .menu-list__link--active.pv-hover-inview,
  body .menu-list__link[aria-current="page"].pv-hover-inview {
    color: var(--header-color) !important;
    transform: scale(1.1) !important;
  }
  /* ENTFERNT (Round 28/Batch 16): diese Regel setzte bei Touch-Geraeten
     (Scroll-in-View, siehe Abschnitt 3 oben) einen dunkelgruenen Hintergrund
     + helle Schrift - ein Rest aus Round 27 Batch 3, VOR Merles Kurswechsel
     in Round 27 Batch 13 ("bitte nur groesser werden, nicht die Farben
     veraendern"), der damals nur die normale :hover-Regel (Abschnitt 2 oben)
     angepasst hat, nicht dieses Touch-Aequivalent hier. Dadurch sprang der
     Button auf Mobil beim Scrollen-ins-Bild weiterhin dunkel um - das war
     Merles gemeldete "zu dunkle Animation". Ersatzlos gestrichen, damit auch
     auf Touch nur noch die Groesse waechst (Abschnitt 2), keine Farbe mehr.
  body .stelldirdeineboxzusammen.pv-hover-inview {
    background-color: var(--pv-green-dark, #143c1f) !important;
    color: #ddffbb !important;
  } */
  /* NEU (Round 28, 20. Batch): Merle "stelle dir hier deine box zusammen
     animiert jetzt gar nicht mehr beim drueberscrollen". Root Cause
     gefunden: als die Hintergrundfarben-Regel oben (ENTFERNT, Batch 16)
     ersatzlos gestrichen wurde, kam dafuer NIE ein Ersatz fuer das
     Scroll-in-View-Wachstum selbst - fuer diesen Button gibt es dadurch gar
     keine aktive .pv-hover-inview-Regel mehr, obwohl er in mobile-fixes.js
     (hoverSelectors) weiterhin beobachtet wird und die Klasse korrekt
     bekommt. Alle anderen Buttons aus hoverSelectors (.pv-button,
     .button-custom, etc.) haben direkt unterhalb jeweils eine eigene
     .pv-hover-inview-Regel - hier fehlte sie als einzige. Fix: derselbe
     Zielwert wie beim bestehenden Touch-:hover-Wachstum direkt unten,
     damit Scroll-in-View und Antippen gleich aussehen.
     KORREKTUR (Round 28, 21. Batch): Zielwert zusammen mit dem :hover-Wert
     direkt unten auf ein dezenteres Wachstum (~5% statt ~11%) reduziert,
     siehe Kommentar dort ("animiert zu gross"). */
  body .stelldirdeineboxzusammen.pv-hover-inview {
    font-size: clamp(0.8rem, 4.1vw, 1.51rem) !important;
  }
  /* Die Original-Regel ".stelldirdeineboxzusammen:hover { font-size: 2.35em
     !important; }" ist normales :hover, kein @media(hover:none)-Aequivalent.
     Auf Touch bleibt :hover nach dem Antippen oft "haengen" (sticky hover),
     wodurch das Element auf 2.35em aufskalierte. Fix: hier (spaeter in der
     Kaskade + !important) die mobile Zielgroesse aus Abschnitt 2 fuer alle
     Touch-Geraete erneut erzwingen. */
  /* GEAENDERT (Round 28/Batch 18): Zielwert jetzt identisch mit dem
     BISHERIGEN Ruhezustand (siehe Abschnitt 2, dort jetzt verkleinert) -
     das Antippen soll wieder bis zum "jetzt zustand" (Merles Wortwahl)
     wachsen, nicht darueber hinaus. War: clamp(0.72rem, 3.8vw, 1.4rem).
     KORREKTUR (Round 28, 21. Batch): Merle "animiert zu gross" - der
     Batch-18-Zielwert (0.85rem/4.4vw/1.6rem) war der alte, VOR Batch 18
     geltende Ruhezustand, also ein deutlich groesserer Sprung (~11%) als bei
     allen anderen Buttons dieser Art (z.B. "Stoebere im Katalog": nur 4%,
     scale(0.96)->scale(1)). Zielwert jetzt enger an den aktuellen
     Ruhezustand (clamp(0.76rem,3.9vw,1.44rem)) herangerueckt - nur noch ca.
     5% Wachstum, Schaetzwert in Anlehnung an die anderen Buttons. */
  body .stelldirdeineboxzusammen:hover {
    font-size: clamp(0.8rem, 4.1vw, 1.51rem) !important; /* war 0.85rem/4.4vw/1.6rem */
  }
  /* NEU (Round 28, 21. Batch): Merle "kann der Button onclick einen rosa
     Hintergrund bekommen?" - :active greift kurz waehrend des Antippens/
     Klickens selbst (unabhaengig vom Scroll-in-View- oder Sticky-Hover-
     Mechanismus), daher hier zusaetzlich und unabhaengig von den anderen
     Zustaenden ergaenzt. */
  body .stelldirdeineboxzusammen:active {
    background-color: var(--header-color) !important;
  }
  /* GEAENDERT (Round 28/Batch 17): an den Desktop-Hover (siehe oben, Punkt
     12 der Mobilfeedback-Liste) angeglichen - kein Hintergrundwechsel mehr,
     Schrift zu rosa statt Dunkelgruen, etwas weniger Wachstum. */
  body .pv-button.pv-hover-inview {
    border-color: var(--header-color) !important;
    color: var(--header-color) !important;
    transform: scale(1.04) !important;
  }
  /* GEAENDERT (Round 28/Batch 18): Merle, Handy-Buttons-Feedback - "nicht
     die Schrift pink werden lassen, dazu im Ausgangszustand den Button
     kleiner machen" (Ausgangszustand-Verkleinerung siehe neue Mobil-Regel
     bei Abschnitt "Jetzt packen."-Button, Basis-Scale 0.95) - Wachstum hier
     von 1.1 auf 1.0 reduziert (waechst jetzt nur noch auf die bisherige,
     native Groesse statt darueber hinaus), Farbwechsel zu Pink komplett
     entfernt. War: stroke-color + color auf --header-color, scale(1.1). */
  body .pv-product-btn.pv-hover-inview {
    transform: scale(1) !important;
  }
  body .pv-tagline.pv-hover-inview {
    background-color: var(--header-color) !important;
    transform: scale(1.08) !important;
  }
  body .box-cta__link.pv-hover-inview {
    color: var(--header-color) !important;
    -webkit-text-stroke-color: var(--header-color) !important;
  }
  body .box-allproducts__link.pv-hover-inview {
    color: var(--header-color) !important;
    -webkit-text-stroke-color: var(--header-color) !important;
  }
  body .button-custom.pv-hover-inview {
    background-color: var(--header-color) !important;
    --button-border-color: var(--header-color) !important;
  }
  /* NEU (Round 28/Batch 18): "Stoebere im Katalog" auf Touch von der
     generischen .button-custom-Pink-Faerbung ausnehmen (siehe Desktop-
     Pendant, selber Grund) - nur noch dezentes Wachstum (0.96 -> 1.0). */
  body .button-custom--AVmw1QzBrZ21OSVo0e__button_wkxYLF.pv-hover-inview {
    background-color: #def2c7 !important;
    --button-border-color: var(--pv-green-dark) !important;
    transform: scale(1) !important;
  }
}


/* ---------------------------------------------------------------- 4.
   ÜBERSCHRIFTEN (h3-h6) — SYSTEMATISCHER FIX
   ---------------------------------------------------------------- */

/* WICHTIGSTER FIX: h3-h6 werden bisher komplett in "vw" gesetzt, ohne
   Untergrenze (z.B. h5 { font-size: 1.8vw !important; }) - bei 390px ergibt
   das ca. 7px, vermutlich Ursache fast aller "Schrift zu klein"-Meldungen.
   Auf Mobil eine Mindestgroesse per clamp(), Desktop bleibt exakt wie bisher.
   Das "body "-Praefix ist der entscheidende Unterschied, der uns gegen die
   gleich spezifischen Original-Regeln gewinnen laesst. */
@media screen and (max-width: 1199px) {
  body h3 { font-size: clamp(1.3rem, 5vw, 2rem) !important; }
  body h4 { font-size: clamp(1.05rem, 4vw, 1.6rem) !important; }
  body h5 { font-size: clamp(1.15rem, 4.6vw, 1.75rem) !important; }
}
/* KORREKTUR (Round 28, 65. Batch): Merle meldet, dass h6 beim Schmalerziehen
   des Browserfensters "zwischenzeitlich viel zu gross" wird - eine Luecke in
   den Media Queries. Root Cause: die h6-Regel stand bisher (wie h3-h5 oben)
   nur bis max-width:1199px - oberhalb davon fiel h6 auf die native Theme-
   Variable (--font-h6--size) zurueck, die wir nicht einsehen/auslesen
   koennen (sie wird nicht in dieser Datei definiert). Offenbar erzeugt genau
   der Uebergang an dieser 1199px-Grenze einen Sprung nach oben. Fix: h6 aus
   dem gemeinsamen Media-Query-Block herausgeloest und KOMPLETT UNSCOPED
   (gilt auf allen Breiten) gesetzt - der clamp() deckelt die Groesse so
   oder so bei 1.55rem, ist also auch auf echtem Desktop unproblematisch
   klein/unauffaellig. Dadurch gibt es keine Breiten-Grenze mehr, an der die
   native Variable kurzzeitig durchschlagen koennte. h3-h5 bewusst nicht
   angefasst, da nur h6 gemeldet wurde. */
body h6 { font-size: clamp(1.05rem, 4.2vw, 1.55rem) !important; }

/* Box-Titel im Homepage-Karussell ("Probier-Box" etc.), eigene Klasse mit
   eigenem vw-Wert (1.9vw), unabhängig vom generischen h4 oben. */
@media screen and (max-width: 1199px) {
  body [class*="__product_title_9pPDEV"] p {
    font-size: clamp(1.15rem, 4.8vw, 1.6rem) !important;
  }
}

/* "Welche Box passt zu Dir?" (h2, +15%) */
@media screen and (max-width: 1199px) {
  body [class*="__text_aLNxiX"] {
    font-size: 115% !important;
  }
}

/* "100% pflanzlich. 100% innovativ. 100% lecker" (.pv-tagline-headline).
   Ziel: jedes "100% X"-Wortpaar bleibt in einer Zeile. Das ist abhängig von
   der tatsächlichen Zeichenbreite auf deinem Gerät - bitte live prüfen und
   die vw-Zahl in der Mitte des clamp() ggf. nachjustieren. */
@media screen and (max-width: 1199px) {
  body .pv-tagline-headline {
    /* AB 7.10. (Teil 8): Merle "100% x ... zu klein" - da jede Phrase jetzt
       per display:block (siehe unten) ihre eigene Zeile hat, kein
       Umbruch-Risiko mehr beim Vergroessern. Clamp angehoben (war 1.6rem/
       8.2vw/2.4rem). AB 7.10. (Teil 10): "jetzt besser, aber bitte noch
       etwas groesser" - nochmal angehoben (war 1.8rem/9vw/2.7rem). */
    font-size: clamp(2rem, 10vw, 3rem) !important;
    /* KORREKTUR (7.10., Teil 12): Merle "100% X einen Webstroke geben" -
       gleiche Technik wie bei der Hero-Headline/den anderen "Webstroke"-
       Texten in dieser Datei: Stroke-Farbe = Fuell-Farbe (erzeugt einen
       kraeftigeren/fetteren Eindruck, kein Kontur-Effekt).
       KORREKTUR (Round 28, 20. Batch): Merle "100% X zu viel Webstroke auf
       Mobil" - 1.2px war als fixer px-Wert gesetzt, unabhaengig von der
       (auf Mobil deutlich groesseren, clamp(2rem,10vw,3rem)) Schriftgroesse
       hier. Reduziert auf 0.8px, Schaetzwert in Anlehnung an die analoge
       Reduzierung bei den Pillen selbst (Abschnitt 18, dort 1.8px -> 1.25px
       auf Mobil) - bitte live gegenchecken ob das jetzt duenn genug ist. */
    -webkit-text-stroke: 0.8px #e3f3c6 !important;
  }
}
/* AB 7.10. (2. Korrektur): Merles erster Wunsch war "Schrift waechst beim
   Hervorheben nicht mehr mit" - das verhinderte zwar den Umbruch, aber auch
   das gewuenschte Groesser-Werden selbst. Merles eigentlicher Wunsch: Wort
   SOLL beim Hervorheben pink + groesser werden, nur eben OHNE dass dabei die
   naechste Zeile mit umbricht. Fix: nicht mehr die Groesse einschraenken,
   sondern jedes "100% X" auf eine eigene Zeile stellen (display:block) -
   dann hat jede Phrase ihre eigene Zeile und kann unabhaengig wachsen, ohne
   eine andere Phrase zur Seite zu drängen.
   KORREKTUR (Round 26): dieser Block galt bisher bis 1199px, also auch im
   gesamten "schmaler Desktop"-Bereich (750-1199px). Merles neuer Wunsch:
   "bis zum schmalen Format koennen 100% pflanzlich und 100% innovativ auch
   noch in einer Zeile stehen" - sie moechte, dass zwei der drei Phrasen dort
   weiterhin zusammen in einer Zeile bleiben koennen, solange der Platz
   reicht, statt zwangsweise schon ab 1199px jede auf eine eigene Zeile zu
   springen. Fix: das erzwungene display:block (+ die zugehoerigen Zeilen-
   abstand-Werte darunter) jetzt auf max-width:749px eingegrenzt - im
   "schmaler Desktop"-Bereich (750-1199px) bleiben die drei Phrasen normale
   Inline-Elemente und brechen nur dort um, wo der verfuegbare Platz
   tatsaechlich nicht reicht (natuerlicher Textfluss statt erzwungener
   Eigenzeile). Die Schriftgroessen-Regel direkt darueber bleibt unveraendert
   bei max-width:1199px, da die Groessenskalierung selbst unabhaengig von
   dieser Umbruch-Frage ist. */
@media screen and (max-width: 749px) {
  body .pv-tagline-headline .benefit-trigger {
    display: block !important;
    /* AB 7.10. (Teil 10): Merle "bitte mehr Zeilenabstand" - bisher kein
       eigener Abstand zwischen den drei block-Zeilen gesetzt (nur die
       natuerliche line-height). Schaetzwert, bitte live gegenchecken.
       KORREKTUR (Round 18): Merle "Zeilenabstand bei 100% X zu gross" -
       deutlich zurueckgenommen (war 0.35em). Erneut ein Schaetzwert, bitte
       live gegenchecken ob das jetzt passt. */
    margin-bottom: 0.15em !important;
    /* KORREKTUR (7.10., Teil 12): Merle "ein ganz klein bisschen weniger
       line height" - vorher keine eigene line-height gesetzt (nur die
       native Zeilenhoehe der Ueberschrift). Minimal reduziert, bitte live
       gegenchecken ob das reicht.
       KORREKTUR (Round 18): zusaetzlich zur margin-bottom-Reduzierung oben
       weiter auf 1.0 (normale Zeilenhoehe ohne Zusatzabstand) verkleinert -
       Schaetzwert, bitte beide Werte zusammen live gegenchecken. */
    line-height: 1.0 !important;
  }
  body .pv-tagline-headline .benefit-trigger:last-child {
    margin-bottom: 0 !important;
  }
}


/* ---------------------------------------------------------------- 5.
   TAGLINE-ROW ("Zertifiziert ökologisch...", "Einfach bestellen...", etc.)
   ---------------------------------------------------------------- */

@media screen and (max-width: 1199px) {
  body .pv-tagline-row {
    justify-content: center !important;
    width: 100% !important;
  }
  body .pv-tagline {
    font-size: clamp(0.62rem, 3.6vw, 0.95rem) !important;
    white-space: nowrap !important;
    padding: 0.3em 0.7em !important;
  }
}


/* ---------------------------------------------------------------- 6.
   HOMEPAGE-PRODUKTKARUSSELL (Frischegerichte/Tortelloni) ID bestaetigt:
   shopify-section-template--31616257655114__product_list_WCk8kE (bereits ID-
   gescopt, !important trotzdem ergaenzt)
   ---------------------------------------------------------------- */

/* NEU (Round 28, 65. Batch): Merle "sah vorher alles besser aus" - das
   Karussell wirkt jetzt randlos/zu eng am Seitenrand, haette gerne wieder
   etwas Luft links/rechts. Nur Desktop gescopt (die mobile Karussell-
   Mechanik, inkl. bewusst auf 0px gesetztem --gutter-slide-width direkt
   unterhalb, bleibt unangetastet - dort war der randnahe Start ausdruecklich
   gewuenscht). Padding statt margin verwendet, damit die volle Section-
   Breite (full-width) nicht durch einen negativen Ueberhang/Scrollbalken
   gestoert wird. SCHAETZWERT (16px), bitte live gegenchecken. */
@media screen and (min-width: 1200px) {
  #shopify-section-template--31616257655114__product_list_WCk8kE {
    padding-left: 16px !important;
    padding-right: 16px !important;
    box-sizing: border-box !important;
  }
}
@media screen and (max-width: 749px) {
  /* 5-10% kleiner ueber die App-eigene CSS-Variable statt transform (das
     wuerde nur optisch verkleinern, den Platzbedarf im Grid nicht). Auch auf
     Tortelloni angewendet - war vorher versehentlich nur auf Gerichte
     gescopt, dadurch ca. 8% groesser. */
  #shopify-section-template--31616257655114__product_list_WCk8kE [data-testid="resource-list-grid"],
  #shopify-section-template--31616257655114__product_list_gPQqGm [data-testid="resource-list-grid"] {
    --mobile-card-size: 54cqw !important; /* war 60cqw */
    row-gap: 5px !important; /* ca. -60% vertikaler Abstand, bitte live gegen den Ist-Wert prüfen */
  }

  /* Abstand zwischen den Karten: war calc(gap-scale * 33px), min. 24px durch
     eine eigene max()-Regel im Theme selbst - die lässt sich nur mit
     !important auf das --gap direkt (nicht --gap-scale) unterschreiten */
  #shopify-section-template--31616257655114__product_list_WCk8kE [data-testid="product-list"],
  #shopify-section-template--31616257655114__product_list_gPQqGm [data-testid="product-list"] {
    --gap: 11px !important;
  }

  /* Karussell startet näher am linken Rand */
  #shopify-section-template--31616257655114__product_list_WCk8kE .resource-list__carousel,
  #shopify-section-template--31616257655114__product_list_gPQqGm .resource-list__carousel {
    --gutter-slide-width: 0px !important;
  }
}

/* NEU (Round 28/Batch 17): Merle, "Mobilfeedback Hoch" Punkt 4 - per Video
   gezeigt: tippt/zieht man auf einem Produktkarussell-Bild, "hebt" es sich
   an, statt dass normal im Karussell gewischt wird. Root Cause gefunden:
   `<img>`-Elemente sind im Browser standardmaessig `draggable="true"` (das
   ist das native HTML5-Bild-Drag, z.B. zum Ziehen auf den Desktop) - genau
   dieses native Verhalten konkurriert auf Touch-Geraeten mit dem
   beabsichtigten Karussell-Swipe und erzeugt den sichtbaren "Hebe"-Effekt.
   Fix: das nicht-standardisierte, aber von allen gaengigen Browsern
   unterstuetzte `-webkit-user-drag:none` auf allen Produktbildern in den
   Karussells - deaktiviert nur das native Bild-Drag, das Karussell-eigene
   Touch-Swipe-Handling ist davon unberuehrt. */
.product-media__image {
  -webkit-user-drag: none !important;
  user-select: none !important;
}

/* Boxen-Karussell (product_list_cyt63E) BLEIBT bewusst unskaliert - siehe
   Referenzdoku. Nur der Produkttitel wird vergrößert (25%), siehe Abschnitt
   17. */

/* NEU (Round 28, 65. Batch): "Rosa Rand" am unteren Hero-Rand, der Logo/
   Siegel anschneidet - von Merle SELBST live per DevTools gefunden und
   verifiziert: ".hero__container" (Klassen "spacing-style section
   section--full-width", innerhalb der Hero-Section) ist ein CSS-Grid mit
   einer FEST GESETZTEN Pixel-Zeilenhoehe (live gemessen: grid-template-rows
   z.B. "808px"), die vermutlich einmalig beim ersten Rendern berechnet
   wurde. mobile-fixes.js laesst bei sichtbarer Ankuendigungsleiste
   (".hero-wrapper"/"#Hero-template--...") per JS zusaetzlich nachtraeglich
   WACHSEN (um die Leistenhoehe) - die feste Grid-Zeile WAECHST dabei nicht
   mit, es bleibt ein ungenutzter Streifen am unteren Rand des Grid-
   Containers frei, der die eigene (rosa) Hintergrundfarbe der Section
   zeigt und dort Logo/Siegel ueberlagert/abschneidet. Merle hat selbst
   getestet: "display:grid" fuer dieses Element in DevTools deaktivieren
   behebt es. Hier 1:1 genau dieser von ihr verifizierte Fix, aber eng auf
   genau dieses eine Element gescopt (ID + alle drei Klassen zusammen),
   damit NICHT versehentlich jedes andere ".section"-Element auf der Seite
   (vermutlich eine generische Oxygen/Theme-Utility-Klasse) mitgetroffen
   wird. */
/* ROLLBACK (Round 28, 67. Batch): Merle meldet direkt nach dem Deploy DREI
   neue Regressionen, die auf genau diese eine Regel zurueckgehen: (1) Logo +
   Bio-Siegel komplett verschwunden (Desktop UND Handy hoch), (2) Hero-
   Headline/Subline auf Desktop-Breite auf einmal viel zu klein, (3) auf
   Handy hoch laeuft der Header ueber den rosa Hintergrund hinaus. UND der
   eigentliche Zielfehler (rosa Balken unten vom Grid) ist auf Handy quer
   weiterhin sichtbar - der Fix hat also an der Stelle, wo er sollte, gar
   nicht gegriffen, aber an drei anderen Stellen neue Schaeden angerichtet.
   Root-Cause-Verdacht: ".hero__container" ist ein CSS-Grid, in dem Logo,
   Bio-Siegel, Deko-Fotos/Welle und die Hero-Textgruppe vermutlich alle per
   grid-row/grid-column/grid-area UEBEREINANDER in dieselbe Zelle gelegt
   werden (uebliche Technik fuer sich ueberlagernde Bild-/Text-Ebenen).
   "display:block" macht aus diesem Grid-Container einen normalen Block-
   Container - dadurch werden ALLE grid-row/grid-column/grid-area-Angaben
   der Kinder wirkungslos, sie fallen in normale Dokumentreihenfolge
   zurueck UND die vom JS (fitHero()) gemessene Container-Hoehe/-Breite
   aendert sich grundlegend (Grid- vs. Block-Layout-Algorithmus rechnen
   unterschiedlich), was sowohl die Logo/Siegel-Positionierung als auch die
   JS-Schriftgroessenberechnung durcheinanderbringt. Deshalb HIER
   zurueckgerollt (keine Aenderung an .hero__container mehr), damit ueber
   Nacht nichts kaputt bleibt, das vorher funktioniert hat. Der eigentliche
   rosa-Balken-Fix wird naechste Runde mit einem gezielteren, nicht-
   destruktiven Ansatz neu angegangen (z. B. nur "grid-template-rows: auto"
   statt des ganzen Grids, damit Logo/Siegel/Welle ihre Grid-Platzierung
   behalten und nur die feste Pixel-Zeilenhoehe durch eine wachsende Hoehe
   ersetzt wird) - dafuer aber zuerst live mit Merle gegenchecken, nicht
   blind erneut schaetzen. */

/* NEU (Round 28, 71. Batch): "naechste Runde" ist jetzt - Merle bestaetigt
   den rosa Balken UND ein unten angeschnittenes Logo/Bio-Siegel auf ALLEN
   DREI Breakpoints (Desktop breit, Handy hoch, Desktop/Tablet hoch) -
   universell genug, um einen gemeinsamen Root Cause zu bestaetigen statt
   drei Einzelfaelle: die Ankuendigungsleiste ist bei ihr sichtbar (siehe
   Screenshots "Weclome to New Planet V..."), mobile-fixes.js laesst dafuer
   "heroWrapper" nachtraeglich per JS wachsen (Abschnitt 16/fitHero()) -
   aber ".hero__container" (das CSS-Grid, das Logo/Siegel/Welle/Textgruppe
   alle UEBEREINANDER in dieselbe Zelle legt) hat eine einmalig beim ersten
   Rendern fest eingefrorene Pixel-Zeilenhoehe (grid-template-rows), die bei
   diesem nachtraeglichen Wachstum nicht mitwaechst. Dadurch bleibt am
   unteren Rand ein ungenutzter Streifen (= der rosa Balken, zeigt die
   Hintergrundfarbe der Section), UND Logo/Bio-Siegel - von mobile-fixes.js
   anhand der GEWACHSENEN Hoehe positioniert - landen unterhalb der noch
   alten, kleineren Grid-Zelle, also sichtbar abgeschnitten/ausserhalb.
   Dasselbe Diagnose-Muster wie Merles eigener DevTools-Fund von vorhin
   (".hero__container" ist der Grid-Container mit der fixen Zeilenhoehe),
   nur jetzt mit dem gezielteren, nicht-destruktiven Fix, der Batch 65-67
   fehlte: NICHT "display:block" (das toetet das ganze Grid, reisst dabei
   die grid-basierte Stapel-Platzierung von Logo/Siegel/Welle komplett raus
   - das war der Fehler von vorhin), sondern NUR die Zeilenhoehe selbst auf
   "auto" - das Grid-Layout (und damit die Positionierung aller Kinder)
   bleibt vollstaendig erhalten, nur die eine Zeile darf jetzt mit dem
   Inhalt mitwachsen, statt bei ihrer initialen Messung eingefroren zu
   bleiben. SCHAETZUNG, da ich das nicht live nachstellen kann (Browser-Tool
   haengt gerade) - bitte als Erstes gegenchecken, ob jetzt sowohl der rosa
   Balken als auch Logo/Siegel auf allen drei Breakpoints stimmen. */
/* ROLLBACK (Round 28, 75. Batch): "display:block" (voriger Versuch, basierend
   auf Merles eigenem isoliertem DevTools-Test) bricht jetzt nachweislich
   AUCH Handy-Hochformat: Merle meldet per Screenshot, dass direkt nach dem
   Laden alles korrekt aussieht, sobald aber fitHero() (JS) greift, "der
   planet c" (Deko-Hintergrundgrafik) ueber den Hero hinauslaeuft, Logo UND
   Bio-Siegel komplett verschwinden (nur noch leere Boxen an deren Stelle),
   UND ".hero__content-wrapper" sichtbar weit ueber den eigentlichen Hero
   hinausragt. Root Cause (jetzt klarer): unter "display:grid" stretchen
   Grid-Kinder standardmaessig auf die volle Zellengroesse - genau das gibt
   ".hero__content-wrapper" (der positionierte Bezugsrahmen fuer die absolut
   positionierten Logo/Siegel-Kinder) seine korrekte Hoehe. Mit
   "display:block" faellt dieses automatische Stretching weg, der Wrapper
   bekommt stattdessen nur noch die Hoehe, die sein eigener Inhalt vorgibt -
   bei ueberwiegend absolut positionierten Kindern (die laut CSS nicht zur
   Elterngroesse beitragen) vermutlich undefiniert/inkonsistent, je nachdem
   was JS noch an Positionen draufschreibt. Das erklaert sowohl den Hero-
   quer-Fall (Siegel verschwanden, bis Merles bottom:6.5em-Patch auf der
   Headline halfen) als auch jetzt Handy-Hochformat - zu viele Breakpoints
   haengen an diesem automatischen Grid-Stretching, um "display:block" hier
   gefahrlos einzusetzen. KOMPLETT ZURUECKGEROLLT (kein Eingriff mehr an
   ".hero__container"s display/grid-template-rows) - der urspruengliche
   rosa-Balken-Fall bleibt dadurch wieder offen, aber ohne diese neuen,
   schwereren Regressionen. Fuer den naechsten Versuch brauche ich echte
   Live-Daten (Computed-Werte von ".hero__container" UND
   ".hero__content-wrapper": height, min-height, grid-template-rows,
   grid-row, align-self) statt weiterer Schaetzungen - zu viele
   aufeinanderfolgende Kollateralschaeden, um hier noch blind zu raten. */
/* NEU (Round 28, 77. Batch): Merle meldet den rosa Balken (+ abgeschnittenes
   Logo/Siegel) wie erwartet wieder, nachdem der display:block-Fix komplett
   raus ist. Neuer Versuch, diesmal OHNE "display" anzufassen (behaelt das
   Grid und damit automatisch das Stretching von ".hero__content-wrapper",
   das Handy-Hochformat/Desktop-quer gebraucht haben) - stattdessen ALLE
   denkbaren Hoehen-Fixierungen auf ".hero__container" selbst entfernt, nicht
   nur "grid-template-rows" (das allein hatte im 72. Batch nachweislich
   nichts gebracht - vermutlich, weil zusaetzlich noch eine explizite
   "height"/"min-height" dieselbe Zeile fixiert hat, die grid-template-
   rows:auto allein nicht erfasst). Falls das wieder nicht reicht: bitte wie
   angekuendigt die Computed-Werte aus dem Styles-Panel schicken, dann
   suchen wir gezielt statt weiter zu schaetzen. */
/* GELOEST (Round 28, 80. Batch): Merle hat den rosa Balken selbst live in
   Safari DevTools endgueltig gefunden - "height: auto" (meine letzte
   Schaetzung) reichte nicht, aber "height: 100%" direkt auf genau diesem
   Element behebt ihn vollstaendig. "auto" liess die Hoehe offenbar auf den
   (zu kleinen) Inhalt schrumpfen bzw. an einer anderen nativen Vorgabe
   haengen - "100%" bindet die Hoehe stattdessen explizit an den Elternrahmen
   (der durch fitHero() bereits korrekt um die Ankuendigungsleiste
   mitwaechst), wodurch kein ungenutzter Streifen mehr uebrig bleibt. Direkt
   uebernommen, 1:1 wie von Merle verifiziert. */
#shopify-section-template--31616257655114__hero_jVaWmY
  .hero__container.spacing-style.section.section--full-width {
  grid-template-rows: auto !important;
  height: 100% !important;
  min-height: auto !important;
}


/* Schatten hinter dem ersten Slide-Bild: auf Mobil weniger weit nach unten
   versetzt, damit er nicht mehr unten abgeschnitten wird. Gilt als
   allgemeiner Fallback-Wert fuer alle Sektionen OHNE eigenen, spezifischeren
   Wert (siehe Abschnitt 6b fuer die jetzt pro Sektion unterschiedlichen
   Werte: Homepage-Gerichte/WCk8kE, Boxen/cyt63E, Alle-Gerichte-Seite). */
@media screen and (max-width: 1199px) {
  body .product-media-container.media-fit:first-of-type::before {
    transform: scale(0.84) translate(-2px, 6px) !important; /* AB 2.10.: Merles finaler Wert, einheitlich mit dem Basiswert; Round 28/27. Batch: 1px nach rechts (war -3px), Merle konnte das genaue Element nicht mehr identifizieren - dieser allgemeine Fallback-Wert wurde sicherheitshalber mit den beiden spezifischeren Werten unten mitgenudged */
  }
}

/* ---------------------------------------------------------------- 6b.
   SCHLAGSCHATTEN PRO SEKTION DIFFERENZIERT (AB 2.10., zweite Runde):
   Merle wollte die drei Bereiche nicht mehr einheitlich, sondern mit
   leicht unterschiedlichen scale/translate-Werten. Diese Regeln sind
   spezifischer (ID-gescopt) als der allgemeine Fallback oben und
   gewinnen daher automatisch, ohne dass der Fallback fuer andere
   Sektionen (z.B. gPQqGm) angetastet werden muss.
   ---------------------------------------------------------------- */
@media screen and (max-width: 1199px) {
  /* Homepage-Gerichte-Karussell (WCk8kE). KORREKTUR (Round 28/Batch 16):
     Merle hat im "Mobilfeedback Hoch"-Paket (Punkt 3) explizit scale(.83)
     translate(-4px,7px) genannt und auf Nachfrage bestaetigt, dass genau
     diese Sektion (Gerichte-Produktraster auf der Shop-Startseite, NICHT
     die Boxen/cyt63E und NICHT die Alle-Gerichte-Seite) gemeint ist, und
     ausdruecklich "Werte aus meinem Feedback uebernehmen" gesagt - direkt
     uebernommen, auch wenn das vom Round-20-Wert (-6px,13px) abweicht.
     KORREKTUR (Round 28/Batch 18): Merle "hab mich umentschieden... bitte
     doch scale(.82) translate(-3px,9px)" - direkt uebernommen, keine
     Schaetzung. */
  #shopify-section-template--31616257655114__product_list_WCk8kE .product-media-container.media-fit:first-of-type::before {
    /* Round 28/27. Batch: 1px nach rechts (war -3px) - Merle "before shadow
       im Produkt/Gerichtraster muss 1px nach rechts", konnte das genaue
       Element aber nicht mehr in den DevTools finden. Da nicht sicher ist,
       ob die Homepage- oder die Alle-Gerichte-Sektion gemeint war, wurden
       beide (plus der allgemeine Fallback oben) gleichermassen genudged. */
    transform: scale(0.82) translate(-2px, 9px) !important;
  }
  /* Boxen-Karussell (cyt63E) - AB 7.10. (Mobil-Feedback-Batch): Merles neuer
     Wert. */
  #shopify-section-template--31616257655114__product_list_cyt63E .product-media-container.media-fit:first-of-type::before {
    transform: scale(0.85) translate(-5px, 9px) !important; /* Round 28/27. Batch: 1px nach rechts (war -6px) */
  }
}


/* ---------------------------------------------------------------- 7. ALLE-
   GERICHTE-SEITE (Kollektions-/Filterseite)
   ---------------------------------------------------------------- */

@media screen and (max-width: 749px) {
  /* Scrollbar aus (nur mobil) */
  html, body { scrollbar-width: none !important; }
}
@media screen and (max-width: 749px) {
  html::-webkit-scrollbar,
  body::-webkit-scrollbar { width: 0px !important; height: 0px !important; }
}

/* #ResultsList: bestehende Regel setzt padding-inline:0 auf ALLEN Breakpoints
   (siehe base.css) - dadurch wirkt es auf Mobil zu weit links/nicht mittig.
   Wir geben ihm auf Mobil einen kleinen, symmetrischen Innenabstand zurück.
   (bereits ID-gescopt) */
@media screen and (max-width: 1199px) {
  #shopify-section-template--31616257720650__main #ResultsList {
    padding-inline: 12px !important;
    /* AB 7.10. (Mobil-Feedback-Batch): 4vh war zu viel Abstand nach oben,
       auf Wunsch auf 0.5vh reduziert. */
    padding-top: 0.5vh !important;
  }
}

/* .facets-toggle (Alle-Gerichte-Seite, "Filter"-Button): hatte ungewolltes
   padding-block und eine feste height, die der Button nicht braucht. AB
   2.10. (zweite Runde) auf Wunsch entfernt/auf auto gesetzt.
   KORREKTUR 7.10.: Merle hat live per DevTools getestet - "padding-block:
   0 !important" rausgenommen und stattdessen "padding-block-start: 2vh"
   gesetzt sah besser aus (etwas Luft oben, aber nicht so viel wie vorher).
   Entsprechend hier fest eingebaut, "padding-block: 0" entfernt. */
@media screen and (max-width: 1199px) {
  #shopify-section-template--31616257720650__main .facets-toggle {
    height: auto !important;
    padding-block-start: 2vh !important;
  }
}
/* NEU (Round 28/Batch 17): Merle, "Mobilfeedback Hoch" Punkt 13 - "Quer auf
   der Alle-Gerichte-Seite ueber UND unter dem Filter ein bisschen Abstand".
   Oben gibt es bereits padding-block-start:2vh (alle Breiten bis 1199px) -
   unten fehlte bisher jeglicher Abstand zum Ergebnis-Raster darunter.
   Gezielt nur fuer echtes Handy-Quer ergaenzt (dieselbe
   orientation:landscape+max-height:500px-Erkennung wie an anderen Stellen
   in dieser Datei). Schaetzwert, bitte live gegenchecken. */
@media screen and (orientation: landscape) and (max-height: 500px) {
  #shopify-section-template--31616257720650__main .facets-toggle {
    margin-block-end: 1.5vh !important;
  }
}

/* slideshow-slides auf der Alle-Gerichte-Seite: minimaler margin-left, damit
   die Produktbilder leicht nach rechts verschoben sind (AB 2.10., zweite
   Runde, auf Wunsch). Betrifft alle Produktkarten-Karussells dieser Seite. */
@media screen and (max-width: 1199px) {
  #shopify-section-template--31616257720650__main slideshow-slides {
    margin-left: 1% !important;
  }
}

/* WIEDER AKTIVIERT, auf Mittelwert (Round 28, 25. Batch): Merle "sollten
   eben nicht einfach sein wie frueher, dann wird der Titel abgeschnitten -
   sondern genau das dazwischen vorher und jetzt". Interpretiert als: weder
   die urspruengliche 0.82em-Verkleinerung (Round 24, "frueher" - kleiner als
   alle anderen Produkttitel) noch die komplett deaktivierte normale
   Schriftgroesse (seit Round 24, "jetzt" - laut diesem Feedback nun wieder
   mit abgeschnittenem Titel) - sondern ein Mittelwert, 0.91em (Mitte
   zwischen 0.82 und 1.0). Falls "dazwischen" stattdessen etwas anderes
   gemeint war (z.B. mehr Zeilen statt kleinerer Schrift), bitte kurz
   zurueckmelden. */
@media screen and (max-width: 749px) {
  body product-card:has(a[href*="/products/bio-tortellini-in-feiner-bolognesesosse"]) [class*="text-block--AU0VTQ2xrMmQ5M1VQV__product_title_4nY4eT"],
  body product-card:has(a[href*="/products/bio-tortellini-in-feuriger-tomatensauce"]) [class*="text-block--AU0VTQ2xrMmQ5M1VQV__product_title_4nY4eT"],
  body product-card:has(a[href*="/products/bio-tortellini-in-cremiger-cahmpignonsosse"]) [class*="text-block--AU0VTQ2xrMmQ5M1VQV__product_title_4nY4eT"],
  body product-card:has(a[href*="/products/bio-tortellini-in-rahmiger-spinatsauce"]) [class*="text-block--AU0VTQ2xrMmQ5M1VQV__product_title_4nY4eT"] {
    font-size: 0.91em !important;
  }
  body product-card:has(a[href*="/products/bio-tortellini-in-feiner-bolognesesosse"]) [class*="text-block--AU0VTQ2xrMmQ5M1VQV__product_title_4nY4eT"] p,
  body product-card:has(a[href*="/products/bio-tortellini-in-feuriger-tomatensauce"]) [class*="text-block--AU0VTQ2xrMmQ5M1VQV__product_title_4nY4eT"] p,
  body product-card:has(a[href*="/products/bio-tortellini-in-cremiger-cahmpignonsosse"]) [class*="text-block--AU0VTQ2xrMmQ5M1VQV__product_title_4nY4eT"] p,
  body product-card:has(a[href*="/products/bio-tortellini-in-rahmiger-spinatsauce"]) [class*="text-block--AU0VTQ2xrMmQ5M1VQV__product_title_4nY4eT"] p {
    font-size: inherit !important;
  }
}


/* ----------------------------------------------------------------
   8. QUICK-VIEW / PRODUKT-POPUP
   ---------------------------------------------------------------- */

/* Echter Bug: "position: relative" auf einem <dialog>-Element hebt die
   Standard-Zentrierung im Viewport auf und positioniert es relativ zu seiner
   Stelle im Dokumentfluss - deshalb oeffnete sich das Popup oben beim Header.
   Fix: position: fixed (nativer Standard von <dialog> bei showModal()). */
body .quick-view-modal {
  position: fixed !important;
}

/* AB 2.10. (zweite Runde): Preis + Grammzahl im Produkt-Popup auf Mobil in
   eine Zeile ("€5,99 | 400g"). Live verifiziert: der gemeinsame Zeilen-
   Container ist .layout-panel-flex--row.mobile-column (die Grammzahl steckt
   in text-block--AVFJVeU5DcjZ6M3M0W__text_j9eXBx); .mobile-column ist die
   Theme-eigene Klasse, die auf Mobil IMMER auf flex-flow:column umschaltet -
   das liess Preis und Gramm untereinander statt nebeneinander stehen. Per
   :has() nur auf genau diese Zeile gescopt, keine anderen mobile-column-
   Zeilen betroffen.
   KORREKTUR (7.10., Teil 6, Punkt 27/43): Merle hat "mobile vertikale
   Ausrichtung" im Theme-Editor fuer diesen Block zwischenzeitlich
   deaktiviert (.mobile-column verschwand dadurch) - unsere obige Regel
   (erfordert .mobile-column im Selektor) griff dadurch gar nicht mehr, und
   OHNE .mobile-column gilt stattdessen Horizons eigene
   ".layout-panel-flex--row:not(.mobile-column) > .text-block { flex: 1 1
   var(--max-width--display-tight) }" - das gibt Preis UND Gramm-Textblock
   gleich viel Flex-Wachstum, wodurch der Preis in einer unnoetig breiten Box
   mit viel Leerraum vor "| 400g" landet (genau das von Merle gezeigte
   Screenshot). ZUSAETZLICH, selbst mit wieder aktiviertem Schalter (.mobile-
   column vorhanden): live simuliert (Klasse per JS zurueckgesetzt) - unsere
   Regel oben setzt zwar flex-flow/align-items/gap, aber NIE justify-content,
   das bleibt dadurch auf var(--vertical-alignment-mobile) stehen (aktuell
   "center" statt "left" gespeichert) - die ganze Preis+Gramm-Gruppe sitzt
   dadurch mittig in der Zeile statt am linken Rand, selbst wenn die Kinder
   selbst schon richtig schmal sind. Fix fuer BEIDE Zustaende gleichzeitig:
   .mobile-column nicht mehr Voraussetzung fuer den Selektor (gilt jetzt
   unabhaengig vom Theme-Editor-Schalter), justify-content hart auf
   flex-start, UND die beiden Kind-Textbloecke selbst auf flex:0 1 auto
   zurueckgesetzt (verhindert das Breitwachsen im .mobile-column:not(...)-
   Fall). Dadurch ist das Ergebnis ab jetzt unabhaengig vom Theme-Editor-
   Schalter immer gleich: Preis und Gewicht linksbuendig, eng nebeneinander. */
@media screen and (max-width: 749px) {
  #ProductInformation-template--31616257622346__main .layout-panel-flex--row:has([class*="text-block--AVFJVeU5DcjZ6M3M0W__text_j9eXBx"]) {
    flex-flow: row nowrap !important;
    justify-content: flex-start !important;
    align-items: baseline !important;
    gap: 0.35em !important;
  }
  #ProductInformation-template--31616257622346__main .layout-panel-flex--row:has([class*="text-block--AVFJVeU5DcjZ6M3M0W__text_j9eXBx"]) > * {
    flex: 0 1 auto !important;
  }
}

@media screen and (max-width: 749px) {
  /* Minimaler Abstand über/unter dem Produktbild */
  body .quick-view-modal__content .product-information__grid {
    gap: 6px !important;
  }
  body .quick-view-modal {
    padding: 16px !important;
  }
  /* Popup insgesamt mehr Platz: bisher width:80vw/max-width:85vw/ max-
     height:85vh - schmaler Rand links/rechts, weniger oben/unten. Da .quick-
     view-modal per margin:auto zentriert wird, verkleinert eine groessere
     Breite/Hoehe automatisch den Rand. */
  body .quick-view-modal {
    width: 88vw !important;
    max-width: 94vw !important;
    max-height: 90vh !important;
  }
}

/* Tap-Ausklapp-Zustand für die gekürzten Icon-Texte (siehe Abschnitt 9) -
   hier zentral definiert, da JS diese Klasse dort togglet.
   KORREKTUR 1 (Round 28, 48. Batch, inzwischen WIDERLEGT): Merle meldete
   "der footer text lässt sich durch tappen nicht aufklappen". Erste Analyse
   (Chrome-Inspektion): Klick setzt "pv-expanded" korrekt, aber die Clamp-
   Regel in Abschnitt 9 ist ID-gescopt (1 ID + 1 Klasse), diese Aufhebungs-
   Regel hier war nur "body .pv-expanded" (0 ID + 2 Klassen) - Fix war, hier
   dieselben beiden IDs zu ergaenzen, fuer identische Spezifitaet.
   KORREKTUR 2 (Round 28, 49. Batch): Merle meldet TROTZ Korrektur 1 weiterhin
   "laesst sich nicht aufklappen". Erneute Live-Pruefung ergab: Korrektur 1
   war UNVOLLSTAENDIG - bei IDENTISCHER Spezifitaet (1 ID + 1 Klasse auf
   beiden Seiten) gewinnt bei Cascade-Gleichstand die Regel, die SPAETER im
   File steht, nicht die mit mehr "Begruendung" im Kommentar. Die Clamp-Regel
   (Abschnitt 9) steht im File NACH dieser Regel hier - sie hat also trotz
   Korrektur 1 strukturell weiterhin gewonnen, der Kommentar von Korrektur 1
   ("zusaetzlich in Abschnitt 9 abgesichert") wurde nie tatsaechlich
   umgesetzt. Live per injiziertem Test-Stylesheet (an ERSTER Stelle im
   <head>, also im denkbar schlechtesten Dateiposition-Fall) bestaetigt:
   mit zusaetzlichem Typselektor ("rte-formatter.pv-expanded" statt nur
   ".pv-expanded") gewinnt die Regel IMMER, unabhaengig von der Reihenfolge
   im File - Spezifitaet steigt dadurch auf 1 ID + 1 Klasse + 1 Typ, echt
   hoeher als die Clamp-Regel (1 ID + 1 Klasse + 0 Typ), kein Dateiposition-
   Gluecksspiel mehr noetig. Live verifiziert: computed webkitLineClamp
   wechselt zuverlaessig von "2" auf "none"/"unset", GENAU wie gewuenscht. */
@media screen and (max-width: 749px) {
  body .pv-expanded,
  #shopify-section-sections--31616257786186__section_rPB8Wx rte-formatter.pv-expanded,
  #shopify-section-sections--31616257786186__section_KtXkqU rte-formatter.pv-expanded {
    -webkit-line-clamp: unset !important;
    overflow: visible !important;
  }
}


/* ---------------------------------------------------------------- 9. ICON-
   TITEL-TEXT-SEKTIONEN (Gekühlte Lieferung / Haltbarkeit / Qualität /
   Zubereitung ...) — section_rPB8Wx & section_KtXkqU (bereits ID-gescopt)
   ---------------------------------------------------------------- */

@media screen and (max-width: 749px) {
  #shopify-section-sections--31616257786186__section_rPB8Wx .rte,
  #shopify-section-sections--31616257786186__section_KtXkqU .rte {
    display: -webkit-box !important;
    -webkit-line-clamp: 2 !important;
    -webkit-box-orient: vertical !important;
    overflow: hidden !important;
  }

  /* Icons (nur <img>, die Payment-Icons sind <svg> und daher automatisch
     ausgenommen - du hattest bestätigt, dass es dort sonst keine weiteren
     imgs gibt) */
  #shopify-section-sections--31616257786186__section_rPB8Wx img,
  #shopify-section-sections--31616257786186__section_KtXkqU img {
    margin-left: 8px !important;
  }
}


/* ---------------------------------------------------------------- 10. "MEHR
   DETAILS ..." BUTTON (.pv-button--thin) MITTIG Ein Versuch ueber
   ":has()"-Wildcard auf das Elternelement wurde wieder entfernt: .pv-button--
   thin wird auch vom Footer-Button genutzt - "body *:has(> .pv-button--thin)"
   traf beide Elternelemente und machte den Footer-Bereich kaputt. Zurueck auf
   die sichere, nur-den-Button-selbst- betreffende Variante; die FAQ-
   Zentrierung bleibt dadurch unvollstaendig, bis das tatsaechliche
   Elternelement bekannt ist. */
@media screen and (max-width: 749px) {
  body .pv-button--thin {
    display: flex !important;
    width: fit-content !important;
    margin-inline: auto !important;
  }
}

/* FAQ-Button soll mittig auf Handy UND Desktop sein - auf Mobil inzwischen
   korrekt, auf Desktop gab es noch keine Regel. Bewusst nicht die generische
   .pv-button--thin-Klasse verwendet (traf beim letzten Versuch auch den
   Footer-Button), sondern wie in mobile-fixes.js gezielt auf die FAQ-Section
   gescopt. */
@media screen and (min-width: 750px) {
  .color-custom-sections--31616257786186__section_x9fTHp .pv-button--thin {
    display: flex !important;
    width: fit-content !important;
    margin-inline: auto !important;
  }
}


/* ---------------------------------------------------------------- 11. .PV-
   BUTTON 12% KLEINER (z.B. "Erfahre mehr über Planet V"), OHNE die --thin-
   Variante ("Mehr Details...") anzufassen
   ---------------------------------------------------------------- */

@media screen and (max-width: 749px) {
  body .pv-button:not(.pv-button--thin) {
    font-size: 1.144em !important; /* -12% von 1.3em */
  }
}

/* "Erfahre mehr ueber Planet V"-Button (Tagline-Sektion, section_fB7FHf)
   etwas kleiner + mehr Abstand nach oben zur Tagline-Pillen-Reihe. Gezielt
   nur auf diese Section gescopt, nicht die generische .pv-button-Regel. */
@media screen and (max-width: 749px) {
  #shopify-section-template--31616257655114__section_fB7FHf a.pv-button:not(.pv-button--thin) {
    font-size: 1.0em !important; /* nochmal kleiner als die site-weiten 1.144em */
    margin-top: 1.2em !important;
  }
}


/* ---------------------------------------------------------------- 12.
   NEWSLETTER-EINGABEFELD 12% NIEDRIGER (Footer, bereits ID-gescopt)
   ---------------------------------------------------------------- */

@media screen and (max-width: 749px) {
  #shopify-section-sections--31616257786186__footer_m9NzUG .email-signup__input-group .field__input {
    padding-block: calc(var(--input-padding, 1em) * 0.88) !important;
  }
}
/* Falls das Eingabefeld dadurch nicht sichtbar kleiner wird (unklar, welche
   interne Variable/Klasse das Padding wirklich steuert, ohne footer.liquid
   vorliegen zu haben), bitte kurz Bescheid geben - dann brauche ich die
   Klasse des <input> selbst aus dem Inspector. */


/* ---------------------------------------------------------------- 13.
   GUTSCHEIN-SEITE: Desktop-Skalierung auf Mobil wieder raus (Original-Regeln
   bleiben fuer Desktop erhalten, hier nur in eine min-width-Media-Query
   verschoben). Bereits ID-gescopt.
   ---------------------------------------------------------------- */

@media screen and (min-width: 750px) {
  /* GEAENDERT (Round 27, 8. Batch): Merle "Gutscheinseite soll linksbuendig
     sein, margin-inline weg" - vorher margin-inline:auto (zentriert die auf
     65%/95% verschmaelerte Box mittig auf der Seite), jetzt 0 (Box bleibt am
     linken Rand, max-width schneidet nur noch rechts ab). Live vor der
     Aenderung gemessen: margin-left/-right waren exakt gleich gross (Beweis
     fuer Zentrierung) - mit margin-inline:0 faellt das weg. */
  /* KORREKTUR (Round 28/Batch 14): Merle "bitte Block mit dem Gutschein-
     raster einruecken wie den Seitentitel, genauso unten 'Im Gutschein sind
     die Versandkosten...'". Live gemessen (950px-Fenster, Gutschein-
     Collection-Seite): die eigentliche Seiten-Ueberschrift ("Du willst
     Planet V verschenken? Prima Idee...", eigene Section "section_tzR3xh")
     sitzt bei left:78px, waehrend dieser Block (Raster, Trennlinie,
     Versandkosten-Text - alle drei liegen im selben .section--page-width,
     daher reicht EINE Aenderung fuer alle drei) bisher bei nur left:40px
     sass (38px Differenz = exakt 4% von 950px). Fix: margin-inline:0 durch
     margin-left:4vw ersetzt, damit dieser Block denselben linken Einzug wie
     der Seitentitel bekommt (40px + 38px = 78px, live nachgerechnet). */
  #shopify-section-template--32323933831498__product_list_iNEHLA .section--page-width {
    max-width: 65% !important;
    margin-left: 4vw !important;
    margin-right: 0 !important;
  }
  #shopify-section-template--32323933831498__product_list_iNEHLA h1,
  #shopify-section-template--32323933831498__product_list_iNEHLA h2 {
    font-size: 208% !important;
  }
  #shopify-section-template--32323933831498__product_list_iNEHLA h5 {
    font-size: 115% !important;
  }
}
/* KORREKTUR (7.10., Teil 13): Merles Wunsch - dasselbe auch auf Mobil, hatte
   bisher nur die Desktop-Regel oben (min-width:750px). "Breite auf 95%
   beschraenken und auf der Seite zentrieren". */
@media screen and (max-width: 749px) {
  /* GEAENDERT (Round 27, 8. Batch): Merle "Gutscheinseite soll linksbuendig
     sein, margin-inline weg" - selbe Aenderung wie oben bei Desktop, hier
     fuer Mobil. Live VOR der Aenderung gemessen (500px-Sandbox-Breite):
     margin-left/-right je 12.5px (=exakt zentriert bei 95%-max-width auf
     500px Viewport) - das war die gemeldete Nicht-Linksbuendigkeit. */
  #shopify-section-template--32323933831498__product_list_iNEHLA .section--page-width {
    max-width: 95% !important;
    margin-left: 4vw !important;
    margin-right: 0 !important;
  }
}

/* NEU (Round 28/Batch 14): Merle "die Trennlinie darueber links zentrieren
   und an die Laenge des Produktrasters anpassen" (Gutschein-Seite, Linie
   zwischen Raster und "Im Gutschein sind die Versandkosten..."-Text). Live
   gemessen: der Trennlinien-Container selbst (".divider-...") ist bereits
   genauso breit wie das Produktraster (537.5px, exakt gleiche left/right-
   Kante) - das Problem liegt EINE Ebene tiefer: die Linie ".divider__line"
   hat nur "flex-basis:47%" und der Container zentriert sie per
   "justify-content:center", wodurch nur eine kurze Linie in der Mitte
   erscheint statt ueber die volle Raster-Breite. Fix: Container links-
   buendig (flex-start) + Linie auf volle Breite (100%) - dadurch beginnt
   sie links exakt an derselben Kante wie das Raster und reicht bis zur
   rechten Kante. */
#shopify-section-template--32323933831498__product_list_iNEHLA .divider-AL1pTSmxyRTEyTkFpL__divider_xBFN7A {
  justify-content: flex-start !important;
}
#shopify-section-template--32323933831498__product_list_iNEHLA .divider-AL1pTSmxyRTEyTkFpL__divider_xBFN7A .divider__line {
  flex-basis: 100% !important;
}

/* NEU (Round 28/Batch 18): Merle "Gutscheinseite: die Gutscheine in drei
   Columns auf Handy hoch UND Handy quer". AUSDRUECKLICHER HINWEIS: ich kenne
   die exakte Grid-Markup-Klasse dieser speziellen Section nicht aus eigener
   Live-Pruefung (Chrome-Verbindung war zu diesem Zeitpunkt getrennt) - hier
   beide in dieser Datei fuer andere "product_list_..."-Sections bekannten
   Grid-Varianten vorsorglich gesetzt (".resource-list.resource-list--grid"
   wie bei den Homepage-Karussells, ".product-grid--grid" wie bei der Alle-
   Gerichte-Seite). Eine der beiden sollte greifen, die andere ist dann
   wirkungslos. Bitte live gegenchecken, ob 3 Spalten tatsaechlich
   ankommen. */
@media screen and (max-width: 749px) {
  #shopify-section-template--32323933831498__product_list_iNEHLA .resource-list.resource-list--grid,
  #shopify-section-template--32323933831498__product_list_iNEHLA .product-grid--grid {
    --column-count: 3 !important;
    grid-template-columns: repeat(3, minmax(0, 1fr)) !important;
  }
}
@media screen and (orientation: landscape) and (max-height: 500px) {
  #shopify-section-template--32323933831498__product_list_iNEHLA .resource-list.resource-list--grid,
  #shopify-section-template--32323933831498__product_list_iNEHLA .product-grid--grid {
    --column-count: 3 !important;
    grid-template-columns: repeat(3, minmax(0, 1fr)) !important;
  }
}

/* NEU (Round 28, 28. Batch): Gutscheinseite, Handy hoch - Merle "Produkttitel
   der Gutscheine kleiner und nicht mit ... abkuerzen, sondern ausschreiben,
   div nach unten verlaengern". Live geprueft (Chrome, ~500px Breite): der
   Titel ("Planet V Probier-Box Gutschein" etc.) sitzt in einem generierten
   Shopify-Textblock-Div (H3.h4 innerhalb eines Div mit Klasse
   "text-block--...__product_title_tYUpzC-2", section-spezifisches Suffix
   per [class*=...] erfasst) - dieses Div UND die H3 selbst haben beide nativ
   "-webkit-line-clamp:3" + "overflow:hidden" + "text-overflow:ellipsis",
   das erzeugt das Abschneiden mit "...". Fix: Clamp/Overflow/Ellipsis auf
   beiden Ebenen aufgehoben (Text darf jetzt beliebig viele Zeilen voll
   ausschreiben) + Schrift etwas verkleinert, wie gewuenscht. Das umgebende
   Div braucht keine explizite Hoehen-Aenderung ("nach unten verlaengern") -
   es ist ein normales Flow-Element ohne fixe Hoehe, waechst durch das
   Aufheben von overflow:hidden automatisch mit dem jetzt vollstaendigen
   Text mit. Bewusst nur auf Handy-Hochformat gescoped (Merles expliziter
   Wunsch), Desktop/Querformat unveraendert. */
@media screen and (max-width: 1199px) and (orientation: portrait) {
  #shopify-section-template--32323933831498__product_list_iNEHLA [class*="__product_title_"],
  #shopify-section-template--32323933831498__product_list_iNEHLA h3.h4 {
    overflow: visible !important;
    -webkit-line-clamp: unset !important;
    text-overflow: clip !important;
    font-size: 0.85em !important;
  }
}

/* NEU (7.10., Teil 13): Produktseiten, die als EIGENSTAENDIGE SEITE (nicht im
   Quick-View-Popup) geoeffnet werden, sollen etwas schmaler sein - sowohl
   Gutschein-Produkte (die laut Merles Beobachtung beim Klick ohnehin immer
   direkt zur Produktseite fuehren statt ein Popup zu oeffnen, siehe Abschnitt
   16 weiter unten) als auch normale Produkte, wenn man sie z. B. per
   Rechtsklick "In neuem Tab oeffnen" direkt aufruft. WICHTIG: dasselbe
   ".product-information"-Markup wird auch INNERHALB des Quick-View-Popups
   verwendet (siehe ".quick-view-modal__content .product-information__grid"
   weiter oben/unten in dieser Datei) - dort soll NICHTS davon gelten. Fix:
   ":not(.quick-view-modal__content *)" schliesst jede Instanz aus, die
   irgendwo innerhalb des Popups liegt, trifft also nur die eigenstaendige
   Seite. Merles Hinweis "das Bild kann so gross bleiben" - hier bewusst
   NICHT zusaetzlich am Bild/der Media-Spalte herumgeschraubt, nur die
   Gesamtbreite der Section reduziert. */
@media screen and (max-width: 749px) {
  body .product-information.section.section--page-width.spacing-style.relative:not(.quick-view-modal__content *) {
    max-width: 95% !important;
    margin-inline: auto !important;
  }
}
/* Zusaetzlich Merles zweiter, mit exakter ID genannter Fall: normale
   Produktseite (shopify-section-template--31616257622346__main), wenn sie
   als eigenstaendige Seite geoeffnet wird (z. B. "Link in neuem Tab
   oeffnen") - zusaetzlich zur Breite auch oben/unten Abstand. Auch hier
   ":not(.quick-view-modal__content *)" als Sicherheitsnetz, falls dieselbe
   Section-ID jemals auch innerhalb des Popups vorkommen sollte. */
@media screen and (max-width: 749px) {
  #shopify-section-template--31616257622346__main:not(.quick-view-modal__content *) {
    max-width: 95% !important;
    margin-inline: auto !important;
    margin-block: 1.5em !important;
  }
}


/* ---------------------------------------------------------------- 14. MIX &
   MATCH / EASY BUNDLES ("Fuelle Deine Box") ACHTUNG: gbb*-Klassen kommen von
   der Easy-Bundles-App, deren CSS oft spaet laedt - die aggressivste
   Konkurrenz von allen. Deshalb ueberall !important + body-Praefix. Reicht
   das nicht (Inline-Styles), waere ein JS-Helfer noetig
   (element.style.setProperty(..., 'important')).
   ---------------------------------------------------------------- */

/* a) [ENTFERNT] Der eigene Klapp-Mechanismus (max-height/overflow auf
   .gbbBundleFooter) wurde entfernt: der native EB-Wagen bringt selbst schon
   eine eigene Auf-/Zuklapp-Animation mit (data-animation="expand-height").
   Unser max-height:210px/overflow:hidden hatte diese native Animation
   abgeschnitten - vermutlich Ursache dafuer, dass der ausgeklappte Wagen
   "komisch" aussah. Der zugehoerige JS-Toggle ist ebenfalls entfernt. */


/* b) Step-Titel im Fortschrittsbalken: das Div soll breiter werden statt den
   Text zu clampen, auf Desktop UND Mobil (vorher nur mobil per Line-Clamp,
   was auf breiteren Screens weiterhin 3-zeilig umbrach). Line-Clamp entfernt,
   stattdessen kleinere Schrift + engerer Spalten-Gap fuer alle Breakpoints. */
body .gbbDiscountStepsProgressBarSteps {
  gap: 4px !important; /* war 8px */
}
body .gbbDiscountStepsProgressBarStepTitleWrapper {
  min-width: 0 !important;
  flex: 1 1 auto !important;
}
body .gbbDiscountStepsProgressBarStepTitle {
  display: block !important;
  -webkit-line-clamp: unset !important;
  overflow: visible !important;
  white-space: normal !important;
  line-height: 1.1 !important;
  hyphens: none !important;
  font-size: 0.66rem !important;
}
@media screen and (min-width: 750px) {
  body .gbbDiscountStepsProgressBarStepTitle {
    font-size: 0.78rem !important;
  }
}

/* NEU (Round 28, 31. Batch): Merle meldet fuer Handy-QUER "der Progressbar
   nutzt nicht die gesamte Breite zum rechten Rand, dadurch ueberschneiden
   sich die gbbDiscountStepsProgressBarStepTitleWrapper". Die obigen Regeln
   (min-width:0 + flex:1 1 auto auf den einzelnen Step-Titeln) setzen bereits
   voraus, dass der UMGEBENDE Flex-Container (".gbbDiscountStepsProgressBar-
   Steps") selbst die volle verfuegbare Breite seiner Spalte einnimmt - ohne
   eigenes "width:100%" kann er aber schmaler bleiben als sein Eltern-Element,
   wodurch den Step-Titeln insgesamt weniger Platz zur Verfuegung steht als
   eigentlich vorhanden waere.
   NACHTRAG (Round 28, 33. Batch): Merle meldet "immer noch nicht gefixt" -
   live am echten, befuellten Warenkorb nachgemessen (900x287-Testfenster):
   zutreffend, die Titel ueberlappten tatsaechlich noch (z.B. Titel 2 endete
   bei x=768, Titel 3 begann bereits bei x=759.5 - 8.5px Ueberlappung). Root
   Cause: "width:100%" auf ".gbbDiscountStepsProgressBarSteps" bezieht sich
   nur auf SEIN direktes Eltern-Element - das war selbst aber auch schon
   schmaler als der eigentlich verfuegbare Platz (257.9px statt moeglicher
   307.9px), weil es seinerseits nicht die volle Breite SEINES Eltern-Grids
   eingenommen hat (vermutlich wieder eine EB-eigene, nicht per Cross-Origin-
   Stylesheet einsehbare Breitenvorgabe). Die laut easy-bundles-sdk-
   reference.md dokumentierte Verschachtelung ist ".gbbDiscountStepsProgress
   BarWrapper.gbbDiscountProgressBarContainer" > ".gbbDiscountStepsProgress
   BarContainer" > ".gbbDiscountStepsProgressBarSteps" - Fix: "width:100%"
   jetzt auf ALLEN DREI Ebenen gesetzt, nicht nur der innersten. Live
   bestaetigt: keine Ueberlappung mehr, alle drei Titel exakt gleich breit
   (je 100px) mit kleinem, gleichmaessigem Abstand dazwischen. */
/* KORREKTUR (Round 28, 47. Batch): Merle meldet erneut "gbbDiscountSteps
   ProgressBarWrapper hat die Regel width:calc(100% - 50px), das macht es
   kaputt, bitte entfernen". Diese calc(100% - 50px)-Regel stammt NICHT aus
   dieser Datei (hier stand immer width:100%, siehe Kommentar oben) - sie ist
   also die native EB-eigene Regel, die hier weiterhin gewinnt. Root Cause:
   die Media Query unten hatte zusaetzlich "min-width:750px" - reale Handys
   im Querformat sind aber oft SCHMALER als 750px (z.B. iPhone SE quer
   667px), lagen dadurch ausserhalb dieser Regel und bekamen weiterhin die
   native calc()-Breite. Fix: "min-width:750px" entfernt, dieselbe Grenze wie
   beim bereits live bestaetigten Cart-Drawer-Sidebar-Fix (Abschnitt weiter
   unten, min-width:640px) waere zwar noch praeziser, aber hier bewusst ganz
   weggelassen (keine Breiten-Untergrenze mehr), damit JEDES Handy im
   Querformat erfasst wird, unabhaengig von seiner genauen Breite - analog zu
   den meisten anderen "echtes Handy quer"-Regeln in dieser Datei. */
@media screen and (orientation: landscape) and (max-height: 500px) {
  body .gbbDiscountStepsProgressBarSteps,
  body .gbbDiscountStepsProgressBarContainer,
  body .gbbDiscountStepsProgressBarWrapper {
    width: 100% !important;
    box-sizing: border-box !important;
  }
}

/* NEU (Round 28, 49. Batch): Merle meldet (Screenshot) "gbbDiscountSteps
   ProgressBarStepTitle sind rechts abgeschnitten, alle ... koennen um 50%
   ihrer eigenen Breite nach links ruecken. dann schliessen sie mit ihrer
   rechten Kante mit dem jeweiligen Step ab." Live per Chrome nachgemessen
   (echte DOM-Struktur, .gbbDiscountStepsProgressBarSteps ist bei EB nativ
   ein CSS-Grid; jeder Titel sitzt "position:relative" mit einem von EB
   selbst berechneten, FESTEN "left"-Versatz, der fuer alle drei Titel
   IDENTISCH ist statt sich pro Spalte zu unterscheiden - dadurch driftet
   der dritte/letzte Titel am weitesten nach rechts und ragt ueber den
   Container hinaus, waehrend der erste eher zu weit links vom eigenen Step
   sitzt). Live getestet: "transform:translateX(-50%)" auf dem Titel selbst
   verschiebt jeden Titel um die Haelfte seiner EIGENEN (unterschiedlichen)
   Breite nach links - beim dritten/dem bisher abgeschnittenen Titel
   verschwand der Ueberlauf dadurch nahezu vollstaendig (vorher +47px ueber
   den Container hinaus, danach nur noch -6px, also sicher innerhalb). Exakt
   Merles eigener Vorschlag, live bestaetigt wirksam. */
@media screen and (orientation: landscape) and (max-height: 500px) {
  body .gbbDiscountStepsProgressBarStepTitle {
    transform: translateX(-50%) !important;
  }
}

/* b2) Etwas mehr Luft zwischen Fortschrittsbalken und "Fuelle Deine
   Box"-Bereich: helle gruene Trennlinie oben auf
   .gbbFooterBundleInfoContainer plus etwas margin/padding. */
body .gbbFooterBundleInfoContainer {
  border-top: 1px solid #f4ffdb !important; /* war var(--pv-cream, #e3f6c2) - Round 26, 6. Batch: fest auf EB-einheitliches Hellgruen, unabhaengig vom sitewide --pv-cream-Wert */
  margin-top: 12px !important;
  padding-top: 12px !important;
}
/* NEU (Round 26, 5. Feedback-Batch): "nur auf Desktop border-top und
   margin-top weg, der Rest gilt genau so auch fuer Mobil" - padding-top
   bleibt also ueberall bei 12px, nur border-top/margin-top verschwinden ab
   Desktop. Dieselbe "EB-Desktop"-Medienabfrage wie an allen anderen Stellen
   in dieser Datei fuer dieses Widget (Abschnitt 44/58 etc.) verwendet, statt
   einer neuen Breiten-Grenze zu erfinden. */
@media screen and (min-width: 750px), screen and (orientation: landscape) and (max-height: 500px) {
  body .gbbFooterBundleInfoContainer {
    border-top: none !important;
    margin-top: 0 !important;
    /* NEU (Round 28, 47. Batch): Merle moechte auf Handy-quer zusaetzlich
       auch das padding-top auf 0 (bisher ueberall 12px, siehe Grundregel
       oben) - gleiche Media Query wie border-top/margin-top direkt darueber,
       da Merles Screenshot/DevTools-Test genau diese Kombination (Desktop +
       Handy-quer) zeigte. */
    padding-top: 0 !important;
  }
}

/* NEU (Round 26, 5. Feedback-Batch): "Leeren"-Button-Hintergrund - exakt
   Merles eigener, per Safari-Inspector getesteter Wert/Selektor (live
   bestaetigt: diese Variable loest zu #e0edd4 auf, ein helles Creme-Gruen -
   ersetzt den bisherigen nativen blassen Pink-Ton, passend zur "zu bunt"-
   Rueckmeldung). Die Position (rechts ueber .gbbProductSlotsContainerWrapper,
   gegenueber .gbbFooterTotalItemsInCart) ist noch NICHT umgesetzt - siehe
   Erklaerung in der Antwort an Merle: das sind zwei verschiedene,
   nicht-benachbarte Grid-Container, eine Verschiebung dorthin braeuchte eine
   echte DOM-Verschiebung per JS (MutationObserver, da Easy Bundles diesen
   Bereich bei jeder Interaktion neu rendert) - genau das Risiko, wegen dem
   ein fast identischer Verschiebe-Versuch (Box-Auswahl in den Wagen, siehe
   mobile-fixes.js Abschnitt 9b) vor dem Launch bewusst deaktiviert und auf
   "nach dem Launch, gruendlich testen" verschoben wurde. */
body .gbbFooterClearItemsButtonWrapper {
  background-color: var(--gbb-category-tab-inactive-text-color, #e0edd4) !important;
}

/* c) Gerichte-Grid: 3 statt 4 Spalten auf Mobil. minmax(0, 1fr) statt bloßem
   1fr aus demselben Grund wie beim Desktop-Fix weiter oben (Abschnitt zu
   .gbbProductsContainer) - siehe dortigen Kommentar. */
@media screen and (max-width: 749px) {
  body .gbbProductsContainer {
    grid-template-columns: repeat(3, minmax(0, 1fr)) !important;
  }
}

/* d) Abstand Bild -> Titel verkleinern */
@media screen and (max-width: 749px) {
  body .gbbProductTitleOnly {
    padding-top: 0.2em !important;
  }
}

/* d2) AB 7.10. (Punkt 21): Preise in den Mix&Match-Produktkarten etwas
   kleiner. */
@media screen and (max-width: 749px) {
  body .gbbProductPrice,
  body .gbbProductCompareAtPrice {
    font-size: 0.85em !important;
  }
}

/* e) "in meine Box"-Button: kleinere Schrift/line-height, damit der Text
      in den Button passt. NACHTRAG 7.10. (Merles Screenshot: Karten
      "ueberlaufen"): die kleinere Schrift allein reicht nicht - der Button
      selbst hat KEINE Breitenbegrenzung (display:flex, width:auto) und
      behaelt seine natuerliche/Mindest-Inhaltsbreite, die bei schmalen
      Mobil-Karten (~115-120px) breiter ist als die Karte selbst. Dadurch
      ragt der dunkelgruene Pillen-Button rechts ueber die Karte hinaus und
      ueberlappt die naechste Spalte - sichtbar an der "aufgebrochenen"
      Kartenumrandung. Fix: Button + sein Wrapper hart auf 100% der
      Kartenbreite begrenzt, Text darf dafuer zweizeilig umbrechen
      (white-space:normal, bereits Standard) und der Radius ist fuer eine
      schmale, evtl. zweizeilige Pille verkleinert. Live im Browser mit
      kuenstlich verschmaelerter Karte getestet - behebt das Ueberlaufen. */
@media screen and (max-width: 749px) {
  body .gbbProductAddButton {
    font-size: 0.68rem !important;
    line-height: 1.15 !important;
    width: 100% !important;
    max-width: 100% !important;
    box-sizing: border-box !important;
    white-space: normal !important;
    border-radius: 20px !important; /* war ein grosser, fixer Pillen-Radius */
    padding-inline: 4px !important;
  }
  body .gbbProductButtonContainer,
  body .gbbProductActionContainer {
    width: 100% !important;
    max-width: 100% !important;
    box-sizing: border-box !important;
  }
}

/* e2) AB 7.10. (Punkt 30): sobald ein Gericht in die Box gelegt wurde,
   ersetzt Easy Bundles den "in meine Box"-Button durch einen
   Mengen-Steller (.gbbQuantityStepper mit den Kindern
   .gbbQuantityStepperRemoveButton/-Label/-AddButton). Der hat eine
   groessere Schrift als .gbbProductAddButton oben - Merles Wunsch: dieselbe
   kleinere Schrift (.68rem) soll auch hier gelten, damit die Karte beim
   Umschalten Button -> Steller nicht "springt"/groesser wirkt. */
@media screen and (max-width: 749px) {
  body .gbbQuantityStepper,
  body .gbbQuantityStepperRemoveButton,
  body .gbbQuantityStepperLabel,
  body .gbbQuantityStepperAddButton {
    font-size: 0.68rem !important;
  }
}

/* f) Produkttitel & Beilagen: NIE mit "..." abkürzen (Karte ist eh schon
   height:auto, also unproblematisch für's Layout) - gilt für alle
   Breakpoints, nicht nur mobil */
body .gbbProductTitleOnly {
  display: block !important;
  -webkit-line-clamp: unset !important;
  overflow: visible !important;
}
body .pv-beilagen {
  display: block !important;
  -webkit-line-clamp: unset !important;
  overflow: visible !important;
}
/* Seit die Produktbilder auf eine feste, kleinere Breite gesetzt wurden
   (78px-Kreis, Abschnitt 36), ist die Textspalte schmaler - bei laengeren
   Beilagen-Texten lief der Text seitlich in die Nachbarkarte hinein.
   overflow:visible war absichtlich gegen Ellipsis-Abschneiden, erlaubte aber
   implizit ein zu langes Wort ohne Umbruch. Fix: Breite auf die eigene Spalte
   begrenzen + Wortumbruch erzwingen. */
@media screen and (max-width: 768px) {
  body .gbbProductTitleOnly,
  body .pv-beilagen,
  body .gbbProductTextContainer {
    width: 100% !important;
    max-width: 100% !important;
    box-sizing: border-box !important;
    overflow-wrap: break-word !important;
    word-break: break-word !important;
    hyphens: auto !important;
  }
}

/* AB 2.10. (dritte Runde): .gbbProductTextContainer - Zeilenhoehe/Schriftgroesse
   auf Wunsch angepasst. Ohne Breakpoint, da diesmal nicht als "nur mobil"
   genannt. */
body .gbbProductTextContainer {
  line-height: 114% !important;
  font-size: 11px !important;
}


/* ================================================================ AB HIER:
   BATCH-Freigabe (ausser den beiden EB-Support-Themen Box-Preise &
   Gesamtpreis-Desktop). Jeder Abschnitt ist einzeln kommentiert; mehrere
   Punkte sind "best effort / bitte live pruefen", da entweder das genaue
   Markup fehlte oder nicht gegen die Live-Seite getestet werden konnte.
   ================================================================ */

/* ----------------------------------------------------------------
   15. HEADER: HAMBURGER-FARBEN + WARENKORB-ICON
   ---------------------------------------------------------------- */

/* Hinweis: Die Nav-Leiste (.menu-list--mobile ausblenden) hatten wir hier
   zuerst per CSS gelöst, Merle hat das aber direkt im Shopify-Editor (Theme-
   Einstellungen) gelöst - CSS-Regel deshalb wieder entfernt, damit es keine
   zwei konkurrierenden Lösungen für dieselbe Sache gibt. */

/* --color-background sorgte fuer dunkelgruen-auf-dunkelgruen im Hamburger-
   Menue. Wird zurueckgesetzt (nicht hart gesetzt), damit die normale
   Fallback-Farbe des Theme greift. */
body .color-custom-top-sections--31616257753418__header_section,
body .color-custom-top-sections--31616257753418__header_section .text-block {
  --color-background: initial !important;
}

/* Warenkorb-Symbol auf Mobil unsichtbar: die SVG (fill="none",
   stroke="currentColor") ist korrekt dimensioniert, die Sichtbarkeit haengt
   komplett von der geerbten `color` ab (--color-foreground, kommt aus dem
   Color-Scheme der Header-Section im Theme-Editor, nicht aus base.css) - auf
   Mobil vermutlich zu aehnlich zum Hintergrund. Statt das Color-Scheme zu
   erraten: sicherer Fallback nur fuers Warenkorb-Icon (per aria-label
   eingegrenzt) - feste dunkelgruene Farbe + heller Halo-Schatten, damit es
   unabhaengig vom Hintergrund sichtbar bleibt. Behebt die Ursache nicht,
   macht das Icon aber zuverlaessig sichtbar. */
/* KORREKTUR 7.10.: Merle hat beide Regeln live per DevTools deaktiviert und
   das sah richtig aus - das Warenkorb-Icon soll genauso dunkel
   starten wie Hamburger-Menu/Nutzer-Icon und erst beim Sticky-Werden des
   Headers hell werden (genau wie die anderen Icons das von selbst schon
   tun), nicht durchgehend fest creme-farben per !important. Die beiden
   Farb-Regeln UND der Schatten-Filter sind daher komplett entfernt - das
   Warenkorb-Icon folgt jetzt wieder demselben nativen Mechanismus
   (--color-foreground je nach data-sticky-state) wie die uebrigen
   Header-Icons, ohne eigene Sonderbehandlung. */
@media screen and (max-width: 749px) {
  /* Vertikale Ausrichtung: Warenkorb-Icon saß laut Screenshot etwas zu hoch
     im Vergleich zu den Nachbar-Icons derselben Zeile - Bookend-Spalte
     bekommt dieselbe Flex-Zentrierung wie die anderen (best effort, bitte
     live gegenchecken). */
  #shopify-section-sections--31616257753418__header_section .header__row--top .header-actions__action[aria-label="Warenkorb"] {
    display: flex !important;
    align-items: center !important;
    justify-content: center !important;
    align-self: center !important;
  }
}


/* NEU (Round 28, 41. Batch): Merle "ueberall: der Hintergrund von der
   Hero-Subline soll bitte dieselbe Farbe wie der Webstroke der
   Hero-Headline bekommen". Bewusst AUSSERHALB jeder Media Query (gilt
   ueberall, wie gewuenscht). Live gemessen: Headline-Webstroke ist
   rgb(19, 51, 23) / #133317, Subline-Hintergrund war bisher rgb(20, 60,
   31) / #143c1f (zufaellig fast identisch mit unserer eigenen Variable
   --pv-green-dark, aber NICHT dieselbe Quelle - beide Werte kommen live
   nachweislich aus nativen, von Shopifys Theme-Editor pro Hero-Section
   inline generierten <style>-Regeln, nicht aus einer gemeinsamen
   CSS-Variable). Da keine der beiden Farben an eine Variable gekoppelt
   ist, kann dieser Hintergrund die Stroke-Farbe nicht automatisch "live"
   mitverfolgen - der Wert ist hier als Snapshot hart hinterlegt. Falls
   Merle die Headline-Stroke-Farbe spaeter im Theme-Editor aendert, muss
   dieser Wert von Hand nachgezogen werden (bitte dann Bescheid geben).
   KORRIGIERT (Batch 42): Merle meldet, dass seitdem die "Stelle Dir Hier
   Deine Box Zusammen"-Buttons (Startseite UND "Alle Gerichte"-Seite) eine
   dunkelgruene Schrift/einen dunkelgruenen Hintergrund bekommen haben - live
   bestaetigt: GENAU dieser Button traegt zusaetzlich zu seiner eigenen Klasse
   (.stelldirdeineboxzusammen) ebenfalls die native Theme-Klasse
   .hero-text-group__subline (siehe mehrere aeltere Kommentare weiter unten im
   selben Abschnitt, die genau diese Doppelbelegung schon fuer andere
   Eigenschaften dokumentieren) - die obige, unscoped Regel traf dadurch auch
   den Button und ueberschrieb dessen eigenes, helles background-color:#def2c7
   (hoehere Spezifitaet durch den "body "-Vorfahren: 0,1,1 statt 0,1,0 bei
   ".stelldirdeineboxzusammen" allein). Fix: Selektor um ".hero__container" als
   zusaetzlichen, live bestaetigten Vorfahren ergaenzt (derselbe Trick wie an
   anderer Stelle schon fuer die Bio-Siegel verwendet) - live geprueft: der
   Button liegt NICHT innerhalb von .hero__container, die echte Hero-Subline
   schon. Die Regel trifft dadurch nur noch die echte Subline, der Button
   behaelt seinen eigenen, hellen Hintergrund. */
body .hero__container .hero-text-group__subline {
  background-color: #133317 !important;
}

/* ---------------------------------------------------------------- 16. HERO:
   JS-AUTO-FIT + LAYOUT-UMBAU HOCHFORMAT Schriftgroessen-Berechnung laeuft in
   mobile-fixes.js ("HERO AUTO-FIT"), da reines CSS (clamp/vw) den Textumbruch
   nicht zuverlaessig trifft. Hier nur die CSS-Basis: Logo+Siegel aus
   absoluter Positionierung geloest, landen im Textfluss unter der Subline,
   Hero-Hoehe darf wachsen. Groesserer Strukturwechsel - bitte zuerst live
   gegenchecken.
   KORREKTUR (Round 20): Merle "auf iPad Hochkant soll Headline/Subline/Logo
   skalieren wie Handy Hochkant" - Bereich von max-width:749px auf
   max-width:1199px erweitert (orientation:portrait bleibt), damit iPad im
   Hochformat (z.B. 820x1180) denselben content-getriebenen Hero bekommt wie
   ein Handy, statt der festen 100dvh-Zwangshoehe aus Abschnitt 16b weiter
   unten (die jetzt umgekehrt genau diesen Bereich ausklammert, siehe dort).
   mobile-fixes.js (fitHero) wurde passend mitgeaendert (isTabletPortraitLikePhone).
   KORREKTUR (Round 29, 93. Batch): ECHTER ROOT CAUSE fuer Merles neuen Bug
   "Headline komplett unsichtbar (y-Position -710px!)" bei 928x1057 und
   aehnlichen 750-1199px-Hochformat-/quadratischen Fenstern - live per
   DevTools bestaetigt. Dieser Block (position:static + height:auto,
   "Handy-Logik") lief HIER WEITERHIN bis 1199px, WAEHREND Abschnitt 16b
   ("echter Desktop", siehe dort) seit der Routing-Korrektur in genau diesem
   Breitenbereich JETZT EBENFALLS greift (position:relative + fixe
   Mindesthoehe + eigene Lift-Transform-Berechnung in mobile-fixes.js) - ZWEI
   grundverschiedene Layout-Systeme (position:static+height:auto hier vs.
   position:relative+Flex-Zentrierung dort) ueberschrieben sich dadurch
   gegenseitig Eigenschaft fuer Eigenschaft, je nachdem welche Regel zufaellig
   spaeter im Stylesheet steht - das ergab eine voellig inkonsistente,
   kaputte Mischung statt eines der beiden sauberen Systeme. Der urspruengliche
   Grund fuer die Erweiterung auf 1199px (Round 20, "iPad Hochkant wie Handy")
   gilt nach dem 92./93. Batch nicht mehr: iPad-Hochkant & jedes andere
   750-1199px-Hochformat-/quadratische Fenster soll jetzt bewusst durch
   Abschnitt 16b ("echter Desktop") laufen, konsistent mit Landscape/Breit
   (Merles eigener Vorschlag: "eine Regel mit derselben Hoehen-Logik, nur
   anderer Breite"). Fix: Grenze zurueck auf 749px - deckungsgleich mit der
   bereits angepassten JS-Grenze (isTabletPortraitLikePhone) und den beiden
   anderen Abschnitt-16-CSS-Blocken. Echtes Handy-Hochformat (<=749px)
   bleibt dadurch unveraendert bei seinem bewaehrten, content-getriebenen
   System. */
@media screen and (max-width: 749px) and (orientation: portrait) {
  body .hero-wrapper {
    min-height: 0 !important;
    height: auto !important;
    /* Hero insgesamt etwas nach oben (negativer Margin) und gleichzeitig mehr
       Hoehe insgesamt (unten mehr Padding als oben), damit unter dem Strich
       sogar mehr Raum fuer Logo/Siegel bleibt. */
    padding-block: 0px 28px !important; /* AB 29.9. (Folge-Runde 8) von 68px auf 28px runtergesetzt, davor 46px - siehe Korrektur unten */
    /* KORREKTUR (Round 28, 41. Batch): war -18px (reine Schaetzung aus einer
       frueheren Runde, die per Kommentar ausdruecklich als in der Sandbox
       nicht live verifizierbar markiert war - siehe Hinweis bei der
       margin-bottom/margin-top-Regel auf .hero-text-group weiter unten,
       derselbe Hintergrund). Merle hat in ihrem eigenen, echten Browser bei
       sehr schmalen Fensterbreiten selbst experimentell -68px ermittelt und
       per Screenshot als "sah gut aus" bestaetigt - direkt uebernommen,
       keine eigene Schaetzung mehr. */
    margin-block-start: -68px !important;
  }
  /* Ursache fuer die Luecke oben: padding-block-start (46px) fuellte den
     Bereich vor der Section-Oberkante nur mit der Seiten-Hintergrundfarbe
     statt mit dem Hero-Hintergrund. Fix: padding-top auf 0. Die
     Sicherheitsabstand- Funktion (Headline nicht zu nah am Header) uebernimmt
     jetzt .hero-text-group selbst (margin-top weiter unten) - Hero-
     Hintergrund und Text-Abstand sind damit entkoppelt. Live verifiziert:
     kein heller Streifen mehr, Headline behaelt Abstand zum Header. */
  /* WICHTIGSTE KORREKTUR: Subline riesig/3-zeilig UND Logo+Siegel unsichtbar
     - vermutlich weil .hero-text-group auf position:absolute stand und
     dadurch nicht zur automatischen Hoehe von .hero-wrapper (height:auto)
     beitrug; dieses schrumpfte auf fast nur seine Padding-Hoehe, alles
     darunter wurde von overflow:hidden abgeschnitten. Fix: position:relative
     statt absolute - die Textgruppe fliesst wieder normal mit und zieht die
     Wrapper-Hoehe korrekt hoch. Zentrierung bleibt ueber align-items:center.
     KORREKTUR (7.10., Teil 13): "position:relative" war selbst die Ursache
     fuer "Bio-Siegel sind immer noch mittig" - .hero-text-group ist NAEHER am
     Siegel-Wrapper als das eigentlich gemeinte .hero__content-wrapper, und
     wurde durch position:relative faelschlich selbst zum containing block
     fuer .hero-text-group__siegel-wrapper (position:absolute). Dadurch
     bezog sich dessen right/bottom-Prozent nicht auf die volle Hero-Flaeche,
     sondern nur auf die (viel kuerzere) Hoehe der Text-Gruppe selbst - das
     Siegel landete dadurch optisch "in der Mitte" statt in der echten Ecke.
     Fix: position:static statt relative. Fuer den Hoehen-Fix oben macht das
     keinen Unterschied (static traegt genauso normal zur Hoehe bei wie
     relative), nimmt .hero-text-group aber aus der Containing-Block-Kette
     raus, so dass .hero__content-wrapper (ebenfalls position:relative,
     umspannt die ganze Hero-Flaeche) wieder die massgebliche Bezugsgroesse
     ist. Bitte live gegenchecken, da das nicht ohne dein echtes Geraet/
     Content vollstaendig verifizierbar ist. */
  body .hero-text-group {
    position: static !important; /* war relative, davor absolute */
    top: auto !important;
    left: auto !important;
    transform: none !important;
    width: 100% !important;
    /* KORREKTUR (Round 28, 29. Batch): Merle "die Heroheadlinegroup sitzt
       auf dem Handy zu tief". Live gemessen (606x701, Sandbox-Annaeherung
       an Hochformat-Handy): zwischen .hero-wrapper-Oberkante und
       .hero__content-wrapper-Oberkante liegen bereits 66px Abstand, exakt
       passend zu --header-height (66px) - das ist offenbar eine NATIVE,
       nicht von uns gesetzte Theme-Reservierung fuer den (sticky) Header.
       Die hier zusaetzlich gesetzten 44px (seit 29.9.) kommen also
       OBENDRAUF - zusammen >100px Abstand, bevor die Headline ueberhaupt
       beginnt. Fix: eigenen Zusatz-Abstand deutlich reduziert (44 -> 16px),
       die native 66px-Reservierung bleibt als Haupt-Sicherheitsabstand
       zum Header bestehen. AUSDRUECKLICHER HINWEIS: beim Live-Test in der
       Sandbox veraenderte diese Zahl den sichtbaren Abstand ueberraschend
       wenig (vermutlich wirkt noch ein weiterer, nicht von uns gesetzter
       Spacing-Mechanismus mit, z.B. natives Grid-/Flex-"gap" auf
       .hero__content-wrapper) - konnte das in der verfuegbaren Zeit nicht
       vollstaendig aufklaeren. Bitte live auf echtem Geraet gegenchecken;
       falls die Textgruppe dadurch immer noch zu tief sitzt, bitte kurz
       Bescheid geben (im Zweifel mit Skizze/Screenshot + genauem
       gewuenschtem Pixel-Abstand) - dann gezielt an der echten Ursache
       weitersuchen statt weiter zu raten. */
    /* KORREKTUR (neue Anfrage): Merle "auf Mobil Hochformat die Heroheadline
       und Subline bitte etwas hoch schieben, das hat einen margin-top, der
       sollte 30-50% des aktuellen Wertes sein" - Mittelwert (40%) von 16px
       gewaehlt: 16px * 0.4 = 6.4px. Falls 30% oder 50% doch besser aussieht,
       bitte kurz sagen. */
    margin-top: 6.4px !important; /* war 16px */
    display: flex !important;
    flex-direction: column !important;
    align-items: center !important;
    /* war 14px einheitlich - jetzt enger als Basis, Logo/Siegel bekommen
       darunter gezielt wieder mehr Raum per margin-top (siehe unten) */
    gap: 8px !important;
    z-index: 6 !important; /* Ziel-Stapelreihenfolge, siehe Kommentar unten */
  }
  /* Zusaetzliches Sicherheitsnetz gegen "komplett unsichtbar": .hero-wrapper
     hat genug Hoehe, Logo/Siegel fehlen trotzdem. Falls irgendwo visibility/
     opacity/display auf "unsichtbar" steht, wird das hart zurueckgesetzt -
     kostet nichts, falls das nicht die Ursache war. */
  body .hero-text-group__logo-link,
  body .hero-text-group__logo,
  body .hero-text-group__siegel-wrapper,
  body .hero-text-group__siegel {
    visibility: visible !important;
    opacity: 1 !important;
  }
  body .hero-text-group__logo-link,
  body .hero-text-group__logo {
    position: static !important;
    bottom: auto !important;
    left: auto !important;
    display: block !important;
    z-index: 5 !important;
  }
  /* KORRIGIERT (Round 28, 28. Batch): Merle meldet nach dem "1/5"-Fix aus
     Batch 27 direkt zwei neue Probleme: (a) das Logo sei jetzt "winzig"
     (siehe ihr Screenshot mit dem Pfeil - ein kaum sichtbarer Punkt) und (b)
     der Hero passe sich in der Hoehe ueberhaupt nicht an den Inhalt an,
     bleibt riesig mit viel Leerraum. ECHTE, ZWEI UNABHAENGIGE Ursachen live
     gefunden (500x524, echter Tab):
     1) DOPPELTE Skalierung: die vorherige Regel setzte "transform:
        scale(0.16)" auf ZWEI verschachtelte Elemente gleichzeitig
        (".hero-text-group__logo-link" UND ".hero-text-group__logo", das
        <img> SITZT INNERHALB des Links) - Transforms vererben sich optisch
        an Kind-Elemente, zwei verschachtelte scale(0.16) multiplizieren sich
        dadurch zu effektiv 0.16*0.16=0.0256 (statt der gewollten 0.16). Live
        gemessen: das <img> rendert dadurch auf nur 10x9.6px statt der
        beabsichtigten ~64x61px - das war das "winzig", nicht ein falscher
        Zielwert.
     2) "transform" ist rein visuell und aendert NIE die Layout-Groesse, mit
        der ein Element bei seinen Geschwistern/Eltern "zu Buche schlaegt" -
        das <img> blieb dadurch FUER DIE HERO-HOEHEN-BERECHNUNG bei seiner
        vollen nativen Groesse (400x377px), obwohl es nur noch winzig
        AUSSAH. In Kombination mit der bestehenden Zentrierungs-Regel weiter
        unten (urspruenglich: Logo soll "mittig zwischen Subline und
        Hero-Unterkante" sitzen, ueber margin-top/bottom:auto in einer Flex-
        Spalte) blieb dadurch viel zu viel Leerraum reserviert - das war
        Merles "Hero passt sich nicht an".
     Fix: komplett auf ECHTE (layout-wirksame) Groesse umgestellt statt
     transform - Hoehe direkt per CSS gesetzt (width:auto zieht die Breite
     automatisch im Seitenverhaeltnis nach, wie beim Desktop-Logo). Ziel-
     groesse an Viewport-BREITE gekoppelt (Hochformat: Breite ist der
     knappere Faktor, siehe auch Merles eigene Begruendung zur Headline
     weiter unten) statt an einem festen px-Wert - bei 500px Breite ergibt
     das ca. 60px Hoehe, nahe an der urspruenglich gewollten "1/5"-Groesse
     (~61px), nur jetzt OHNE den Verdopplungsfehler und mit echter
     Layout-Wirkung. */
  /* NEU (Round 28, 31. Batch): Merle "Planet V Logo 50% größer" (Handy
     Hochformat, Screenshot 8+9) - alle drei clamp()-Eckwerte um 50% erhöht
     (war clamp(28px, 12vw, 65px)). */
  body .hero-text-group__logo {
    /* Round 28, 81. Batch (10% kleiner) wieder zurueckgenommen - Merle:
       "logo doch nicht alleine runter" (82. Batch), Logo soll wieder seine
       vorherige Groesse haben. */
    height: clamp(42px, 18vw, 97.5px) !important;
    margin-top: 16px !important; /* etwas Luft zur Subline, siehe auch Zentrierungs-Regel weiter unten */
    /* NEU (Round 28, 29. Batch): ECHTER Root Cause fuer Merles "Logo ist
       nicht mittig" live gefunden (606x701, echter Tab, Sandbox-
       Annaeherung an Hochformat-Handy): der umgebende Wrapper-Div ist
       nachweislich korrekt zentriert (getBoundingClientRect-Mitte ==
       Viewport-Mitte), das img selbst sass aber trotzdem ~34px zu weit
       links. Ursache: Shopifys natives "Position"-Feature setzt auf dem img
       selbst einen eigenen "transform: translateX(-50%)" (gedacht fuer den
       JETZT nicht mehr genutzten Fall "position:absolute + left:50%" - ein
       solches Element braucht translateX(-50%), um trotz left:50% wirklich
       mittig zu sitzen). Diese Datei setzt position zurueck auf "static"
       (oben), OHNE transform zurueckzusetzen - der native
       translateX(-50%)-Rest verschiebt das Bild dadurch um die Haelfte
       seiner EIGENEN Breite nach links, obwohl es durch die normale
       Flex-Zentrierung des Wrapper-Divs bereits korrekt mittig sitzen
       wuerde. Fix: transform explizit zuruecksetzen. */
    transform: none !important;
  }
  /* Logo + beide Siegel sollen auf Mobil nach unten rechts wandern, Siegel
     zusaetzlich uebereinander statt nebeneinander. Ursache der bisher nur
     halbherzig wirkenden align-self:flex-end-Regel: Logo/Siegel stecken nicht
     direkt als Kind in der Flex-Spalte .hero-text-group, sondern in einem
     eigenen, klassenlosen Wrapper-div von Horizon, das auf seinen Inhalt
     schrumpft - align-self auf den Kind-Elementen selbst wirkte daher ins
     Leere. Fix Teil 1: die Wrapper-divs per :has() ansprechen und dort align-
     self: flex-end setzen. Zusaetzlicher Fund: Horizons "Position"-Feature
     setzt auf dem Siegel-Wrapper einen eigenen transform:translate(...) aus
     dem Editor, der zusaetzlich ~18px zu weit nach rechts verschob - Fix Teil
     2: transform hart zurueckgesetzt. Fix Teil 3: flex-direction:column +
     align-items zum rechten Rand stapelt die Siegel uebereinander statt
     nebeneinander. Live verifiziert bei 500px Fensterbreite (Sandbox-
     Obergrenze) - kein Ueberstand mehr, bitte auf echtem Geraet gegenchecken. */
  /* Neuer Wunsch, ersetzt "Logo+Siegel zusammen unten rechts": das Logo soll
     allein und mittig sitzen, zwischen Subline- und Hero-Unterkante
     zentriert; die Siegel bleiben (gestapelt) am rechten Rand, jetzt aber als
     eigener, aus dem Textfluss geloester Block (position:absolute relativ zu
     .hero__content-wrapper, wie auf Desktop in Abschnitt 16b), damit sie das
     Logo beim Zentrieren nicht mehr beeinflussen. */
  body .hero__content-wrapper {
    position: relative !important;
    /* NEU (Round 28, 79. Batch): Merle hat live in Safari DevTools direkt
       nachgewiesen (nicht geschaetzt!): "top" auf 0 setzen behebt das
       abgeschnittene Logo/die abgeschnittenen Bio-Siegel auf Handy hoch
       komplett (der rosa Balken selbst ist ein ANDERES, unabhaengiges
       Problem - bleibt separat offen, siehe ".hero__container" weiter oben
       in dieser Datei). Offenbar hat Shopifys natives "Position"-Feature
       hier einen eigenen, nicht ueber Inline-Style gesetzten (sondern per
       eingebettetem <style>-Tag kommenden) top-Wert ungleich 0 - mein
       vorheriger JS-Versuch (nativen Inline-top sichern/wiederherstellen)
       griff deshalb ins Leere, der Wert kam nie ueber Inline-Style. Direkt
       Merles verifizierten Wert uebernommen. */
    top: 0 !important;
  }
  /* KORRIGIERT (Round 28, 28. Batch): "margin-top/bottom: auto" verteilte
     bisher absichtlich den GESAMTEN Leerraum zwischen Subline und Hero-
     Unterkante je zur Haelfte ueber/unter diesen Logo-Wrapper (frueherer
     Wunsch: Logo mittig zwischen Subline und Hero-Unterkante). Genau das
     erzeugte jetzt (zusammen mit dem oben behobenen Transform-Bug) den
     riesigen Leerraum, den Merle als "Hero passt sich nicht an" meldet - sie
     moechte stattdessen, dass das Logo DIREKT unter der Subline mit normalem
     Abstand sitzt und der Hero sich auf die tatsaechliche Inhaltshoehe
     schrumpft. Fix: keine Auto-Margins mehr, nur noch horizontale
     Zentrierung (align-self bleibt). */
  body .hero__content-wrapper > div:has(> .hero-text-group__logo-link) {
    align-self: center !important;
    margin-right: 0 !important;
    margin-top: 0 !important;
    /* KORREKTUR (Round 28, 29. Batch): Merle "Logo hat keinen Abstand zum
       Hero-Unterkante" - war zuvor hart auf 0 gesetzt (siehe Kommentar
       oben, sollte damals den von Auto-Margins verursachten UEBERGROSSEN
       Leerraum beheben). Jetzt ein kleiner, fester Abstand als zusaetzliche
       Sicherheit zur Hero-Unterkante (die .hero-wrapper-eigenen 28px
       padding-bottom, siehe Abschnitt 16 oben, bleiben zusaetzlich
       bestehen - zusammen also sichtbar mehr Luft als vorher). Schaetzwert,
       bitte live gegenchecken, ob 20px reichen oder mehr/weniger sein
       sollen. */
    margin-bottom: 20px !important;
  }
  /* GEFUNDENER BUG (7.10., Teil 13): diese Regel und die fast gleichnamige
     weiter unten (".hero-text-group__siegel-wrapper", Kommentar "Siegel fest
     unten rechts") haben BEIDE dieselbe Spezifitaet UND dieselbe Media Query
     - bei Gleichstand gewinnt im CSS immer die zuletzt im Stylesheet stehende
     Regel, pro Eigenschaft einzeln. Die Werte right/bottom/position/display/
     margin/transform/z-index hier wurden dadurch bisher IMMER von der
     spaeteren Regel ueberschrieben und hatten nie sichtbare Wirkung - das
     erklaert, warum mehrfache right/bottom-Anpassungen hier (6%/4% -> 3%/3%)
     am Ergebnis nichts aenderten. Alle Positionierungs-Werte sind jetzt dort
     unten konsolidiert; hier bleiben nur die Eigenschaften stehen, die die
     spaetere Regel NICHT setzt (flex-direction/align-items), damit nichts an
     zwei Stellen gepflegt werden muss. */
  body .hero-text-group__siegel-wrapper {
    /* AB 29.9.: Merle möchte die beiden Siegel nebeneinander statt
       übereinander gestapelt - war flex-direction:column. Live geprüft: passt
       bei 500px Fensterbreite (Sandbox) mit deutlichem Abstand zum Logo,
       keine Überlappung. */
    flex-direction: row !important;
    align-items: flex-end !important;
  }
  body .hero-text-group__siegel {
    display: inline-block !important;
    height: 32.6px !important; /* AB 29.9.: nochmal ~10% kleiner (war 38px); Round 28/25. Batch: weitere 8% kleiner (war 34px); Round 28, 35. Batch: Merle "Bio Siegel 5% größer" (echtes Handy) - war 31px */
    width: auto !important;
  }
  /* Subline: Stroke duenner (1.8 -> 1.6px) + Stapelreihenfolge oben; die
     Schriftgroesse wird in mobile-fixes.js ("HERO AUTO-FIT") live berechnet -
     hier daher bewusst kein festes font-size. */
  body .hero-text-group__subline {
    -webkit-text-stroke-width: 1.6px !important; /* war 1.8px */
    /* GEFUNDENER BUG (Round 28, 20. Batch): Merle "stelle dir hier deine box
       zusammen Button hat immer noch zu viel Webstroke" - obwohl die eigene
       Basis-Regel (.stelldirdeineboxzusammen, ganz oben in der Datei)
       "-webkit-text-stroke: 0 !important" setzt. Root Cause gefunden: dieser
       Button traegt zusaetzlich zu .stelldirdeineboxzusammen auch die native
       Theme-Klasse .hero-text-group__subline (siehe Kommentar einige Zeilen
       weiter unten zum Transition-Bug, derselbe Fund) - und GENAU diese
       Regel hier setzt -webkit-text-stroke-WIDTH auf 1.6px, was die Longhand-
       Property gegen die Shorthand "-webkit-text-stroke: 0" der eigenen
       Klasse gewinnen laesst, weil ".hero-text-group__subline" (mit "body "-
       Praefix) dieselbe Spezifitaet wie ".stelldirdeineboxzusammen" hat UND
       spaeter in der Kaskade steht. Fix direkt darunter, gezielt nur fuer
       das Element, das BEIDE Klassen gleichzeitig traegt (hoehere
       Spezifitaet, gewinnt unabhaengig von der Position in der Datei). */
  }
  body .stelldirdeineboxzusammen.hero-text-group__subline {
    -webkit-text-stroke-width: 0 !important;
    /* KORREKTUR (7.10., Teil 10): Merle meldet, der "Stell Dir Deine Box
       zusammen"-Button animiere beim Scroll-in-View nicht sanft, sondern
       springe "0 auf 100" (abrupter Farbwechsel). Root Cause gefunden: dieser
       Button traegt zusaetzlich zur eigenen Klasse (.stelldirdeineboxzusammen)
       auch die native Klasse .hero-text-group__subline - und die Regel hier
       hatte "transition: font-size 0.25s ease-out !important" gesetzt. Eine
       Kurzschreibweise wie "transition" ERSETZT dabei den GESAMTEN vorherigen
       Transition-Wert, statt nur font-size zu ergaenzen - dadurch ging die in
       .stelldirdeineboxzusammen eigentlich schon vorhandene Farb-Transition
       (0.6s ease) fuer genau dieses Element komplett verloren, der
       Farbwechsel beim Scroll-in-View-Trigger (mobile-fixes.js, Abschnitt 1)
       wirkte dadurch wie ein harter Sprung statt eines weichen Uebergangs.
       Fix: color/-webkit-text-stroke-color wieder mit in dieselbe
       transition-Deklaration aufgenommen, damit beide Effekte (Hero-Subline
       weich bei Schriftgroessen-Aenderungen, CTA-Button weich beim
       Farbwechsel) nebeneinander bestehen bleiben.
       GEFUNDENER STRUKTUR-BUG (Round 28, 35. Batch): hier fehlte die
       oeffnende "{" fuer diese Deklaration - die "transition"-Zeile stand
       als Deklaration OHNE eigenen Selektor direkt nach der schliessenden "}"
       der Regel oben, gefolgt von einer weiteren "}" ohne passendes "{".
       Diese ueberzaehlige schliessende Klammer hat die komplette @media
       (max-width:1199px and orientation:portrait)-Klammer dieses Abschnitts
       ganze 62 Zeilen zu frueh geschlossen - alles von hier bis zur
       naechsten echten "}" (u.a. "white-space:nowrap" fuer die Subline,
       UND vor allem "margin-top:20px !important" fuer den Subline-Headline-
       Abstand) ist dadurch OHNE Media-Query-Schutz GLOBAL/UNSCOPED auf jede
       Fensterbreite angewendet worden, inklusive Desktop. Das erklaert u.a.,
       warum der in mobile-fixes.js fuer Desktop berechnete, groessere
       Headline-Subline-Abstand (SUBLINE_HEADLINE_GAP_FACTOR) nie sichtbar
       war: ein globaler "margin-top:20px !important" (fuer Mobil gedacht)
       hat den per JS gesetzten Inline-Wert (z. B. ~49px bei breitem Desktop)
       die ganze Zeit ueberschrieben. Fix: Deklaration zurueck in die Regel
       oben verschoben (gleicher Selektor, keine neue Regel noetig), damit
       der Media-Query-Block wieder korrekt dort schliesst, wo er von Anfang
       an schliessen sollte. */
    transition: font-size 0.25s ease-out, color 0.6s ease, -webkit-text-stroke-color 0.6s ease !important;
  }
  /* WICHTIGSTE KORREKTUR - behebt "viel zu klein skaliert": fitHero()
     schrumpft die Schrift, bis die Box unter 92% Fensterbreite faellt - setzt
     voraus, dass die Box mit der Textbreite mitschrumpft. Seit .hero-text-
     group auf position:relative + width:100% + display:flex steht, nehmen
     Headline/Subline als block-artige Elemente immer die volle Breite ein -
     die Box wurde nie kleiner als 92vw, die JS-Schleife lief bis zur
     Untergrenze durch. Fix: Breite auf den Textinhalt schrumpfen (fit-
     content), zentriert ueber Auto-Margins - macht fitHero()'s Breitenmessung
     wieder verlaesslich. */
  body .hero-text-group__headline,
  body .hero-text-group__subline {
    width: fit-content !important;
    max-width: 92vw !important;
    margin-left: auto !important;
    margin-right: auto !important;
    text-align: center !important;
  }
  /* Der Punkt nach "geliefert." bricht auf schmaleren iPhones allein auf eine
     eigene Zeile um - derselbe Bug wie auf Desktop (Abschnitt 16b): die
     Headline hat max-width:92vw + overflow-wrap:break-word, bei minimal zu
     breiter Schrift bricht der Browser nur das letzte Wort statt der ganzen
     Zeile. Der Desktop-Fix (kein max-width + word-break:keep-all) wurde nie
     hierher gespiegelt. Fix fuer die Headline (nicht die Subline, die hat
     schon white-space:nowrap): max-width aufheben + Wortumbruch hart
     verbieten - fitHero() soll die Schrift notfalls weiter schrumpfen. */
  body .hero-text-group__headline {
    max-width: none !important;
    word-break: keep-all !important;
    overflow-wrap: normal !important;
    hyphens: none !important;
  }
  /* Subline soll auf Mobil immer einzeilig bleiben und kleiner skaliert
     werden. Root Cause: fitHero() schrumpft per fitToWidth(), bis die Box
     unter 92% Fensterbreite faellt - das funktioniert nur, wenn die Box
     ueberhaupt breiter werden kann. Die Subline hat aber max-width:92vw +
     white-space:normal, der Browser bricht den Text also selbst um, die Box
     bleibt immer <= 92vw, die JS-Schleife greift nie ein. Fix: white-space:
     nowrap + max-width:none nur fuer die Subline, damit fitToWidth() die
     tatsaechliche Breite sieht und korrekt schrumpft. Live verifiziert:
     Schrift schrumpft von ~24.1px auf ~21.1px, danach 1 Zeile bei
     450.7px/460px Ziel. */
  body .hero-text-group__subline {
    white-space: nowrap !important;
    max-width: none !important;
  }
  /* Subline soll naeher an die Headline heranruecken. Sie erbt (ueber
     dieselbe Klasse wie der CTA-Button) einen nativen margin-top von 3em -
     bei aktueller Schriftgroesse ca. 63px zusaetzlich zum 8px-Flex-Gap. Hart
     auf einen festen, viel kleineren Wert reduziert. */
  body .hero-text-group__subline {
    margin-top: 20px !important; /* AB 7.10.: war 10px, auf Merles Wunsch "etwas mehr Abstand" erhoeht - Richtwert, bitte live gegenchecken */
  }
  /* Stapelreihenfolge abgesichert: Logo (z:5)/Siegel (z:4) erben als BEM-
     Kinder von .hero-text-group bereits dessen z-index:6 gegenueber den
     Planeten (1-3). Damit Headline/Subline auch innerhalb der Gruppe sicher
     ueber Logo/Siegel liegen, hier zusaetzlich ein eigener, hoeherer z-index. */
  body .hero-text-group__headline,
  body .hero-text-group__subline {
    position: relative !important;
    z-index: 7 !important;
  }
}

/* NEU (Round 28, 32. Batch): Merle "Auf dem Handy ist der Hero perfekt, Logo
   nur 18% kleiner, und den Webstroke der Subline halbieren" - ausdrücklich
   NUR für echtes Handy (Breite <= 749px), NICHT für die "schmale Hochkant-
   Browserfenster"-Fälle (siehe Abschnitt weiter unten, isTabletPortraitLike-
   Phone), die eigene, separate Anpassungen bekommen. Da die allgemeine
   Mobil/Tablet-Hochkant-Regel oben (max-width:1199px) für beide Fälle
   gemeinsam gilt, hier eine engere, nach ihr stehende (= bei gleicher
   Spezifität gewinnende) Regel nur für max-width:749px. */
@media screen and (max-width: 749px) and (orientation: portrait) {
  body .hero-text-group__logo {
    /* GEFUNDEN (Round 28, 35. Batch): diese ganze Regel wurde bisher von
       einem Strukturbug (siehe base-css-changelog/offene-aufgaben-liste,
       Fund dieser Runde) STILL SCHWEIGEND aus dem CSSOM entfernt und hat nie
       gegriffen - live per CSSOM-Parse bestaetigt. Merles "Logo nur 18%
       kleiner" war dadurch nie sichtbar wirksam; stattdessen galt die
       groessere clamp(42px, 18vw, 97.5px)-Rueckfallregel (siehe Abschnitt
       weiter oben, max-width:1199px). Mit dem Strukturbug-Fix greift diese
       Regel jetzt zum ERSTEN MAL tatsaechlich - zusaetzlich hier gleich
       Merles neuer Wunsch "Logo 5% kleiner" (diese Runde) mit eingerechnet:
       alle drei clamp()-Eckwerte nochmal um 5% reduziert. */
    height: clamp(32.7px, 14.02vw, 76px) !important; /* war clamp(34.4px, 14.76vw, 80px), nochmal 5% kleiner - UND jetzt dank Strukturbug-Fix ueberhaupt erstmals wirksam */
  }
  body .hero-text-group__subline {
    -webkit-text-stroke-width: 0.8px !important; /* war 1.6px, halbiert - GEFUNDEN (Round 28, 35. Batch): auch diese Regel war bisher durch denselben Strukturbug aus dem CSSOM entfernt, siehe Kommentar oben */
  }
}

/* NEU (Round 28, 32. Batch): Merle zur "schmalen Hochkant-Browserfenster"-
   Ansicht (Screenshot 1, z. B. ein schmal gezogenes Desktop-Fenster oder ein
   Tablet im Hochformat - NICHT das echte Handy, das laut Merle bereits "perfekt"
   ist): "Textgroup ein Stück runter, Logo ein Stück hoch, beide zentriert auf
   der Heromitte; das Logo könnte statt eigenständig unten zu sitzen, an die
   Herogroup unten andocken, im doppelten Abstand zur Subline wie die Subline
   zur Headline hat, und mit der Herotextgroup mitskalieren." Dafür braucht
   dieser Bereich (750-1199px, Hochformat - entspricht genau "isTablet
   PortraitLikePhone" in mobile-fixes.js) überhaupt erst einen festen
   Hero-Rahmen, in dem "zentrieren" etwas bedeutet - bisher hatte .hero-wrapper
   hier (wie beim echten Handy) height:auto, wuchs also IMMER exakt auf die
   Inhaltshöhe, ohne jeden Leerraum zum Zentrieren. Fix: in genau diesem
   schmaleren Bereich (anders als beim echten Handy direkt darüber/darunter)
   wie auf Desktop min-height:100dvh verwenden - die eigentliche Positionierung
   übernimmt mobile-fixes.js (siehe dortiger neuer isTabletPortraitLikePhone-
   Zweig). Muss NACH der allgemeinen Regel oben stehen, um bei gleicher
   Spezifität zu gewinnen.
   KORREKTUR (Round 28, 38. Batch): Merle testete "schmales Hochkant-
   Browserfenster" live bei 725px Breite (per DevTools gemessen) und meldete
   "du hast gar nichts gefixt" - Root Cause: das feste "min-width:750px" traf
   ihr tatsächliches Testfenster (725px) nicht, es fiel dadurch in den
   gemeinsamen "echtes Handy"-Bereich zurück. Ein reiner Breiten-Schwellwert
   kann einen mit der Maus schmal gezogenen Desktop-Browser nicht zuverlässig
   von einem echten, schmalen Touch-Gerät unterscheiden - der einzige dafür
   geeignete CSS-Signal ist (hover:hover) and (pointer:fine) (= Maus
   vorhanden), das echte Touch-Phones zuverlässig ausschließt, unabhängig
   von der exakten Pixel-Breite. Fix: "min-width:750px" entfernt, stattdessen
   "(hover:hover) and (pointer:fine)" ergänzt - trifft jetzt JEDES schmale,
   mit der Maus bediente Browserfenster im Hochformat bis 1199px, auch wenn
   es (wie bei Merles Test) unter 750px liegt. Dieselbe Umstellung wurde
   konsistent auch in mobile-fixes.js (isMobile-Definition) und in der
   zweiten Fassung dieses Bereichs weiter unten in der Datei vorgenommen. */
/* KORREKTUR (Round 28, 88. Batch): Merle "Tablet braucht Touchscreen-
   Funktionen, optisch wie Desktop hoch" - diese Regel war bisher auf
   "(hover:hover) and (pointer:fine)" (Maus) beschraenkt, mit der
   urspruenglichen Begruendung, einen schmal gezogenen Maus-Desktop-Browser
   (<750px) von einem echten Handy zu unterscheiden (siehe Kommentar oben).
   Ein echtes Touch-Tablet (z.B. iPad hochkant, 768-1024px breit) wurde
   dadurch unbeabsichtigt ebenfalls ausgeschlossen - ab 750px ist "echtes
   Handy" (das eigene, separate Regel-Set bis max-width:749px) ohnehin per
   Breite ausgeschlossen, Maus/Touch muss dort also gar nicht mehr
   unterschieden werden. Fix: zweigeteilte Bedingung - ab 750px breit gilt
   diese Regel JETZT FUER ALLE Zeigegeraete (Maus UND Touch), darunter
   (<750px, wo die Verwechslungsgefahr mit einem echten Handy besteht)
   weiterhin nur bei Maus.
   KORREKTUR (Round 29, 89. Batch): Merle meldet bei 601x798 (schmales,
   mit Maus/Trackpad bedientes Fenster, z.B. Safari-Custom-Groesse) werden
   Logo/Bio-Siegel abgeschnitten. Root Cause: diese Regel hatte bisher KEINE
   Mindesthoehe - sie geht von genug vertikalem Platz aus (100dvh-Hero +
   die unten folgenden vh-basierten Abstaende), passt aber bei knapp 800px
   Hoehe nicht mehr. JS stuft ein derart schmales+kurzes Fenster intern
   ohnehin schon fast wie ein Handy ein (isTabletPortraitLikePhone/
   pvIsMobilePortraitScope). Fix (Merles Wahl): Mindesthoehe von 850px
   ergaenzt - darunter faellt die Ansicht automatisch auf das bestehende,
   bereits bewaehrte Echtes-Handy-Regelwerk (siehe Abschnitt weiter oben,
   max-width:749px, keine hover-Einschraenkung) zurueck. 850px ist ein
   Schaetzwert mit etwas Sicherheitsabstand ueber den gemeldeten 798px -
   bitte live gegenchecken, ob das reicht oder der Wert noch hoeher muss.
   KORREKTUR (Round 29, 93. Batch): ECHTER ROOT CAUSE fuer "Headline
   verschwindet"/"Navbar-Ueberlappung bei quadratischem Fenster" gefunden
   (live per DevTools bei 1101x1126 bestaetigt, siehe ausfuehrlicher
   Kommentar bei "isTabletPortraitLikePhone" in mobile-fixes.js): der
   750-1199px-Hochformat-Zweig dieser Regel UND die "echter Desktop"-Regel
   weiter unten (Abschnitt 16b, deren "(hover:hover) and (pointer:fine)"-
   Bedingung KEINE Ausrichtung prueft) griffen in genau diesem Breitenbereich
   bei einem mit der Maus bedienten Hochformat-/quadratischen Fenster
   GLEICHZEITIG - zwei grundverschiedene Positionierungs-Systeme
   (position:absolute+top% hier vs. position:relative+Flex dort) ueberschrieben
   sich gegenseitig. Fix (konsistent mit Merles eigenem Vorschlag "bei sehr
   schmalen Fenstern auf Handy-Hochformat-Styling umschalten, sonst wie
   Desktop breit behandeln"): dieser 750-1199px-Hochformat-Zweig entfaellt
   komplett - dieser Breitenbereich läuft jetzt durchgaengig durch die
   "echter Desktop"-Regel (Abschnitt 16b), deren Bedingung dafuer unten
   passend auf Hochformat erweitert wurde. Nur das echte schmale
   Hochkant-Browserfenster (<750px, mit Maus ODER Touch) bleibt hier. */
@media screen and (max-width: 749px) and (orientation: portrait) and (hover: hover) and (pointer: fine) and (min-height: 850px) {
  body .hero-wrapper {
    min-height: 100dvh !important;
    height: 100dvh !important;
  }
}

/* ---------------------------------------------------------------- 16b. HERO:
   DESKTOP/BREITE FENSTER (ab 750px) - Groesse an der Fensterhoehe statt an
   fixen px ausrichten. Ursache: .hero-wrapper hatte auf Desktop eine feste,
   native min-height:800px - Fensterhoehe hatte keinerlei Auswirkung.
   Zusaetzlich positioniert Horizons "Position"-Feature Headline/Logo/Siegel
   mit festen Pixelwerten statt Prozent. FIX: 1) .hero-wrapper bekommt
   height/min-height:100dvh. 2) .hero-text-group + Logo + Siegel-Wrapper von
   position:absolute auf position:relative umgestellt - dadurch uebernimmt der
   native Flex-Container (justify-content:flex-end) die Anordnung: alles
   stapelt sich unten, der freie Platz sammelt sich automatisch oben. Die
   Schriftgroesse wird bewusst nicht per festem clamp()/vw gesetzt
   (Zeilenumbruch unvorhersehbar) - fitHero() uebernimmt das auch fuer
   Desktop. Deshalb kein font-size/!important hier - das wuerde die JS-Inline-
   Styles ueberstimmen und die Anpassung wirkungslos machen (live geprueft).
   KORREKTUR (nach erstem Live-Test): die erste fitHero()-Logik zwang die
   Headline immer auf 40% der Hero-Hoehe, auch wenn ihre natuerliche Groesse
   gepasst haette. Umgebaut: Headline/Subline behalten zuerst immer ihre
   natuerliche Groesse und werden nur verkleinert, wenn der Inhalt nicht mehr
   in die Hero-Hoehe passt - eine reine Verkleinerung kann keinen
   zusaetzlichen Umbruch erzeugen. line-height wird deshalb nicht mehr
   ueberschrieben. Logo/Siegel-Hoehe bleibt als einfacher clamp()-Wert in CSS.
   Live getestet bei 1600x806 und 1000x657 - kein Ueberlappen. Bitte auf einem
   hoeheren Monitor gegenchecken (Sandbox hier auf ~950px gedeckelt).
   KORREKTUR (Round 20): der Bereich 750-1199px im HOCHFORMAT (iPad Hochkant)
   gehoert jetzt zu Abschnitt 16 oben (Handy-Hochkant-Logik) statt hierher -
   die Bedingung ist daher aufgeteilt in "echtes breites Desktop" (ab 1200px,
   unabhaengig von der Ausrichtung) ODER "750-1199px, aber nur im Querformat"
   (z.B. iPad Quer, Handy Quer in diesem Breitenbereich). iPad Hochkant faellt
   dadurch jetzt NICHT mehr hierher, sondern in Abschnitt 16.
   KORREKTUR 2 (Bugfix nach Video-Feedback): Handy im Querformat kann durchaus
   breiter als 749px sein (z.B. iPhone 14 quer ca. 844px) - landete dadurch
   faelschlich HIER (echtes Desktop-Verhalten: 100dvh erzwungen) statt im
   dedizierten Handy-Quer-Bereich (170vh, siehe Abschnitt weiter unten). Echte
   Handy-Quer-Geraete sind aber zuverlaessig FLACH (Hoehe <=500px), waehrend
   Tablet-Quer (z.B. iPad Quer) deutlich hoeher ist. Deshalb zusaetzlich
   "und (min-height: 501px)" ergaenzt, damit flache Handy-Quer-Viewports hier
   NICHT mehr hineinfallen, sondern korrekt im Handy-Quer-Bereich landen.
   KORREKTUR (Round 26): Bedingung um den dritten "quadratischer/hochformatiger
   Desktop"-Zweig erweitert - ausfuehrliche Begruendung siehe der erste
   Vorkommen dieser Media Query weiter oben in der Datei (Abschnitt beim
   Webkit-Text-Stroke). Das war der direkte Root Cause fuer Merles gemeldete
   "Hero-Headline sitzt nicht mittig"-Bug bei quadratischem Fenster: ohne
   diesen Zweig blieb .hero-text-group in diesem Breitenbereich auf
   position:absolute (von weiter oben in der Datei), die Positionierung lief
   dadurch noch nach den fuer ein anderes Format gedachten Regeln. */
@media screen and (min-width: 1200px), screen and (min-width: 750px) and (orientation: landscape) and (min-height: 501px), screen and (min-width: 750px) and (max-width: 1199px) and (orientation: portrait) {
  /* GEAENDERT (Round 28, 32. Batch): Merle zu sehr breiten, aber knapp hohen
     Fenstern (Screenshot 3): "die Heroheadline sollte schon um 25% schrumpfen
     können, der Hero sollte eine Mindesthöhe auf dem Desktop haben und
     einfach nach unten aus dem Browserfenster rauslaufen". Bisher zwang
     "height:100dvh !important" den Hero auf EXAKT die (in diesem Fall sehr
     kleine) Fensterhöhe - mobile-fixes.js (fitHero, echter-Desktop-Zweig)
     berechnet availableHeight direkt daraus, wodurch Headline/Logo bei sehr
     flachen Fenstern extrem stark schrumpfen mussten, um überhaupt
     hineinzupassen. Fix: "height:100dvh" entfernt (nur noch min-height
     bleibt bestimmend), UND min-height per CSS max() zusätzlich auf einen
     festen Mindestwert (560px, SCHÄTZWERT) angehoben - dadurch kann der Hero
     bei sehr kurzen Fenstern über die Fensterhöhe hinaus nach unten wachsen
     (Seite wird an der Stelle scrollbar) statt sich bis zur Unkenntlichkeit
     zusammenzudrücken. Bei normal hohen Fenstern ändert sich nichts (100dvh
     ist dort ohnehin größer als 560px, der Inhalt füllt die Box wie bisher
     exakt aus). */
  body .hero-wrapper {
    min-height: max(100dvh, 560px) !important;
  }
  /* Erklaert "springt nach unten"/"skaliert ruckartig": nicht .hero-wrapper
     ist die tatsaechlich sichtbare Box, sondern `.hero__container` - dessen
     Hoehe veraendert sich beim reinen Verbreitern des Fensters (Hoehe
     unveraendert!) von ~904px auf ~673px, vermutlich ueber eine native
     Horizon-Bildhoehen-/Seitenverhaeltnis-Logik. Die fuer fitHero() relevante
     Hoehe war also nicht nur von der Fensterhoehe abhaengig. Fix:
     `.hero__container` zusaetzlich hart auf 100dvh fixiert. Der Attribut-
     Selektor [id^="Hero-template--"] sichert gezielt nur den Hero-Container
     ab (nicht die generische Klasse ".hero", die auch ausserhalb vorkommen
     koennte). GEAENDERT (Round 28, 32. Batch): gleicher Grund/gleiche
     Aenderung wie direkt oberhalb bei .hero-wrapper (min-height statt hartem
     height, plus 560px-Mindesthöhen-Deckel). */
  body .hero__container,
  body [id^="Hero-template--"] {
    min-height: max(100dvh, 560px) !important;
  }
  body .hero__content-wrapper {
    /* AB 28.9.: positionierter Bezugsrahmen für das jetzt wieder eigenständig
       (per position:absolute) positionierte Siegel unten - siehe .hero-text-
       group__siegel-wrapper weiter unten. */
    position: relative !important;
  }
  body .hero-text-group {
    position: relative !important;
    top: auto !important;
    left: auto !important;
    right: auto !important;
    bottom: auto !important;
    /* `!important` bei transform entfernt - "Headline/Subline hoeher" wird
       jetzt live per mobile-fixes.js (transform:translateY) gesetzt. Mit
       !important haette der CSS-Startwert immer gegen die JS-Zuweisung
       gewonnen - derselbe Stolperstein wie zuvor bei font-size, top und
       margin-bottom. transform:none bleibt als Startwert, nur ohne
       !important. */
    transform: none;
  }
  body .hero-text-group {
    width: 100% !important;
    display: flex !important;
    flex-direction: column !important;
    align-items: center !important;
    gap: 0.1dvh !important; /* AB 28.9., 4. Korrektur: nochmal enger, Merles Wunsch "subline höher an die headline ran" (war 0.4dvh) */
    /* margin-bottom bewusst ohne !important. Ursache fuer "alles zu weit
       unten, abgeschnitten": ein fixer 6dvh-Betrag reichte nicht fuer die
       tatsaechliche Logo-Hoehe (clamp(36px,8dvh,110px)) und war zusaetzlich
       mit !important gegen ein Nachjustieren per JS blockiert. Fix: mobile-
       fixes.js setzt den Wert jetzt live passend zur Logo-Hoehe. */
    margin-bottom: 6dvh;
    z-index: 6 !important;
  }
  body .hero-text-group__headline,
  body .hero-text-group__subline {
    z-index: 7 !important;
    width: fit-content !important;
    margin-left: auto !important;
    margin-right: auto !important;
  }
  body .hero-text-group__headline {
    /* Merle nutzt jetzt manuelle <br>-Umbrueche im Headline-Markup, damit die
       Zeilenaufteilung immer gleich bleibt. Ein max-width war dafuer
       kontraproduktiv: bei schmalen Fenstern brach das Theme ein einzelnes zu
       breites Wort mitten im Wort um ("geliefer" / "t."). Fix: kein max-width
       mehr - die Breite wird ausschliesslich von fitHero() ueber die
       Schriftgroesse gesteuert, ohne die <br>-Umbrueche zu veraendern. word-
       break/overflow-wrap/ hyphens zusaetzlich hart auf "kein Umbrechen",
       damit ein Fehlerfall sichtbar uebersteht statt lautlos den Punkt zu
       isolieren. */
    max-width: none !important;
    overflow-wrap: normal !important;
    word-break: normal !important;
    hyphens: none !important;
    text-align: center !important;
    /* NEU (Round 28/Batch 15): Merle meldet bei einem sehr hohen/schmalen
       Desktop-Fenster, dass die Headline so viel Hoehe einnimmt, dass unten
       das Logo abgeschnitten wird, und wuenscht explizit eine geringere
       line-height als Teil der Loesung (zusaetzlich zu den in mobile-
       fixes.js reduzierten Logo-Abstaenden). Mobil steht line-height bereits
       auf 106% (Abschnitt weiter oben) - hier derselbe Gedanke fuer Desktop,
       das bisher GAR keine eigene line-height hatte (nativer Theme-Wert).
       Schätzwert, da ich dieses genaue, sehr hohe Fensterformat in meiner
       Sandbox nicht nachstellen kann - bitte live gegenchecken. */
    /* KORREKTUR (Round 28, 77. Batch): Merle "lineheight der heroheadline zu
       gross" (Desktop quer) - von 100% auf 90% reduziert. Hinweis zu ihrem
       "99% wird irgendwie ueberschrieben"-Test: ein in DevTools testweise
       eingetragener Wert OHNE "!important" verliert automatisch gegen jede
       bestehende "!important"-Regel (genau das hier) - das ist kein Bug,
       beim naechsten Live-Test in DevTools bitte "!important" mit eintragen,
       dann zeigt sich der Effekt sofort. */
    line-height: 90% !important;
    /* WIEDER EINGESETZT (Round 28, 76. Batch): Merle bestaetigt per
       Screenshot (breiter echter Desktop) - die Bio-Siegel fehlen WEITERHIN,
       obwohl der display:block-Hero-Fix komplett zurueckgerollt ist. Die
       75.-Batch-Theorie (Siegel-Problem sei nur eine Nebenwirkung von
       display:block gewesen) war damit WIDERLEGT - es ist ein eigenstaendiges
       Problem. Merles live verifizierter Wert hilft nachweislich auch ohne
       display:block, also direkt wieder rein, 1:1 wie von ihr getestet. */
    bottom: 6.5em !important;
  }
  /* NEU (Round 28/Batch 18): Merle, erneuter Hinweis - "bei sehr breit
     gezogenem Desktop wird das Logo unten abgeschnitten, die Abstaende und
     die line-height muessten kleiner werden, die Schriftgroessen sollen
     aber gleich bleiben". Zusaetzlich zu obigem line-height:100% (das gilt
     fuer JEDEN Desktop/Tablet-Querformat-Fall) hier eine WEITERE Reduzierung
     nur fuer wirklich sehr breite Fenster (aspect-ratio >= 2:1 als
     Schaetzwert fuer "sehr breit gezogen"). Siehe auch mobile-fixes.js fuer
     die passend verkleinerten Logo-Abstaende in genau diesem Fall.
     AUSDRUECKLICHER HINWEIS: konnte nicht live gegengeprueft werden (Chrome
     getrennt), der aspect-ratio-Schwellenwert ist eine Schaetzung. */
  @media (min-aspect-ratio: 2/1) {
    body .hero-text-group__headline {
      line-height: 90% !important;
    }
  }
  body .hero-text-group__logo-link {
    /* Logo soll fest auf halber Strecke zwischen Subline-Unterkante und Hero-
       Unterkante sitzen, statt direkt unter der Subline zu kleben. Haengt von
       zwei live veraenderlichen Werten ab (Subline-Position, Hero-Hoehe) -
       deshalb aus dem Flex-Stapel geloest und per position:absolute + live
       berechnetem "top" in mobile-fixes.js platziert. Horizontal weiterhin
       zentriert. */
    position: absolute !important;
    /* "top" bewusst ohne !important - Kern-Bug des Absturzes ("Logo weg"):
       !important auf "top" gewinnt immer gegen einen per JS gesetzten
       normalen Inline-Style. Der berechnete Wert wurde zwar korrekt
       geschrieben, der computed style blieb aber bei top:0 - das Logo landete
       immer oben. Fix: nur ein einfacher Startwert (0, ohne !important),
       mobile-fixes.js ist die einzige Quelle fuer den tatsaechlichen Wert. */
    top: 0;
    left: 50% !important;
    right: auto !important;
    bottom: auto !important;
    transform: translateX(-50%) !important;
    margin: 0 !important;
    display: block !important;
    z-index: 5 !important;
  }
  body .hero-text-group__logo {
    /* Beim Aufsplitten der alten gemeinsamen Reset-Regel ist der Reset fuer
       das innere <img> versehentlich weggefallen. Horizons natives
       "Position"-Feature setzt dort selbst position:absolute +
       transform:matrix(...) als Inline-Style - ohne Reset blieb das bestehen,
       das Logo wurde unsichtbar/ verschoben. Fix: Logo-Bild wieder auf
       position:relative - die Positionierung passiert jetzt ausschliesslich
       ueber den umgebenden .hero-text-group__logo-link. */
    position: relative !important;
    top: auto !important;
    left: auto !important;
    right: auto !important;
    bottom: auto !important;
    transform: none !important;
    display: block !important;
    /* NEU (Round 28, 32. Batch): Merle "Logo größer, doppelt so groß" - siehe
       die erste Fassung dieser Regel weiter oben in der Datei (ebenfalls
       verdoppelt), beide synchron gehalten.
       KORREKTUR (Round 28, 35. Batch): Merle "Logo auf dem Desktop 20%
       kleiner" (breites Fenster) - alle drei clamp()-Eckwerte um 20%
       reduziert (war clamp(72px, 16dvh, 220px)). Siehe auch die zweite,
       weiter oben in der Datei stehende Fassung derselben Regel (dort
       ebenfalls reduziert), beide synchron gehalten. */
    /* KORREKTUR (Round 28, 37. Batch): Merle "Logo 8% kleiner" (breiter
       Desktop) - alle drei clamp()-Eckwerte zusaetzlich um 8% reduziert
       (war clamp(57.6px, 12.8dvh, 176px)). Siehe auch die erste, weiter
       oben in der Datei stehende Fassung derselben Regel (dort ebenfalls
       reduziert), beide synchron gehalten. Live verifiziert (1920x764):
       Logo schrumpft von 97.79px auf 89.96px, entspricht genau 8%. */
    /* NEU (Round 28, 76. Batch): Merle "Logo auch größer" - siehe die erste
       Fassung weiter oben in der Datei, synchron um denselben Faktor (25%)
       erhoeht. */
    height: clamp(66.24px, 14.72dvh, 202.4px) !important; /* war clamp(52.992px, 11.776dvh, 161.92px), 25% groesser */
    width: auto !important;
    z-index: 5 !important;
  }
  body .hero-text-group__siegel-wrapper {
    /* Siegel fest unten rechts in der Ecke, unabhaengig von
       Headline/Subline/Logo - dafuer aus dem Flex-Stapel geloest und relativ
       zum umgebenden .hero__content-wrapper (position:relative) fest
       positioniert. KONSOLIDIERT (7.10., Teil 13): das ist die Regel, die
       tatsaechlich gewinnt (siehe Kommentar weiter oben) - right/bottom hier
       sind jetzt auf Merles zuletzt gewuenschten Wert (3%/3%, war 3dvh/3dvh)
       gesetzt, zusammen mit .hero-text-group auf position:static (siehe
       oben) sollte das Siegel jetzt wirklich in der Ecke von
       .hero__content-wrapper landen statt mittig. Bitte live gegenchecken. */
    position: absolute !important;
    top: auto !important;
    left: auto !important;
    /* KORREKTUR (Round 28, 20. Batch): Merle "Bio-Siegel IMMER noch rechts
       abgeschnitten" - das ist die tatsaechlich wirksame Regel (siehe
       "GEFUNDENER BUG"-Kommentar bei der anderen, bisher wirkungslosen
       ".hero-text-group__siegel-wrapper"-Regel weiter oben in dieser
       Datei). 3% war Merles eigener, zuletzt genannter Wert (7.10., Teil
       13) - der reicht laut aktuellem Feedback nicht aus. Grosszuegig auf
       9% erhoeht (mehr als die bisherigen 3% UND mehr als der nie wirksam
       gewordene 7%-Versuch), Schaetzwert, bitte live gegenchecken.
       KORREKTUR (Round 28, 35. Batch): Merle "Bio-Siegel auf breitem Desktop
       zu weit rechts, 2-4% weiter links" - auf 12% erhoeht (Mitte des
       genannten Bereichs). Gilt hier als BASIS-Wert fuer das gesamte
       Breiten-Spektrum dieses Blocks; fuer den schmaleren Bereich
       (750-1199px) gibt es direkt im Anschluss an diesen Block eine
       gezielte Korrektur in die GEGENTEILIGE Richtung (Merles getrennte
       Rueckmeldung dort: "etwas weiter rechts"), da ein einzelner
       Prozentwert beide Faelle nicht gleichzeitig bedienen kann.
       KORREKTUR (Round 28, 37. Batch): Merle "Bio-Siegel immer noch zu
       weit links, bitte die 12%-Regel loswerden" - auf 2% reduziert.
       Live verifiziert (1920x764 echter Desktop): Siegel sitzt danach
       nah am rechten Rand, nicht mehr abgeschnitten. */
    right: 2% !important; /* war 12% */
    bottom: 3% !important;
    transform: none !important;
    margin: 0 !important;
    display: flex !important;
    justify-content: flex-end !important;
    /* NEU (Round 28, 32. Batch): Merle "doppelt so viel Gap zwischen beiden
       Bio-Siegeln" (Desktop). */
    gap: 12px !important; /* war 6px, verdoppelt */
    z-index: 4 !important;
  }
  body .hero-text-group__siegel {
    /* NEU (Round 28, 32. Batch): Merle "Bio Siegel 50% größer" - siehe auch
       die erste Fassung dieser Regel weiter oben in der Datei (ebenfalls
       um 50% erhöht), beide synchron gehalten. */
    height: clamp(34.5px, 7.77dvh, 120px) !important; /* war clamp(23px, 5.18dvh, 80px), 50% größer */
    width: auto !important;
  }
}

/* NEU (neue Anfrage): Merle "kann der hero auf breiten Desktopbrowserfenstern
   etwas weniger hoch werden? 10% weniger vom vh? also 90/95vh statt 100?" -
   ausdruecklich nur fuer "breite" Fenster genannt, NICHT fuer die schmale/
   quadratische "echter Desktop"-Zone (750-1199px) oder Tablet-Quer, die ihre
   grosse Mindesthoehe laut Merles eigener Architektur-Vorgabe ausdruecklich
   behalten sollen. Deshalb bewusst als eigener, NACH dem grossen
   gemeinsamen Block oben stehender (= bei gleicher Spezifitaet gewinnender)
   Block NUR fuer min-width:1200px - 100dvh -> 90dvh (genau die von ihr
   genannten "10% weniger"; falls 95vh doch besser aussieht, bitte Bescheid
   geben). Der grosse Block oben (Zeile ~6266) bleibt dabei komplett
   unangetastet - hier wird nur die Mindesthoehe fuer den schmaleren
   min-width:1200px-Ausschnitt gezielt ueberschrieben. */
@media screen and (min-width: 1200px) {
  body .hero-wrapper,
  body .hero__container,
  body [id^="Hero-template--"] {
    min-height: max(90dvh, 560px) !important;
  }
}

/* NEU (Round 28, 35. Batch): Merle meldet fuer ein schmaleres Desktop-/
   Browserfenster (750-1199px breit, "quadratisch" bzw. "ultraschmal" -
   faellt in denselben Breitenbereich wie der dritte OR-Zweig des grossen
   Blocks direkt oberhalb) eine GEGENTEILIGE Bio-Siegel-Position ("etwas
   weiter rechts" statt "weiter links" wie beim breiten Desktop) UND eine
   deutlich groessere Siegel-Groesse ("doppelt so groß"), ausserdem einen
   insgesamt knapperen Hero ("15% kleiner in der Hoehe"). Bewusst als
   separater, NACH dem grossen Block stehender (= bei gleicher Spezifitaet
   gewinnender) Mini-Block umgesetzt, damit der breite Desktop-Fall
   (>=1200px) komplett unangetastet bleibt - diese Media Query matcht NUR
   den schmaleren 750-1199px-Bereich. AUSDRUECKLICHER HINWEIS: ich konnte in
   meiner Sandbox nicht zuverlaessig zwischen Merles "quadrat"- und
   "ultraschmal"-Testfenstern unterscheiden (beide fielen bei meinen
   Versuchen in genau diesen Breitenbereich) - die feinere, asymmetrische
   Logo-Positionierung ("Abstand Subline-Logo halbieren, Logo aber tiefer")
   aus der "quadrat"-Meldung habe ich deshalb NICHT separat umgesetzt, um
   nichts auf Verdacht falsch herum zu drehen. Bitte bei Gelegenheit die
   genauen Pixel-Masse (Fensterbreite x -hoehe) der beiden Testfaelle
   mitteilen, dann kann ich das gezielt nachschaerfen. */
/* ENTFERNT (Round 29, 93. Batch): ECHTER ROOT CAUSE fuer Merles neu
   gemeldeten Bug "Hero-Hoehe wird vom Fenster-BREITE statt von der Hoehe
   bestimmt" (ihre eigenen Worte: "at first the height gets determined by
   the browser windows width, not the height - that should not have
   influence"). Dieser Mini-Block senkte die Hero-Mindesthoehe exakt in
   diesem Breitenfenster (750-1199px) von 100dvh auf 85dvh ab - unabhaengig
   von der tatsaechlichen Fensterhoehe. Beim Ziehen ueber die 1200px-Grenze
   hinweg sprang die Hero-Hoehe dadurch abrupt zwischen 85dvh und 100dvh hin
   und her (live von Merle beobachtet: "#Hero-template--...hero_jVaWmY wird
   kleiner, 1160/1260px auf 1045px, sollte aber gleich bleiben") - rein
   breitenabhaengig, exakt das, was sie jetzt explizit nicht mehr moechte.
   Fix: dieser Hoehen-Sonderfall entfaellt ersatzlos - der gesamte "echter
   Desktop"-Bereich (Landscape/Breit/Quadrat, s.u.) nutzt jetzt einheitlich
   dieselbe Mindesthoehen-Formel (max(100dvh, 560px), Abschnitt 16b) ohne
   Ausnahme fuer diesen Breitenbereich. Die hier vormals gesetzte Siegel-
   Position (right:3%) ist identisch mit dem Wert, den der nachfolgende,
   fuer denselben Breitenbereich ebenfalls geltende Block (naechster
   Abschnitt, "ab ca. 1138px...") ohnehin setzt - keine Funktionslluecke. */

/* NEU (Round 28, 86. Batch): Merle "ab ca. 1138px sieht Desktop quer gut
   aus, das soll auch bei breiteren Fenstern so aussehen - Media Query auf
   ganz breite Browserfenster uebertragen". Die vorher (83./85. Batch) nur
   auf 750-1199px gescopten Siegel-/Logo-Fixes werden hier UNVERAENDERT
   uebernommen, aber mit derselben "echter Desktop" Media Query wie der
   grosse gemeinsame Block (Abschnitt 16b, inkl. min-width:1200px) versehen
   - gilt jetzt fuer ALLE Desktop-/Tablet-quer-Breiten gleichermassen, nicht
   mehr nur fuer den schmaleren Bereich. Bewusst als eigener, NACH dem
   grossen Block UND nach dem 750-1199px-Mini-Block stehender Block (gewinnt
   bei gleicher Spezifitaet). */
@media screen and (min-width: 1200px), screen and (min-width: 750px) and (orientation: landscape) and (min-height: 501px), screen and (min-width: 750px) and (max-width: 1199px) and (orientation: portrait) {
  body .hero-text-group__siegel-wrapper {
    bottom: 3.5em !important;
    /* "right" vereinheitlicht auf denselben Wert wie der 750-1199px-Block
       (3%, war dort 1%/hier 2%) - Merle "ein bisschen mehr Abstand right",
       jetzt fuer ALLE Desktop-Breiten gleich. */
    right: 3% !important;
    transform: translateX(6px) !important;
  }
  body .hero-text-group__logo {
    height: clamp(50.97168px, 11.32704dvh, 155.7468px) !important;
  }
}

/* NEU (neue Anfrage): Merle "auf schmal sind im Hero die organic labels zu
   weit unten, mehr Platz zu bottom" - bezieht sich auf die schmale/
   quadratische "echter Desktop"-Zone (750-1199px Hochformat), NICHT auf
   breiten Desktop oder Desktop-Quer (dort kein Problem gemeldet). Die obige
   Regel setzt "bottom:3.5em" fuer alle drei Faelle gemeinsam - hier eine
   engere, NUR fuer den schmalen Hochformat-Bereich geltende, NACH ihr
   stehende (= gewinnende) Korrektur mit groesserem bottom-Wert (Siegel
   ruecken dadurch weiter nach oben, weg vom unteren Rand). Schaetzwert ohne
   Live-Zugriff, bitte gegenchecken. */
@media screen and (min-width: 750px) and (max-width: 1199px) and (orientation: portrait) {
  body .hero-text-group__siegel-wrapper {
    bottom: 6em !important;
  }
}

/* NEU (Round 28, 37. Batch): Merle-Feedback speziell fuer das SCHMALE
   Hochkant-Browserfenster (Hochformat, mit Maus bedient - "schmales
   Hochkant-Desktop", in mobile-fixes.js "isTabletPortraitLikePhone"),
   NICHT fuer echtes Handy-Hochformat (Touch, das soll unveraendert
   bleiben). Deshalb bewusst als eigener, ENGER gefasster Block NACH dem
   grossen gemeinsamen Hochformat-Block (Abschnitt 16) platziert, der bei
   gleicher Spezifitaet gewinnt.
   KORREKTUR (Round 28, 38. Batch): Merle testete live bei 725px Breite
   (per DevTools gemessen, Screenshot) und meldete "du hast gar nichts
   gefixt" - Root Cause: das urspruengliche "min-width:750px" traf ihr
   Testfenster nicht, es fiel dadurch in den "echtes Handy"-Bereich
   zurueck. Fix: "min-width:750px" entfernt, stattdessen "(hover:hover)
   and (pointer:fine)" (= Maus vorhanden) ergaenzt - dieselbe Umstellung
   wie bei der min-height-Regel weiter oben und bei "isMobile" in
   mobile-fixes.js, dort ausfuehrlicher begruendet. Der Logo-z-index-
   Override (zuvor hier, "-1") ist jetzt unnoetig geworden und entfernt -
   die Welle selbst wurde stattdessen in der gemeinsamen Z-Index-Regel
   weiter unten in der Datei direkt angehoben (gilt jetzt fuer BEIDE
   Faelle, echtes Handy und schmales Desktop, wie von Merle fuer Handy
   Hochformat zusaetzlich gewuenscht). Zusaetzlich NEU: Bio-Siegel sollen
   laut Merle hier auch "doppelt so gross" sein (zusaetzlich zu right:9%)
   - Hoehen-Clamp verdoppelt gegenueber dem gemeinsamen Basis-Wert
   (clamp(34.5px,7.77dvh,120px) aus Abschnitt 16b). Und ein kleiner
   margin-top-Zuschlag ergaenzt (Merle: "vielleicht brauchst du auch noch
   einen margin-top"), SCHAETZWERT.
   AUSDRUECKLICHER HINWEIS: konnte in dieser Runde NICHT live verifiziert
   werden - die Sandbox konnte trotz mehrerer Versuche (inkl. des sonst
   zuverlaessigen "Tab schliessen/neu anlegen"-Workarounds, mehrerer
   Seitenverhaeltnisse bis 780x1300) kein echtes Hochformat-Browserfenster
   erzeugen (bekannte Einschraenkung der Test-Umgebung, kein Hinweis auf
   einen Code-Fehler). Bitte diese Regeln auf deinem echten Browserfenster
   gegenchecken. */
/* KORREKTUR (Round 28, 88. Batch): dieselbe Erweiterung wie bei der ersten
   Fassung dieser Media Query weiter oben (siehe dortiger Kommentar) - gilt
   ab 750px jetzt fuer Maus UND Touch (Tablets), darunter weiterhin nur
   Maus.
   KORREKTUR (Round 29, 89. Batch): dieselbe Mindesthoehen-Ergaenzung (siehe
   dortiger Kommentar, Abschnitt 16 weiter oben) - unter 850px Hoehe faellt
   auch dieser Block auf das Echtes-Handy-Regelwerk zurueck.
   KORREKTUR (Round 29, 93. Batch): derselbe Fix wie beim ersten Vorkommen
   dieser Media Query (Abschnitt 16 weiter oben, dortiger Kommentar) - der
   750-1199px-Hochformat-Zweig entfaellt, da er sich nachweislich (live
   per DevTools bei 1101x1126 bestaetigt) mit der "echter Desktop"-Regel
   (Abschnitt 16b) ueberschnitt und dadurch Headline/Siegel verschwinden
   liess. Dieser Breitenbereich laeuft jetzt durchgaengig ueber Abschnitt
   16b (inkl. dessen eigener, kleinerer Siegel-Groesse/-Position fuer
   Hochformat/quadratische Fenster, siehe dortiger "ab ca. 1138px"-Block). */
@media screen and (max-width: 749px) and (orientation: portrait) and (hover: hover) and (pointer: fine) and (min-height: 850px) {
  /* KORREKTUR (Round 28, 41. Batch): Merle "in sehr schmalen Browserfenstern
     brauchen die organic labels rechts etwas mehr Rand: right 10%" - war 9%
     (Batch 39, eigener spezifischerer Wert statt der gemeinsamen 11.5% aus
     Abschnitt 16, die fuer echtes Handy-Hochformat unveraendert bleibt). */
  body .hero-text-group__siegel-wrapper {
    right: 10% !important;
  }
  /* NEU (Round 28, 38. Batch): Merle "die Bio-Siegel muessen hier doppelt
     so gross sein" - Hoehen-Clamp gegenueber dem gemeinsamen Basis-Wert
     (clamp(34.5px,7.77dvh,120px)) verdoppelt.
     KORREKTUR (Round 28, 39. Batch): Merle "Desktop narrow: ... organic
     labels needs to be 40% of their size" - der 38.-Batch-Wert (verdoppelt)
     war ihr zu gross. Fix: auf 40% des bisherigen (verdoppelten) Wertes
     reduziert: clamp(69px,15.54dvh,240px) * 0.4 = clamp(27.6px,6.216dvh,96px). */
  body .hero-text-group__siegel {
    height: clamp(27.6px, 6.216dvh, 96px) !important;
    width: auto !important;
  }
  /* Merle "Headline sitzt oben fest, hat einen grossen margin-bottom (8%,
     Screenshot) - den loswerden oder auf ca. 6% setzen, dann passt der
     Abstand Logo/Herotextgroup". Dieser margin-bottom steht NICHT in
     unserem CSS/JS (per grep bestaetigt) - es ist ein natives, von
     Shopifys Theme-Editor-"Position"-Feature direkt inline gesetztes
     margin-bottom:8%. Fix: per !important auf Merles genannten
     Kompromisswert (6%) ueberschrieben - vorsichtiger als "ganz
     entfernen", da margin-bottom in dieser zentrierten Flex-Spalte den
     verfuegbaren Platz nach oben/unten verschieben kann. */
  body .hero-text-group {
    /* KORREKTUR (Round 28, 41. Batch): war 6% (SCHAETZWERT aus Batch 38,
       ausdruecklich als in der Sandbox nicht live verifizierbar markiert -
       die Sandbox konnte damals trotz mehrerer Versuche kein echtes
       Hochformat-/Schmal-Browserfenster erzeugen, siehe Kommentar weiter
       oben vor dieser Media Query). Merle hat in ihrem eigenen Browser bei
       sehr schmalen Fensterbreiten selbst 17vh ermittelt und als gut
       befunden - direkt uebernommen statt einer neuen eigenen Schaetzung. */
    margin-bottom: 17vh !important;
    /* KORREKTUR (Round 28, 41. Batch): war 24px (ebenfalls unverifizierter
       Schaetzwert aus Batch 38). Merle: margin-top:0px passte bei ihr. */
    margin-top: 0px !important;
  }
}

/* NEU (Round 27): Hero-Welle (.planet-wave) umfaerben. Die Welle ist ein
   Inline-SVG mit der Fuellfarbe direkt als HTML-Attribut auf dem <path>
   gesetzt (fill="#f6c0df", = --wave-color) - kein mask-image/background wie
   beim Tagline-SVG. Per CSS auf dem <path> selbst ueberschrieben, das
   gewinnt gegenueber dem HTML-Attribut. */
body .planet-wave path {
  fill: #f8c2dd !important;
}

/* Wave + Planeten: im Hochformat nach oben rutschen, Planeten +35% Größe,
   Welle nur in der Höhe +35% strecken (scaleY, Breite/105vw unverändert).
   Werte für "nach oben rutschen" sind eine erste Schätzung (top/bottom um ca.
   10 Prozentpunkte verschoben) - bitte live nachjustieren. */
/* Ziel-Stapelreihenfolge von unten nach oben: PlanetC, Welle, PlanetB,
   PlanetA, Siegel, Logo, Headline-Gruppe (z-index 1-6). Da der Original-
   Zentrierungswert der Planeten unbekannt ist (section-eigenes Stylesheet),
   wird relativ zur eigenen Breite ueber translateX verschoben - funktioniert
   unabhaengig vom Grundwert, sofern die Original-Regel das uebliche
   "left:50%; transform:translate(-50%,-50%)"-Muster nutzt. */
@media screen and (max-width: 749px) and (orientation: portrait) {
  /* AB 26.9.: nochmal 120% vom JETZIGEN Stand (1.215 * 1.2 = 1.458) + etwas
     nach oben (top von 45% auf 41%) - Merles Wunsch.
     KORREKTUR (7.10., Teil 13): Merle hat selbst live im Theme Editor weiter
     nachjustiert und per Screenshot die finalen Werte geschickt - 1:1
     uebernommen (war top:41%/scaleY(1.458)). */
  body .planet-wave,
  body .image-block--AOUx3c1hVZFdZQWRGc__image_khPEg8 {
    top: 43% !important;
    transform: translate(-50%, -50%) scaleY(1.8) !important;
    /* KORREKTUR (Round 28, 27. Batch): Merle neue Ziel-Stapelreihenfolge
       "von oben nach unten: Herotext+Logo+Biosiegel, dann Welle, dann
       Planeten" - bisher lag die Welle (z-index 2) HINTER PlanetA
       (z-index 3), genau umgekehrt zum Wunsch. Fix: Welle ueber alle drei
       Planeten gehoben (hoechster Planet-Wert ist PlanetA mit 3), bleibt
       aber weiterhin unter Logo (5)/Herotext-Gruppe (6). */
    z-index: 4 !important; /* war 2 */
  }
  body .image-block--AVit0ZnV1WW5hb1Jna__image_arzrNG { /* PlanetC */
    top: -12% !important;
    width: 53% !important; /* AB 7.10.: war 49.1%, Merle "nur etwas groesser" - 8% groesser gerechnet (49.1% * 1.08) */
    z-index: 1 !important;
    /* AB 7.10. (Teil 12): Merle konnte diese Regel im Theme Editor nicht mehr
       finden/bearbeiten, Wunsch kam daher direkt im Chat: "leicht nach links"
       + "geringere opacity". Fuer "nach links" bewusst margin-left statt
       left/right verwendet, weil wir den nativen Grundwert (section-eigenes
       Stylesheet) nicht kennen - margin wirkt bei einem absolut positionierten
       Element trotzdem zusaetzlich zur bestehenden top/Zentrierung, ganz
       unabhaengig davon, ob die Section intern mit left, right oder
       transform zentriert. Beide Werte Schaetzungen, bitte live
       gegenchecken. */
    margin-left: -4% !important;
    /* KORREKTUR (7.10., Teil 13): Merle "opacity bei den Planeten nur auf 0.9
       runtersetzen" - war zu stark reduziert auf 0.8, jetzt dezenter. */
    opacity: 0.9 !important;
  }
  /* Schlagschatten-Korrektur: kein filter:drop-shadow, sondern ein echtes
     ::before mit eigenem transform. Position unveraendert, nur proportional
     mitgewachsen (gleicher Faktor 1.08 wie der Planet selbst), damit der
     Schatten weiterhin zur Groesse passt.
     AB 7.10. (Teil 12): Merles Wunsch "sein before bitte kleiner" - Scale von
     0.96 auf 0.75 reduziert (Schaetzwert, bitte live gegenchecken, ob das
     reicht oder noch kleiner werden soll). */
  body .image-block--AVit0ZnV1WW5hb1Jna__image_arzrNG::before {
    transform: scale(0.75) translate(-8.6px, 8.6px) !important;
  }
  /* Planet A/B bewegen sich seit dem seitlichen transform-Versatz gar nicht
     mehr. Ursache: die Planeten haben eigene Float-Animationen (floatA/B/C)
     ueber transform - unser statisches transform mit !important friert diese
     Animation ein (ein Keyframe kann eine hoeher priorisierte, nicht-
     animierte !important-Regel nicht ueberstimmen). Seitlicher Versatz
     deshalb entfernt, Planeten landen auf ihrer urspruenglichen Position. Ein
     gewuenschter Versatz muesste ueber "left"/"right" statt "transform"
     laufen. */
  /* KORREKTUR (7.10., Teil 13): Merle hat PlanetB live im Theme Editor
     selbst noch deutlich weiter nach unten/links verschoben und per
     Screenshot die finalen Werte geschickt ("viel viel weiter unten") - 1:1
     uebernommen (war bottom:14%/left:-15%). */
  body .image-block--ANXBET1RNT21iUXpQS__image_c9fKJQ { /* PlanetB */
    /* KORREKTUR (Round 28, 82. Batch): Merle "planet c ein wenig herunter
       auf handy hoch" - bottom etwas negativer (war -4%), Schaetzwert,
       bitte live gegenchecken. */
    bottom: -7% !important;
    width: 58.3% !important; /* AB 7.10.: war 54%, Merle "etwas groesser" - 8% groesser gerechnet (54% * 1.08) */
    z-index: 0 !important; /* AB 2.10.: war 3, Merles finaler Wert */
    left: -20% !important;
    /* KORREKTUR (7.10., Teil 13): "opacity bei den Planeten nur auf 0.9
       runtersetzen" - war zu stark reduziert auf 0.8. */
    opacity: 0.9 !important;
  }
  /* AB 2.10., NEU: PlanetB hatte bisher keinen eigenen Schatten-Versatz -
     Merles finaler Wert dafuer ergaenzt (analog zum Muster bei PlanetA/C).
     AB 7.10.: proportional mitgewachsen (Faktor 1.08, wie der Planet selbst).
     KORREKTUR (7.10., Teil 13): Merles live im Theme Editor gefundener
     finaler Wert per Screenshot uebernommen (war scale(1.08)
     translate(-13px, 0px)). */
  body .image-block--ANXBET1RNT21iUXpQS__image_c9fKJQ::before {
    transform: scale(1.1) translate(-23px, 3px) !important;
  }
  /* KORREKTUR (7.10., Teil 13): Merle hat PlanetA live im Theme Editor noch
     weiter nach rechts/groesser verschoben und per Screenshot die finalen
     Werte geschickt - 1:1 uebernommen (war top:40%/width:75.8%/
     right:-34.6%). */
  body .image-block--AMmV1bHd1ajlxYU11Y__image_EHj6Xp { /* PlanetA */
    top: 38% !important;
    width: 79.8% !important;
    z-index: 3 !important;
    right: -46.6% !important;
  }
  /* AB 2.10. (Merles finaler Wert), AB 7.10. proportional mitgewachsen
     (Faktor 1.08, "samt before shadow etwas groesser 8%").
     KORREKTUR (7.10., Teil 13): Merles live im Theme Editor gefundener
     finaler Wert per Screenshot uebernommen (war scale(1.22)
     translate(-9.7px, 11.9px)). */
  body .image-block--AMmV1bHd1ajlxYU11Y__image_EHj6Xp::before {
    transform: scale(1.12) translate(-13.7px, 26.9px) !important;
  }
}

/* NEU (Round 28, 63. Batch): Merle "Planet c im hero desktop breit bitte
   nochmal verschieben" - gemeint ist .image-block--ANXBET1RNT21iUXpQS__image_c9fKJQ,
   in unseren eigenen Kommentaren weiter oben "PlanetB" genannt (Merles "Planet c"
   und unser "PlanetB" sind derselbe Selektor - reine Namensabweichung, keine
   Verwechslung mit einem anderen Element). Die existierende Regel fuer diesen
   Selektor (oben, Zeile ~6342) gilt NUR fuer schmales Hochformat-Handy
   (max-width:749px and orientation:portrait) - fuer "Desktop breit" gab es
   bisher noch gar keine eigene Regel. Neue, separat scoped Regel ergaenzt,
   exakte Media-Query-Bedingung wie bei den uebrigen "Desktop/breite Fenster"-
   Hero-Regeln (Abschnitt 16b) uebernommen, damit es konsistent mit
   derselben Bildschirmklasse greift, in der Merle das gerade angeschaut hat. */
@media screen and (min-width: 1200px), screen and (min-width: 750px) and (orientation: landscape) and (min-height: 501px) {
  body .image-block--ANXBET1RNT21iUXpQS__image_c9fKJQ { /* PlanetB / Merles "Planet c" */
    left: -5% !important;
    bottom: 0 !important;
    width: 36% !important;
  }
}

/* NEU (neue Anfrage, 1. Teil): Merle "auf schmalen Browserfenstern bleiben
   Welle und Planeten winzig, anders als auf Mobil Hochformat - bitte
   vergleichen und groesser machen, die Welle besonders hoeher statt breiter
   strecken" (sie hat die Herotextgroup testweise selbst ausgeblendet, um das
   zu zeigen). Root Cause: fuer die schmale/quadratische "echter Desktop"-Zone
   (750-1199px, Hochformat) gab es bisher GAR KEINE eigene Groessen-Regel fuer
   Welle/PlanetA/PlanetC (nur PlanetB/"Planet c" hat oben eine Regel, aber nur
   fuer Breit/Landscape, nicht fuer diese Zone) - alle vier fallen hier auf
   die native, fuer einen vollbreiten Desktop-Hero gedachte Theme-Groesse
   zurueck, die bei dieser schmaleren/hoeheren Proportion winzig wirkt.
   Fix (1. Versuch): eigene Regel fuer genau diese Zone, direkt an Merles
   eigenen, bereits bewaehrten Hochformat-Handy-Werten orientiert (nur
   Groesse, keine Position).

   KORREKTUR (2. Teil, neue Anfrage): Merle hat live gegengeprueft und meldet
   zurueck: "die Planeten doch wieder 15% kleiner machen jeweils und ihre
   Position eher wie auf dem Handy setzen" - UND zusaetzlich drei konkrete
   Richtungskorrekturen ueber die reinen Handy-Werte hinaus: "planet c weiter
   viel nach links und oben" (= ihr "Planet c" = unser PlanetB/image_c9fKJQ,
   siehe Namens-Klarstellung Batch 63), "planet a weiter nach rechts" (=
   PlanetA/image_EHj6Xp) und "planet b weiter nach links unten" (= ihr
   "Planet b" = unser PlanetC/image_arzrNG - NICHT zu verwechseln mit
   PlanetB!). Fix: jetzt zusaetzlich zur Groesse (-15% von den obigen,
   bereits von Mobil uebernommenen Breiten) auch die volle Positionierung
   (top/bottom/left/right/margin-left/opacity) 1:1 von der Mobil-Hochformat-
   Regel (Abschnitt weiter oben, Zeile ~6819ff.) uebernommen, als Basiswert
   fuer die genannten weiteren Richtungs-Verschiebungen.
   AUSDRUECKLICHER HINWEIS: ich kann diese schmale Desktop-Breite (750-1199px,
   Hochformat) in meiner eigenen Sandbox nicht nachstellen (dokumentierte
   Einschraenkung) - sowohl die Groessen- als auch insbesondere die NEUEN
   Richtungs-Versatz-Werte (wieviele Prozentpunkte "weiter rechts"/"viel
   weiter links" tatsaechlich bedeuten) sind Schaetzwerte, bitte unbedingt live
   gegenchecken. Fuer die Welle ("ein Stueck hoch"): da der native top-Wert
   dieser Zone unbekannt ist (kein eigenes top in dieser Regel, nur
   transform/scaleY), per zusaetzlichem margin-top (wirkt unabhaengig vom
   unbekannten Grundwert) nach oben verschoben statt eines geratenen
   top-Werts. */
@media screen and (min-width: 750px) and (max-width: 1199px) and (orientation: portrait) {
  body .planet-wave,
  body .image-block--AOUx3c1hVZFdZQWRGc__image_khPEg8 {
    transform: translate(-50%, -50%) scaleY(1.8) !important;
    margin-top: -3vh !important; /* NEU: "Welle ein Stueck hoch", Schaetzwert */
  }
  body .image-block--AMmV1bHd1ajlxYU11Y__image_EHj6Xp { /* PlanetA, Merles "Planet a" */
    width: 67.83% !important; /* 79.8% * 0.85 (15% kleiner) */
    top: 38% !important; /* von Mobil-Hochformat uebernommen */
    right: -56.6% !important; /* war Mobil-Wert -46.6% - "weiter nach rechts" (negativer = weiter rechts), Schaetzwert */
  }
  body .image-block--AVit0ZnV1WW5hb1Jna__image_arzrNG { /* PlanetC, Merles "Planet b" */
    width: 45.05% !important; /* 53% * 0.85 */
    top: -2% !important; /* war Mobil-Wert -12% - "weiter nach unten" (weniger negativ = weiter unten), Schaetzwert */
    margin-left: -14% !important; /* war Mobil-Wert -4% - "weiter nach links" (negativer = weiter links), Schaetzwert */
    opacity: 0.9 !important; /* von Mobil uebernommen */
  }
  body .image-block--ANXBET1RNT21iUXpQS__image_c9fKJQ { /* PlanetB, Merles "Planet c" */
    width: 49.555% !important; /* 58.3% * 0.85 */
    bottom: 8% !important; /* war Mobil-Wert -7% - "viel weiter nach oben" (weniger negativ/positiv = weiter oben), Schaetzwert, groesserer Schritt wegen "viel" */
    left: -35% !important; /* war Mobil-Wert -20% - "viel weiter nach links" (negativer = weiter links), Schaetzwert, groesserer Schritt wegen "viel" */
    opacity: 0.9 !important; /* von Mobil uebernommen */
  }
}

/* ---------------------------------------------------------------- 56. EASY
   BUNDLES "CONSOLIDATED DESIGN": RUNDUNG AUF 40PX ENTFERNT (AB 2.10., zweite
   Runde): die Regel body[gbb-consolidated-design="true"]{border-radius:40px}
   rundete auf der EB-Seite das komplette main-div ab - auf Wunsch komplett
   entfernt, kein Ersatz noetig.
   ---------------------------------------------------------------- */

/* Hero-Hintergrund lueckenlos bis oben: der gruene Streifen ganz oben blieb
   auch mit background:transparent sichtbar (zeigt den gruenen Body-
   Hintergrund durch). Zwischenzeitlich wurde der Header im Top-Zustand
   stattdessen pink eingefaerbt. ZURUECKGENOMMEN: dadurch war der Header
   dauerhaft rosa statt transparent. Der urspruengliche Grund (gruener
   Streifen beim ersten Scroll-Frame) ist inzwischen durch einen gezielteren
   Fix behoben (Header steht jetzt fest per position:fixed;top:0). Pink-
   Workaround daher entfernt - live bestaetigt war diese Regel
   (rgb(235,153,191) auf dem aeusseren .header-Element) exakt die Ursache. */


/* "Gruener Balken blitzt beim Scrollen oben auf". Ursache: der Header traegt
   gleichzeitig transparent="not-sticky" und sticky="always"; das native
   Theme-Stylesheet setzt dafuer .header[transparent] { position: absolute;
   top:0; ... } - bleibt auch im Zustand data-sticky-state="active" bestehen.
   Der Header ist dadurch nie wirklich fixiert, sondern scrollt normal mit,
   wodurch oberhalb ein Streifen des gruenen Body-Hintergrunds sichtbar wird.
   Fix: sobald data-sticky-state="active", per position:fixed an die Viewport-
   Oberkante zwingen. Live getestet: kein gruener Blitzer mehr. KORRIGIERT
   ("es flackert sobald man scrollt", site-weit gemeldet). Die Regel griff nur
   im Zustand "active" - im Zustand "inactive" (den Horizon beim Scrollen nach
   unten selbst setzt) faellt der Header auf natives position:static zurueck.
   Da ein position-Wert nicht animiert werden kann, ist jeder Wechsel ein
   harter Sprung - und Horizons Scroll-Richtungs- Erkennung kann den Zustand
   bei natuerlichem Touch-Scrollen mehrfach pro Scroll-Vorgang umschalten,
   wodurch der Header wiederholt zwischen fixiert und aus dem Fluss gefallen
   sprang - das erlebt sich als Flackern. Fix: Header bleibt in beiden
   Zustaenden durchgehend position:fixed, der Modus wechselt nie mehr. Das
   Ein-/Ausblenden passiert stattdessen ueber eine animierbare
   transform:translateY()-Verschiebung mit eigener transition. Live
   verifiziert: position bleibt immer "fixed", nur transform aendert sich
   sanft (0 ↔ -100%). */
/* Vierter Teil desselben Flacker-Bugs, nur auf Mobil reproduzierbar (vorher
   im Desktop-Format getestet, wo diese @media-Regel gar nicht greift). Im
   Handy-Breakpoint (390px) flackert data-sticky-state kontinuierlich, mehrere
   hundert Mal pro Sekunde, auch im Ruhezustand (vermutlich eine
   ResizeObserver-Rueckkopplungsschleife in Horizons Sticky-Code, nicht durch
   uns patchbar). Die zuvor gesetzte `transition: transform 0.2s` wurde
   dadurch staendig neu gestartet und abgebrochen, bevor sie ihr Ziel
   erreichte - transform blieb bei winzigen Zwischenwerten haengen und
   zitterte ununterbrochen, sichtbar als Wackeln des gesamten Headers. Fix:
   Transition komplett entfernt, beide Zustaende bekommen denselben, fest
   fixierten Wert (translateY(0), immer sichtbar oben). Das Auto-Ausblenden
   beim Scrollen faellt damit bewusst weg - Preis dafuer, dass der
   zugrundeliegende Horizon-Bug nicht kontrollierbar ist. Ausblenden liesse
   sich spaeter separat ueber data-scroll-direction loesen (stabiler). */
/* KOMPLETT ZURUECKGENOMMEN: neuer, schlimmerer Bug direkt nach der letzten
   Aenderung - Header flackert wieder, seitliches Rausscrollen moeglich,
   Padding springt. Per Inspector gefunden: eine zweite, uebersehene native
   Regel zielt nicht auf #header-component, sondern auf die umschliessende
   Section: .header-section:has(#header-component[sticky="always"]), ... {
   position: sticky; top: -1px; z-index: var(--layer-menu-drawer); } Der
   vollstaendige native Mechanismus: die aeussere .header-section bekommt
   immer position:sticky (nativer Browser-Sticky, ohne JS); der innere Header
   bekommt immer position:absolute;top:0 und "reitet" dadurch an der Oberkante
   seiner Sektion mit. Erst das Zusammenspiel ergibt den "bleibt oben
   kleben"-Effekt, ganz ohne position:fixed. data-sticky-state steuert dabei
   nur noch Opacity, nicht die Positionierung. Unsere eigene position:fixed-
   Regel arbeitete die ganze Zeit gegen dieses Zusammenspiel: ein fixed
   positioniertes Kind ignoriert seine sticky Sektion komplett, wodurch beide
   nicht mehr zusammenpassten - erklaert die springenden Padding-Werte und das
   seitliche Rausscrollen. Fix: die komplette position:fixed-Regel ersatzlos
   entfernt. Positionierung liegt jetzt vollstaendig beim nativen
   Zusammenspiel - robuster, performanter, und loest nebenbei vermutlich auch
   das "wird nie dunkelgruen"-Problem. Bitte kein position:fixed mehr zur
   Gegensteuerung einsetzen. */

/* Neuer, anderer Flacker-Bug: "es flackert ein pinker/cremefarbener Balken
   unter dem Header" (per Screen-Recording und Chrome DevTools bestaetigt) -
   nicht derselbe Bug wie oben (bereits geloest). Per Event-Tracing gefunden:
   Horizon zeichnet den zweifarbigen Header-Hintergrund nicht ueber eine feste
   Farbe auf der Row selbst (.header__row--top ist transparent), sondern ueber
   ein verstecktes Element .header__underlay dahinter, dessen "height" per
   CSS-Transition von 0 auf die volle Header-Hoehe hochfaehrt. Bei schnellem
   Scrollen bricht diese Transition immer wieder mitten in der Animation ab
   und startet neu - die Hoehe bleibt zwischendurch bei winzigen Werten wie
   0-15px stehen, wodurch der Header fuer diese Millisekunden nur teilweise
   gruen ist und der hellere Seiteninhalt durchscheint. Das ist der gemeldete
   Flacker; der Mechanismus ist Theme-eigener Code, nicht direkt patchbar.
   Fix: .header__row--top bekommt zusaetzlich eine eigene, feste, deckende
   Hintergrundfarbe (dieselbe Gruen-Variable wie das Underlay) - die Top-Row
   ist dadurch immer vollstaendig gruen ausgefuellt, unabhaengig vom Underlay.
   NACHTRAG: "flackert immer noch genauso" - per Safari-Inspector zweiter
   Puzzle-Teil gefunden: eine native Regel (styles.css:165) schaltet ueber
   :not([data-sticky-state="active"]) die Farbvariablen --color-foreground
   zwischen der korrekten Cremefarbe und --color-transparent-text (hier
   zufaellig dunkelgruen = quasi unsichtbar) um - dasselbe instabile Attribut,
   das schon beim ersten Flacker-Fix als mehrfach pro Sekunde springend
   identifiziert wurde. Der damalige Fix verhinderte nur, dass dieses Springen
   den Header selbst verschiebt, nicht dass die Textfarbe mitflackert. Fix:
   --color-foreground/-rgb zusaetzlich fest auf die korrekte Cremefarbe
   gepinnt, unabhaengig davon, wie oft das Attribut weiter umschaltet. Live
   verifiziert: Farbe blieb ueber mehrere Sekunden aktives Scrollen konstant.
   NACHTRAG (Punkt 1 von Merles Liste): der Header soll vor dem ersten
   Scrollen wieder nativ transparent sein. Die obige Regel war bisher unscoped
   und machte ihn dadurch auch im Zustand "inactive" (ganz oben) staendig
   gruen. Fix: zusaetzlicher [data-sticky-state="active"]-Filter - oben bleibt
   der Header transparent, der Flacker-Fix greift weiterhin sobald gescrollt
   wird. NACHTRAG: jetzt, wo der Header nativ sticky oben klebt, "springt sehr
   auf beim scrollen" - kein Positions-Sprung mehr, sondern ein harter
   Farbwechsel im selben Frame (transparent -> Dunkelgruen). Fix: eine kurze,
   weiche Transition auf der Hintergrundfarbe, unscoped gesetzt, damit sie in
   beide Richtungen greift. */
#shopify-section-sections--31616257753418__header_section .header__row--top {
  transition: background-color 0.28s ease-out !important;
}
#shopify-section-sections--31616257753418__header_section .header[data-sticky-state="active"] .header__row--top {
  background-color: var(--color-background-top-row, #092f01) !important;
  --color-foreground: var(--color-background-bottom-row, #e3f3c6) !important;
  --color-foreground-rgb: 227 243 198 !important;
}

/* AB 2.10. (dritte Runde): Header soll NUR auf der Easy-Bundles-Seite nach
   dem ersten Scrollen (data-sticky-state="active") auf ca. halbe Hoehe
   schrumpfen. Seiten-Scope ueber body[gbb-consolidated-design="true"] (bereits
   als zuverlaessiger EB-Seiten-Marker aus Abschnitt 56 bekannt), damit Header
   auf allen anderen Seiten unangetastet bleibt. Bewusst NICHT per
   transform:scale() oder position:fixed geloest (siehe ausfuehrliche
   Kommentare oben zum Flacker-Bug: "Bitte kein position:fixed mehr zur
   Gegensteuerung einsetzen" - transform:scale auf das sticky/absolute
   positionierte Element wuerde dasselbe fragile Zusammenspiel stoeren).
   Stattdessen wird derselbe, bereits bewaehrte Mechanismus wie beim
   "Header-Topbar kompakter"-Fix (Padding/Icon-Groessen reduzieren statt
   Position/Transform anfassen) hier nochmal staerker angewendet, nur in
   diesem Zustand auf dieser Seite. Ohne Breakpoint, da diesmal nicht als
   "nur mobil" genannt - gilt also auch auf Desktop. **Bitte live
   gegenchecken, ob das zusammen mit der echten Logo-Groesse tatsaechlich
   wie "halb so hoch" wirkt.**
   KORREKTUR (7.10.): Merle meldet, nur der INHALT (Logo/Icons) werde
   kleiner, die Zeile (".header__row--top") selbst behalte aber ihre volle
   Hoehe - der jetzt kleinere Inhalt schwimmt dadurch nur mit mehr Leerraum
   oben/unten in derselben grossen Box, die Navbar nimmt also weiterhin denselben
   Platz ein. Ursache: Horizon setzt auf diesem Flex-Element vermutlich eine
   eigene min-height (ueber eine Theme-Variable), die unabhaengig von unserem
   reduzierten padding-block bestehen bleibt - reines Padding reicht hier
   nicht aus. Fix: min-height zusaetzlich explizit auf 0 setzen und die Zeile
   per height:auto rein vom (jetzt kleineren) Inhalt + padding bestimmen
   lassen. */
/* KORREKTUR (7.10., Teil 5): Live auf der EB-Seite (/products/box) direkt
   nachgeprueft (Scroll-Position 0 bis 1200px, mehrfach) - das Attribut
   "data-sticky-state" existiert auf DIESER Seite nie, in keinem
   Scroll-Zustand (vermutlich weil dieser Header ueber "sticky: always"
   konfiguriert ist statt "beim Hochscrollen" - Horizon scheint den
   Sticky-Zustand nur im zweiten Fall ueberhaupt zu tracken). Deshalb griff
   die gesamte folgende Regelgruppe auf der EB-Seite BISHER NIE - das war
   die tatsaechliche Ursache fuer "da hat sich gar nichts getan". Fix: ein
   eigener, einfacher Scroll-Listener in mobile-fixes.js (nur auf der
   EB-Seite aktiv, siehe dortiger Abschnitt "EB-Header-Schrumpfen per
   Scroll-Klasse") setzt stattdessen die eigene Klasse ".pv-eb-header-scrolled"
   auf #header-component. Die alte [data-sticky-state="active"]-Bedingung
   bleibt zusaetzlich (per Komma) bestehen, falls Horizon das Attribut
   hier doch irgendwann selbst setzt - schadet nicht, greift nur zusaetzlich. */
/* KORREKTUR (Round 20): Merle will die ganze Schrumpf-Funktion NUR auf
   kleinen Bildschirmen (nicht auf Desktop, nicht auf iPad) - der Kommentar
   weiter oben ("Ohne Breakpoint... gilt also auch auf Desktop") war eine
   bewusste frühere Entscheidung, die hier ausdrücklich zurückgenommen wird.
   Die komplette Regelgruppe bis zum Ende dieses Abschnitts (inkl.
   Transitions) wird dafuer in eine max-width:749px-Media-Query gepackt - der
   Scroll-Listener selbst (mobile-fixes.js) bleibt unveraendert und
   togglet die Klasse weiterhin auch auf breiten Bildschirmen, das macht
   aber nichts mehr sichtbar, weil hier keine Regel mehr ausserhalb von
   749px darauf reagiert. */
@media screen and (max-width: 749px) {
body[gbb-consolidated-design="true"] #shopify-section-sections--31616257753418__header_section .header[data-sticky-state="active"] .header__row--top,
body[gbb-consolidated-design="true"] #shopify-section-sections--31616257753418__header_section .header.pv-eb-header-scrolled .header__row--top {
  padding-block: 2px !important;
  min-height: 0 !important;
  height: auto !important;
}
body[gbb-consolidated-design="true"] #shopify-section-sections--31616257753418__header_section .header[data-sticky-state="active"] .header__columns,
body[gbb-consolidated-design="true"] #shopify-section-sections--31616257753418__header_section .header[data-sticky-state="active"] #header-component[data-menu-style='drawer'] .header__columns,
body[gbb-consolidated-design="true"] #shopify-section-sections--31616257753418__header_section .header.pv-eb-header-scrolled .header__columns,
body[gbb-consolidated-design="true"] #shopify-section-sections--31616257753418__header_section .header.pv-eb-header-scrolled#header-component[data-menu-style='drawer'] .header__columns {
  --header-mobile-bookend: 18px !important;
}
/* KORREKTUR (7.10., Teil 11): Merle hat selbst per Theme-Editor-Inspector
   herausgefunden, dass ".header__drawer" (natives Horizon-Element, nicht
   aus base.css) eine eigene min-height ueber die Custom-Property
   "--header-drawer-min-height" (60px) traegt, die unabhaengig von der
   obigen Regelgruppe bestehen blieb und den Header daran gehindert hat,
   wirklich zu schrumpfen (padding-block:2px + min-height:0 auf
   .header__row--top liefen ins Leere, weil .header__drawer als Kind-
   Element seine eigene Mindesthoehe behielt und dadurch die Zeile wieder
   aufgebläht hat). Live bestaetigt: deaktiviert man diese Regel, schrumpft
   der Header tatsaechlich. Fix: hier direkt mit min-height:0 !important
   uebersteuert statt die Custom Property umzudefinieren (robuster gegen
   Spezifitaets-Kniffe). */
body[gbb-consolidated-design="true"] #shopify-section-sections--31616257753418__header_section .header[data-sticky-state="active"] .header__drawer,
body[gbb-consolidated-design="true"] #shopify-section-sections--31616257753418__header_section .header.pv-eb-header-scrolled .header__drawer {
  min-height: 0 !important;
}
/* KORREKTUR (7.10., Teil 11): die bisherige Regelgruppe hier (13px/10px
   Icon-Groessen) war ein "Best effort", solange .header__drawer den Header
   ohnehin nicht wirklich schrumpfen liess (siehe Fix oben) - jetzt, wo die
   Zeile tatsaechlich kompakter wird, wirkten 13px/10px viel zu winzig und
   zusammengequetscht (Merles Screenshot: Warenkorb-Icon nur 13x13px). Neue,
   einheitliche Zielgroesse fuer BEIDE Icons (Warenkorb + Konto): 26px -
   das ist zufaellig fast exakt die natuerliche, ungeschrumpfte Groesse des
   Warenkorb-Icons (26x26px) - dafuer muss dieses also gar nicht mehr
   verkleinert werden, nur das (bisher riesige, 44x44px) Konto-Icon auf
   dasselbe Mass gebracht werden, damit beide nebeneinander gleich wirken. */
body[gbb-consolidated-design="true"] #shopify-section-sections--31616257753418__header_section .header[data-sticky-state="active"] .header__row--top .svg-wrapper,
body[gbb-consolidated-design="true"] #shopify-section-sections--31616257753418__header_section .header.pv-eb-header-scrolled .header__row--top .svg-wrapper {
  height: 26px !important;
  width: 26px !important;
}
/* AB 7.10.: das Konto-Icon (<shopify-account>) wurde bisher NICHT kleiner -
   sein SVG steckt nicht in einem ".svg-wrapper" wie die anderen Icons,
   sondern in einem einfachen <span> (eigene Web-Component-Struktur), daher
   hat die Regel oben es nie erfasst. KORREKTUR (Teil 11): der eigentliche
   Knopf (nicht nur das SVG darin) sitzt sogar in einer geschlossenen
   Shadow-DOM-Struktur (<shopify-account>) - normales CSS von aussen
   erreicht dessen Innenleben gar nicht. Shopify exponiert dafuer aber einen
   CSS-"part"-Namen ("signed-out-avatar" fuer Gaeste, vermutlich
   "signed-in-avatar" fuer angemeldete Kund:innen - live nur im
   Gast-Zustand nachgeprueft) - darueber lässt sich der Knopf direkt von
   aussen per ::part() ansprechen, OHNE dass Horizon dafuer extra Hooks
   bauen musste. Auf dieselbe 26px-Zielgroesse wie das Warenkorb-Icon
   gebracht, damit beide nebeneinander gleich gross wirken. */
body[gbb-consolidated-design="true"] #shopify-section-sections--31616257753418__header_section .header[data-sticky-state="active"] .header__row--top shopify-account::part(signed-out-avatar),
body[gbb-consolidated-design="true"] #shopify-section-sections--31616257753418__header_section .header.pv-eb-header-scrolled .header__row--top shopify-account::part(signed-out-avatar),
body[gbb-consolidated-design="true"] #shopify-section-sections--31616257753418__header_section .header[data-sticky-state="active"] .header__row--top shopify-account::part(signed-in-avatar),
body[gbb-consolidated-design="true"] #shopify-section-sections--31616257753418__header_section .header.pv-eb-header-scrolled .header__row--top shopify-account::part(signed-in-avatar) {
  /* WICHTIG: der Knopf traegt INNERHALB der Shadow-DOM-Struktur zusaetzlich
     ein eigenes min-width/min-height (live gemessen: 43.96px) - das sticht
     ein von aussen gesetztes width/height allein aus (min-height gewinnt
     immer gegen ein kleineres height). Deshalb hier zwingend auch
     min-width/min-height mit ueberschreiben, sonst bleibt der Knopf trotz
     width/height:26px optisch bei ca. 44px haengen (live so nachgewiesen). */
  width: 26px !important;
  height: 26px !important;
  min-width: 26px !important;
  min-height: 26px !important;
}
body[gbb-consolidated-design="true"] #shopify-section-sections--31616257753418__header_section .header[data-sticky-state="active"] .header__row--top .account-button svg,
body[gbb-consolidated-design="true"] #shopify-section-sections--31616257753418__header_section .header.pv-eb-header-scrolled .header__row--top .account-button svg {
  width: 16px !important;
  height: 16px !important;
}
/* KORREKTUR (7.10., Teil 11): selbst nachdem .header__drawer selbst auf
   min-height:0 gesetzt ist, blieb der Hamburger-Knopf bei 58x58px stehen.
   Ursache: nicht .header__drawer begrenzt die Groesse, sondern dessen Enkel
   ".header__icon--summary" (das eigentliche <summary>-Element des nativen
   Menu-Drawers) traegt ein festes padding:16px um das 26px-Icon herum - macht
   16+26+16=58px. Fix: Padding in diesem Zustand deutlich reduziert, damit
   der Hamburger-Knopf aehnlich kompakt wie Warenkorb/Konto-Icon wird. */
body[gbb-consolidated-design="true"] #shopify-section-sections--31616257753418__header_section .header[data-sticky-state="active"] .header__icon--summary,
body[gbb-consolidated-design="true"] #shopify-section-sections--31616257753418__header_section .header.pv-eb-header-scrolled .header__icon--summary {
  padding: 5px !important;
}
/* KORREKTUR (7.10., Teil 11): "transform:scale(0.5)" auf dem Logo war der
   Grund fuer Merles "Logo sitzt irgendwie links, fuellt den Container nicht
   aus" - eine CSS-transform veraendert nur die VISUELLE Darstellung, nicht
   die Layout-Box (der Container blieb in Originalgroesse stehen, das Bild
   schrumpfte optisch nach links oben weg, transform-origin:left center).
   Fix: direkt eine echte Zielgroesse setzen (keine Transform) - das Bild
   nimmt dadurch tatsaechlich weniger Platz ein UND bleibt (weil
   .header__columns bereits align-items:center hat) innerhalb seiner Spalte
   vertikal zentriert. */
body[gbb-consolidated-design="true"] #shopify-section-sections--31616257753418__header_section .header[data-sticky-state="active"] .header-logo__image,
body[gbb-consolidated-design="true"] #shopify-section-sections--31616257753418__header_section .header.pv-eb-header-scrolled .header-logo__image {
  transform: none !important;
  height: 22px !important;
  width: auto !important;
}

/* KORREKTUR (7.10., Teil 12): Merle "kannst du den header in der eb box
   animieren dass er nicht einfach kleiner springt?" - alle obigen
   Groessen-Regeln greifen nur im jeweiligen Zustand ([data-sticky-state=
   "active"]/.pv-eb-header-scrolled), daher bisher ein harter Sprung ohne
   jede Übergangs-Animation. Fix: hier UNABHAENGIG vom Zustand (wirkt also
   in beide Richtungen - Schrumpfen beim Scrollen UND Zurueckwachsen) eine
   kurze Transition auf genau die Eigenschaften, die sich zwischen den
   beiden Zustaenden aendern. Bewusst NUR auf Innenmasse einzelner Kind-
   Elemente angewendet, NICHT auf die Positionierung von .header__row--top
   selbst (siehe die ausfuehrlichen Kommentare weiter oben zum Flacker-Bug:
   "Bitte kein position:fixed mehr zur Gegensteuerung einsetzen") - das
   sollte mit dem nativen Sticky-Mechanismus nicht kollidieren.
   WICHTIG (Transition-Shorthand-Falle, aus frueherer Erfahrung in dieser
   Datei bekannt): ".header__row--top" und ".header-logo__image" hatten
   BEREITS eine eigene Transition (background-color bzw. transform) - ein
   neues "transition:" wuerde diese sonst komplett ersetzen statt ergaenzen.
   Deshalb hier fuer diese beiden Elemente die bestehende Transition mit in
   die neue Deklaration uebernommen, statt sie zu verlieren. */
body[gbb-consolidated-design="true"] #shopify-section-sections--31616257753418__header_section .header__row--top {
  transition: background-color 0.28s ease-out, min-height 0.3s ease, height 0.3s ease, padding 0.3s ease !important;
}
body[gbb-consolidated-design="true"] #shopify-section-sections--31616257753418__header_section .header-logo__image {
  transition: transform 220ms ease, height 0.3s ease, width 0.3s ease !important;
}
body[gbb-consolidated-design="true"] #shopify-section-sections--31616257753418__header_section .header__drawer,
body[gbb-consolidated-design="true"] #shopify-section-sections--31616257753418__header_section .header__row--top .svg-wrapper,
body[gbb-consolidated-design="true"] #shopify-section-sections--31616257753418__header_section .header__row--top shopify-account::part(signed-out-avatar),
body[gbb-consolidated-design="true"] #shopify-section-sections--31616257753418__header_section .header__row--top shopify-account::part(signed-in-avatar),
body[gbb-consolidated-design="true"] #shopify-section-sections--31616257753418__header_section .header__row--top .account-button svg,
body[gbb-consolidated-design="true"] #shopify-section-sections--31616257753418__header_section .header__icon--summary {
  transition: min-height 0.3s ease, min-width 0.3s ease, height 0.3s ease, width 0.3s ease, padding 0.3s ease !important;
}
} /* Ende @media max-width:749px (Round 20: Header-Schrumpfen nur mobil) */


/* ----------------------------------------------------------------
   17. BOXEN-KARUSSELL: TITEL +25%, HOVER-RICHTUNG
   ---------------------------------------------------------------- */

#shopify-section-template--31616257655114__product_list_cyt63E .product-card__content p[role="heading"] {
  font-size: 125% !important;
  transition: transform 0.2s ease !important;
  min-height: 2.6em !important;  /* Fallback für sehr alte Browser */
min-height: 2lh !important;   
  display: flex !important;              /* NEU */
  flex-direction: column !important;      /* NEU */
  justify-content: flex-start !important;   /* NEU */
}
/* Hover/Touch-Vergrößerung statt Verkleinerung (best effort - die
   ursprüngliche Verkleinerungs-Regel kenne ich nicht im Detail, daher hier
   eine höher-spezifische Gegen-Regel) */
/* KORREKTUR (9.10., Round 27 Batch 11): Merle meldet "onhover wird der
   Titel der Probierbox größer und links abgeschnitten" - das betrifft die
   ERSTE Karte im Karussell (kein Nachbar links, der das Wachsen nach links
   auffangen könnte). Ursache: scale() wächst standardmäßig von der MITTE
   aus in alle Richtungen (auch nach links), das bestehende
   overflow:visible auf dem Text-Div (Abschnitt weiter unten) reicht dafür
   nicht, wenn eine WEITERE, dort nicht erfasste Ebene (vermutlich der
   Karussell-Scroll-Container selbst) links clippt. Fix: transform-origin
   auf "links" gesetzt, damit die Vergrößerung nur noch nach RECHTS wächst,
   nicht mehr nach links - vermeidet das Problem, statt die exakte
   clippende Ebene zu kennen. Konnte echtes :hover auf echter
   Desktop-Breite in meiner Sandbox nicht nachstellen, bitte live
   gegenchecken, ob links jetzt nichts mehr abschneidet. */
#shopify-section-template--31616257655114__product_list_cyt63E .product-card:hover .product-card__content p[role="heading"],
#shopify-section-template--31616257655114__product_list_cyt63E .product-card.pv-hover-inview .product-card__content p[role="heading"] {
  transform-origin: left center !important;
  transform: scale(1.12) !important;
}
/* Titel-Text auf/zuklappen (per Klick, siehe mobile-fixes.js). Der
   aufgeklappte Titel ueberschneidet sich mit Preis/Buttons darunter. Ohne
   genaues Markup die robusteste Absicherung: Content-Container auf flex-
   column (Geschwister rutschen bei wachsender Hoehe normal nach unten) +
   eigener Stacking-Kontext fuer den aufgeklappten Titel. */
#shopify-section-template--31616257655114__product_list_cyt63E .product-card__content {
  display: flex !important;
  flex-direction: column !important;
}
#shopify-section-template--31616257655114__product_list_cyt63E .product-card__content p[role="heading"].pv-boxtitle-expanded {
  -webkit-line-clamp: unset !important;
  overflow: visible !important;
  position: relative !important;
  z-index: 3 !important;
}

/* NEU (Round 27, 8. Batch): Merle "margin beim Boxtitel weg, aber ohne dass
   er beim Hover-Scale abgeschnitten wird, soll stattdessen einfach ueber das
   div laufen". Root Cause gefunden: der Titel-Text selbst steckt in einem
   eigenen, generierten Shopify-Textblock-Div (Klasse
   "...__product_title_9pPDEV", bereits an anderer Stelle in dieser Datei
   fuer Schriftgroesse benutzt) - und GENAU dieses Div hat nativ
   overflow:hidden (vermutlich fuer den Zeilen-Clamp-Mechanismus gedacht,
   siehe .pv-boxtitle-expanded oben). Live gemessen: schon im Ruhezustand
   (ganz ohne Hover) ist die Titel-Box breiter als dieses Div - der
   Hover-Scale (1.12, s. o.) macht es nur sichtbarer. Die bestehenden
   overflow:visible-Fixes weiter unten in dieser Datei (Abschnitt zum
   "Jetzt fuellen"-Button) greifen hier NICHT, die betreffen andere,
   weiter aussen liegende Container (.product-card/.product-card__content/
   .resource-list__slide), nicht dieses Textblock-Div. Fix: overflow hier
   direkt auf visible, nur Desktop (>=750px, da der Hover-Scale auf Mobil
   ueber Abschnitt 48 weiter unten ohnehin deaktiviert ist) - der Titel darf
   jetzt ueber sein Div hinauslaufen statt abgeschnitten zu werden.
   EHRLICHER HINWEIS: echtes Hover auf einer echten Desktop-Breite konnte ich
   in meiner Sandbox nicht nachstellen (Fenster-Resize greift dort nicht,
   siehe Notiz an anderer Stelle) - bitte auf einem echten Desktop-Bildschirm
   gegenchecken, ob der Titel jetzt sauber ueberlaeuft statt abgeschnitten
   zu werden. */
@media screen and (min-width: 750px) {
  #shopify-section-template--31616257655114__product_list_cyt63E [class*="__product_title_9pPDEV"] {
    overflow: visible !important;
  }
}


/* ---------------------------------------------------------------- 18.
   TAGLINE-SEKTION: STROKE/GAP/LONG-PILL + SCROLL-FARBE (Scroll-Trigger-Logik
   in mobile-fixes.js, ersetzt dort die IntersectionObserver-Zuordnung nur
   fuer .pv-tagline)
   ---------------------------------------------------------------- */

@media screen and (max-width: 749px) {
  body .pv-tagline {
    -webkit-text-stroke: 1.25px var(--pv-green-dark, #143c1f) !important; /* war 1.8px */
  }
  /* KORREKTUR (Round 20): Merle "Taglines brauchen auf kleinen Geraeten mehr
     Abstand, damit sie beim Hover/Scroll-Trigger (transform:scale(1.08), s.
     .pv-scroll-active weiter unten) nicht zusammenstossen - duerfen seitlich
     aber nicht abgeschnitten werden". transform:scale() nimmt keinen
     zusaetzlichen Platz im Flex-Layout ein (rein visuell), bei nur 10px/8px
     Abstand ueberlappt eine um 8% wachsende Pille leicht ihre Nachbarn. Gap
     testo rechnerisch grosszuegig erhoeht (deutlich mehr als die paar Pixel,
     die 8% Wachstum zusaetzlich braucht), bewusst NICHT durch breitere
     Pillen/mehr Padding geloest (das haette das Risiko fuer seitliches
     Abschneiden erhoeht, flex-wrap faengt den Rest ab). */
  body .pv-tagline-row {
    gap: 18px !important;
    row-gap: 14px !important;
    flex-wrap: wrap !important;
  }
  body .pv-tagline.pv-tagline--long {
    font-size: clamp(0.5rem, 2.9vw, 0.8rem) !important;
    white-space: normal !important;
    text-align: center !important;
    max-width: 98vw !important;
  }
}

/* Vom Scroll-Trigger (JS) gesetzte Klasse - Farbe analog zur bestehenden
   Hover-Logik (:has()). AB 2.10. (Phase 2): das leichte Wachsen
   (transform:scale(1.08)) fehlte bisher hier - die Pille bekam beim
   Scroll-Trigger nur die Hintergrundfarbe, nicht das volle :hover-Gefuehl. */
body .pv-tagline.pv-scroll-active {
  background-color: var(--header-color, #eb99bf) !important;
  transform: scale(1.08) !important;
}
/* AB 2.10. (Phase 2): das JS (updateTaglineScroll() in mobile-fixes.js)
   toggelt .pv-scroll-active bereits auf dem jeweils auslösenden Trigger-Wort
   (.benefit-trigger) ZUSAETZLICH zur Pille - dafuer fehlte bisher komplett
   die CSS-Seite, weshalb am Trigger-Wort optisch nichts passierte. Fix:
   dieselbe Optik wie :hover. */
body .benefit-trigger.pv-scroll-active {
  color: var(--header-color) !important;
  font-size: 110% !important;
  /* KORREKTUR (7.10., Teil 14): Merle "bei den 100% X ist die Webstroke-
     Farbe immer noch nicht mit animiert" - der Grund: ich hatte die
     Stroke-Farbe bisher nur auf ".benefit-trigger:hover" ergaenzt (siehe
     oben), aber auf dem Handy gibt es keinen Maus-Hover - dort faerbt sich
     das Wort stattdessen ueber genau DIESE Klasse hier (.pv-scroll-active,
     wird von mobile-fixes.js beim Scroll-Trigger gesetzt). Genau hier fehlte
     die Stroke-Farbe noch. Jetzt ergaenzt. */
  -webkit-text-stroke-color: var(--header-color) !important;
}


/* ---------------------------------------------------------------- 19.
   FOOTER-BUTTON (.pv-button--thin) ZENTRIEREN, ANIMATION WEG
   ---------------------------------------------------------------- */

body .pv-button--thin {
  animation: none !important;
  /* KORREKTUR (Round 27): Merle "Animation beim FAQ-Button ist abgehackt".
     Root Cause gefunden: diese Regel hatte die Transition auf NUR "color"
     eingeschraenkt (urspruenglich hier, um die oben entfernte Keyframe-
     Animation zu stoppen) - dabei aber "transform" aus der Liste
     rausgefallen. Der Hover-Scale-Effekt (transform:scale(1.08), kommt von
     der Basis-Regel .pv-button:hover) hatte dadurch gar keine eigene
     Transition mehr und sprang hart/abgehackt auf die neue Groesse, statt
     weich zu gleiten. Fix: transform wieder mit in die Liste aufgenommen,
     "animation:none" bleibt bestehen (verhindert weiterhin die alte
     Keyframe-Schleife). */
  transition: color 0.2s ease, transform 0.3s ease !important;
}
@media screen and (max-width: 749px) {
  body .pv-button--thin {
    --padding-inline-start: 20px !important;
    --padding-inline-end: 20px !important;
    text-align: center !important;
    justify-self: center !important;
  }
}


/* ----------------------------------------------------------------
   20. BOX-SEITE: H2 WEITER VERGRÖSSERN, CTA-BUTTON KLEINER, ALLE-GERICHTE
       BILD-NUDGE
   ---------------------------------------------------------------- */

@media screen and (max-width: 749px) {
  body [class*="__text_aLNxiX"] {
    font-size: 145% !important; /* war 115%, laut Merle noch nicht genug */
  }
  body .stelldirdeineboxzusammen {
    font-size: clamp(0.72rem, 3.8vw, 1.4rem) !important; /* Minimum weiter runter, war 0.85rem */
  }
}

/* Alle-Gerichte: Bilder (nicht die ganze Karte) leicht nach rechts. Selektor
   best effort (Produktkarten-Bildcontainer) - bitte live prüfen. */
@media screen and (max-width: 749px) {
  #shopify-section-template--31616257720650__main .product-media {
    margin-left: 6px !important;
  }
}


/* ---------------------------------------------------------------- 21.
   CHECKOUT: BESTELLUEBERSICHT-FARBE Shopifys gehostete Kasse laedt
   assets/base.css NICHT - eine Regel hier haette keine Wirkung. Diese Farbe
   muss im Shopify-Admin unter Einstellungen -> Kasse -> Branding eingestellt
   werden (bzw. bei Plus in checkout.liquid). Deshalb bewusst keine Regel, um
   keine falsche Sicherheit vorzugaukeln.
   ---------------------------------------------------------------- */


/* ---------------------------------------------------------------- 22.
   ACCOUNT-BEREICH IN MARKENFARBEN (BEST EFFORT) Markup der Account-Templates
   unbekannt - generischer Ansatz ueber die automatisch vergebenen
   body.template-customers-*-Klassen (Online Store 2.0 Standard). Bitte live
   gegenchecken.
   ---------------------------------------------------------------- */

body.template-customers-login .field__input,
body.template-customers-register .field__input,
body.template-customers-account .field__input,
body.template-customers-addresses .field__input,
body.template-customers-order .field__input {
  border-color: var(--pv-green-dark, #143c1f) !important;
}
body.template-customers-login button.button,
body.template-customers-register button.button,
body.template-customers-account button.button,
body.template-customers-addresses button.button {
  background-color: var(--pv-green-dark, #143c1f) !important;
  color: var(--pv-cream, #f5ffe4) !important;
  border-color: var(--pv-green-dark, #143c1f) !important;
}
body.template-customers-login a:not(.button),
body.template-customers-register a:not(.button) {
  color: var(--header-color, #eb99bf) !important;
}


/* ----------------------------------------------------------------
   23. PRODUKTBILD-GALERIE (PDP + QUICK-VIEW): RAND FIXEN, THUMBNAILS AN
   ---------------------------------------------------------------- */

/* Grid-Zeile an die tatsächliche (quadratische) Bildhöhe koppeln statt an
   feste 50dvh/70dvh - das war die Ursache für den leeren Bereich unter dem
   Bild. */
body .product-media-container.constrain-height {
  --grid-template-rows: auto !important;
  --grid-template-rows-desktop: auto !important;
}

/* Miniaturbilder auch auf Mobil zeigen statt nur Zahlen-Punkte (Merles
   Wunsch, Alternative Chevron-Pfeile s. Kommentar unten). Klassennamen mit
   Doppelpunkt (Tailwind-artig) müssen im Selektor escaped werden. */
@media screen and (max-width: 749px) {
  body media-gallery slideshow-controls[thumbnails].mobile\:hidden {
    display: flex !important;
  }
  body media-gallery slideshow-controls.desktop\:hidden.media-gallery__mobile-controls {
    display: none !important;
  }
  body media-gallery {
    --thumbnail-width: 38px !important; /* schmaler als Desktop-Wert (57px) */
  }
}
/* Falls die Thumbnail-Leiste auf schmalen Screens zu eng wird, alternativ die
   Chevron-Pfeile einblenden - dafuer die obigen drei Regeln ersetzen durch:
   body slideshow-arrows.mobile\:hidden { display: flex !important; } */


/* ----------------------------------------------------------------
   24. EASY BUNDLES: 3-SPALTEN-BREITE, "ZUR KASSE"-ZUSTAND, STICKY,
       AUSKLAPP-BUTTON, KATEGORIE-BUTTONS
   ---------------------------------------------------------------- */

/* a) 3-Spalten sprengen die Breite: klassischer CSS-Grid-Overflow (1fr allein
   verhindert Overflow durch intrinsische Mindestbreiten NICHT, minmax(0,1fr)
   schon). Zusätzlich Bilder/Karten auf 100% Breite begrenzt. */
@media screen and (max-width: 749px) {
  /* Mehr Platz zwischen den Produkten (Gap erhoeht), Grid darf 1-3% breiter
     werden, aber nie ueber die Bildschirmbreite hinaus (max-width:100vw +
     symmetrischer negativer Margin-Ausgleich, bleibt zentriert). */
  body .gbbProductsContainer {
    grid-template-columns: repeat(3, minmax(0, 1fr)) !important;
    gap: 10px !important; /* war 6px */
    width: 102% !important; /* war implizit 100% - +2%, Merles Wunsch 1-3% */
    max-width: 100vw !important;
    margin-inline: -1% !important;
    box-sizing: border-box !important;
  }
  /* Die feste Bildgröße (statt width:100%/height:auto) ist jetzt in Abschnitt
     36 (EASY BUNDLES: BILDGRÖSSE FEST) geregelt - siehe dort für die
     Begründung (Grid-Row-Fix gegen die ausbrechenden Bilder). */
  body .gbbProductItem {
    min-width: 0 !important;
  }
  /* NEU (Round 26, 2. Feedback-Runde): Merle "kannst du den EB-Produktkarten
     auf dem Handy weniger Border-Radius geben, dass sie ein Drittel weniger
     abgerundet sind?" Live gemessene native Werte (Referenz, volle Desktop-
     Breite): Karte (.gbbProductItem) 45px, Bild-Container
     (.gbbProductImageContainer) 43px, Bild selbst (.gbbProductImage) 50%
     (= volle Kreisform). Alle drei um ein Drittel reduziert (*2/3), damit
     das Verhaeltnis zueinander gleich bleibt - nur auf Mobil (max-width:
     749px), wie gewuenscht, Desktop bleibt unveraendert bei den nativen
     Werten. */
  body .gbbProductItem {
    border-radius: 30px !important;
  }
  body .gbbProductImageContainer {
    border-radius: 29px !important;
  }
  body .gbbProductImage {
    border-radius: 33% !important;
    /* NEU (Round 28/Batch 17): Merle, "Mobilfeedback Hoch" Punkt 18 - "scale
       0.98 weg, eher scale 1.08 sogar hin, die Bilder sind zu klein auf
       meinem iPhone und haben noch Platz". Nur auf Mobil (dieser Block,
       max-width:749px) - Desktop behaelt den Basiswert scale(0.98)
       (Abschnitt "Easy Bundles Mix & Match" ganz oben). */
    transform: scale(1.08) !important;
  }
}

/* b) Bundle-Wagen als echtes Popup/Bottom-Sheet statt sticky. position:
   sticky wirkt nur, wenn kein Vorfahre overflow:hidden/auto/scroll setzt -
   das reicht schon, um es unsichtbar zu deaktivieren. position:fixed ist
   robuster und macht aus dem Wagen automatisch das gewuenschte Popup:
   zugeklappt unten angedockt, ausgeklappt ein Bottom-Sheet mit eigener
   Scroll-Flaeche und abgerundeten oberen Ecken.
   KORREKTUR (Round 23, Bugfix "CartDrawer fuellt die komplette Seite aus und
   verdeckt alles" auf der EB Mix&Match-Seite): dieselbe Breiten-vs-Hoehen-
   Erkennungslücke wie beim Hero/Produktraster (siehe weiter oben in dieser
   Datei) - "max-width:749px" greift auf Handy im Querformat oft NICHT (echte
   Geraete sind dort haeufig breiter als 749px, z.B. iPhone 14 quer ca.
   844px). Der ganze Bottom-Sheet-Umbau (position:fixed, max-height-Deckel,
   abgerundete Ecken) blieb dadurch auf Handy-Quer wirkungslos - der Drawer
   fiel auf sein natives, nicht gedeckeltes Hoehenverhalten zurueck und
   konnte dadurch den gesamten (auf Handy-Quer ohnehin knappen) Viewport
   fuellen. Fix: Bedingung um unsere etablierte Handy-Quer-Erkennung
   (Querformat UND Hoehe <=500px) erweitert.
   KORREKTUR (Round 28, Batch 17, Punkt 21 - Merles ausdruecklicher Wunsch
   "bitte das Querformat vom Desktop uebernehmen"): die Handy-Quer-
   Erweiterung von Round 23 (direkt darueber beschrieben) wieder aus DIESER
   Regel entfernt - der Bottom-Sheet-Wagen (position:fixed, deckt das ganze
   Produktbild zu) soll im echten Handy-Querformat nicht mehr greifen.
   Stattdessen bekommt das Querformat jetzt weiter unten einen eigenen
   Zuschnitt, der - wie am Desktop - die Sidebar als echte zweite Grid-Spalte
   neben dem Produktraster zeigt (siehe neue Regel "Punkt 21" nach dem
   "schmaler Desktop"-Block). Diese Regel hier bleibt dadurch nur noch fuer
   schmale Handy-Breiten im HOCHFORMAT (max-width:639px) zustaendig.
   KORREKTUR (Round 26, Merles Meldung "bei quadratischem Desktopfenster
   verdeckt der Cartdrawer die ganze Seite"): live per Chrome bestaetigt
   (document.styleSheets-Inspektion bei 737px Fensterbreite) - GENAU diese
   Regel hier ist die Ursache, nicht EB selbst. Grund: EBs eigene interne
   JS-Weiche (window.gbbSideFooter.utility.isMobileView(), live per
   window.innerWidth-Spoofing binaer gesucht) wechselt zwischen "Mobil-DOM"
   und "Desktop-DOM" bereits bei ca. 600-640px - UNSER Schwellenwert hier
   lag bisher bei 749px. Im Luecken-Bereich 640-749px liefert EB also schon
   sein volles Desktop-DOM (kompletter Sidebar-Inhalt, kein kompaktes Mobil-
   Element), unsere Regel zwingt diesem Desktop-Inhalt aber weiterhin
   position:fixed + volle Seitenbreite auf - dadurch wird aus der Sidebar ein
   Vollbild-Overlay, das die ganze Seite verdeckt. Fix: Schwellenwert von
   749px auf 639px gesenkt, synchron zu EBs eigenem Umschaltpunkt. Der
   Handy-Quer-Zweig (Querformat + Hoehe <=500px) bleibt unveraendert, falls
   doch mal ein echtes Handy im Querformat breiter als 639px ist. */
@media screen and (max-width: 639px) {
  body .gbbBundleFooter {
    position: fixed !important; /* war sticky */
    bottom: 0 !important;
    left: 0 !important;
    right: 0 !important;
    width: 100% !important;
    max-width: 100vw !important;
    z-index: 9999 !important;
    padding-bottom:0.3vh;
  }
  body .gbbDrawer.gbbCartDrawer,
  body .gbbFooterBundleItemsContainer {
    max-height: 85vh !important;
    overflow-y: auto !important;
    -webkit-overflow-scrolling: touch !important;
    border-radius: 16px 16px 0 0 !important;
    box-shadow: 0 -4px 24px rgba(0, 0, 0, 0.25) !important;
  }
  /* Merle: das Feld mit der Anzahl ausgewählter Gerichte ("0 Gericht/e") ist
     viel zu breit und füllt den ganzen Container - vermutlich flex:1/flex-
     grow von der App. Hart auf ~20vw begrenzt und vom Strecken ausgenommen. */
  body .gbbFooterTotalItemsInCart {
    width: 20vw !important;
    max-width: 20vw !important;
    flex: 0 0 auto !important;
  }
}

/* b2) NEU (Round 26): "SCHMALER DESKTOP" - 4-Spalten-Produktraster laeuft
   ueber (Merles Meldung, Screenshot bei 830px Fensterbreite: "ab dieser
   Groesse abwaerts nur drei Gerichtscolumns, damit 4 nicht passiert"), UND
   die Sidebar (Warenkorb/Gesamtpreis) verschwindet teils komplett
   (Screenshot bei 761px). Live per Chrome bestaetigt (JS-Inspektion der
   echten DOM-Struktur, 1400px-Referenzmessung):
   - ".gbbProductsContainer" ist ein natives CSS-Grid mit vier FESTEN Px-
     Spalten (kein fr/%), die EB per eigenem JS aus der verfuegbaren Breite
     berechnet. Bei 1400px passen vier Spalten bequem (ca. 219px je Spalte),
     bei den schmaleren Fensterbreiten reicht der Platz dafuer nicht mehr -
     Text/Bilder laufen ueber den Rand.
   - Die Sidebar (".gbbBundleFooter") sitzt zusammen mit dem Produktraster in
     einem gemeinsamen Grid-Eltern-Element (".gbbCategoriesBodyContainer",
     ebenfalls mit festen Px-Spalten, bei 1400px z.B. "919px 414px"). Auch
     hier gilt: diese Px-Werte werden von EBs eigenem JS berechnet, nicht von
     uns - bei genuegend schmaler Gesamtbreite kann die zweite Spalte
     (Sidebar) offenbar auf eine zu kleine oder gar keine Breite mehr kommen,
     wodurch der Wagen optisch komplett verschwindet.
   AUSDRUECKLICHER HINWEIS: meine Chrome-Sandbox laesst sich auf keine
   echte schmalere Fensterbreite als die Standardgroesse bringen (der
   resize_window-Befehl aendert zwar das Chrome-Fenster, aber window.
   innerWidth bleibt unveraendert - dieselbe Einschraenkung wie schon frueher
   in diesem Projekt dokumentiert), ich konnte die beiden Bugs deshalb NICHT
   bei echten 830px/761px nachstellen. Die DOM-/Grid-Struktur selbst (oben
   beschrieben) ist aber live bestaetigt, nicht geraten. Fix: beide Grids in
   einem "schmaler Desktop"-Bereich (640px, EBs eigener Mobil/Desktop-
   Umschaltpunkt) hart auf eigene, sichere Werte gesetzt statt EBs berechnete
   Px-Werte zu uebernehmen: Produktraster auf drei gleich breite Spalten
   (verhindert die 4-Spalten-Ueberlaufung), Sidebar-Spalte auf eine
   Mindestbreite gedeckelt (verhindert das Verschwinden).
   KORREKTUR (Round 26, 2. Feedback-Runde, noch vor dem ersten Test dieser
   Datei gemeldet): Merle "die Probierbox [=die Box-Groessen-Auswahl mit den
   drei Kreisen in der Sidebar] ist wahnsinnig gequetscht, kannst du die
   Groesse der Selectionbox aus breitem Browserfenster moeglichst lange
   beibehalten und eher die Produktkarten kleiner skalieren bzw. frueher in
   3 Columns umbrechen?" - zwei Aenderungen dafuer: (1) die Sidebar-
   Mindestbreite von 300-360px auf 380-420px angehoben (naeher an ihrer
   natuerlichen Desktop-Breite von ca. 414px, live gemessen) - sie behaelt
   dadurch ueber einen groesseren Breitenbereich praktisch ihre volle Groesse,
   die Kompression trifft fast ausschliesslich das Produktraster. (2) die
   Obergrenze dieses Bereichs von 1099px auf 1199px angehoben (deckt sich
   jetzt mit der sonst in dieser Datei ueberall verwendeten "echter Desktop"-
   Grenze von 1200px) - das Produktraster wechselt dadurch "frueher" (bei
   einer groesseren Fensterbreite) auf 3 statt 4 Spalten, wie gewuenscht. */
@media screen and (min-width: 640px) and (max-width: 1199px) {
  body .gbbCategoriesBodyContainer {
    grid-template-columns: minmax(0, 1fr) minmax(380px, 420px) !important;
  }
  body .gbbProductsContainer {
    grid-template-columns: repeat(3, minmax(0, 1fr)) !important;
  }
  body .gbbProductItem,
  body .gbbProductItem * {
    min-width: 0 !important;
  }
  body .gbbBundleFooter {
    min-width: 380px !important;
  }
  /* NEU (Round 28/Batch 18): Merle, Desktop-Quer-Feedback - "die Selection
     Boxes sitzen hier ebenfalls nicht mittig im Cart... der ganze Container
     muesste nur mittiger (margin-left vielleicht einfach weg)". Vermuteter
     Root Cause: .gbbBoxSelectionContainer hat hier keine eigene Breite
     weniger als ihr Grid-Zellen-Platz, dadurch greift eine reine margin:auto-
     Zentrierung nicht von selbst - zusaetzlich width:fit-content ergaenzt,
     damit der Container wirklich auf seine 3 Kacheln zusammenschrumpft und
     dann per margin-inline:auto zentriert werden kann. AUSDRUECKLICHER
     HINWEIS: konnte nicht live gegengeprueft werden (Chrome getrennt) -
     Merles eigene Vermutung war nur "margin-left vielleicht weg", hier
     stattdessen die (robustere) Zentrierungs-Technik versucht; bitte
     gegenchecken, ob das wirklich mittig sitzt. Nur fuer den "schmaler
     Desktop"-Sidebar-Bereich gescopt, NICHT fuer breiten Desktop (dort laut
     Merle schon alles top). */
  body .gbbBoxSelectionContainer {
    width: fit-content !important;
    margin-inline: auto !important;
  }
}

/* b3) NEU (Round 26, 4. Feedback-Batch): Merles neue Meldung: "bei einer
   Desktopbreite kurz vor Handy Hochkant bitte nur ein oder zwei Columns
   Gerichte, das passt sonst nicht". Das untere Ende des obigen "schmaler
   Desktop"-Bereichs (ab 640px) ist fuer 3 Spalten anscheinend immer noch zu
   schmal. AUSDRUECKLICHER HINWEIS: sie hat keine exakte Fensterbreite dazu
   genannt - 640-899px ist eine Schaetzung (die untere Haelfte des
   bestehenden Bereichs), bitte bestaetigen, ob das die richtige Grenze
   trifft oder ob sie nach oben/unten verschoben werden muss. 2 statt 1
   Spalte gewaehlt als Mittelweg (1 Spalte haette bei den eher breiten/
   runden Produktkarten sehr viel Leerraum rechts erzeugt) - falls 1 Spalte
   doch besser aussieht, einfach Bescheid geben. */
@media screen and (min-width: 640px) and (max-width: 899px) {
  body .gbbProductsContainer {
    grid-template-columns: repeat(2, minmax(0, 1fr)) !important;
  }
}

/* b4) GESCHICHTE: urspruenglich in Batch 17 eingefuehrt (Cart als echte
   zweite Grid-Spalte statt Bottom-Sheet im Handy-Querformat), in Batch 21
   als Regression deaktiviert (Annahme ueber die DOM-Struktur schien falsch -
   Produktraster kollabierte auf 1 Spalte, Cart-Spalte blieb leer). In
   Batch 24 wurde die DOM-Struktur erneut live untersucht und bestaetigt,
   dass die urspruengliche Architektur-Annahme (".gbbCategoriesBodyContainer"
   = Grid mit Produktspalte + ".gbbBundleFooter" als direkte Kinder) die
   ganze Zeit KORREKT war - die damalige Regression lag vermutlich an etwas
   anderem (evtl. einem Konflikt mit der gleichzeitig aktiven JS-Zwangsregel
   in mobile-fixes.js, die zum selben Zeitpunkt ebenfalls deaktiviert wurde).

   NEU UMGESETZT UND DIESMAL ECHT LIVE VERIFIZIERT (Round 28, 24. Batch,
   Nachbesserung): Merles konkreter Wunsch war diesmal nicht mehr "wie
   Desktop", sondern ein eigenes 65%/35%-Verhaeltnis (Produkte/Cart), dazu
   Box-Auswahl-Items (Probier-/Single-/Family-Box) duerfen HIER (einzige
   Ausnahme) untereinander statt nebeneinander stehen, und der Untertitel
   ("6x Gerichte - 39,99€ (inkl. Versand)") soll in einer Zeile bleiben.
   Live in Chrome getestet (echtes 900x277-Fenster, Querformat + Hoehe
   <=500px - erfuellt durch die Sandbox-Grenzen zufaellig auch exakt den
   Bereich, in dem die meisten echten Handys im Querformat tatsaechlich
   liegen, siehe "min-width:640px" unten):
   - 65/35-Aufteilung per fr-Einheiten umgesetzt (".gbbCategoriesBodyContainer"
     reagiert live bestaetigt auf fr-Einheiten - anders als z. B.
     ".gbbProductsContainer"/".gbbBoxSelectionContainer", die fr nachweislich
     ignorieren, siehe anderer Kommentar in dieser Datei). Ergebnis bei 848px
     Innenbreite: 541px/292px, exakt 65%/35%.
   - WICHTIGER FUND dabei: ".gbbBundleFooter" hat aus der "schmaler Desktop"-
     Regel oben (Punkt b2) eine "min-width:380px !important" geerbt - bei
     einer 35%-Spalte, die oft schmaler als 380px ist, zwingt das den Wagen
     ueber seine eigene Grid-Zelle hinaus und erzeugt horizontalen Overflow
     der GESAMTEN Seite (live gemessen: 962px Inhalt bei 900px Fensterbreite,
     also 62px Overflow). Live durch eine eigene, kleinere min-width hier
     behoben (900px = 900px danach, kein Overflow mehr).
   - Box-Auswahl-Items auf 1 Spalte gesetzt, NUR innerhalb von
     ".gbbBundleFooter" gescopt (trifft keine andere Stelle, an der dieselbe
     Komponente vorkommt). Live bestaetigt: alle drei Untertitel-Varianten
     (6x/12x/24x Gerichte) sind danach exakt 17px hoch = eine einzige Zeile,
     vorher mehrzeilig bei 3 nebeneinander liegenden, nur ca. 120px breiten
     Kacheln.
   - Produktraster-Spaltenzahl damals bewusst NICHT eigens gesetzt (Annahme:
     bleibt bei den 3 Spalten aus der "schmaler Desktop"-Regel oben) - bei 65%
     Breite live als weiterhin gut lesbar bestaetigt.
     KORREKTUR (Round 28, 26. Batch): diese Annahme war falsch - live am
     echten 700x232-Fenster (Querformat, Teil des hier gueltigen
     min-width:640px-Bereichs) nachgemessen, dass tatsaechlich die NOCH
     SPEZIFISCHERE "640-899px -> 2 Spalten"-Regel (Punkt b3, direkt oberhalb)
     gewinnt, nicht die 3-Spalten-Regel - beide haben dieselbe Spezifitaet,
     b3 steht aber SPAETER im File als die 3-Spalten-Regel und gewinnt dadurch
     fuer genau den 640-899px-Teilbereich. Merle meldet dazu konkret "die
     Gerichtkarten muessen dreispaltig" - jetzt direkt im Handy-Quer-Block
     unten explizit auf 3 Spalten gesetzt, das gewinnt wiederum ueber b3, weil
     dieser Block noch spaeter im File steht.
   EINSCHRAENKUNG, ausdruecklich: "min-width:640px" in der Media Query
   begrenzt diese neue Regel bewusst auf denselben Breitenbereich wie die
   "schmaler Desktop"-Regel oben (deren Architektur hier live bestaetigt
   wurde) - ein sehr schmales Handy im Querformat unter 640px Breite (in der
   Praxis selten, die meisten modernen Handys liegen im Querformat deutlich
   darueber) faellt weiterhin auf das alte Bottom-Sheet-Verhalten zurueck,
   NICHT auf diese Regel. Diese Grenze absichtlich konservativ gewaehlt, um
   nicht erneut den unverifizierten <640px-Bereich zu riskieren, der schon
   einmal zur Batch-21-Regression gefuehrt haben koennte. Falls ein reales
   schmaleres Handy-Quer-Geraet betroffen ist, bitte melden.

   NACHBESSERUNG, noch im selben Live-Test gefunden: mit der obigen 1-Spalten-
   Regel allein passten nur die kuerzeste der drei Untertitel-Varianten (6x)
   wirklich in eine Zeile - 12x/24x (laengerer Text wegen "versandkostenfrei"
   statt "inkl. Versand") brachen trotzdem noch um, weil ".gbbBundleFooter"
   selbst 20px Innenabstand links/rechts hat und dadurch real nur ca. 220px
   Textbreite uebrig bleiben (gemessen), der laengste Untertitel aber echte
   ca. 249px bei 14px Schriftgroesse braucht. Live durchgetestet: 12px
   Schriftgroesse reicht mit ausreichend Sicherheitsabstand (ca. 221px bei
   12px vs. 220px verfuegbar), alle drei Varianten danach bestaetigt einzeilig
   (Hoehe exakt 14.94px bei allen dreien), kein neuer horizontaler Overflow
   der Seite (900px = 900px). */
@media screen and (orientation: landscape) and (max-height: 500px) and (min-width: 640px) {
  /* KORREKTUR (Round 28, 26. Batch): Merle "der Cart-Drawer braucht etwas
     mehr Platz, vielleicht eher 58-42%" - von 65/35 auf 58/42 geaendert. */
  body .gbbCategoriesBodyContainer {
    grid-template-columns: minmax(0, 58fr) minmax(220px, 42fr) !important;
  }
  /* NEU (Round 28, 26. Batch): siehe Kommentar weiter oben ("KORREKTUR") -
     die allgemeine "schmaler Desktop"-3-Spalten-Regel wird fuer den
     640-899px-Teilbereich von einer noch spezifischeren 2-Spalten-Regel
     ueberschrieben. Hier explizit erzwungen, da dieser Block spaeter im File
     steht und dadurch gewinnt. Merle: "die Gerichtkarten muessen dreispaltig". */
  body .gbbProductsContainer {
    grid-template-columns: repeat(3, minmax(0, 1fr)) !important;
  }
  body .gbbBundleFooter {
    min-width: 220px !important;
  }
  body .gbbBundleFooter .gbbBoxSelectionContainer {
    grid-template-columns: 1fr !important;
  }
  body .gbbBundleFooter .gbbBoxSelectionSubtext {
    font-size: 12px !important;
    white-space: nowrap !important;
  }
}

/* d) Mengen-Plus/Minus-Buttons ausblenden. Fertiger Snippet von Merle (Round
   28, 26. Batch), unveraendert uebernommen. */
.quantity-minus.button-unstyled,
.quantity-plus.button-unstyled {
  display: none !important;
}
/* NEU (Round 28, 58. Batch): Merle "nur auf der Mystery-Box-Seite den
   quantity-selector-wrapper wieder mit + und - und klickbar machen". Die
   Regel direkt oben blendet diese Buttons seit dem 26. Batch SITEWEIT aus
   (".quantity-minus.button-unstyled"/".quantity-plus.button-unstyled") -
   live bestaetigt (Chrome verbunden, echte Mystery-Box-Produktseite
   /products/mystery-box): genau diese Regel (aus UNSERER eigenen Datei,
   nicht aus dem nativen Theme) setzt "display:none" auf die beiden Buttons
   im ".quantity-selector-wrapper" des nativen Produktformulars - der native
   Theme-Wert waere "display:flex" (aus dem kompilierten Theme-Stylesheet
   ausgelesen). Fuer die Mystery-Box-Seite hier gezielt wieder hergestellt,
   ueberall sonst bleibt die Ausblend-Regel unveraendert aktiv. Die
   Seitenerkennung (Body-Klasse "pv-mystery-box-page") setzt
   mobile-fixes.js, neuer Block 31 (gleiches Muster wie die B2B/Ueber-uns-
   Seitenerkennung, Block 25). */
body.pv-mystery-box-page .quantity-minus.button-unstyled,
body.pv-mystery-box-page .quantity-plus.button-unstyled {
  display: flex !important;
}

/* e) NEU (Round 28, 27. Batch): Merle "cart-quantity-selector-component im
   Cart in der Breite auf den Inhalt beschraenken". Live bestaetigt (Cart-
   Drawer, echter Desktop-Tab): das Custom-Element selbst ist
   display:flex;justify-content:space-between mit fester Breite 105px - durch
   das Ausblenden der Minus/Plus-Buttons direkt oberhalb bleibt nur noch das
   17px breite Mengen-Eingabefeld uebrig, die 105px-Box laesst dadurch ca.
   88px toten/leeren Raum links+rechts davon stehen. Fix: Breite auf den
   tatsaechlichen Inhalt schrumpfen lassen statt fest 105px. */
cart-quantity-selector-component {
  width: fit-content !important;
  /* KORREKTUR (Round 28, 28. Batch): Merle "die Zahl ist jetzt doch etwas
     sehr eingequetscht" - width:fit-content allein liess dem Eingabefeld
     praktisch keinen Luftraum mehr (live gemessen: Komponente 38px, Feld
     36px - nur 1px Luft je Seite). Etwas Innenabstand ergaenzt, Breite bleibt
     weiterhin inhaltsbasiert (fit-content + Padding statt fester 105px). */
  padding-inline: 8px !important;
}
/* NEU (Round 28, 29. Batch): Merle "das Mengen-Feld soll kein Eingabefeld
   sein, nur die Anzahl anzeigen" - mobile-fixes.js setzt dafuer "readonly"
   auf das input-Element (verhindert Tastatur-Eingabe, laesst die +/-
   Buttons aber weiter funktionieren, siehe Kommentar dort). Hier nur die
   OPTISCHE Seite: Cursor zeigt "default" statt der Text-Einfuege-Markierung,
   die nativen Auf/Ab-Spinner-Pfeile (die bei einem reinen Anzeige-Feld
   keinen Sinn ergeben) werden ausgeblendet. */
cart-quantity-selector-component input {
  cursor: default !important;
}
cart-quantity-selector-component input::-webkit-outer-spin-button,
cart-quantity-selector-component input::-webkit-inner-spin-button {
  -webkit-appearance: none !important;
  margin: 0 !important;
}
cart-quantity-selector-component input[type="number"] {
  -moz-appearance: textfield !important;
}

/* c) "zur Kasse"-Button: ausgegraut bis Bedingung erfüllt (Klasse
   .pv-eb-ready wird von mobile-fixes.js gesetzt) */
body .gbbFooterNextButton {
  background-color: #939a7c !important;
  transition: background-color 0.25s ease !important;
}
body .gbbFooterNextButton.pv-eb-ready {
  background-color: #f4ffdb !important; /* war var(--pv-cream, #E3F3C6) - Round 26, 6. Batch: EB-einheitliches Hellgruen */
}

/* d) Workaround-"Fehlermeldung": Schrittbotschaft kurz pink + größer bei
   verfrühtem Klick (Klasse .pv-eb-shake wird von mobile-fixes.js gesetzt) */
body .gbbDiscountMessageContainer.pv-eb-shake {
  animation: pvEbShake 0.5s ease !important;
}
@keyframes pvEbShake {
  0%   { transform: scale(1); }
  30%  { color: var(--header-color, #eb99bf) !important; transform: scale(1.08); }
  100% { transform: scale(1); }
}

/* e) Ausklapp-Button (Menge + Chevron): 30% größer, dunkelgrüner Rahmen,
   dunkelgrünes Icon, sticky gegen Abschneiden */
@media screen and (max-width: 749px) {
  body .gbbCartIconWithQuantityContainer {
    transform: scale(1.3) !important;
    transform-origin: center bottom !important;
    border: 2px solid var(--pv-green-dark, #143c1f) !important;
    border-radius: 999px !important;
    position: sticky !important;
    bottom: 4px !important;
    z-index: 41 !important;
  }
  body .gbbCartIconWithQuantityContainer svg {
    --gbb-caret-up-icon-color: var(--pv-green-dark, #143c1f) !important;
  }
}

/* f) Kategorie-Filter-Buttons verkleinern (Padding halbiert, Schrift -20%,
   Abstand minimal - Ausgangswerte geschätzt, bitte live gegen Ist-Werte
   prüfen) */
@media screen and (max-width: 749px) {
  body .gbbCategoryTabContainer {
    padding-block: 0.5em !important;
  }
  body .gbbCategoryTabTitle {
    font-size: 0.8em !important;
  }
  /* KORREKTUR (Round 27, 7. Feedback-Batch): "Tabs beruehren sich beim
     Hovern" - live bestaetigt und Root Cause gefunden: beim Hover bekommen
     inaktive Tabs transform:scale(1.06) (Abschnitt "EB Mix&Match-Seite -
     Hover-Verhalten" weiter unten), was bei nur 2px Gap tatsaechlich zu
     NEGATIVEM Abstand fuehrt (live gemessen: -1.66px, also echte
     Ueberlappung). Mit 8px Gap bleiben beim Hover noch ca. 4.3px Luft -
     live per echtem Hover auf "Empfehlungen" nachgemessen (Nachbar-Tabs
     beruehren sich nicht mehr). */
  body .gbbCategoriesTabsContainer {
    /* NEU (Round 28/Batch 17): Merle, "Mobilfeedback Hoch" Punkt 20 -
       "Abstand zwischen den Kategorie-Tabs ein Drittel bis 40% weniger".
       Konflikt mit dem Kommentar direkt darueber: bei 8px Gap blieben nach
       dem Hover-Scale(1.06) der Nachbar-Tabs nur ca. 4,3px Luft - eine volle
       40%-Reduzierung (auf 4,8px) wuerde die Luft auf ~1px druecken und
       vermutlich das in Round 27 Batch 7 behobene "Tabs beruehren sich bei
       Hover"-Problem wieder zurueckbringen. Bewusst nur auf 6px reduziert
       (-25%, nicht -40%) als Kompromiss - bitte live gegenchecken, ob das
       optisch reicht; mehr Reduzierung nur auf Merles ausdrueckliches "ja,
       trotz Hover-Risiko".
       KORREKTUR (Round 28/Batch 18): Merle wiederholt den Wunsch nach der
       vollen Reduzierung ("ein Drittel - 40% weniger!") - jetzt auf 4.8px
       (-40%) umgesetzt. Damit das oben beschriebene Hover-Beruehrungs-Risiko
       dabei nicht zurueckkommt, wurde GLEICHZEITIG der Hover-Scale der Tabs
       (Abschnitt "EB Mix&Match-Seite - Hover-Verhalten", .gbbCategoryTab
       Container[data-is-active="false"]:hover) von 1.06 auf 1.03 reduziert -
       das haelt die Luft beim Hover rechnerisch bei ca. 2.95px (statt sie auf
       ~1px zu druecken). Bitte live gegenchecken, ob beides zusammen gut
       aussieht. */
    gap: 4.8px !important; /* war 6px, davor 8px, davor 2px */
  }
}

/* NEU (Round 26, 2. Feedback-Runde): Merle "um die Selectionbox-Texte kann
   auch minimal mehr Padding sein" (Screenshot zeigt die drei Kreise
   "Probier-Box/Single-Box/We-are-family-Box" sehr eng am Text). Live
   gemessen (volle 1400px-Desktop-Breite, unabhaengig vom schmaler-Desktop-
   Fix oben): natives Padding ist 8px rundum - bei "We-are-family-Box" bleibt
   dadurch kaum Luft zum Rand. Minimal auf 10px erhoeht, wie gewuenscht. Vor
   der Mobil-Regel direkt darunter platziert, damit die dort bereits
   eingestellten 22px (fuer den dort beobachteten anderen Ueberlauf) unberuehrt
   gewinnen. */
body .gbbBoxSelectionItem {
  padding: 15px !important; /* war 10px - Merle hat 15px selbst live getestet (Round 26, 5. Batch) */
}

/* g) Box-Auswahl (.gbbBoxSelectionItem): Innenabstand oben/unten halbiert +
   Abstand Titel/"X Gerichte" verkleinert, geschaetzt ohne Live-Zugriff auf
   die Ist-Werte. NACHTRAG: weiterhin ueberlaufender Text. Live gemessen: das
   Element ist bei 43px-Radius und nur 75.5px Hoehe faktisch eine volle
   Pillenform - ohne gerade Wandflaeche rutscht zweizeiliger Subtext (Family-
   Box) sichtbar in die Rundung. Fix: Innenabstand oben/unten wieder
   vergroessert (6px -> 16px), die Kachel waechst dadurch ueber die
   Rundungsgrenze hinaus und bekommt wieder gerade Wandflaeche. */
@media screen and (max-width: 749px) {
  body .gbbBoxSelectionItem {
    padding-block: 22px !important; /* war 16px - Merle meldete 7.10.: Subtext
      (v.a. 2-3-zeilig bei Probier-/Family-Box) ruckt weiterhin sichtbar in
      die Rundung, 16px reichte nicht */
    gap: 2px !important;
    row-gap: 2px !important;
    line-height: 112% !important; /* AB 7.10., Punkt 25 */
  }
}
/* NEU (Round 28, 31. Batch): Merle meldet fuer Handy-QUER explizit "kaum
   Padding oben/unten" bei .gbbBoxSelectionItem - die obige Regel (22px
   padding-block) war bisher auf "max-width:749px" begrenzt, echtes
   Handy-Quer (oft >=750px breit) fiel dadurch komplett durch dieselbe
   Breakpoint-Luecke wie mehrfach weiter oben in dieser Datei gefunden. Fix:
   dieselbe Regel zusaetzlich fuer echtes Handy-Quer aktiviert. */
@media screen and (min-width: 750px) and (orientation: landscape) and (max-height: 500px) {
  body .gbbBoxSelectionItem {
    padding-block: 22px !important;
    gap: 2px !important;
    row-gap: 2px !important;
    line-height: 112% !important;
  }
}
/* KORREKTUR (Round 28, 57. Batch): Merle meldet jetzt im Rahmen des grossen
   "HANDY QUER EB SEITE"-Pakets das Gegenteil - Innenabstand soll komplett
   weg (0 statt 15px/22px). Steht bewusst NACH der obigen Regel (gewinnt bei
   gleicher Spezifitaet) und ueberschreibt sowohl die hier gesetzten 22px
   als auch die unscoped 15px-Grundregel (ganz am Anfang der Datei) fuer
   ALLE vier Seiten (nicht nur block), da Merles Wunsch diesmal "padding weg"
   ohne Einschraenkung auf eine Richtung war. */
@media screen and (orientation: landscape) and (max-height: 500px) {
  body .gbbBoxSelectionItem {
    padding: 0 !important;
  }
}
/* KORREKTUR (Round 20): Merle will dieselbe engere Zeilenhoehe (112%, siehe
   oben) fuer Boxtitel UND Subtitel jetzt auch auf Desktop - bisher nur
   innerhalb der max-width:749px-Regel gesetzt. Bewusst NUR line-height hier
   dupliziert (nicht padding-block/gap - die bleiben mobile-spezifisch,
   danach war nicht gefragt), unscoped, gilt also auf allen Breiten. */
body .gbbBoxSelectionHeading,
body .gbbBoxSelectionSubtext {
  line-height: 112% !important;
}

/* Pille soll auf ihren Inhalt beschraenkt und zentriert (oder unten
   ausgerichtet) in .gbbBoxSelectionContainer sitzen. Der Container ist ein
   3-spaltiges Grid mit align-items:stretch - bricht eine Kachel durch
   laengeren Titel in eine zusaetzliche Zeile um, werden die kuerzeren
   Nachbar-Pillen auf dieselbe Zeilenhoehe gestreckt. Fix: height:fit-content
   + align-self:center, damit sie mittig in der Zeile sitzt statt gestreckt zu
   werden. NACHTRAG 7.10.: offenbar hat align-self am Kind allein nicht
   gereicht (ggf. App-eigenes align-items:stretch !important am Container
   gewinnt sonst) - deshalb zusaetzlich align-items:start direkt am
   Grid-Container, als zweite Verteidigungslinie gegen das Strecken. */
@media screen and (max-width: 749px), screen and (min-width: 750px) and (orientation: landscape) and (max-height: 500px) {
  body .gbbBoxSelectionItem {
    height: fit-content !important;
    align-self: center !important;
  }
  body .gbbBoxSelectionContainer {
    align-items: start !important;
  }
}


/* ================================================================ AB HIER:
   BATCH 25.9.2026 ABEND, TEIL 2 ("Ja das ist alles"-Freigabe)
   ================================================================ */

/* ---------------------------------------------------------------- 25. NAV /
   MENUE-DRAWER: HINTERGRUND, TRENNLINIE, SCHRIFT Klassen im Inspector
   bestaetigt, 1:1 aus dem DOM: .menu-drawer traegt Hintergrund/Textfarbe,
   jeder Link .menu-drawer__menu-item, der Text-Span .menu-drawer__menu-item-
   text. Bewusst keine IDs verwendet (die auto-generierten
   a#HeaderDrawer-...-IDs aendern sich bei jeder Content-Aenderung) - nur
   stabile CSS-Klassen bzw. Textinhalt.
   KORREKTUR (Round 28, 51. Batch): Merle meldet, auf dem iPad ihrer Mutter
   habe der Menue-Drawer KEINEN Hintergrund. Root Cause (Code-Analyse, dieselbe
   "Breakpoint-Luecke" wie an mehreren anderen Stellen in diesem Projekt):
   diese komplette Regel war auf "max-width:749px" gescopt - ein iPad liegt
   aber je nach Ausrichtung bei ca. 768-1024px (oder mehr bei iPad Pro), weit
   ueber dieser Grenze, und fiel dadurch komplett durch die Regel. Laut unserer
   eigenen Header-Referenz (`#header-component[data-menu-style='drawer']`,
   siehe claude/section-ids-referenz.md) nutzt der Header SITEWEIT den
   Drawer-Menue-Stil, nicht nur auf schmalen Bildschirmen - die Breiten-
   Beschraenkung war daher von Anfang an zu eng gefasst und nie fuer
   Tablet-/breitere Faelle gedacht. Fix: Media Query komplett entfernt, die drei
   Regeln gelten jetzt unconditional (der Drawer ist ohnehin nur sichtbar,
   wenn er tatsaechlich geoeffnet ist - keine Auswirkung auf andere Layouts,
   wenn er geschlossen bleibt). NICHT LIVE VERIFIZIERT (Chrome-Erweiterung
   diese Runde nicht verbunden) - bitte auf dem iPad gegenchecken, ob der
   Hintergrund jetzt erscheint, und zur Sicherheit auch auf dem echten
   Desktop-Browser pruefen, ob der Drawer dort (falls er dort ebenfalls
   genutzt wird) nicht unerwuenscht aussieht.
   ---------------------------------------------------------------- */
/* Menue-Drawer-Hintergrund explizit auf #E3F3C6 (nicht die --pv-cream-
   Variable, die an anderer Stelle #f5ffe4 ist - zwei aehnliche, aber
   unterschiedliche Cremetoene). Direkter Hex-Wert, damit es unabhaengig vom
   Variablenwert der gewuenschte Ton bleibt. */
body .menu-drawer {
  --color-background: #E3F3C6 !important;
  background-color: #E3F3C6 !important;
}
/* Trennlinie zwischen Menuepunkten: 1px -> 3px, dunkelgruen. Gilt fuer alle
   Menuepunkte, nicht nur die "|"-Stelle (separater Bug, siehe mobile-
   fixes.js Abschnitt 2). */
body .menu-drawer__menu-item {
  border-block-end: 3px solid var(--pv-green-dark, #143c1f) !important;
}
/* Schrift der Menüpunkte auf die Headline-Schriftart erzwingen (aktuell
   löst --font-accent--family vermutlich auf eine andere Schrift auf - diese
   Variable ist in base.css nirgends definiert, kommt also von außerhalb) */
body .menu-drawer .menu-list__link,
body .menu-drawer__menu-item-text {
  font-family: "co-headline", sans-serif !important;
}


/* ---------------------------------------------------------------- 26. BOXEN-
   KARUSSELL: PADDING, TITEL/BESCHREIBUNG, ZEILEN Das Klick-Routing selbst ist
   in mobile-fixes.js Abschnitt 8 komplett neu gebaut (strikte Allow-List
   statt elementsFromPoint), siehe dort.
   ---------------------------------------------------------------- */
@media screen and (max-width: 749px) {
  /* AB 7.10. (Mobil-Feedback-Batch): links hatte die Section ein Padding,
     rechts keins - dadurch wirkte das ganze Raster schief/asymmetrisch.
     Jetzt beidseitig derselbe, kleinere Wert. */
  #shopify-section-template--31616257655114__product_list_cyt63E [data-testid="resource-list-grid"] {
    padding-left: 0.4em !important; /* war 0.8em */
    padding-right: 0.4em !important; /* war 0 (keine Regel) */
  }
  /* Abstand unterhalb der Karten-Reihe auf 1/3 reduziert (Ausgangswert kommt
     aus der --padding-block-end-mobile-Variable des Theme-Editors, hier fest
     überschrieben - bitte live gegen Ist-Wert prüfen) */
  #shopify-section-template--31616257655114__product_list_cyt63E .section--padding-block-end,
  #shopify-section-template--31616257655114__product_list_cyt63E {
    padding-block-end: calc(var(--padding-block-end-mobile, 32px) / 3) !important;
  }
  /* "Jetzt fuellen"-Buttons nicht mehr links abgeschnitten. overflow:visible
     allein reichte nicht - vermutlich clippt eine weitere Ebene (.product-
     card, meist mit overflow:hidden fuers Bild) mit. Fix: overflow:visible
     eine Ebene hoeher + eigenes margin-left am Button als zusaetzliches Netz. */
  #shopify-section-template--31616257655114__product_list_cyt63E .product-card {
    overflow: visible !important;
  }
  #shopify-section-template--31616257655114__product_list_cyt63E .product-card__content {
    overflow: visible !important;
    padding-inline-start: 4px !important;
  }
  #shopify-section-template--31616257655114__product_list_cyt63E .pv-product-btn {
    margin-left: 4px !important;
  }
  /* AB 26.9., Punkt 12 ("bitte auch bei Preis"): Merle bestätigt - gleiches
     Problem/gleicher Fix wie beim "Jetzt füllen"-Button oben (Preis war
     ebenfalls links abgeschnitten). */
  #shopify-section-template--31616257655114__product_list_cyt63E .price,
  #shopify-section-template--31616257655114__product_list_cyt63E .compare-at-price {
    overflow: visible !important;
  }
  #shopify-section-template--31616257655114__product_list_cyt63E .price {
    margin-left: 4px !important;
  }
  /* KORREKTUR (Round 19): .compare-at-price bekam hier bisher dasselbe
     margin-left:4px wie .price - das war zusaetzlich zum natuerlichen
     Zwischenraum der beiden Preis-Elemente, dadurch der von Merle gemeldete
     zu grosse Abstand ("weiter nach links ran"). .compare-at-price steht
     nicht am linken Kartenrand (dort ist bereits .price), braucht also den
     Clipping-Schutz von oben nicht in der gleichen Groesse - auf 0 gesetzt.
     Die eigentliche Farbe/Groesse/vertikale Ausrichtung dieses Preises wird
     weiter oben in der Datei geregelt (Abschnitt "Box-Produktkarten"). */
  #shopify-section-template--31616257655114__product_list_cyt63E .compare-at-price {
    margin-left: 0px !important;
  }
  /* Overlay-Link gibt Klicks frei (siehe mobile-fixes.js Abschnitt 8: das JS
     wertet jetzt e.target statt elementsFromPoint aus und navigiert bei
     Bild-/Button-Klicks manuell - dafür darf der Link selbst keine Klicks
     mehr abfangen) */
  #shopify-section-template--31616257655114__product_list_cyt63E .product-card__link {
    pointer-events: none !important;
  }
  /* AB 2.10.: die hier vorher stehende eigene clamp:5-Regel entfernt - sie
     traf dieselben <p>-Elemente wie die jetzt einheitliche clamp:4-Regel ganz
     oben in der Datei (Abschnitt "Einzelne Text-Bloecke") und gewann dort
     durch die spaetere Position im Code faelschlich gegen Merles neuen,
     einheitlichen Wert. Es soll nur noch EINE Stelle geben, die den
     Zeilen-Clamp fuer diesen Text bestimmt. */
  /* Pinke Trennlinie unter gekuerztem Fliesstext (::after) ausblenden: war
     als Hover-Hinweis gedacht, auf Touch gibt es aber kein Hover, die Linie
     blieb dauerhaft stehen.
     KORREKTUR 7.10.: genau das war der Bug hinter "beim zweiten Antippen
     (Einklappen) klappt es nicht, die rosa Linie erscheint wieder" - diese
     Regel hatte KEIN "body "-Praefix, die Basis-Regel fuer dieselbe Linie
     weiter oben in der Datei (Abschnitt "Einzelne Text-Bloecke") aber schon
     ("body [class*=...]::after"). Ohne "body" ist diese Regel hier
     spezifitaets-maessig SCHWAECHER als die Basis-Regel, obwohl sie spaeter
     in der Datei steht - Position im Code zaehlt nur bei gleicher
     Spezifitaet. Beim Einklappen (Klasse .pv-desc-expanded wird entfernt)
     verlor diese Regel dadurch gegen die Basis-Regel, die Linie blitzte
     wieder auf. Fix: "body " ergaenzt, jetzt gewinnt sie zuverlaessig. */
  body [class*="text-block--Aa3pheDByY0ViLzV1N__text_rycJiT"]::after {
    display: none !important;
  }
  /* Box-Titel 3% kleiner, Beschreibung 8% kleiner (relativ zur bisherigen
     Section-17-Größe von 125%) */
  #shopify-section-template--31616257655114__product_list_cyt63E .product-card__content p[role="heading"] {
    font-size: 121.25% !important; /* 125% * 0.97 */
  }
  #shopify-section-template--31616257655114__product_list_cyt63E .product-card__content p:not([role="heading"]) {
    font-size: 92% !important;
  }
}
/* AB 2.10.: die Portrait-spezifische clamp:5-Regel, die hier stand, wurde aus
   demselben Grund wie oben entfernt (einheitlicher clamp:4-Wert gewinnt jetzt
   ueberall). */


/* ---------------------------------------------------------------- 27.
   TAGLINE-PILLEN: GROESSE ANPASSEN + FEHLENDE LUECKEN .pv-tagline-row nutzt
   justify-content:space-between - bei umgebrochenen Zeilen zieht das die
   Pillen bis an den Rand auseinander, der gap-Abstand verschwindet dadurch
   optisch. Fix: auf Mobil center statt space-between.
   ---------------------------------------------------------------- */
@media screen and (max-width: 749px) {
  body .pv-tagline-row {
    justify-content: center !important;
    /* KORREKTUR (Round 20): diese Regel steht im Stylesheet NACH Abschnitt 18
       (dort gerade auf 18px/14px erhoeht) und hat dieselbe Spezifitaet -
       gewinnt also und hat den Abstand bisher unbemerkt wieder auf 10px
       zurueckgesetzt. Hier auf denselben neuen Wert synchronisiert, damit
       beide Regeln konsistent bleiben, egal welche zuletzt im Stylesheet
       steht. */
    gap: 18px !important;
    row-gap: 14px !important;
  }
  /* Pillen etwas kompakter, damit sie zuverlässiger in die Zeile passen, ohne
     auf die JS-Messung angewiesen zu sein */
  body .pv-tagline {
    padding: 0.28em 0.6em !important;
    font-size: clamp(0.58rem, 3.3vw, 0.88rem) !important; /* war 0.62rem/3.6vw/0.95rem */
  }
}


/* ---------------------------------------------------------------- 28. STELL-
   DIR-DEINE-BOX: ABSTAND OBERHALB DER SECTION VERKLEINERN Ein Abstands-Div
   nutzt max(20px, calc(var(--spacing-scale) * 100px)) - bei Standard-Scale
   deutlich mehr als 20px auf Mobil. Wird auf Mobil hart auf 20px gekappt.
   ---------------------------------------------------------------- */
@media screen and (max-width: 749px) {
  #shopify-section-template--31616257655114__section_7xGaLq {
    padding-block-start: 20px !important;
  }
  /* Das kappt nur das aeussere Section-Padding. Ein inneres Div (section-
     content-wrapper) bringt sein eigenes padding-block-start von max(20px,
     calc(var(--spacing-scale) * 100px)) mit - das ist der eigentlich
     sichtbare Rand und soll komplett weg (0), das aeussere 20px-Padding
     bleibt bestehen. */
  #shopify-section-template--31616257655114__section_7xGaLq .spacing-style.layout-panel-flex.layout-panel-flex--column.section-content-wrapper.mobile-column {
    padding-block-start: 0 !important;
  }
}


/* ---------------------------------------------------------------- 28b.
   PRODUKT-SLIDES: ALLE BILDER AB DEM 2. RUND (nicht nur exakt Bild 2)
   URSACHE: ganz oben in base.css gibt es eine Rundung nur fuer das 1. Bild
   (:first-of-type) und das 2. Bild (:nth-of-type(2)) - ab dem 3. Foto fehlt
   jede Regel, diese Bilder bleiben eckig. FIX: dieselbe Rundung fuer jedes
   Bild ab dem 2. (":not(:first-of-type)" statt ":nth-of-type(2)"), mit
   !important. Gilt auf Mobil UND Desktop.
   ---------------------------------------------------------------- */
body .product-media-container.media-fit:not(:first-of-type) .product-media {
  transform: scale(0.83) !important;
  transform-origin: center center !important;
  border-radius: 50% !important;
  overflow: hidden !important;
  box-shadow: inset 0 0 40px rgba(0, 0, 0, 0.65) !important;
}
body .product-media-container.media-fit:not(:first-of-type) img {
  border-radius: 0% !important;
}


/* ---------------------------------------------------------------- 29. FAQ-
   BUTTON: KEIN PINK-AUFBLITZEN BEIM VORBEISCROLLEN Der FAQ-Button teilt sich
   vermutlich eine generische Klasse aus dem Scroll-in-View-"Hover" (Abschnitt
   3), die auch andere CTAs behalten sollen. Statt zu raten: gezielte Opt-Out-
   Klasse "pv-no-scroll-hover" im FAQ-Button-Block eintragen, die JS in
   mobile-fixes.js dann ueberspringt.
   ---------------------------------------------------------------- */
body .pv-no-scroll-hover.pv-hover-inview {
  color: inherit !important;
  background-color: inherit !important;
  -webkit-text-stroke-color: inherit !important;
  transform: none !important;
}


/* ---------------------------------------------------------------- 30. ALLE-
   GERICHTE: SCHATTEN-VERSATZ MIT DEM BILD-NUDGE MITZIEHEN Abschnitt 20
   verschob das Produktbild um 6px nach rechts, der Schlagschatten (Abschnitt
   6) zog nicht mit. Hier derselbe Versatz zusaetzlich auf den Schatten, nur
   auf dieser Seite, leicht verkleinert.
   ---------------------------------------------------------------- */
@media screen and (max-width: 749px) {
  #shopify-section-template--31616257720650__main .product-media-container.media-fit:first-of-type::before {
    transform: scale(0.8) translate(-2px, 8px) !important; /* AB 2.10. (zweite Runde): neuer Wert fuer die Alle-Gerichte-Seite; Round 28/27. Batch: 1px nach rechts (war -3px), siehe Sammel-Kommentar bei den anderen beiden Schatten-Stellen */
  }
}


/* ---------------------------------------------------------------- 31.
   GERICHTKOLLEKTIONEN-KARUSSELLS: PINK-PFEILE AUCH BEIM TORTELLONI- KARUSSELL
   (Paritaet zum Gerichte-Karussell) Die Pfeile sind im Original nur bei
   :hover/:focus-within eingeblendet - auf Touch gibt es kein Hover. Fix: bei
   hover:none die Pfeile fuer beide Karussells immer sichtbar. */
@media (hover: none) {
  #shopify-section-template--31616257655114__product_list_WCk8kE slideshow-arrows .slideshow-control,
  #shopify-section-template--31616257655114__product_list_gPQqGm slideshow-arrows .slideshow-control {
    animation: none !important;
    opacity: 1 !important;
    transform: none !important;
  }
  /* Die Pfeile beim Tortelloni-Karussell fehlen trotz identischer Regel wie
     beim funktionierenden Gerichte-Karussell - vermutlich Markup-Unterschied:
     Horizon blendet slideshow-arrows selbst ueber eine "mobile:hidden"-Klasse
     aus, der Elternknoten ist dann display:none, eine Regel auf .slideshow-
     control allein greift nicht. Fix: Elternelement fuer beide Sections hart
     sichtbar gesetzt. */
  #shopify-section-template--31616257655114__product_list_WCk8kE slideshow-arrows,
  #shopify-section-template--31616257655114__product_list_gPQqGm slideshow-arrows {
    display: flex !important;
  }
}
/* Hinweis: gelegentlich falscher erster Slide (rechteckig statt rund) bei
   einem der Karussells konnte in dieser Session nicht live nachgestellt
   werden - falls das weiterhin auftritt, bitte mit Screenshot melden. */

/* ---------------------------------------------------------------- 31c.
   NEU (Round 28/Batch 19): Merle "die kleinen Pfeile in den Slides des
   Produktrasters auf dem Desktop ausblenden" (Screenshot: links/rechts-Pfeil
   links/rechts neben einem Gerichtbild). Betrifft denselben Gerichte- +
   Tortelloni-Karussell-Mechanismus wie Abschnitt 31/31b oben (".slideshow-
   control" in "slideshow-arrows"), hier aber NUR fuer echten Desktop/Maus -
   der Touch-Fall (Abschnitt 31, @media(hover:none)) bleibt bewusst
   unveraendert, da dort die Pfeile erst kuerzlich extra sichtbar gemacht
   wurden (Paritaet Gerichte/Tortelloni) und sie nicht erneut mitgemeldet
   wurden. AUSDRUECKLICHER HINWEIS: unverifiziert (Chrome war beim Schreiben
   nicht verbunden), bitte gegenchecken, ob damit wirklich alle Pfeil-
   Varianten (auch :hover/:focus-within-Einblendung) erfasst sind. */
@media (hover: hover) and (pointer: fine) and (min-width: 750px) {
  #shopify-section-template--31616257655114__product_list_WCk8kE slideshow-arrows,
  #shopify-section-template--31616257655114__product_list_gPQqGm slideshow-arrows {
    display: none !important;
  }
}

/* ---------------------------------------------------------------- 31b.
   TORTELLONI-KARUSSELL: PFEILE FEHLEN AUF DESKTOP Beide Karusselle nutzen
   dieselbe Desktop-Spaltenzahl (--column-count: 5). Gerichte hat 14 Slides ->
   Ueberlauf -> Pfeile korrekt aktiv. Tortelloni hat nur 4 Produkte -> kein
   Ueberlauf -> Pfeile werden von Horizons Logik korrekt deaktiviert, es gibt
   nichts zu scrollen. Kein Anzeige-Bug, sondern ein Layout-Fall. Ein Fix
   ueber weniger Spalten wurde SOFORT ZURUECKGEDREHT: die Tortelloni-Kacheln
   wurden dadurch viel zu gross UND die Pfeile erschienen trotzdem nicht - die
   Theorie war falsch. Regel deaktiviert, --column-count bleibt bei 5. Die
   eigentliche Ursache muss neu untersucht werden.
   ---------------------------------------------------------------- */
@media screen and (min-width: 750px) {
  #shopify-section-template--31616257655114__product_list_gPQqGm .resource-list {
    /* --column-count: 3 !important;  -- ZURÜCKGEDREHT, siehe Kommentar oben */
  }
}


/* ---------------------------------------------------------------- 32. BODY-
   WEITES HORIZONTALES SCROLLEN VERHINDERN Pinch-Zoom bleibt erlaubt - nur das
   versehentliche seitliche Wegziehen der Seite wird unterbunden. GEAENDERT:
   der Header (position:sticky) scrollt jetzt normal mit statt oben zu kleben.
   Ursache: "overflow-x:hidden" auf html/body ist ein bekannter Safari-
   Sonderfall - sobald body ein overflow ungleich "visible" hat, behandelt
   Safari es als eigenen Scroll-Container, wodurch position:sticky bei Kindern
   relativ dazu statt zum Viewport berechnet wird und praktisch nicht mehr
   wirkt. Fix: overflow-x:hidden -> overflow-x:clip (verhindert das Wegziehen
   genauso, erzeugt in Safari aber keinen eigenen Scroll-Container, Support
   seit iOS 16). max-width:100vw bleibt als zweite Absicherung.
   KORREKTUR (Round 28, 48. Batch): Merle meldet "wenn man die eb seite
   gleich quer laedt, der inhalt [laeuft] ueber das div". Root Cause
   (Code-Analyse, siehe auch Abschnitt 80 unten zur "breakpoint gap"):
   diese Regel war nur auf "max-width:749px" gescopt - ein echtes Handy in
   Querformat ist aber meistens 667-926px breit und faellt komplett durch
   dieses Sicherheitsnetz, obwohl genau dort (siehe Abschnitt 9x/Querformat-
   Regeln unten) viel schmalerer Inhalt erzwungen wird, der beim allerersten
   Layout-Pass (vor Anwendung dieser Breiten-Regeln) kurzzeitig breiter sein
   kann als der Viewport. Fix: Media Query um die im Projekt etablierte
   "echtes Handy, unabhaengig von der Breite"-Erkennung erweitert. */
@media screen and (max-width: 749px),
  screen and (orientation: landscape) and (max-height: 500px) {
  html, body {
    overflow-x: clip !important;
    max-width: 100vw !important;
  }
}


/* ----------------------------------------------------------------
   33. PRODUKTSEITE / QUICK-VIEW-POPUP
   ---------------------------------------------------------------- */

/* NEU (Round 28/Batch 14): Merle "die Fraction-Column-Verteilung bei
   schmalerem Browserfenster ist komisch... das Bild muesste 2fr einnehmen
   und der Text 1fr bei diesen schmaleren Fenstern". Root Cause live
   gefunden (Chrome-Grid-Diagnose aller matchenden Regeln): natives Horizon-
   CSS setzt fuer das Quick-View-Popup
   ".product-information__grid.product-information--media-left" bei
   >=1200px "grid-template-columns:2fr 1fr" (Bild groesser) - GENAU im
   dazwischenliegenden "schmaler Desktop"-Bereich (750-1199px) aber nur
   "1fr min(50vw, var(--sidebar-width,480px))", wodurch sich das
   Verhaeltnis umdreht (Bild wird auf ca. 480px/50vw gedeckelt, Text waechst
   frei - live gemessen bei 950px: Bild 276px, Text 400px, also Text
   groesser als Bild). Fix: fuer genau diese Luecke (750-1199px) dieselbe
   2fr:1fr-Aufteilung wie auf echtem Desktop erzwingen. Musste dafuer exakt
   dieselbe Klassenkombination wie die native Regel treffen plus "body"
   davor (hoehere Spezifitaet durch einen zusaetzlichen Elementselektor),
   da eine einfachere Regel (nur ".product-information__grid") gegen die
   native 3-Klassen-Regel verloren hat - live an dieser Fallstricke selbst
   nachgewiesen. Live verifiziert bei 950px: Bild jetzt 389px, Text 195px,
   deutlich bildlastiger, Text bleibt lesbar (Titel bricht in 3 Zeilen um,
   kein Abschneiden). HINWEIS: Merle hatte als Alternative auch "schneller
   auf 1 Spalte umstellen" vorgeschlagen - falls dir das lieber ist, bitte
   melden, das 2fr:1fr-Verhaeltnis ist die von mir gewaehlte Variante. */
@media screen and (min-width: 750px) and (max-width: 1199px) {
  body .quick-view-modal__content .product-information__grid.product-information--media-left {
    grid-template-columns: 2fr 1fr !important;
  }
}

/* NEU (Round 28/Batch 14): defensive Absicherung gegen "Scroll-Chaining" -
   falls der von Merle gemeldete Scroll-Bug (Hover ueber Produktbild scrollt
   "das Textfeld" statt des ganzen Popups) damit zusammenhaengt, dass der
   Scroll beim Erreichen des oberen/unteren Rands des Popups an die
   dahinterliegende Seite durchgereicht wird: overscroll-behavior:contain
   verhindert genau das. UNVERIFIZIERT als Fix fuer das eigentliche
   gemeldete Problem - ich konnte den beschriebenen Bug in meiner Chrome-
   Sandbox bei 700px und 950px trotz mehrerer Versuche (echter Scroll ueber
   dem Bild, Diagnose aller Scroll-Container und Touch-Action-Werte) nicht
   nachstellen: das Popup scrollte bei mir bereits als Ganzes (Bild+Text
   gemeinsam), unabhaengig davon, ob ich ueber Bild oder Text gescrollt
   habe. Diese Regel schadet nicht, loest das Problem aber moeglicherweise
   nicht - bitte Browser/Geraet + ob es am oberen/unteren Rand oder
   mittendrin passiert mitteilen, dann kann ich gezielter suchen. */
body dialog.quick-view-modal {
  overscroll-behavior: contain !important;
}

@media screen and (max-width: 749px) {
  /* Bild soll quadratisch werden und die volle Breite von <slideshow-
     component> ausfuellen (statt fester dvh-Hoehe, die je nach
     Bildschirmhoehe mal zu hoch/niedrig war). aspect-ratio:1/1 + width:100%
     loest das unabhaengig von der Popup-Groesse - die Hoehe folgt automatisch
     der Breite. */
  body .quick-view-modal__content slideshow-slide.qv-active-slide {
    width: 100% !important;
    aspect-ratio: 1 / 1 !important;
    height: auto !important;
    max-height: none !important;
  }
  /* Abstand Titel <-> Galerie verkleinert (war ca. 20px) */
  body .quick-view-modal__content .product-information__grid,
  body .quick-view-modal__content .group-block {
    padding-block: 8px !important;
    gap: 8px !important;
  }
  /* KORREKTUR (Round 28, 47. Batch) direkt im Anschluss: siehe eigene,
     orientation:portrait-gescopte Regel weiter unten im Batch-47-Abschnitt -
     die hier auf 8px belaesst nur den Fallback fuer alte Browser ohne
     orientation-Unterstuetzung, Merles eigentlicher Wunsch (0 statt 8px, nur
     Hochformat) wird dort umgesetzt und gewinnt dank spaeterer Position im
     File bei jedem Hochformat-Breite unter 749px zusaetzlich. */
  /* Ursache: max-width:100vw war der Bug - das ist die gesamte
     Bildschirmbreite, der Dialog selbst aber nur 80vw. Das Content-Div durfte
     dadurch breiter werden als sein Rahmen und lief rechts raus. Muss 100%
     heissen (vom Elternelement), nicht 100vw. Zusaetzlich box-sizing:border-
     box auf den Dialog, damit dessen Padding nicht zur Breite dazuzaehlt. */
  body .quick-view-modal {
    box-sizing: border-box !important;
  }
  body .quick-view-modal__content {
    overflow-x: hidden !important;
    max-width: 100% !important; /* war 100vw - das war der Bug */
    box-sizing: border-box !important;
  }
  /* Weiterer Teil der Ursache: der komplette Inhalt (4. Miniaturbild, Titel-
     Text) wird rechts abgeschnitten - er ist breiter als das Popup,
     overflow-x:hidden schneidet ihn einfach ab. Grund: der Inhalt ist die
     komplette, unveraenderte Produktseiten-HTML (Quick-View-JS kopiert
     #MainContent 1:1 hinein) inkl. einer fuer volle Seitenbreite berechneten
     Innenabstands-Variable. Fix: 1) diese Variable im Popup hart auf einen
     kleinen Wert setzen, 2) alle Nachkommen im Popup hart auf max-width:100%
     begrenzen + Woerter notfalls umbrechen statt abschneiden. */
  body .quick-view-modal__content,
  body .quick-view-modal__content media-gallery,
  body .quick-view-modal__content .product-information__media {
    --padding-inline-start: 8px !important;
    --padding-inline-end: 8px !important;
  }
  body .quick-view-modal__content * {
    max-width: 100% !important;
    box-sizing: border-box !important;
  }
  body .quick-view-modal__content h1,
  body .quick-view-modal__content h2,
  body .quick-view-modal__content h3,
  body .quick-view-modal__content .view-product-title {
    overflow-wrap: break-word !important;
    word-break: break-word !important;
  }
  /* Miniaturbild-Leiste scrollbar machen - laut Referenzdoku steckt die
     eigentliche Scroll-Leiste in einem zusätzlichen Wrapper (scroll-
     hint.slideshow-controls__thumbnails-container), daher hier
     sicherheitshalber auf mehreren Ebenen gleichzeitig. */
  body .quick-view-modal__content .slideshow-controls__thumbnails,
  body .quick-view-modal__content .slideshow-controls__thumbnails-container,
  body .quick-view-modal__content scroll-hint {
    overflow-x: auto !important;
    -webkit-overflow-scrolling: touch !important;
    max-width: 100% !important;
  }
  /* Bei Gerichten mit vielen Bildern (4 Miniaturen) werden diese weiterhin
     abgeschnitten und das Produkt-Div verrutscht rechts raus. Diagnose: das
     ist das <slideshow-controls>-Element selbst, nicht nur dessen innere
     Klassen (die die Regeln oben erfassen). Zwei Teile fehlten: 1)
     <slideshow-controls> (und Flex-/Grid-Vorfahren) brauchen min-width:0 -
     sonst verhindert der Flex-Default min-width:auto das Schrumpfen und
     drueckt den Eltern-Container breiter als das Popup. 2) <slideshow-
     controls> muss selbst die scrollbare Box sein, sonst bleibt seine Breite
     durch die Summe aller Miniaturen bestimmt. */
  body .quick-view-modal__content slideshow-controls {
    display: block !important;
    min-width: 0 !important;
    max-width: 100% !important;
    width: 100% !important;
    overflow-x: auto !important;
    -webkit-overflow-scrolling: touch !important;
  }
  body .quick-view-modal__content media-gallery,
  body .quick-view-modal__content .product-information__media,
  body .quick-view-modal__content .product-information__grid,
  body .quick-view-modal__content .group-block {
    min-width: 0 !important;
  }
}
/* Bio-/Pflanzlich-Siegel auf der Produktseite stapeln. WIRKLICHE URSACHE
   (Computed-Styles bestaetigt): nicht flex-wrap, sondern flex-direction! Der
   Elternteil traegt die generische Klasse ".mobile-column" (siteweite Theme-
   Utility), die "flex-direction:column" gegen die gewuenschte "--row"
   durchsetzt - Flex-Kinder stapeln sich bei column immer, unabhaengig von
   flex-wrap. Fix ohne den unbekannten Elternklassennamen zu brauchen: :has()
   waehlt den direkten Elternteil aus. */
@media screen and (max-width: 749px) {
  body *:has(> .image-block--AK3Q5M2xnWEc0ZFAvW__image_LPpgVz) {
    flex-direction: row !important; /* DER eigentliche Fix - war column */
    flex-wrap: nowrap !important;
    --flex-wrap-mobile: nowrap !important;
    /* Fallback, falls der Elternteil kein Flexbox, sondern ein Grid ist (dann
       greift flex-direction/-wrap gar nicht) - erzwingt zwei Spalten
       nebeneinander statt untereinander. */
    grid-template-columns: repeat(2, 1fr) !important;
    grid-auto-flow: column !important;
    /* AB 26.9. (2. Runde): Merle bestätigt - Siegel sind jetzt nebeneinander,
       floaten aber links, sollen rechts sein. Rechtsbündig für Flex- (Haupt-
       achse) UND Grid-Fall (justify-items greift bei Grid). */
    justify-content: flex-end !important;
    justify-items: end !important;
  }
  /* Zusaetzliches Sicherheitsnetz: falls es kein Umbruch-, sondern ein
     Breiten-Problem ist - Bildbreite hart auf knapp die Haelfte begrenzt,
     damit rechnerisch immer Platz fuer ein zweites Siegel bleibt, plus flex-
     shrink:0. */
  body .image-block--AK3Q5M2xnWEc0ZFAvW__image_LPpgVz {
    max-width: 46% !important;
    flex-shrink: 0 !important;
  }
}
/* Falls es danach immer noch stapelt, bitte kurz Bescheid - dann ist es
   vermutlich kein flex-wrap-Problem, sondern die Bilder selbst sind zu breit
   fuer eine gemeinsame Zeile (dann brauche ich stattdessen die Klasse des
   zweiten Siegel-Bilds, um beide zu verkleinern). */

/* Auf den Produkt-POPUP-Seiten sollen die Siegel nicht rechtsbuendig sein -
   anders als auf der echten Produktseite (Regel direkt oberhalb, justify-
   content:flex-end). Da beide Kontexte denselben Baustein teilen, hier eine
   auf den Popup-Dialog beschraenkte Override-Regel (hoehere Spezifitaet), nur
   dort auf zentriert umgestellt. */
@media screen and (max-width: 749px) {
  body dialog.quick-view-modal *:has(> .image-block--AK3Q5M2xnWEc0ZFAvW__image_LPpgVz) {
    justify-content: center !important;
    justify-items: center !important;
  }
}

/* "Jetzt meine Box zusammenstellen"-Button: dieser Punkt konnte nicht
   zugeordnet werden ("welchen Button, auf welcher Seite?") - vermutlich ein
   Missverstaendnis. Fix bewusst entfernt statt auf gut Glueck auf .pv-button
   --thin angewendet (haette sonst z.B. den Footer-Button betroffen). Falls
   doch gemeint, bitte Seite + Screenshot schicken. */


/* ----------------------------------------------------------------
   34. EASY BUNDLES: PADDING, RÄNDER, AUSWAHL-STYLING, BILDER
   ---------------------------------------------------------------- */
@media screen and (max-width: 749px) {
  /* Innenabstand links/rechts reduziert (war 1em) */
  body .gbbBundleBody {
    padding-left: 0.4em !important;
    padding-right: 0.4em !important;
  }
  /* Kategorie-Kopf volle Breite + Rahmen durchgezogen + halbiert (war 4px) */
  body .gbbCategoriesHeaderContainer {
    width: 100% !important;
    margin-inline: 0 !important;
    border-bottom: 2px solid var(--pv-green-dark, #143c1f) !important;
  }
  /* Kategorie-Tabs: kein Innenabstand rechts (damit der letzte Tab nicht
     unnötig eingerückt wirkt). AB 26.9.: padding-left (der "Scroll-Hinweis
     links") auf Merles Wunsch wieder entfernt - trug zum zu großen Abstand
     zwischen Box-Auswahl und Kategorien-Bereich bei (Punkt 19/20). */
  body .gbbCategoriesTabsContainer {
    padding-right: 0 !important;
  }
  /* Abstand der einzelnen Kategorie-Tabs nach oben halbiert (Original:
     margin-top: 2em, siehe Zeile ~1045 im Original-CSS) - trägt ebenfalls zum
     zu großen Abstand oberhalb der Box-Auswahl bei. */
  body .gbbCategoryTabContainer {
    margin-top: 1em !important;
  }
  /* Abstand zwischen Kategorie-Kopf und Box-Auswahl verkleinert. Struktur
     bestaetigt: .gbbCategoriesContainer und .gbbBundleFooter sind direkte
     Geschwister-Kinder von .gbbBundleBody (CSS-Grid) - der Abstand ist also
     genau dieser gap-Wert, kein Ratefix mehr. */
  body .gbbBundleBody {
    gap: 6px !important;
    row-gap: 6px !important;
  }
  /* Ausklapp-Button (Menge + Chevron) im Bundle-Wagen nach oben:
     .gbbCartIconWithQuantityContainer ist ein Grid-Kind von .gbbBundleFooter,
     steht in der Dokumentreihenfolge nach den anderen beiden Kindern und
     sitzt dadurch visuell unten. `order` verschiebt es rein optisch nach
     oben, ohne DOM oder Drawer-Mechanismus anzufassen. */
  body .gbbCartIconWithQuantityContainer {
    order: -1 !important;
  }
  /* Ausgewählte Box-Auswahl (Probier-/Single-/Family-Box). KORREKTUR (Round
     26, 5. Batch, "zu bunt"-Rückmeldung): die Pink-/Magenta-Farbe (Planet-
     Shadow, erst in Batch 4 eingeführt) wieder zurückgenommen - Merle möchte
     jetzt denselben ruhigen, "minimal dunkleres Grün + zarte dunkle Kontur"-
     Look wie die ausgewählten Produktkarten/Kategorie-Tabs (vereinheitlicht
     über das ganze Widget). Siehe auch die unscoped Version direkt nach
     diesem Media-Query-Block, die dasselbe für den Desktop-Sidebar-Fall
     abdeckt. */
  body .gbbBoxSelectionItem[aria-pressed="true"],
  body .gbbBoxSelectionItem[data-is-active="true"] {
    background-color: #d9edbe !important;
    border: 1.5px solid #748c7b !important;
  }
  /* Überschrift + Untertext der Box-Auswahl mittig statt linksbündig */
  body .gbbBoxSelectionHeading,
  body .gbbBoxSelectionSubtext {
    text-align: center !important;
    width: 100% !important;
  }
  /* Abstand Produkttitel <-> Bild weiter verkleinert (war bereits auf
     0.2em reduziert, siehe Abschnitt 14d) */
  body .gbbProductTitleOnly {
    padding-top: 0.05em !important;
  }
  /* Preis wieder sichtbar (30.9.) - vorher hier komplett ausgeblendet, um
     die Luecke zum Beilagen-Text zu schliessen. Fuer jetzt erstmal nur
     wieder eingeblendet, Feinschliff (Abstand/Groesse) folgt. */
  body .gbbProductPricesContainer {
    display: flex !important;
  }
  /* Produktbilder, die aus dem runden Rahmen ausbrechen: die vollstaendige
     Ursache + der Fix (feste Bildgroesse + Grid-Row-Korrektur) sind jetzt in
     Abschnitt 36 gebuendelt (fixe 150px-Grid-Row im Easy-Bundles-Stylesheet
     gefunden). Die alte, schwaechere Regel hier wurde dorthin verschoben,
     damit es nur eine aktuelle Quelle gibt. */
}
/* Beide oben offenen Punkte (Gap-Ursache + Cart-Icon-Reposition) sind seit
   26.9. mit den echten DOM-Klassen von Merle umgesetzt, siehe Kommentare oben
   im @media-Block. */

/* ---------------------------------------------------------------- 34b. BOX-
   AUSWAHL (.gbbBoxSelectionItem): AUSGEWAEHLT/NICHT AUSGEWAEHLT WIE DIE
   PRODUKTKACHELN STYLEN, AUCH AUF DESKTOP (Round 26, 4. Feedback-Batch).
   KORREKTUR (Round 26, 5. Feedback-Batch, "zu bunt"-Rueckmeldung): die in
   Batch 4 eingefuehrte Planet-Shadow-Pink-Farbe wieder zurueckgenommen.
   Ausgewaehlt jetzt: derselbe "minimal dunkleres Gruen (#d9edbe) + zarte
   dunkle Kontur (#748c7b, 1.5px)"-Look wie die ausgewaehlten Produktkarten
   und die aktiven Kategorie-Tabs - ein EINHEITLICHER "ausgewaehlt"-Look im
   ganzen Widget statt verschiedener Farben je Element. Nicht ausgewaehlt:
   unveraendert sehr hellgruen + weisse Kontur + dunkle Schrift - live an
   einer unausgewaehlten Produktkachel gemessen (Bio Zucchino Ragout, volle
   Desktop-Breite): background rgb(227,243,198) = #e3f3c6, outline
   rgb(241,242,243) 2px solid ~ #f1f2f3 (fast weiss), Textfarbe rgb(9,47,1) =
   #092f01. Diese exakten, live gemessenen Werte hier 1:1 uebernommen, damit
   beide Kachel-Typen wirklich identisch wirken. */
/* ALT (Backup, Round 26, 5. Batch): Hintergrund #d9edbe.
   NEU (Round 27, 3. Batch): Merle "#d8eeb9 soll die Hintergrundfarbe sein" -
   minimaler Farbton-Unterschied zum bisherigen Wert, 1:1 wie gewuenscht
   uebernommen. */
body .gbbBoxSelectionItem[aria-pressed="true"],
body .gbbBoxSelectionItem[data-is-active="true"] {
  background-color: #d8eeb9 !important;
  border: 1.5px solid #748c7b !important;
}
/* ALT (Backup, Round 26, 5./6. Batch - hellgruener Hintergrund + dunkle
   Schrift + fast-weisse Kontur, identisch zu den unausgewaehlten
   Produktkacheln):
body .gbbBoxSelectionItem[aria-pressed="false"],
body .gbbBoxSelectionItem[data-is-active="false"] {
  background-color: #f4ffdb !important;
  border: 2px solid #f1f2f3 !important;
  color: #092f01 !important;
}
body .gbbBoxSelectionItem[aria-pressed="false"] .gbbBoxSelectionHeading,
body .gbbBoxSelectionItem[aria-pressed="false"] .gbbBoxSelectionSubtext,
body .gbbBoxSelectionItem[data-is-active="false"] .gbbBoxSelectionHeading,
body .gbbBoxSelectionItem[data-is-active="false"] .gbbBoxSelectionSubtext {
  color: #092f01 !important;
}
*/
/* NEU (Round 27, 3. Batch): Merle "bei den NICHT ausgewaehlten
   gbbBoxSelectionItems die Farben umkehren - helle Schrift, dunkelgruener
   Hintergrund, helle Kontur". Bewusste Umkehr des bisherigen "hell mit
   dunkler Schrift"-Looks nur fuer die UNAUSGEWAEHLTEN Kacheln (der
   AUSGEWAEHLTE Look direkt oberhalb bleibt unveraendert hell). Farben
   wiederverwendet aus dem bereits etablierten "hell auf dunkelgruen"-Paar
   dieses Batches (Hero-Button-Hover, siehe dort): #143c1f (= --pv-green-dark)
   als Hintergrund, #ddffbb als Schrift/Kontur. */
/* KORREKTUR (Round 27, 7. Feedback-Batch): Merle "hat immer noch die
   falsche background Farbe. bitte einfach den background auf none setzen!"
   - das war der eigentliche, bisher uebersehene Root Cause fuer die
   wiederholten Rueckmeldungen zur falschen Box-Auswahl-Hintergrundfarbe
   (Batch 5/6): diese HIER gesetzte dunkelgruene background-color (aus
   Round 27, 3. Batch, noch vor der #e5f6cc/Cart-Variablen-Debatte) stand
   weiterhin im Code und gewann, weil Abschnitt 67 weiter unten (die
   spaetere border/outline-Regel) gar kein eigenes background-color gesetzt
   hatte. Jetzt direkt hier beseitigt statt an anderer Stelle zu
   ueberschreiben, um genau diese Art von "zwei Regeln, selber Selektor"-
   Falle nicht zu wiederholen. ALT (Backup): background-color: var(--pv-
   green-dark, #143c1f) !important; */
/* KORREKTUR (9.10., Round 27 Batch 13): Merle meldet (erneut Batch-10-Punkt
   17, "Wichtig!") "Hintergrundfarbe der Selection-Boxes fehlt, Schrift
   wirkt giftgrün statt dunkelgrün". Root Cause: "background:none" oben war
   Round 27 Batch 7 Merles eigene, damals richtige Anweisung ("einfach den
   background auf none setzen") - gedacht als Korrektur zu einem falschen
   DUNKLEN Hintergrund. Seitdem hat sich aber auch der Seitenhintergrund
   geaendert (jetzt hell, #e9f6d7, siehe Abschnitt "EB-Seite Hintergrundfarbe"
   weiter unten) - ohne eigenen Hintergrund UND mit hellem Text (#ddffbb)
   verschwindet die Kachel fast komplett im jetzt ebenfalls hellen
   Seitenhintergrund (das "giftgrün" ist vermutlich der helle Text ohne
   dunklen Kontrast dahinter). Fix: wieder ein eigener (heller, aber vom
   Seitenhintergrund unterscheidbarer) Hintergrund + dunkelgruene Schrift -
   analog zum bereits bestehenden "hell mit dunkler Schrift"-Look der
   AUSGEWAEHLTEN Kachel direkt oberhalb, nur in einem noch helleren Ton,
   damit der Unterschied ausgewaehlt/nicht ausgewaehlt sichtbar bleibt.
   JUDGEMENT CALL: das kehrt Merles eigene Batch-3/7-Entscheidung
   ("helle Schrift auf dunklem Hintergrund" bzw. "background:none") wieder
   um - auf Basis ihrer aktuellen, expliziten Rueckmeldung, nicht geraten.
   Bitte bestaetigen, ob das jetzt wieder passt. */
/* KORREKTUR (Round 28/Batch 14): Merle "der Background von den nicht
   ausgewaehlten Boxen sollte doch so dunkelgruen sein wie der Cart Drawer"
   (Screenshot: das dunkelgruene Panel, in dem die Box zusammengestellt
   wird). Live nachgemessen: dieses Panel ist ".gbbBundleFooter" mit
   background-color rgb(9,47,1) = #092f01 (NICHT identisch mit --pv-green-
   dark/#143c1f, extra nachgemessen statt geraten) - der Ueberschriften-Text
   darauf ("Probier-Box" etc.) nutzt #e3f3c6, dieselbe helle Creme-Farbe wie
   die Tagline-Headline. Fix: unausgewaehlte Kacheln auf exakt diese beiden
   Farben umgestellt (dunkler Hintergrund #092f01 + helle Schrift #e3f3c6),
   damit sie optisch mit dem Panel verschmelzen statt als helle Flecken
   herauszustechen. Randfarbe ebenfalls auf die helle Creme-Farbe (etwas
   gedaempft) gesetzt, damit die Kachel auf dem gleichfarbigen Hintergrund
   trotzdem als eigene Flaeche erkennbar bleibt.
   ARCHIVIERT (Round 28, 28. Batch): diese unscoped Regel wurde durch Batch
   21/24 (Abschnitt 67b, weiter unten) und jetzt final durch Abschnitt 67c
   (ganz am Ende der Datei, DOM-basiert statt Breite-basiert) ersetzt - nur
   noch EIN aktueller Satz Regeln fuer .gbbBoxSelectionItem[...="false"],
   siehe dort. Auskommentiert statt geloescht, History bleibt nachvollziehbar.
body .gbbBoxSelectionItem[aria-pressed="false"],
body .gbbBoxSelectionItem[data-is-active="false"] {
  background-color: #092f01 !important;
  border: 2px solid rgba(227, 243, 198, 0.4) !important;
  color: #e3f3c6 !important;
}
body .gbbBoxSelectionItem[aria-pressed="false"] .gbbBoxSelectionHeading,
body .gbbBoxSelectionItem[aria-pressed="false"] .gbbBoxSelectionSubtext,
body .gbbBoxSelectionItem[data-is-active="false"] .gbbBoxSelectionHeading,
body .gbbBoxSelectionItem[data-is-active="false"] .gbbBoxSelectionSubtext {
  color: #e3f3c6 !important;
}
*/
/* .gbbProductTitleOnly (Produkttitel-Unterstrich): war bisher nativ
   var(--gbb-discount-pill-bg-color-mobile, per Merles eigenem DevTools-
   Fund), dann unconditional dunkelgruen (Round 26). NEU (Round 27, 8. Batch):
   Merle "an die Outline der jeweiligen Produktkarte anpassen - weiss bei
   unausgewaehlt, dunkelgruen bei ausgewaehlt". Live gemessen: Outline der
   Karte ist weiss (#ffffff) im Normalzustand und #748c7b sobald
   ".gbbQuantityStepper" existiert (= ausgewaehlt, siehe Regel weiter unten in
   dieser Datei) - dieselbe ":has(.gbbQuantityStepper)"-Bedingung hier fuer
   die Unterstrich-Farbe wiederverwendet. Merle wollte explizit "dunkelgruen"
   (unser --pv-green-dark), nicht den etwas blasseren Outline-Ton #748c7b -
   deshalb fuer den ausgewaehlten Zustand bewusst --pv-green-dark behalten,
   nicht 1:1 auf #748c7b umgestellt. */
body .gbbProductTitleOnly {
  border-bottom-color: #ffffff !important;
}
body .gbbProductItem:has(.gbbQuantityStepper) .gbbProductTitleOnly {
  border-bottom-color: var(--pv-green-dark, #143c1f) !important;
}

/* NEU (Round 26, 5. Feedback-Batch, "zu bunt"-Rueckmeldung): Produktkarten
   (Gerichte) OHNE Auswahl bekommen keinen eigenen Hintergrund mehr (live
   gemessen: war #e3f3c6) - Merles Wunsch "Hintergrund weg oder in der
   selben Farbe wie der Hintergrund". transparent gewaehlt statt eines
   geratenen Seiten-Hintergrund-Hex-Werts - das erfuellt beide genannten
   Varianten gleichzeitig (zeigt automatisch die jeweils dahinterliegende
   Farbe durch). Die ausgewaehlte Karte direkt darunter (hoehere Spezifitaet
   durch :has()) bleibt davon unberuehrt. */
body .gbbProductItem {
  background-color: transparent !important;
  /* NEU (Round 27, 6. Feedback-Batch): "die Outline von den nicht
     ausgewaehlten Produktkacheln muss weiss sein". Live gemessen: war
     #f1f2f3 (fast-aber-nicht-ganz weiss, nativer Default). Bewusst UNSCOPED
     (kein :has()-Ausschluss) - live getestet und bestaetigt, dass die
     ausgewaehlte Karte (Regel direkt darunter, hoehere Spezifitaet durch
     :has()) davon unberuehrt bleibt. */
  outline-color: #ffffff !important;
}
/* NEU (Round 26, 5. Feedback-Batch): ausgewaehlte Produktkarte (ein Gericht
   wurde in die Box gelegt, Easy Bundles zeigt dann einen Mengen-Steller
   statt des "in meine Box"-Buttons) - exakt Merles eigener, per Safari-
   Inspector getesteter Wert (Screenshot: outline 1.5px solid #748c7b +
   background-color #d9edbe). Bewusst UNSCOPED (keine Media Query), damit
   die Kontur auf Mobil garantiert genauso dick bleibt wie auf Desktop -
   Merles Hinweis "auf Mobil die Border nicht duenner". */
body .gbbProductItem:has(.gbbQuantityStepper) {
  background-color: #d9edbe !important;
  outline: 1.5px solid #748c7b !important;
}


/* ---------------------------------------------------------------- 36. EASY
   BUNDLES: PRODUKTBILDER-GROESSE FEST (GEGEN DAS AUSBRECHEN AUS DEM RUNDEN
   RAHMEN) Ursache (Grid-Overlay im Inspector): eine fixe Grid-Row-Hoehe im
   Easy-Bundles-eigenen Stylesheet (side-footer-bundle.min.css, @media max-
   width:768px): ".gbbProductItem:has(.gbbProductActionWithContent) { grid-
   template-rows: 150px auto 60px; }". Bei ca. 109px Spaltenbreite dehnt CSS-
   Grid (stretch) den Bildcontainer auf 109x150px - ein Rechteck statt
   Quadrat, unsere aspect-ratio:1/1-Regel wird dabei ueberstimmt, weil beide
   Dimensionen bereits "definit" sind - erklaert die ovalen Bilder bei manchen
   Gerichten. FIX: erste Zeile (Bild) von fix 150px auf auto + dem
   Bildcontainer eine feste, fuer alle Gerichte identische Groesse geben,
   damit Zeile 1 automatisch ueberall gleich hoch wird, unabhaengig von der
   Titellaenge. Breakpoint bewusst 768px (statt 749px), um exakt den Bereich
   der App-eigenen Regel abzudecken. 78px ist ein Schaetzwert - der einzige
   Wert, der ggf. nachjustiert werden muss.
   ---------------------------------------------------------------- */
@media screen and (max-width: 768px) {
  /* Weiterhin "untere Sektion mit dem Knopf zu hoch" - Zeile 3 (Button) war
     noch fest auf 60px, mehr als noetig. Konsequent umgesetzt: auch Zeile 3
     jetzt auto (alle Zeilen ausser dem Bild flexibel). */
  body .gbbProductItem:has(.gbbProductActionWithContent) {
    grid-template-rows: auto auto auto !important; /* war auto auto 60px */
  }
  /* KORREKTUR (Round 26, 4. Feedback-Batch): Merle hat selbst per Safari-
     Inspector nachgewiesen, dass das "overflow:hidden" hier genau das ist,
     was den before-Schatten (Abschnitt "Easy Bundles Mix & Match" ganz oben,
     .gbbProductImageContainer::before) UND den drop-shadow-Filter auf
     .gbbProductImage abschneidet - auf Desktop gibt es diese Zeile nicht,
     deshalb sieht der Schatten dort korrekt aus. Sie hat testweise overflow:
     hidden entfernt und width/height auf eine prozentuale Breite (90%) +
     aspect-ratio:1/1 + top:-2px umgestellt (genau das war schon lange als
     Plan in claude/eb-redesign-mockup-notiz.md notiert, nur noch nicht
     umgesetzt) - das sah bei ihr gut aus, hier 1:1 uebernommen. Die alte,
     feste 78px-Groesse war urspruenglich gegen eine App-eigene fixe Grid-Row-
     Hoehe gedacht (siehe Abschnitt 36 oben, inzwischen selbst laengst auf
     "auto" gefixt) - das war also schon vorher nicht mehr noetig.
     Der before-Schatten selbst blieb bei ihrem Test trotz entferntem
     overflow:hidden weiterhin unsichtbar (nur der Filter-Schatten auf dem
     Bild wurde sichtbar) - sehr wahrscheinlich, weil der Schatten als
     ::before mit z-index:-1 auf dem Container selbst sitzt und dadurch
     potenziell hinter einem GESCHWISTER-Element (z.B. der Karten-Hintergrund)
     verschwindet, waehrend der Filter (gehoert zum Bild-Element selbst, kein
     eigener Stacking-Kontext noetig) das nicht betrifft. Merles eigener
     Vorschlag als Fallback: den Filter stattdessen so stylen wie der
     before-Schatten aussehen sollte (harte Kante, Header-Color) - genau das
     hier umgesetzt, der ::before-Mechanismus bleibt fuers Erste unangetastet
     (Mobil hat dadurch jetzt EINEN sichtbaren Schatten ueber den Filter,
     auch wenn er technisch anders erzeugt wird als auf Desktop). */
  body .gbbProductImageContainer {
    width: 90% !important;
    justify-self: center !important;
    align-self: start !important;
    top: -2px !important;
    overflow: visible !important; /* war hidden - schnitt den Schatten ab */
    border-radius: 50% !important;
    aspect-ratio: 1 / 1 !important;
  }
  body .gbbProductImage {
    width: 100% !important;
    height: 100% !important;
    object-fit: cover !important;
    object-position: center !important;
    /* KORREKTUR (Round 28/Batch 16): Merle nennt im "Mobilfeedback Hoch"-
       Paket (Punkt 19) fuer den EB-Schatten "scale(.96) translate(-3px,6px)"
       und bestaetigt auf Nachfrage "meine Werte uebernehmen" - das passt
       aber technisch nicht 1:1: der EB-Schatten ist (siehe Kommentar oben)
       bewusst NICHT mehr der ::before-Mechanismus mit transform:scale/
       translate (der war hier unsichtbar, siehe Round-26-Batch-4-Fund),
       sondern ein drop-shadow()-Filter auf dem Bild selbst - der kennt kein
       "scale", nur einen x/y-Versatz. Den Y-Versatz als naechstliegende
       Entsprechung von 5px auf ihre 6px angepasst; "scale" kann hier nicht
       uebernommen werden. Bitte bei Gelegenheit bestaetigen, ob der
       Y-Versatz so passt, oder ob am Filter (Unschaerfe/Groesse) noch etwas
       anderes angepasst werden soll.
       KORREKTUR (Round 28/Batch 18): Merle meldet erneut "der Dropshadow
       fehlt, nur ein paar px Versatz und 1-2px Groesse" - der X/Y-Versatz
       (-3px/6px) ist bereits exakt wie gewuenscht gesetzt (siehe oben), NEU
       ergaenzt ist die Unschaerfe/"Groesse" (3. drop-shadow-Parameter, war
       0px) auf 1.5px - als Mittelwert von "1 oder 2px". AUSDRUECKLICHER
       HINWEIS: ich konnte im Code keinen Grund finden, warum der Schatten
       komplett fehlen sollte (keine spaetere Regel setzt filter:none oder
       ueberschreibt ihn) - vermute denselben Cache-Effekt wie bei anderen
       "ist doch laengst im Code"-Meldungen in dieser Datei, bitte nach dem
       Einspielen dieser Datei in einem Inkognito-Fenster gegenchecken.
       KORREKTUR (Round 28, 28. Batch): Merle fragt erneut nach dem "Ursprung"
       dieses Schattens und nennt gleichzeitig einen neuen Zielwert fuer
       ".gbbProductImageContainer::before" (scale(0.98) translate(-5px, 6px)).
       WICHTIGER HINWEIS, bitte lesen: dieser Schatten HIER (der filter auf
       .gbbProductImage) ist seit Batch 16 genau DESHALB die aktive/sichtbare
       Quelle, WEIL das eigentliche ::before (Abschnitt ganz oben, "Easy
       Bundles Mix & Match") auf Mobil nachweislich unsichtbar ist (Merles
       eigener Safari-Inspector-Test, Kommentar oben) - es gibt also aktuell
       KEINEN separaten, zusaetzlichen, ungeklaerten Schatten, sondern genau
       diesen hier, nur eben per filter statt per ::before erzeugt. Da
       "scale" bei einem Filter-Schatten nicht existiert, habe ich nur den
       Versatz auf ihren neuen Wert (-5px/6px) uebernommen; die Unschaerfe
       bleibt bei 1.5px. Das ::before selbst wurde zusaetzlich unten (eigener
       Abschnitt) ebenfalls auf ihren neuen Wert gesetzt, falls es doch
       sichtbar sein sollte oder spaeter sichtbar wird - bitte live
       gegenchecken, ob der Y/X-Versatz jetzt passt. */
    /* KORREKTUR (Round 28, 31. Batch): Merle "der Schatten ist irgendwie
       blurry, er muss scharf sein und 2-3px weiter nach rechts" - "weiter
       nach rechts" heisst X-Versatz weniger negativ (war -5px, jetzt -2.5px,
       Mittelwert der genannten 2-3px-Verschiebung nach rechts - bitte live
       gegenchecken, ob 2 oder 3px genauer passt). "Scharf" = Unschaerfe-
       Parameter (3. Wert) von 1.5px auf 0px (kein Blur mehr). Y-Versatz
       (6px) unveraendert, da nicht erwaehnt. */
    filter: drop-shadow(-2.5px 6px 0px var(--header-color)) !important;
  }
}

/* ---------------------------------------------------------------- 36c.
   EASY BUNDLES: .gbbProductImageContainer::before NEUER ZIELWERT AUF HANDY
   HOCH (Round 28, 28. Batch). Siehe ausfuehrlichen Hinweis in Abschnitt 36
   direkt oberhalb: dieses ::before ist auf Mobil laut Merles eigenem,
   bereits dokumentiertem Test unsichtbar (verschwindet hinter einem
   Geschwister-Element) - der tatsaechlich sichtbare Schatten auf Mobil ist
   der filter auf .gbbProductImage (ebenfalls oben aktualisiert). Dieser Wert
   hier wird trotzdem wie gewuenscht gesetzt (schadet nicht, falls sich die
   Sichtbarkeit doch je aendert), macht aber aktuell vermutlich KEINEN
   sichtbaren Unterschied - bitte beim Gegenchecken daran denken, sonst
   wirkt es wie ein weiterer "Fix greift nicht"-Fall, obwohl die Ursache
   schon lange bekannt ist. */
@media screen and (max-width: 1199px) and (orientation: portrait) {
  body .gbbProductImageContainer::before {
    transform: scale(0.98) translate(-5px, 6px) !important;
  }
}

/* ---------------------------------------------------------------- 36b. EASY
   BUNDLES: PRODUKTKACHELN-GRID-ROWS AUCH AUF DESKTOP Derselbe Effekt wie in
   Abschnitt 36 zeigt sich auch oberhalb von 768px: die erste Grid-Row (Bild)
   bleibt zu gross/gestreckt, erzeugt unnoetig Leerraum zwischen Text und
   Button. Bisher war der Fix bewusst auf max-width:768px beschraenkt - hier
   derselbe Fix, gespiegelt fuer ab 769px. Kein Eingriff in die 78px-
   Bildgroesse (Mobil-spezifisch), nur die Grid-Row-Hoehe.
   ---------------------------------------------------------------- */
@media screen and (min-width: 769px) {
  body .gbbProductItem:has(.gbbProductActionWithContent) {
    grid-template-rows: auto auto auto !important;
  }
}


/* ---------------------------------------------------------------- 37. EASY
   BUNDLES WAGEN: AUSGEWAEHLTE-GERICHTE-SLOTS Die App-eigene Regel
   (.gbbProductSlotsContainer, fixe 75px-Spalten via repeat(auto-
   fit,minmax(75px,75px))) laesst je nach Wagenbreite nicht zuverlaessig 6
   Slots nebeneinander passen, Bilder brechen aus ihrem Slot aus. FIX:
   Spaltenzahl fest auf 6 ("1fr" teilt die verfuegbare Breite immer exakt
   durch 6, robuster als fixer px-Wert). Gap auf 7px (war 6px). Jedes Slot-
   Bild zusaetzlich hart auf ein Quadrat seiner Zelle begrenzt
   (overflow:hidden + object-fit:cover).
   ERWEITERT (Round 28, 31. Batch): Merle meldet fuer Handy-QUER "die
   gbbProductSlotsContainer sind extrem hoch gezogen, muessen quadratisch
   bleiben" - genau dasselbe Problem, das diese Regel bereits fuer
   Hochformat loest, nur dass "max-width:749px" echtes Handy-Querformat NICHT
   abdeckt (reale Handy-Quer-Breiten liegen oft ueber 749px, z.B. iPhone 14
   quer ca. 844px - dieselbe Art Breakpoint-Luecke wie beim Hero-Logo weiter
   oben in dieser Datei). Fix: zusaetzlich fuer "width>=750 UND height<=500"
   (das etablierte Handy-Quer-Muster dieser Datei) aktiviert.
   NACHTRAG (Round 28, 33. Batch): Merle meldet "Produktslots immer noch
   nicht quadratisch" - live am echten, befuellten Warenkorb nachgemessen
   (900x287-Testfenster, echtes Handy-Quer-Breiten/Hoehen-Verhaeltnis): das
   stimmte, ".gbbProductSlotContainer" war 47.98px breit, aber 70px hoch,
   obwohl "aspect-ratio:1/1" bereits computed korrekt "1/1" anzeigte. Root
   Cause: EB setzt auf dem umgebenden Grid ("gbbProductSlotsContainer")
   selbst eine explizite Zeilenhoehe ("grid-template-rows:70px 70px",
   vermutlich per eigenem JS berechnet, nicht in unserer CSS sichtbar/
   aenderbar wegen Cross-Origin-Stylesheet) - das Grid-Item wird per
   Standard-"align-items:stretch" auf diese 70px gestreckt, was Vorrang vor
   aspect-ratio hat (aspect-ratio wirkt nur, wenn die Hoehe "auto" waere,
   nicht wenn sie durch Grid-Stretch bereits definit ist). Fix: Grid-Item
   per "align-self:start" aus dem Stretch-Verhalten herausgenommen und
   "height:auto" ergaenzt - dadurch darf aspect-ratio die Hoehe wieder
   selbst aus der (durch die Spaltenbreite vorgegebenen) Breite berechnen.
   Live bestaetigt: Breite und Hoehe danach exakt identisch (47.98px =
   47.98px). */
@media screen and (max-width: 749px), screen and (min-width: 750px) and (orientation: landscape) and (max-height: 500px) {
  body .gbbProductSlotsContainer {
    grid-template-columns: repeat(6, 1fr) !important;
    gap: 7px !important;
    max-width: 100% !important;
    /* NEU (Round 28, 63. Batch): Merle "die gbbProductSlotContainer
       ueberschneiden sich" (Handy UND Desktop). Root Cause live gefunden:
       EB setzt auf diesem Grid eine eigene, NIEDRIGE explizite
       grid-template-rows (ca. halb so hoch wie die durch aspect-ratio:1/1
       erzwungene Quadrat-Hoehe der Kacheln) - "grid-auto-rows" allein
       reicht nicht, weil EB die Zeilen explizit (nicht nur "auto") setzt.
       Fix: grid-template-rows hart zuruecksetzen, damit grid-auto-rows
       wieder greift und jede Zeile sich an der tatsaechlichen (quadratischen)
       Kachel-Hoehe orientiert. Live verifiziert: Reihen ueberlappen sich
       danach nicht mehr (Reihe 2 beginnt exakt bei Reihe-1-Unterkante +
       Gap). */
    grid-template-rows: none !important;
    grid-auto-rows: min-content !important;
  }
  body .gbbProductSlotContainer {
    width: 100% !important;
    min-width: 0 !important;
    aspect-ratio: 1 / 1 !important;
    overflow: hidden !important;
    /* NEU (Round 28, 33. Batch): siehe Nachtrag-Kommentar oben - noetig,
       damit aspect-ratio gegen EBs eigenes Grid-Stretch gewinnt. */
    align-self: start !important;
    height: auto !important;
    /* NEU (Round 28, 57. Batch): Merle "den borderradius der
       .gbbProductSlotContainer gerne auf 5px" - bisher ueber diese direkt
       gescopte Regel gar nicht gesetzt (der vorher live gemessene 8px-Wert
       kam aus einem Cross-Origin-EB-Stylesheet, siehe Analoga weiter oben
       bei "--gbb-progress-icon-gap" - eine direkt am Element sitzende
       Deklaration gewinnt dort immer, daher hier jetzt selbst direkt am
       Element statt am Vorfahren gesetzt). */
    border-radius: 5px !important;
  }
  body .gbbProductSlotImageContainer {
    width: 100% !important;
    height: 100% !important;
    max-width: 100% !important;
    overflow: hidden !important;
    /* GEAENDERT (Round 28, 63. Batch): Merle "sobald ein
       gbbProductSlotImageContainer gefuellt ist wird das div irgendwie
       kreisfoermig. bitte in dem quadratformat mit abgerundeten ecken
       lassen und die hintergrundfarbe auf #E3F3C6 setzen" - war bisher
       bewusst 50% (rund), jetzt auf Merles Wunsch quadratisch mit
       abgerundeten Ecken (gleicher 8px-Wert wie an anderen rund-aber-eckig-
       Stellen im Projekt) + eigene Hintergrundfarbe statt der nativen
       #f4ffdb. */
    border-radius: 8px !important;
    background-color: #E3F3C6 !important;
  }
  body .gbbProductSlotImageContainer img {
    width: 100% !important;
    height: 100% !important;
    max-width: 100% !important;
    object-fit: cover !important;
    object-position: center !important;
  }
}

/* NEU (Round 28, 31. Batch): Merle zusaetzlich "die Gap zwischen den
   gbbProductSlotsContainer soll geringer werden" - ausdruecklich nur fuer
   Handy-Quer erwaehnt, daher NICHT am 7px-Wert direkt oberhalb (gilt auch
   fuer Hochformat) geaendert, sondern gezielt nur fuer echtes Handy-Quer auf
   einen kleineren Wert ueberschrieben.
   KORREKTUR (Round 28, 57. Batch): Merle "body .gbbProductSlotsContainer
   gap reicht 5px" (5px statt bisher 4px) - leicht angepasst. */
@media screen and (min-width: 750px) and (orientation: landscape) and (max-height: 500px) {
  body .gbbProductSlotsContainer {
    gap: 5px !important;
  }
}

/* NEU (Round 28, 58. Batch): Merle "auf Desktop breit bitte in
   gbbProductSlotsContainer immer 6x gbbProductSlotContainer/
   -ContainerEmpty in eine Reihe". Die bisherige repeat(6,1fr)-Regel (siehe
   Abschnitt 37 oben) war nur fuer mobile Breiten (max-width:749px ODER
   Handy quer) aktiv - auf "echtem" breitem Desktop (hohes/normales
   Fenster, keine der beiden mobilen Bedingungen) blieb die native EB-Regel
   aktiv (repeat(auto-fit, minmax(75px,75px))). Da die EB-Cart-Sidebar laut
   frueherer Live-Messung unabhaengig von der Fensterbreite eine feste
   Innenbreite von ca. 375-450px hat, passen bei 75px pro Spalte oft nur 5
   Spalten nebeneinander (375/75=5) - die 6. Kachel (haeufig eine leere
   "ContainerEmpty"-Platzhalterkachel) faellt dadurch in eine zweite Zeile
   um. Fix: dieselbe repeat(6,1fr)-Logik jetzt zusaetzlich fuer JEDE Breite
   ab 750px aktiviert (unabhaengig von Orientierung/Hoehe) - ueberschneidet
   sich bewusst mit der bereits bestehenden Regel im Handy-Quer-Bereich
   (identische Deklaration, keine Kollision).
   NACHTRAG (Round 28, 59. Batch): Merle meldet per Screenshot "es sind 6,
   allerdings muessen die Produktslots auf die Divbreite herunterskaliert
   werden - also die Divbreite durch 6 teilen". Root Cause: die obige Regel
   aendert nur die SPALTENZAHL des Grids, nicht die Groesse der einzelnen
   ".gbbProductSlotContainer"-Kacheln selbst - die behalten auf breitem
   Desktop weiterhin ihre eigene, von Easy Bundles per Cross-Origin-
   Stylesheet gesetzte Breite/Mindestbreite, wodurch 6 Kacheln zusammen
   breiter als der verfuegbare Platz werden und ueber den Rand hinauslaufen
   (die 6. Kachel wurde dadurch abgeschnitten). Exakt dasselbe Problem wurde
   fuer Mobil/Handy-Quer bereits im 31./33. Batch geloest (siehe Abschnitt 37
   oben, ".gbbProductSlotContainer" dort mit width:100%/min-width:0/aspect-
   ratio:1/1) - hier wird dieselbe, bereits bewaehrte Loesung jetzt auch fuer
   breiten Desktop aktiviert, damit jede Kachel sich zuverlaessig auf genau
   1/6 der Containerbreite herunterskaliert statt ihre feste Eigengroesse zu
   behalten. */
@media screen and (min-width: 750px) {
  body .gbbProductSlotsContainer {
    grid-template-columns: repeat(6, 1fr) !important;
    /* NEU (Round 28, 63. Batch): siehe ausfuehrlicher Kommentar im
       Mobil-/Handy-Quer-Block oben - identisches Reihen-Ueberlappungs-
       Problem trat laut Merle auch auf Desktop auf, gleicher Fix. */
    grid-template-rows: none !important;
    grid-auto-rows: min-content !important;
  }
  body .gbbProductSlotContainer {
    width: 100% !important;
    min-width: 0 !important;
    aspect-ratio: 1 / 1 !important;
    overflow: hidden !important;
    align-self: start !important;
    height: auto !important;
  }
  body .gbbProductSlotImageContainer {
    width: 100% !important;
    height: 100% !important;
    max-width: 100% !important;
    overflow: hidden !important;
    /* GEAENDERT (Round 28, 63. Batch): siehe Kommentar im Mobil-Block oben -
       quadratisch mit abgerundeten Ecken statt rund, plus eigene
       Hintergrundfarbe. */
    border-radius: 8px !important;
    background-color: #E3F3C6 !important;
  }
  body .gbbProductSlotImageContainer img {
    width: 100% !important;
    height: 100% !important;
    max-width: 100% !important;
    object-fit: cover !important;
    object-position: center !important;
  }
}


/* ---------------------------------------------------------------- 36.
   DESKTOP-PUNKTELISTE 28.9. (15 Punkte von Merle, nur Desktop - Mobil macht
   Merle parallel selbst, siehe Chat)
   ---------------------------------------------------------------- */

/* Untertitel-Zeile ist mit der h5-Vorlage etwas zu gross, soll auf
   h6-Groesse. Nicht die globale h5-Regel angefasst (siteweit genutzt),
   sondern gezielt die zwei bekannten Block-Instanzen (Homepage + "Alle
   Gerichte") auf --font-h6--size umgestellt. */
body .text-block--AdlFxdkU4NWJOakN0N__text_yTPACE.h5 > *,
body .text-block--AUlpSSXZhaisxa1lmS__text_aMHfCn.h5 > * {
  /* War erst als var(--font-h6--size) versucht, ergab live nur 16px (Browser-
     Default) statt der echten H6-Groesse - Variable an dieser DOM-Stelle
     offenbar nicht korrekt sichtbar. Robuster: live gemessener Faktor H5
     22.464px / H6 19.968px = 0.8889 (8/9). */
  font-size: 88.9% !important;
}

/* Riesige dunkelgruene Flaeche im Produkt-Popup hinter dem DE-OEKO-Siegel-
   Bereich. Ursache: ein "height-fit" gedachter Baustein (height:auto) sitzt
   in einer Flex-Zeile ohne gesetztes align-items - Default "normal" verhaelt
   sich wie "stretch" und zieht ihn auf die Hoehe seines viel groesseren
   Geschwisters (Produktbild-Galerie) hoch. Fix: eigene Hoehe erzwingen. */
body .color-custom-AUjVOV04zN05JMGhGV__group_gTiNHL {
  align-self: flex-start !important;
}

/* "Jetzt fuellen"-Button im Boxen-Karussell wird bei :hover
   (transform:scale(1.1)) links abgeschnitten - auf Mobil schon gefixt
   (Abschnitt 26), hier derselbe Fix fuer Desktop. Wichtig: Desktop rendert
   diesen Bereich als Slideshow statt Grid (Mobil-Fix hatte dieses Element
   daher gar nicht im Pfad) - per DOM-Kette gefunden, dass genau dieses
   overflow:hidden-Element die Clipping-Ebene ist. */
@media screen and (min-width: 750px) {
  #shopify-section-template--31616257655114__product_list_cyt63E .product-card {
    overflow: visible !important;
  }
  #shopify-section-template--31616257655114__product_list_cyt63E .product-card__content {
    overflow: visible !important;
  }
  #shopify-section-template--31616257655114__product_list_cyt63E .resource-list__slide {
    overflow: visible !important;
  }
  /* KORREKTUR (Round 27, 3. Batch): dieser 6px-Anti-Clipping-Wert stand
     bisher SPAETER in der Kaskade als unsere "Jetzt fuellen"-Button-
     Einrueckungsregel (Abschnitt weiter oben, 14px, Ziel: gleiche Ebene wie
     der Box-Titel) - bei gleicher Spezifitaet gewann dadurch dieser 6px-Wert
     hier, die Einrueckung griff in Wahrheit NIE auf Desktop (live bestaetigt:
     computed margin-left war 6px statt 14px). Fix: Wert hier direkt auf 14px
     gesetzt (Anti-Clipping-Zweck bleibt erhalten, nur der Zahlenwert gleicht
     sich jetzt der gewuenschten Einrueckung an), statt zwei konkurrierende
     Regeln nebeneinander stehen zu lassen. */
  #shopify-section-template--31616257655114__product_list_cyt63E .pv-product-btn {
    margin-left: 14px !important;
  }
}

/* Icon+Text-Sektionen: Icon+Ueberschrift sitzen bei zwei von vier Bloecken
   pro Sektion sichtbar tiefer. KORRIGIERTER Root Cause (die vermutete
   zusaetzliche Verschachtelung existiert nicht, alle vier Bloecke haben
   dieselbe DOM-Tiefe): die aeussere Flex-Spalte hat bei zwei Bloecken
   justify-content:center statt flex-start (vermutlich ein im Theme-Editor
   einzeln gesetzter Wert) - bei kuerzerem Inhalt wird er dadurch sichtbar
   nach unten verschoben. Live verifiziert: Icon-Top vorher 757px, nachher
   697px, exakt auf einer Linie mit den anderen. Selektor nutzt :has(), um
   gezielt die aeussere der zwei gleich benannten Flex-Spalten zu treffen. */
.layout-panel-flex--column:has(> rte-formatter):has(#shopify-block-AejFxSlRCbTJCcXA5S__icon_A7h4qt),
.layout-panel-flex--column:has(> rte-formatter):has(#shopify-block-AYzU4eHJIVXBVditvb__icon_brbW78),
.layout-panel-flex--column:has(> rte-formatter):has(#shopify-block-AenpXT0QyVVU4d0kzM__icon_hUKtcU),
.layout-panel-flex--column:has(> rte-formatter):has(#shopify-block-Ad2JOS1RvczROa3Fwc__icon_WzzfnY) {
  justify-content: flex-start !important;
}

/* Footer-Newsletter-Bereich umgelayoutet. Ursache: .footer-content ist ein
   natives 3-Spalten-Grid mit exakt gleich breiten Spalten - dadurch bricht
   die Ueberschrift in zwei Zeilen um, obwohl rechts Platz uebrig ist. Fix:
   Spalten im Verhaeltnis 3:1.8:1 statt gleich breit (in fr-Einheiten, bleibt
   bei jeder Fensterbreite proportional). */
#shopify-section-sections--31616257786186__footer_m9NzUG .footer-content {
  grid-template-columns: 3fr 1.8fr 1fr !important;
}

/* Newsletter/Footer-Bereich auf Mobil gestapelt statt 3-Spalten-Grid.
   Reihenfolge (Ueberschrift+Text, Eintragefeld, Logo mittig) entspricht
   bereits der DOM-Reihenfolge - nur die Grid-Aufteilung musste gestapelt
   werden. Jedes Kind volle Breite mit Seitenrand (box-sizing:border-box), das
   letzte Kind (Logo) zusaetzlich zentriert. Selektor bewusst strukturell (>
   *, :last-child), da Block-Klassennamen unbekannt waren - noch nicht live
   gegengecheckt. */
@media screen and (max-width: 749px) {
  #shopify-section-sections--31616257786186__footer_m9NzUG .footer-content {
    grid-template-columns: 1fr !important;
    grid-auto-flow: row !important;
    row-gap: 1.5em !important;
  }
  #shopify-section-sections--31616257786186__footer_m9NzUG .footer-content > * {
    grid-column: 1 !important;
    width: 100% !important;
    max-width: 100% !important;
    padding-inline: 1em !important;
    box-sizing: border-box !important;
  }
  #shopify-section-sections--31616257786186__footer_m9NzUG .footer-content > *:last-child {
    display: flex !important;
    flex-direction: column !important;
    align-items: center !important;
    justify-content: center !important;
    text-align: center !important;
  }
}

/* AB 2.10. (Phase 2): vermutlicher echter Root-Cause dafuer, dass der
   Newsletter auf dem Handy weiterhin nicht/falsch angezeigt wurde. Die obigen
   Regeln sind auf ".footer-content" gescopt - Merle hat aber eine andere,
   native Klassen-Kombination genannt (".layout-panel-flex--column
   .mobile-column" + ".group-block-content"), die sie im Theme-Editor selbst
   gefunden hat. Grund: die UNscoped nativen Basis-Regeln weiter oben in
   dieser Datei (".layout-panel-flex { height:100%; }" und
   ".group-block-content { height:100%; width:100%; }") werden auf Mobil nur
   fuer die ROW-Variante zurueckgesetzt (".layout-panel-flex--row:not(
   .mobile-column) { height:auto; }") - die COLUMN-Variante mit
   .mobile-column faellt durch dieses Raster und behaelt height:100%, obwohl
   ihr Inhalt (das Eintragefeld etc.) mehr Platz braucht. Dadurch wurde der
   Newsletter-Block vermutlich abgeschnitten/nicht sichtbar. Fix NUR im
   Footer gescopt (die Klassen sind theme-weit sehr generisch und werden an
   vielen anderen Stellen verwendet - ein unscoped height:auto wuerde dort
   unkontrolliert Layout veraendern). */
@media screen and (max-width: 749px) {
  #shopify-section-sections--31616257786186__footer_m9NzUG .layout-panel-flex--column.mobile-column,
  #shopify-section-sections--31616257786186__footer_m9NzUG .group-block-content {
    height: auto !important;
    min-height: auto !important;
    overflow: visible !important;
  }
}

/* Geklaert, wirkte zunaechst wie ein Widerspruch: es sind zwei verschiedene
   Elemente in der Tagline-Sektion - die Pillen (.pv-tagline, -7%) und "Dein
   Energiekick fuer den Tag." (eigene Zeile ueber der "100%
   pflanzlich..."-Headline, aktuell h6-Groesse), die groesser werden soll.
   Hier +25% (h6 -> spuerbar ueber h5-Groesse). */
body .text-block--AV1BRNS9lQ1ZYMVhXV__text_R3WjXt.h6 :is(h1, h2, h3, h4, h5, h6) {
  /* Nicht als Prozent-Wert, sondern in vw wie die tatsaechlich gewinnende
     Basis-Regel ("h6 { font-size: 1.6vw !important; }") - eine Prozent-Angabe
     griff hier auf var(--font-h6--size) (=16px) zurueck, nicht auf die echte,
     sichtbare h6-Groesse. 1.6vw * 1.25 = 2vw, bestaetigt: 19.968px ->
     24.96px. */
  font-size: 2vw !important;
}
/* "Dein Energiekick..." ist auf Mobil mit 2vw winzig (10px bei ~500px Breite)
   - vw-Einheiten schrumpfen auf schmalen Viewports viel staerker als am
   Desktop. Ziel "doppelt so gross, vielleicht mehr" - hier auf klar ueber das
   Doppelte gesetzt (ca. 21px, +110%), mit clamp() abgesichert statt reinem
   vw. */
@media screen and (max-width: 749px) {
  body .text-block--AV1BRNS9lQ1ZYMVhXV__text_R3WjXt.h6 :is(h1, h2, h3, h4, h5, h6) {
    font-size: clamp(1.1rem, 5.4vw, 1.5rem) !important;
  }
}

/* --- Punkt 10: EB Mix&Match-Seite - Trennlinie unter den Kategorie-Tabs
   (border-bottom) soll weg. */
.gbbCategoriesHeaderContainer,
.gbbCategoriesHeaderContainer:has(.gbbCategoriesTabsContainer) {
  border-bottom: none !important;
}
/* NEU (Round 27, 7. Feedback-Batch): "wegen dem x-overflow ein padding-left
   von 0.3em" - gegen den ersten Tab ("Alle Gerichte"), der sonst direkt am
   linken Rand klebt (live gemessen: 0px Abstand). VORSICHT/HISTORIE: ein
   padding-left auf dem AEHNLICHEN, aber ANDEREN Selektor .gbbCategoriesTabsContainer
   selbst wurde am 26.9. (Round 26) bewusst WIEDER ENTFERNT, weil es zu einem
   zu grossen Abstand zwischen Box-Auswahl und Kategorien-Bereich fuehrte
   (siehe Abschnitt 34 weiter unten). Hier bewusst NUR auf dem spezifischeren,
   von Merle selbst genannten :has()-Selektor (dem Header-Container, nicht
   dem Tabs-Container direkt) gesetzt - ein anderes Element als damals, daher
   eigene, neue Regel statt eine Wiederholung des alten Fehlers. Bitte
   melden, falls der alte Abstands-Nebeneffekt hier doch wieder auftritt. */
.gbbCategoriesHeaderContainer:has(.gbbCategoriesTabsContainer) {
  padding-left: 0.3em !important;
}

/* EB Mix&Match-Seite - Hover-Verhalten. a) Kategorie-Tabs: bei Hover weisse
   Kontur + etwas groesser - ausser dem aktiven Tab (per nativem data-is-
   active="false" unterschieden). KORREKTUR (Round 26, 5. Feedback-Batch,
   "zu bunt"-Rueckmeldung): der bisherige rosa Hintergrund-Fill
   (var(--header-color)) durch eine schlichte weisse Kontur ersetzt, passend
   zum neuen "kein Hintergrund"-Look der inaktiven Tabs. */
/* GEAENDERT (Round 28/Batch 18): Scale von 1.06 auf 1.03 reduziert, als
   Ausgleich fuer den auf 4.8px (-40%) verkleinerten Tab-Abstand auf Mobil
   (siehe Abschnitt "f) Kategorie-Filter-Buttons verkleinern" weiter oben,
   .gbbCategoriesTabsContainer) - verhindert, dass das dort schon einmal
   gefixte "Tabs beruehren sich bei Hover"-Problem zurueckkommt. */
.gbbCategoryTabContainer[data-is-active="false"]:hover {
  outline: 1.5px solid #ffffff !important;
  transform: scale(1.03);
  transition: outline-color 0.2s ease, transform 0.2s ease;
}
/* b) "in meine Box"-Buttons auf den Produktkarten: Vergrößern ist hier
   riskant (fixe Kartenbreite, könnte wieder abschneiden wie Punkt 6) - daher
   wie von Merle als Alternative vorgeschlagen: bei Hover leicht nach oben
   schweben + Schrift headerrosa. */
.gbbProductAddButton {
  transition: transform 0.2s ease, color 0.2s ease;
}
.gbbProductButtonContainer:hover .gbbProductAddButton {
  transform: translateY(-3px);
  color: var(--header-color) !important;
}
/* c) Rechts, Box-Größen-Auswahl (Probier-/Single-/We-are-family-Box): die
   jeweils NICHT ausgewählte Box soll bei Hover animiert werden (analog zu a),
   per nativem data-is-active="false" unterschieden). */
.gbbBoxSelectionItem[data-is-active="false"]:hover {
  transform: scale(1.04);
  transition: transform 0.2s ease;
}


/* ---------------------------------------------------------------- 38.
   KARUSSELL ZEIGT (VOR ALLEM IN SAFARI) MANCHMAL DIE ZWEITE STATT DER ERSTEN
   SLIDE ALS AKTIV (echte Root-Cause-Suche im kompilierten Theme-JS, nachdem
   ein frueherer Schnellfix - .select(0) + scrollLeft=0 - weiterhin manchmal
   fehlschlug) GEFUNDEN per Live-Auslesen der Horizon-Komponentenklasse: 1)
   Der bisherige Fix war zur Haelfte wirkungslos: alle `.card-gallery
   slideshow-component`-Elemente (Bild-Galerien je Produktkarte) sind
   `isNested:true` -> Horizon setzt dafuer automatisch `disabled=true`,
   `select()` kehrt dadurch sofort und ohne Fehler zurueck. Der eigentlich
   gemeldete Bug betrifft aber die Produkt-Ebene selbst (`.resource-
   list__carousel`, 10 Slides) - nicht verschachtelt, reagiert normal auf
   select(). 2) Plausibelster Root Cause: der Scroll-Container hat `overflow-
   anchor:auto` (Browser-Standard) - die native "Scroll Anchoring"-Funktion
   korrigiert scrollLeft automatisch bei Layoutverschiebungen. Beim Laden
   waren noch 15 von 35 Bildern nicht fertig geladen; trifft eine dadurch
   ausgeloeste Verschiebung zeitlich mit `scroll-snap-type:mandatory`
   zusammen, kann der Browser auf den naechstgelegenen (nicht mehr Slide 0)
   Snap-Punkt neu einrasten. Safari hat diese Funktion erst 2023 nachgeruestet
   - passt zu "vor allem Safari" und "manchmal". 3) Zusaetzlicher Unterschied:
   alle nativen `select(...)`-Aufrufe im Theme uebergeben `{animate:false}`
   (Sofort-Sprung). Unser Aufruf tat das nicht, `animate` blieb auf Default
   `true` - genug Zeit, dass ein nachladendes Bild die Zielposition waehrend
   der Animation nochmal verschiebt. FIX (an der Ursache, nicht nur
   haeufigerem Zuruecksetzen): a) `overflow-anchor:none` auf den Slide-Scroll-
   Container - das spec-eigene Werkzeug, um das automatische Nachkorrigieren
   abzuschalten. b) In mobile-fixes.js: der Reset nutzt jetzt Horizons eigene
   `select(0, undefined, {animate:false})`-API statt rohem `scrollLeft=0`,
   damit der interne Zustand synchron bleibt. Live verifiziert
   (Komponentenklasse, select()/#setupSlideshow()-Code, alle 15 slideshow-
   component-Elemente auf isNested/disabled geprueft, Scroll- Container +
   Lade-Status aller 35 Bilder gemessen) - aber keine 1:1- Reproduktion in
   echtem Safari (nur Chrome verfuegbar). Bitte auf dem iPhone gegenchecken,
   ob das Umspringen ausbleibt; bei erneutem Auftreten waere ein Screen-
   Recording hilfreich. */
@media screen and (max-width: 749px) {
  #shopify-section-template--31616257655114__product_list_WCk8kE .resource-list__carousel slideshow-slides,
  #shopify-section-template--31616257655114__product_list_gPQqGm .resource-list__carousel slideshow-slides,
  #shopify-section-template--31616257655114__product_list_cyt63E .resource-list__carousel slideshow-slides {
    overflow-anchor: none !important;
  }
}
@media screen and (min-width: 750px) {
  #shopify-section-template--31616257655114__product_list_WCk8kE .resource-list__carousel slideshow-slides,
  #shopify-section-template--31616257655114__product_list_gPQqGm .resource-list__carousel slideshow-slides,
  #shopify-section-template--31616257655114__product_list_cyt63E .resource-list__carousel slideshow-slides {
    overflow-anchor: none !important;
  }
}

/* NEU (9.10., Round 27 Batch 11): Merle meldet "Spare 12,3%"-Bubble der
   Office-Box (letzte Karte im Boxen-Karussell) rechts abgeschnitten,
   obwohl eigentlich noch Platz da sei. Live per DevTools gemessen (an der
   genauen Office-Box-Bubble, cyt63E): die Bubble selbst ragt NICHT ueber
   ihre eigene Karte hinaus (12px Innenabstand wie vorgesehen) - geclippt
   wird sie stattdessen von einem Scroll-/Raster-Container, dessen eigene
   Breite/Overflow-Kante bei bestimmten Fensterbreiten genau an dieser
   Stelle endet (die letzte Karte hat anders als die anderen keinen
   Nachbarn rechts, der zusaetzlichen Platz "mitbringt"). Da ich Merles
   exakte Fensterbreite in meiner Sandbox nicht 1:1 nachstellen konnte
   (Fenster-Resize greift dort nur bis 1000px, ihr Screenshot deutet auf
   eine andere/breitere Ansicht hin), hier ein vorsichtiger, zusaetzlicher
   Sicherheitsabstand an BEIDEN moeglichen Stellen (Touch-Karussell hier
   und das Maus/Trackpad-Grid weiter unten) statt eines punktgenauen Fixes
   - reserviert etwas Leerraum rechts, damit die letzte Bubble unabhaengig
   von der genauen Container-Grenze Platz hat. SCHAETZWERT, bitte live
   gegenchecken, ob das reicht oder mehr/weniger braucht. */
@media screen and (max-width: 749px) {
  #shopify-section-template--31616257655114__product_list_cyt63E .resource-list__carousel slideshow-slides {
    padding-inline-end: 56px !important;
  }
}
@media screen and (min-width: 750px) {
  #shopify-section-template--31616257655114__product_list_cyt63E .resource-list__carousel slideshow-slides {
    padding-inline-end: 56px !important;
  }
}
/* AB 2.10. (zweite Runde): Tippfehler in der Boxen-ID korrigiert (war
   ...786186__product_list_cyt63E, richtig ist ...655114__product_list_cyt63E
   wie ueberall sonst in dieser Datei) - die Regel griff dadurch bisher nicht
   fuer das Boxen-Karussell. */

/* ZURUECKGENOMMEN: die Karussells liessen sich dadurch nicht mehr seitlich
   wischen - ein Missverstaendnis, gemeint war nur das (davon unabhaengige)
   Zoomen ausschalten, siehe "ZOOM DEAKTIVIEREN" (touch-action:pan-x pan-y +
   Doppeltipp-Sperre in mobile-fixes.js), das Pinch-/Doppeltipp-Zoom bereits
   ueberall abdeckt, ohne Wischen zu blockieren. Diese engere Regel (nur
   pan-y) hatte genau das kaputtgemacht. Komplett entfernt. */


/* ---------------------------------------------------------------- 39. MERLES
   18-PUNKTE-LISTE VOM ECHTEN IPHONE (Mix & Match / Easy-Bundles- Seite +
   weitere Einzelpunkte). Root-Cause-Tiefe bewusst geringer als bei Punkt 6 -
   Zeit-/Ressourcen-Abwaegung bei 18 Punkten auf einmal. Live in Chrome (500px
   Sandbox-Obergrenze) soweit moeglich verifiziert, sonst als "best effort"
   markiert. ---------------------------------------------------------------- */

/* Punkt 7: Seiteninhalt der Mix&Match-Seite wurde vom (damals absolut
   positionierten) Header verdeckt - Fix war ein manuelles padding-top auf
   .page-wrapper, nur auf Easy-Bundles-Seiten. ENTFERNT: seit der heutigen
   Header-Korrektur (position:sticky/absolute) reserviert der Header seinen
   Platz jetzt bereits korrekt selbst - das manuelle Padding von damals kam
   doppelt obendrauf (live: 82px) und erzeugte genau die gemeldete Luecke.
   Grund fuer den alten Fix entfallen, komplett entfernt. */

/* Punkt 8: Suchfeld (gbbSearchBarContainer) weniger hoch + kaum Abstand zu
   den Kategorie-Tabs. Live gemessen: Innenabstand "6px 2px" (~35px
   Gesamthoehe), plus 16px Luecke aus dem gap des Eltern-Containers. */
@media screen and (max-width: 749px) {
  body .gbbSearchBarContainer {
    padding: 2px 2px !important;
    min-height: auto !important;
  }
  body .gbbCategoriesHeaderRow {
    gap: 2px !important;
    row-gap: 2px !important;
  }
}

/* Punkt 9: gbbCartIconWithQuantityContainer ist ueber die volle Breite
   gestreckt (Grid-Default-Stretch der 484px-Spalte). Fix: eigene Breite
   vorgeben + im Grid-Feld zentrieren. */
@media screen and (max-width: 749px) {
  body .gbbCartIconWithQuantityContainer {
    width: 18% !important;
    max-width: 18% !important;
    min-width: 100px !important;
    justify-self: center !important;
    margin-inline: auto !important;
  }
}
/* Trotz Zentrierung bleibt der Button links haengen - vermutlich eine App-
   eigene inline "left"-Position, die margin-inline:auto aussticht. Explizit
   left:auto gesetzt. Ohne Breakpoint, falls nicht nur mobil. */
body .gbbCartIconWithQuantityContainer {
  left: auto !important;
}

/* Punkt 11: Schrittbotschaft etwas kleiner; Untertitel auf dieselbe kleine
   Groesse wie der Titel (~10.56px); Titel-Text soll einzeilig bleiben -
   dafuer auf nowrap umgestellt (war white-space:normal). */
body .gbbDiscountMessage {
  font-size: 0.85em !important;
}
/* Auf Mobil hochkant soll die Schrittbotschaft komplett ausgeblendet werden -
   die Regel oben bleibt fuer Desktop/Querformat bestehen, hier zusaetzlich
   display:none. Gleichzeitig verliert .gbbDiscountContainer sein Padding
   komplett, grid-gap (nur wenn ein Fortschrittsbalken vorhanden ist) von 10px
   auf 5px reduziert. */
@media screen and (max-width: 749px) and (orientation: portrait) {
  body .gbbDiscountMessage {
    display: none !important;
  }
  body .gbbDiscountContainer {
    padding: 0 0 5px 0 !important; /* AB 7.10.: Merles Wunsch (Punkt 23) - nur
      unten 5px, sonst ueberall 0 */
  }
  body .gbbDiscountContainer:has(.gbbDiscountProgressBarContainer) {
    grid-gap: 5px !important;
    gap: 5px !important;
  }
  /* NEU (Round 28, 47. Batch): Merle "get rid of the margin-block of
     .gbbDiscountMessageContainer, its taking up space without displaying
     anything" - .gbbDiscountMessage selbst ist auf Hochformat bereits
     oberhalb auf display:none gesetzt, der umschliessende Container
     .gbbDiscountMessageContainer behaelt aber weiterhin sein eigenes
     margin-block:12px (Grundregel, siehe Abschnitt "Suche noch X
     Gerichte..."-Hinweis) - dadurch bleibt eine leere Luecke. Hier auf 0
     zurueckgesetzt, nur fuer Hochformat (Querformat/Desktop behalten die
     12px, da dort die Nachricht ja sichtbar bleibt). */
  body .gbbDiscountMessageContainer {
    margin-block: 0 !important;
  }
  /* Unteres Padding des fixierten Bundle-Wagens: war komplett entfernt (live
gemessen: 5px), AB 2.10. (dritte Runde) auf Wunsch doch wieder ein kleiner
Wert. AB 7.10. nochmal bestaetigt: 0.3vh bleibt. */
  body .gbbBundleFooter {
    padding-bottom: 0.3vh !important;
  }
}

/* AB 2.10. (dritte Runde): .gbbBundleFooter - oben abgerundete Ecken, der
   obere Rahmen (vermutlich eine native Trennlinie zum Seiteninhalt) soll weg.
   Ohne Breakpoint, da diesmal nicht als "nur mobil" genannt.
   ZURUECKGENOMMEN (gleicher Tag): hatte hier testweise overflow:hidden
   ergaenzt, um das gemeldete Ueberlaufen der Box-Auswahl-Kacheln/"Leeren"-
   Buttons ueber die abgerundete Ecke zu beheben - Merle meldet danach "jetzt
   wirds abgeschnitten". ROOT CAUSE (im Projekt-Dokument base-css-changelog.md
   bereits dokumentiert, von mir beim ersten Versuch uebersehen): genau dieses
   overflow:hidden auf .gbbBundleFooter war FRUEHER schon einmal vorhanden
   (als Teil eines eigenen Klapp-Mechanismus) und wurde bewusst "komplett
   entfernt", weil es den NATIVEN Easy-Bundles-Wagen (.gbbDrawer.gbbCartDrawer
   .gbbFooterBundleItemsContainer, eigene expand-height-Animation/Dialog)
   abschneidet/blockiert. Mein erneutes Hinzufuegen hat also exakt dieselbe,
   bereits bekannte Regression reproduziert. Komplett zurueckgenommen - das
   urspruengliche Ueberlauf-Problem (Kacheln/Button ueber die Rundung hinaus)
   bleibt dadurch zwar bestehen, muss aber anders geloest werden (z.B. gezielt
   nur auf die betroffenen Kind-Elemente, nicht auf .gbbBundleFooter selbst). */
body .gbbBundleFooter {
  border-radius: 10px 10px 0 0 !important;
  border-top: none !important;
}
body .gbbDiscountStepsProgressBarStepSubtitle {
  font-size: 0.66rem !important;
  line-height: 1.1 !important;
}
@media screen and (min-width: 750px) {
  body .gbbDiscountStepsProgressBarStepSubtitle {
    font-size: 0.78rem !important;
  }
}
body .gbbDiscountStepsProgressBarStepTitle {
  white-space: nowrap !important;
}

/* Punkt 12: "zur Kasse"-Button war testweise grau/hellgruen je nach
   Fortschritt eingefaerbt - soll wieder durchgehend #E3F3C6 sein. Die alte
   Regel bleibt bestehen, wird hier mit hoeherer Spezifitaet ueberschrieben. */
body .gbbFooterNextButton,
body .gbbFooterNextButton.pv-eb-ready {
  background-color: #f4ffdb !important; /* war var(--pv-cream, #E3F3C6) - Round 26, 6. Batch: EB-einheitliches Hellgruen */
}

/* Punkt 13: Cart-Drawer soll nicht so hoch herausfahren. Bisher max-
   height:85vh, reduziert auf 70vh - Schaetzwert ohne echtes iPhone zum
   Nachmessen, bitte live gegenchecken. */
@media screen and (max-width: 749px) {
  body .gbbDrawer.gbbCartDrawer,
  body .gbbFooterBundleItemsContainer {
    max-height: 70vh !important;
  }
}
/* KORREKTUR (Round 23, Merles Wunsch "divs in der Hoehe maximal reduzieren"
   auf der EB Mix&Match-Seite im Querformat): auf Handy-Quer ist die
   Bildschirmhoehe insgesamt schon knapp - 70vh davon ist absolut gesehen
   trotzdem noch viel. Eigene, staerkere Reduktion nur fuer diesen Fall
   (55vh statt 70vh). Schaetzwert, bitte live gegenchecken. */
@media screen and (orientation: landscape) and (max-height: 500px) {
  body .gbbDrawer.gbbCartDrawer,
  body .gbbFooterBundleItemsContainer {
    max-height: 55vh !important;
  }
}

/* Punkt 14: das Hamburger-Menue liegt auf der Mix&Match-Seite unter dem Easy-
   Bundles-Drawer - als modales Overlay soll es immer oben liegen. Fix:
   z-index deutlich anheben. KORREKTUR: danach "Menue nicht mehr klickbar" +
   falsche Farbe. Ursache: .menu-drawer und sein Backdrop hatten denselben
   z-index (99999) - bei Gleichstand entscheidet die DOM-Reihenfolge, der
   Backdrop lag darunter ueber dem Drawer und fing dessen Klicks ab. Fix:
   Drawer bekommt einen hoeheren z-index als sein Backdrop, beide bleiben
   ueber dem Easy-Bundles-Cart-Drawer (999). */
.menu-drawer__backdrop {
  z-index: 99999 !important;
}
.menu-drawer {
  z-index: 100000 !important;
}

/* Punkt 16: "Jetzt meine Box zusammenstellen"-Button im Produkt-Popup nur
   entfernen, wenn das Popup von einer Box-Seite aus geoeffnet wurde. Die
   Marker-Klasse "pv-qv-from-box" wird per JS gesetzt (mobile-fixes.js,
   Abschnitt 11), da beide Kontexte dasselbe Popup-Template teilen. Gilt fuer
   Mobil und Desktop. */
body dialog.quick-view-modal.pv-qv-from-box .button-custom--ARFV6Y0hmWkZJWTNtU__button_LeReFL {
  display: none !important;
}

/* Punkt 16b (neue Anfrage): "Jetzt meine Box zusammenstellen"-Button im Popup
   auf Desktop im Ruhezustand 15% kleiner, waechst on-hover auf die bisherige
   (jetzige) Groesse - exakt dasselbe Muster wie beim "Stell Dir hier Deine Box
   zusammen"-Button weiter oben in der Datei (siehe
   .button-custom--AVmw1QzBrZ21OSVo0e__button_wkxYLF, dort ausfuehrlich
   kommentiert). Bewusst nur Desktop (ab 750px) - auf Mobil unveraendert. */
@media screen and (min-width: 750px) {
  body dialog.quick-view-modal .button-custom--ARFV6Y0hmWkZJWTNtU__button_LeReFL {
    transition: transform 0.2s ease !important;
    transform: scale(0.85) !important;
  }
  body dialog.quick-view-modal .button-custom--ARFV6Y0hmWkZJWTNtU__button_LeReFL:hover {
    transform: scale(1) !important;
  }
}

/* Punkt 16c (neue Anfrage): es gibt mittlerweile zwei Exemplare dieses Buttons
   im selben Popup (einmal oben direkt unter dem Preis, einmal weiter unten
   nach der Beschreibung). Auf Handy soll nur das ERSTE (obere) bleiben, auf
   Desktop nur das ZWEITE/letzte (untere) - genau umgekehrt. Da beide
   Exemplare dieselbe Klasse tragen und nicht zwingend direkte Geschwister im
   DOM sind (nth-of-type waere hier nicht zuverlaessig), markiert
   mobile-fixes.js beim Oeffnen des Popups das erste Vorkommen mit
   .pv-qv-dup-first und alle weiteren mit .pv-qv-dup-rest (Abschnitt
   "tagDuplicateButtonsWithRetry") - hier wird je Breakpoint nur noch die
   Sichtbarkeit umgeschaltet. */
@media screen and (max-width: 749px) {
  body dialog.quick-view-modal .button-custom--ARFV6Y0hmWkZJWTNtU__button_LeReFL.pv-qv-dup-rest {
    display: none !important;
  }
}
@media screen and (min-width: 750px) {
  body dialog.quick-view-modal .button-custom--ARFV6Y0hmWkZJWTNtU__button_LeReFL.pv-qv-dup-first {
    display: none !important;
  }
}

/* An dieser Stelle wird jetzt per JS ein Klon des EB-eigenen "in meine
   Box"-Buttons eingesetzt (.pv-modal-add-to-box). .gbbProductAddButton ist
   normalerweise eine kompakte Kachel-Schaltflaeche - im Popup soll sie
   stattdessen volle Breite einnehmen und klar klickbar wirken. */
body dialog.quick-view-modal .pv-modal-add-to-box {
  width: 100% !important;
  max-width: 100% !important;
  box-sizing: border-box !important;
  display: flex !important;
  justify-content: center !important;
  cursor: pointer !important;
  margin-top: 8px !important;
}

/* ----------------------------------------------------------------
   40. MERLES FOLGE-RUNDE (29.9.): BOX-AUSWAHL, DESKTOP-PREIS, ZOOM
   ---------------------------------------------------------------- */

/* a) Box-Name unten ausgerichtet, Subtext oben + kleiner. Live gemessen: die
   Subtext-Grid-Zeile ist 43px hoch, obwohl einzeiliger Text nur ~15px braucht
   (bewusst hoch fuer zweizeiligen Subtext bei der Family-Box, erzeugt bei
   kuerzeren Texten aber Luft). align-self zieht Titel/Subtext an den Rand
   ihrer Zeile, macht den Abstand konsistenter unabhaengig von 1- oder
   2-zeiligem Text. */
body .gbbBoxSelectionHeading {
  align-self: end !important;
}
body .gbbBoxSelectionSubtext {
  align-self: start !important;
}
@media screen and (max-width: 749px) {
  body .gbbBoxSelectionSubtext {
    font-size: 10.5px !important; /* war 12px */
  }
  /* "inkl. Versand" nochmal deutlich kleiner - der Teilstring wird per JS
     (mobile-fixes.js) in einen eigenen <span class="pv-inkl-versand">
     gewrappt, da er im DOM nur Teil eines Textknotens ist. */
  body .gbbBoxSelectionSubtext .pv-inkl-versand {
    font-size: 0.7em !important;
  }
}

/* b) Gesamtpreis-Anzeige beim "zur Kasse"-Button auf Desktop. Root Cause
   (dokumentiert in claude/easy-bundles-sdk-reference.md): Easy Bundles
   rendert den Gesamtpreis-Container zweimal - eingebettet im Button (auf
   Mobil sichtbar) und als eigenstaendigen, von Easy Bundles selbst permanent
   auf display:none gesetzten ".gbbFooterStandaloneTotal"-Block mit demselben,
   korrekt befuellten Preis. Auf Desktop fehlt die eingebettete Variante
   komplett im DOM - die Standalone-Variante ist aber immer vorhanden, nur
   unsichtbar. Fix: ab 750px sichtbar machen (display:grid). Live auf 500px
   verifiziert, dass der Block korrekt befuellt ist - die echte Desktop-Breite
   konnte nicht getestet werden, bitte gegenpruefen.
   KORREKTUR (Round 28, 49. Batch): Merle meldet erneut "gesamt zzgl versand
   ist nicht zentriert - das Problem hatten wir schonmal". Beim erneuten
   Durchgehen der ganzen ".gbbFooterTotalContainer"-Historie (Abschnitt 44,
   58-60, 66, 66b, 66c, Batch 19 - alle bereits unscoped bzw. ueber "min-
   width:750px, ODER landscape+max-height:500px" gescopt, decken also die
   eigentliche Zentrierung bereits ab) faellt auf: GENAU DIESE Regel hier
   (die den Standalone-Block ueberhaupt erst sichtbar macht) haengt noch
   immer NUR an "min-width:750px", ohne den Landscape-Zusatz - exakt dieselbe
   "Breakpoint-Luecke" wie an vielen anderen Stellen dieser Datei bereits
   gefunden. Ein echtes Handy im Querformat, das schmaler als 750px ist (z.B.
   iPhone SE quer, 667px), bekommt dadurch WEITERHIN die eingebettete
   Button-Variante statt der (durch Abschnitt 66b/66c bereits korrekt
   zentrierten) Standalone-Variante - und die eingebettete Variante hat ihre
   EIGENE Zentrierungslogik (Abschnitt 59), die auf ein anderes Containerbild
   abzielt. Fix: Bedingung um den Landscape-Zusatz erweitert, damit JEDES
   Handy im Querformat (unabhaengig von der genauen Breite) zuverlaessig die
   Standalone-Variante bekommt. NICHT live verifizierbar (Sandbox-Grenze) -
   falls die Pille danach immer noch nicht mittig sitzt, bitte einen
   DevTools-Screenshot (Computed-Style-Box von ".gbbFooterTotalContainer.
   gbbFooterStandaloneTotal" UND seinem Eltern-Element) schicken, da hier
   bereits mehrere Anlaeufe ohne Erfolg blieben und weiteres Raten ohne
   echte Messwerte nicht mehr sinnvoll ist. */
@media screen and (min-width: 750px), screen and (orientation: landscape) and (max-height: 500px) {
  body .gbbFooterStandaloneTotal {
    display: grid !important;
  }
}

/* c) Pinch- und Doppeltipp-Zoom auf Mobil deaktivieren. touch-action:pan-x
   pan-y (ohne "pinch-zoom") unterbindet beide Gesten, erlaubt aber normales
   Scrollen - anders als "manipulation" (erlaubt Pinch-Zoom weiterhin). Der
   Viewport-Meta-Tag wird zusaetzlich per JS gesetzt - Hinweis: iOS Safari
   ignoriert user-scalable=no oft aus Barrierefreiheits-Gruenden, touch-action
   ist der zuverlaessigere Teil. Bitte auf einem echten iPhone gegenpruefen. */
html {
  touch-action: pan-x pan-y;
}

/* Abschnitt 41 (Logo mittig / Instagram unten rechts) stand hier urspruenglich
   als eigene Regel, wurde aber durch Abschnitt 53 weiter unten vollstaendig
   ersetzt (robusterer Fix mit explizitem align-self auf dem Icon statt nur
   auf dem Container) - als Duplikat entfernt, um nicht zwei konkurrierende
   Quellen fuer dieselbe Regel zu haben. Die Phase-2-Bestaetigung ("logo
   mittig ausrichten, instalogo unten rechts in die ecke") ist bereits durch
   Abschnitt 53 abgedeckt: .logo-block mittig (align-self:center), .social-
   icons__wrapper rechts+unten (align-self:flex-end, order:2 nach dem Logo). */

/* ---------------------------------------------------------------- 42. BOX-
   KARTEN-BESCHREIBUNGSTEXT: KLICK-BASIERTES AUSKLAPPEN STATT :HOVER Die
   urspruengliche Fassung hatte auf Mobil den :hover-Ausklappzustand hart
   erzwungen, um einen "Text ueberlagert Preis/Button"-Bug (klassischer
   WebKit-Stuck-Hover) zu beheben - verhinderte dabei aber jedes Ausklappen.
   FIX: :hover als Ausloeser aufgegeben - stattdessen dasselbe Klick-Muster
   wie beim Box-Titel: ein Tap/Klick schaltet zusaetzlich die Klasse .pv-
   desc-expanded um. AB 2.10.: nicht mehr auf Mobil beschraenkt (Merles
   Wunsch: auch auf Desktop per Klick statt Hover) - die eigentliche CSS-
   Regel dafuer steht jetzt ganz oben in der Datei direkt bei der
   clamp:4-Regel, hier nur noch der Verweis.
   ---------------------------------------------------------------- */

/* ---------------------------------------------------------------- 43.
   PRODUKTKARTEN AUF MOBIL: NUR DAS ERSTE BILD JE KARTE ANZEIGEN Betrifft alle
   drei Homepage-Karusselle. Jede Produktkarte hat ihre eigene Bild-Galerie,
   ein Tap laesst die native Slideshow intern aufs zweite Bild springen (aria-
   hidden wechselt). Laut Abschnitt 38 ist diese Galerie "isNested" und von
   Horizon bereits disabled - ein eigener select(0)-Aufruf waere wirkungslos.
   Statt den internen Zustand zu kontrollieren, wird das sichtbare Ergebnis
   erzwungen: jedes Bild ausser dem ersten bekommt display:none, unabhaengig
   vom flackernden aria-hidden-Attribut. Bewusst auf `.product-card` gescoped,
   damit die aeussere Karussell-Ebene (ein Slide pro Produkt) unberuehrt
   bleibt. Live verifiziert (Chrome, 500px): vor dem Fix waren beide Bilder
   gleichzeitig sichtbar, danach bleibt das zweite durchgehend bei 0x0px. Gilt
   fuer alle drei Karusselle gleichermassen.
   ---------------------------------------------------------------- */
@media screen and (max-width: 749px) {
  body product-card slideshow-slide.product-media-container:not(:first-of-type),
  body .product-card slideshow-slide.product-media-container:not(:first-of-type) {
    display: none !important;
  }
}

/* ---------------------------------------------------------------- 43b.
   ENTFERNT (Round 28, 40. Batch): Merle "the animation on the
   gerichtproduktraster showing the second slide doesnt look good, please
   remove it again" - der in Batch 36 eingefuehrte und in Batch 39 auf eine
   sequentielle Kaskade umgebaute "zweites Slide-Bild beim Vorbeiscrollen"-
   Effekt fuers Gerichtraster (WCk8kE/gPQqGm) ist auf Merles Wunsch komplett
   zurueckgebaut. Der zugehoerige JS-Teil (hoverSelectors-Eintrag + die
   gerichtrasterShowNext/-HandleIntersection-Queue-Funktionen) wurde
   ebenfalls aus mobile-fixes.js entfernt. Abschnitt 43 oben (zweites
   Slide-Bild generell display:none auf Mobil, gegen Flackern beim
   versehentlichen Antippen) bleibt davon unberuehrt bestehen. */


/* ---------------------------------------------------------------- 44.
   GBBFOOTERTOTALCONTAINER AUF DESKTOP: HINTERGRUND, RUNDUNG, INLINE-LAYOUT
   Gesamt-Container im EB-Footer bekommt auf Desktop hellgruenen Hintergrund,
   sehr runde Ecken (border-radius:999px, unabhaengig von der Hoehe als volle
   Pillenform), Inhalt inline statt untereinander, mittig/linksbuendig. Noch
   nicht live verifiziert - bitte auf echtem Desktop-Fenster gegenchecken.
   KORREKTUR (Round 23, Merles Wunsch "auf der EB Mix&Match-Seite alles was
   geht inline setzen, zb zur Kasse und Gesamtpreis"): diese und die naechsten
   beiden Bloecke (Abschnitt 59, 60) waren bisher an "min-width:750px"
   gekoppelt - das deckt die meisten Handy-Quer-Geraete zwar schon ab (oft
   >749px breit), aber nicht alle (schmalere Modelle im Querformat koennen
   darunter liegen). Bedingung um unsere Handy-Quer-Erkennung (Querformat UND
   Hoehe <=500px) erweitert, damit die Inline-Gestaltung zuverlaessig auch
   dort greift, unabhaengig von der genauen Geraetebreite. */
@media screen and (min-width: 750px), screen and (orientation: landscape) and (max-height: 500px) {
  body .gbbFooterTotalContainer {
    /* KORREKTUR (Round 26, 5. Feedback-Batch, "zu bunt"-Rueckmeldung): die
       helle Pillenflaeche (war #d9ebb1) entfernt - Merles Wunsch "wie die
       nicht ausgewaehlten Box-Auswahl-Kacheln, also zarte helle Kontur,
       helle Schrift, kein BG". Live bestaetigt: dieser Container sitzt auf
       .gbbBundleFooter, dessen Hintergrund selbst dunkelgruen ist
       (#092f01) - eine helle Kontur + helle Schrift passt dort als
       zurueckhaltender "Chip"-Look, ohne eine zusaetzliche bunte Flaeche. */
    background-color: transparent !important;
    border: 1px solid #e3f3c6 !important; /* KORREKTUR (7. Batch): Merle wollte hier explizit #e3f3c6, nicht das im 6. Batch vereinheitlichte #f4ffdb */
    color: #e3f3c6 !important;
    border-radius: 999px !important;
    display: inline-flex !important;
    flex-direction: row !important;
    align-items: center !important;
    justify-content: flex-start !important;
    padding: 0.5em 1em !important;
  }
}

/* ---------------------------------------------------------------- 59.
   GBBFOOTERACTIONCONTAINER AUF DESKTOP: GESAMTPREIS-PILLE UND "ZUR KASSE"-
   BUTTON GLEICH BREIT MIT KLEINEM GAP Laut Screenshot/Devtools-Grid-Overlay
   hat dieser Container native Spalten im Verhaeltnis auto/0.5fr/0.5fr -
   obwohl 0.5fr/0.5fr an sich gleich sein sollte, wirkte die Gesamtpreis-
   Pille auf dem Screenshot deutlich breiter als der Kasse-Button. Vermutung:
   ihr Inhalt (Label+Preis, nicht umbrechend) drueckt die fr-Spalte ueber
   ihren Anteil hinaus, da reine fr-Spalten nicht unter ihren Inhalt
   schrumpfen. Fix: eigene 2-Spalten-Definition mit minmax(0,1fr) statt
   fr allein (verhindert, dass eine Spalte durch ihren Inhalt breiter wird
   als die andere) + kleiner Gap + beide Kinder auf volle Spaltenbreite
   gestreckt. Noch nicht live verifiziert - bitte gegenchecken, ob der
   Container tatsaechlich genau diese zwei Kinder (Gesamtpreis-Pille,
   Kasse-Button) in dieser Reihenfolge enthaelt.
   KORREKTUR (Round 23): Bedingung um Handy-Quer erweitert, siehe Abschnitt
   44 oben. */
@media screen and (min-width: 750px), screen and (orientation: landscape) and (max-height: 500px) {
  body .gbbFooterActionContainer {
    display: grid !important;
    grid-template-columns: minmax(0, 1fr) minmax(0, 1fr) !important;
    gap: 0.5em !important;
    align-items: center !important;
  }
  body .gbbFooterActionContainer > * {
    width: 100% !important;
    min-width: 0 !important;
    justify-self: stretch !important;
  }
  body .gbbFooterActionContainer .gbbFooterTotalContainer {
    justify-content: center !important;
  }
}

/* ---------------------------------------------------------------- 60.
   GBBFOOTERNEXTBUTTON AUF DESKTOP: TEXT LAEUFT UEBER (Merles Meldung 7.10.,
   Teil 15: "im gbbFooterTotalContainer laeuft der Text ueber
   gbbBundleTotalWrapper und gbbFooterTotalValueContainer wegen
   gbbFooterDiscountedTotalValue und gbbFooterNextButton"). Live per Chrome
   nachgesehen (echte Struktur bestaetigt: .gbbFooterNextButton enthaelt als
   natives CSS-Grid mit grid-auto-flow:column + grid-template-columns:auto
   auto auto genau drei Felder nebeneinander - "zur Kasse", "•" und
   .gbbFooterTotalContainer mit "Gesamt (inkl. Versand)" + "€39.99"). Die
   dritte Spalte ist nativ auf "auto" (= max-content, schrumpft nicht unter
   ihren Inhalt), bei overflow:visible auf dem Grid-Container - sobald unsere
   eigene Pillen-Gestaltung (Abschnitt 58 oben, padding+border-radius:999px)
   dort mehr Platz braucht, als der Button insgesamt hergibt, laeuft der
   Inhalt sichtbar ueber den Button-Rand hinaus, statt zu schrumpfen oder
   umzubrechen.
   AUSDRUECKLICHER HINWEIS: ich konnte das NICHT live auf echter Desktop-
   Breite nachstellen - mein Chrome-Sandbox-Fenster ist auf ca. 500px
   Breite gedeckelt (dieselbe Einschraenkung wie bei anderen Desktop-Themen
   in dieser Datei), die echte Struktur/Klassen habe ich aber live bestaetigt.
   Fix: dritte Spalte auf minmax(0, auto) statt auto (darf jetzt schrumpfen,
   statt den Button zu sprengen), zusaetzlich flex-wrap auf der Pille selbst
   (faellt Label+Preis nicht mehr nebeneinander rein, bricht stattdessen auf
   eine zweite Zeile um) + Button-Hoehe auf auto statt fix, damit eine
   zweite Zeile ueberhaupt Platz hat. Bitte auf deinem Desktop-Fenster
   gegenchecken, ob das reicht oder ob du mir lieber einen Screenshot
   schickst, dann kann ich gezielter nacharbeiten.
   KORREKTUR (Round 23): Bedingung um Handy-Quer erweitert, siehe Abschnitt
   44 oben.
   KORREKTUR (Round 24, 8.10., Merles Meldung mit 3 Screenshots aus der
   Shopify-Theme-Editor-Desktop-Vorschau): der Text laeuft bei schmaleren
   FENSTERBREITEN auf echtem Desktop (unabhaengig von Handy-Quer/Orientierung)
   weiterhin ueber - diesmal hart abgeschnitten mitten im Wort ("Gesamt
   (inkl. Versan"), ohne Umbruch und ohne Ellipse. AUSDRUECKLICHER HINWEIS:
   ich hatte in dieser Runde KEINEN funktionierenden Zugriff auf meinen
   Chrome-Sandbox (die Erweiterung hat auf mehrere Versuche hin nicht mehr
   geantwortet) - der folgende Zusatz-Fix ist dadurch eine reine
   Schaetzung/Code-Analyse, NICHT live nachgestellt, bitte unbedingt
   gegenchecken. Vermutete Ursache: der obige flex-wrap:wrap auf
   .gbbFooterTotalContainer laesst nur ganze KIND-Elemente (Label-Wrapper,
   Wert-Wrapper) in eine neue Zeile umbrechen - laut unserer eigenen
   DOM-Referenz (claude/easy-bundles-sdk-reference.md) liegt der eigentliche
   Text aber in den Blatt-Elementen ".gbbFooterTotalLabel" ("Gesamt") und
   ".gbbFooterDiscountedTotalValue" ("€39.99"). Falls diese selbst (oder ein
   Zwischen-Element) per nativer EB-CSS auf white-space:nowrap stehen, bringt
   das Umbrechen der Eltern-Flexbox nichts - der Text innerhalb des Blatt-
   Elements kann trotzdem nicht umbrechen und laeuft stattdessen sichtbar
   ueber dessen eigenen Rand hinaus statt sich zu einer zweiten Zeile zu
   falten. Fix: white-space auf allen Nachfahren von .gbbFooterTotalContainer
   explizit zurueckgesetzt, damit der Browser bei echtem Platzmangel auch
   INNERHALB des Labels umbrechen kann, statt hart abzuschneiden - zusaetzlich
   overflow:visible als Sicherheitsnetz, falls eine native EB-Pillenform mit
   overflow:hidden das Abschneiden zusaetzlich verursacht. */
@media screen and (min-width: 750px), screen and (orientation: landscape) and (max-height: 500px) {
  body .gbbFooterNextButton {
    grid-template-columns: auto auto minmax(0, auto) !important;
    height: auto !important;
    min-height: 38px !important;
    overflow: visible !important;
  }
  body .gbbFooterTotalContainer {
    flex-wrap: wrap !important;
    max-width: 100% !important;
    overflow: visible !important;
  }
  body .gbbFooterTotalContainer .gbbBundleTotalWrapper,
  body .gbbFooterTotalContainer .gbbFooterTotalValueContainer {
    min-width: 0 !important;
  }
  body .gbbFooterTotalContainer,
  body .gbbFooterTotalContainer * {
    white-space: normal !important;
    overflow-wrap: break-word !important;
    word-break: normal !important;
  }
}

/* ---------------------------------------------------------------- 66.
   GESAMTPREIS-PILLE NEU: LABEL IMMER EINZEILIG + KLEINER, PREIS DARUNTER
   ZENTRIERT. Merles neuer, expliziter Wunsch (Round 26, 9-Screenshot-
   Feedback): "gesamt inkl versand kann viel kleiner (immer auf eine zeile)
   und der preis dann je nach div groesse zentriert darunter oder besser
   rechts daneben". Der Round-24-Fix oben (Abschnitt 60) hat bewusst
   white-space:normal erzwungen, damit das Label bei Platzmangel INNERHALB
   sich selbst umbrechen kann statt abgeschnitten zu werden - das loest das
   Ueberlaufen, sieht bei starker Verengung aber genauso "komisch" aus wie
   von Merle jetzt bemaengelt (mehrzeiliger Label-Text in einer runden
   Pillenform). Mit dieser Regel hier nicht mehr noetig: das Label bleibt
   jetzt selbst klein + garantiert einzeilig (white-space:nowrap, kleinere
   Schrift), der Preis wandert bei echtem Platzmangel in die naechste Zeile
   darunter - WARUM "darunter" statt "daneben": die Alternative ("daneben")
   haette eine weitere eigene Breiten-Bedingung gebraucht (ab wann ist genug
   Platz fuer nebeneinander?) - genau diese Art von Breakpoint-Entscheidung
   hat in dieser Datei wiederholt zu Luecken gefuehrt (siehe z.B. den
   639px/749px-Mismatch weiter oben). Die gestapelte, zentrierte Variante
   braucht dagegen gar keine eigene Breite-Bedingung und funktioniert robust
   bei JEDER Breite in diesem Bereich - deshalb hier bewusst die robustere
   statt die (optisch vielleicht minimal kompaktere) schmalere Variante
   gewaehlt. Noch nicht live verifiziert (gleiche Sandbox-Einschraenkung wie
   beim Abschnitt direkt ueber diesem) - bitte an deinem Fenster
   gegenchecken. */
@media screen and (min-width: 750px), screen and (orientation: landscape) and (max-height: 500px) {
  body .gbbFooterTotalContainer {
    flex-direction: column !important;
    align-items: center !important;
    justify-content: center !important;
    gap: 0.1em !important;
    padding: 0.4em 1em !important;
  }
  body .gbbFooterTotalContainer .gbbFooterTotalLabel {
    white-space: nowrap !important;
    font-size: 0.68em !important;
    overflow: visible !important;
  }
  body .gbbFooterTotalContainer .gbbFooterDiscountedTotalValue {
    white-space: nowrap !important;
    font-size: 1.05em !important;
    font-weight: 600 !important;
  }
}

/* NEU (Round 28, 31. Batch): Merle meldet fuer Handy-QUER konkret "Gesamt
   zzgl. Versand laeuft wieder ueber sein div hinaus, sollte hinter 'Gesamt'
   umbrechen". Root Cause: der Abschnitt-66-Fix direkt oberhalb erzwingt
   bewusst "white-space:nowrap" auf ".gbbFooterTotalLabel", damit das Label
   ("Gesamt (zzgl. Versand)") auf EINER Zeile bleibt - das geht aber nur gut,
   solange genug Breite dafuer da ist (normale Desktop-Sidebar). Die echte
   Handy-Quer-Sidebar-Spalte ist dafuer oft zu schmal, nowrap verhindert dann
   zwar das Umbrechen, aber nicht das Ueberlaufen - der Text laeuft sichtbar
   ueber den Rand der Pille hinaus (durch "overflow:visible" sogar ohne
   Abschneiden sichtbar). Fix: nur fuer echtes Handy-Quer (schmaler als die
   generische Breakpoint-Grenze oben) "white-space" auf dem Label wieder auf
   normal zurueckgesetzt, damit es bei Bedarf genau an der Wortgrenze (nach
   "Gesamt") umbricht statt zu ueberlaufen - "Gesamt" bleibt dadurch eine
   eigene Zeile, "(zzgl. Versand)"/"(inkl. Versand)" faellt bei Platzmangel
   automatisch in die naechste. Noch NICHT live verifiziert (siehe Projekt-
   Doku), bitte gegenchecken. */
@media screen and (min-width: 750px) and (orientation: landscape) and (max-height: 500px) {
  body .gbbFooterTotalContainer .gbbFooterTotalLabel {
    white-space: normal !important;
    text-align: center !important;
  }
}

/* NEU (Round 27, 3. Batch): Merle "Gesamt inkl. Versand und der Preis
   muessen in der Konturfarbe des Divs sein". Live gemessen: der Rand
   (border) von .gbbFooterTotalContainer ist #e3f3c6 (helles Creme-Gruen),
   aber Label ("Gesamt (inkl. Versand)") UND Preis ("€39.99") waren bisher
   nativ dunkelgruen (#092f01) - deutlich sichtbarer Farbbruch zur eigenen
   Kontur. Fix: beide Textfarben auf denselben Ton wie der Rand gesetzt. */
body .gbbFooterTotalContainer .gbbFooterTotalLabel,
body .gbbFooterTotalContainer .gbbFooterDiscountedTotalValue,
body .gbbFooterTotalContainer .gbbBundleTotalWrapper {
  color: #e3f3c6 !important;
}

/* ---------------------------------------------------------------- 66b.
   GESAMTPREIS-PILLE (STANDALONE-VARIANTE) NICHT ZENTRIERT BEI "DESKTOP KURZ
   VOR HANDY HOCHKANT" (Round 26, 4. Feedback-Batch, Merles Punkt 4). Laut
   unserer eigenen DOM-Referenz (claude/easy-bundles-sdk-reference.md) gibt es
   ZWEI ".gbbFooterTotalContainer"-Instanzen: eine verschachtelt im "zur
   Kasse"-Button (".gbbFooterActionContainer ... .gbbFooterTotalContainer" -
   dafuer sorgt Abschnitt 59 oben bereits fuer echte Zentrierung der Pille
   SELBST, nicht nur ihres Inhalts), und eine eigenstaendige Geschwister-
   Instanz direkt daneben (".gbbFooterTotalContainer.gbbFooterStandaloneTotal").
   Die Abschnitte 44/66 oben zentrieren bei dieser zweiten, eigenstaendigen
   Instanz bisher nur ihren INHALT (Label ueber Preis) - die Pille bleibt
   dabei "inline-flex" mit auto-Breite (= Breite des eigenen Inhalts) und
   haengt mangels jeglicher Zentrierungs-Regel auf Elternebene am linken Rand,
   statt selbst mittig zu sitzen. Das passt zu Merles Meldung "Preis-Pille bei
   dieser Fensterbreite nicht zentriert". Fix: nur fuer diese Standalone-
   Instanz (eigene Klasse ".gbbFooterStandaloneTotal", beeinflusst die bereits
   per Abschnitt 59 zentrierte verschachtelte Instanz nicht) zusaetzlich per
   margin-inline:auto als Block zentriert.
   AUSDRUECKLICHER HINWEIS: per DOM-Referenz begruendet, aber NICHT live bei
   der genauen Fensterbreite nachgestellt (meine Chrome-Sandbox laesst sich
   nicht auf echte schmale Desktop-Breiten bringen) - bitte gegenchecken, ob
   das die von dir gemeinte Pille ist und ob sie jetzt zentriert sitzt. */
@media screen and (min-width: 750px), screen and (orientation: landscape) and (max-height: 500px) {
  body .gbbFooterTotalContainer.gbbFooterStandaloneTotal {
    display: flex !important;
    width: fit-content !important;
    margin-inline: auto !important;
  }
}

/* ---------------------------------------------------------------- 66c.
   GESAMTPREIS-PILLE: GBBBUNDLETOTALWRAPPER + GBBFOOTERTOTALVALUECONTAINER
   WEITERHIN NICHT MITTIG (Round 27, 7. Feedback-Batch). Merle "hat irgendwas
   mit den columns zu tun". Live (meine Sandbox, 500px Mobil-Breite, kein
   echter Desktop moeglich - gleiche Einschraenkung wie Abschnitt 60/66/66b
   oben) per getComputedStyle nachgemessen: BEIDE Elemente sind selbst
   natives CSS-Grid mit EIGENEN grid-template-columns (z. B. bei
   .gbbFooterTotalValueContainer: "49.59px 0px") und nativem
   justify-content:start - auf Mobil macht das aktuell keinen sichtbaren
   Unterschied, weil die Elemente dort exakt so breit wie ihr Inhalt sind
   (kein Leerraum zum Zentrieren vorhanden). Auf Desktop/in der breiteren
   Pille (Abschnitt 59/66 oben, die den AEUSSEREN Flex-Container bereits
   mit align-items:center zentrieren) werden diese beiden Kind-Elemente
   aber vermutlich auf die volle Breite gestreckt - dann sorgt ihr EIGENES,
   natives justify-content:start dafuer, dass der tatsaechliche Inhalt
   (Text/Preis) innerhalb der eigenen Box weiterhin links haengt, statt in
   der jetzt breiteren Box zu zentrieren. Das passt zu "hat was mit den
   columns zu tun" (ihre eigenen Grid-Spalten, nicht die des Eltern-Grids).
   Fix: justify-content:center direkt auf beiden Elementen selbst gesetzt -
   auf Mobil per Live-Test bestaetigt wirkungslos/unschaedlich (kein
   Leerraum vorhanden, siehe oben), auf Desktop sollte es den Inhalt
   innerhalb der eigenen, jetzt breiteren Box zentrieren.
   AUSDRUECKLICHER HINWEIS: NICHT auf echter Desktop-Breite visuell
   verifizierbar (Sandbox-Einschraenkung), bitte unbedingt gegenchecken,
   ob das jetzt mittig sitzt oder ob eine andere, mir nicht sichtbare
   Ursache dahintersteckt. */
body .gbbBundleTotalWrapper,
body .gbbFooterTotalValueContainer {
  justify-content: center !important;
}
/* NEU (Round 28/Batch 19): Merle hat den eigentlichen Rest-Grund gefunden -
   ".gbbBundleTotalWrapper" hatte bisher keine eigene Breite, konnte sich
   dadurch gar nicht ueber die volle Laenge des Eltern-Divs strecken, um sich
   darin per justify-content:center (siehe Regel oben) tatsaechlich mittig
   auszurichten. width:100% ergaenzt, NUR auf diesem einen Element (nicht
   zusaetzlich auf .gbbFooterTotalValueContainer, laut Merles Befund). */
body .gbbBundleTotalWrapper {
  width: 100% !important;
}

/* ---------------------------------------------------------------- 45. H6
   SITE-WEIT WIEDER AUF DIE NATIVE THEME-GROESSE ZURUECKGESETZT h6 auf
   Startseite/Gutschein-Seite zu gross - nur "Dein Energiekick fuer den Tag"
   soll groesser bleiben. Ursache: ganz oben in der Datei ein unscoped "h6 {
   font-size: 1.6vw !important; }" ohne Media-Query, macht jedes nackte h6 auf
   Desktop zu gross und ueberschreibt die native Theme-Logik (Mobil ist
   bereits ueber die clamp()-Regel abgesichert). "Dein Energiekick..." bleibt
   ueber eine eigene, spezifischere Regel (Abschnitt 36 Punkt 7) unveraendert.
   Fix: die unscoped Basis-Regel entfernt - h6 faellt auf Desktop wieder auf
   die native Theme-Groesse zurueck.
   ---------------------------------------------------------------- */

/* ---------------------------------------------------------------- 46.
   TORTELLONI/GERICHTE: MOBIL JETZT GRID STATT KARUSSELL, 3 SPALTEN Die Mobil-
   Ansicht wurde im Theme-Editor von Karussell auf natives Grid umgestellt.
   Die alten Karussell-Fixes (Abschnitt 6/31/31b/38/43) werden dadurch
   wirkungslos - bewusst nicht entfernt, falls das Karussell spaeter
   zurueckkommt. Neu: 3 Spalten erzwungen (minmax(0,1fr) statt 1fr, wie beim
   Easy-Bundles-Grid) + --column-count gesetzt, falls Horizon darueber steuert
   - bitte live gegenchecken.
   ---------------------------------------------------------------- */
@media screen and (max-width: 749px) {
  #shopify-section-template--31616257655114__product_list_WCk8kE .resource-list.resource-list--grid,
  #shopify-section-template--31616257655114__product_list_gPQqGm .resource-list.resource-list--grid {
    --column-count: 3 !important;
    grid-template-columns: repeat(3, minmax(0, 1fr)) !important;
    /* AB 2.10., Merles Wunsch: Abstand zwischen den Karten deutlich verkleinert. */
    gap: 2px !important;
  }
}
/* NEU (Round 28/Batch 18): Merle "auf Handy quer bitte 5 Spalten auch bei
   dem Gerichtraster" (ausdruecklich NICHT das Boxraster, das hat bereits
   seine eigene 5-Spalten-Regel - siehe Abschnitt "Handy Quer: auch bei den
   Boxen 5 Spalten"). Die obige max-width:749px-Regel deckt echte Handy-Quer-
   Breiten oft NICHT ab (dieselbe Breite-vs-Hoehe-Erkennungsluecke wie an
   anderen Stellen in dieser Datei - ein Handy im Querformat ist haeufig
   breiter als 749px) - eigene, hoehenbasierte Regel ergaenzt, analog zum
   Boxraster. HINWEIS zum before-shadow (Abschnitt 6b, dieselbe Section
   WCk8kE): der Schatten haengt an der einzelnen Produktkarte selbst (nicht
   an der Spaltenzahl), sollte also unabhaengig von 3 vs. 5 Spalten an Ort
   und Stelle bleiben - konnte in der Sandbox aber nicht live mit einer
   echten 5-Spalten-Karte gegengeprueft werden, bitte trotzdem kurz
   gegenchecken. */
@media screen and (orientation: landscape) and (max-height: 500px) {
  #shopify-section-template--31616257655114__product_list_WCk8kE .resource-list.resource-list--grid,
  #shopify-section-template--31616257655114__product_list_gPQqGm .resource-list.resource-list--grid {
    --column-count: 5 !important;
    grid-template-columns: repeat(5, minmax(0, 1fr)) !important;
    gap: 2px !important;
  }
}

/* ---------------------------------------------------------------- 47.
   TORTELLONI/GERICHTE-GRID: PRODUKTTITEL (H5) VERKLEINERN, ANGEGLICHEN AN DIE
   BOXEN-TITEL-GROESSE Im neuen Grid-Layout (Abschnitt 46) rendert Horizon den
   Titel als echtes <h5>, die site-weite unscoped Basis-Regel macht ihn
   dadurch zu gross (derselbe Bug-Typ wie h6, Abschnitt 45). Basis-Regel nicht
   angefasst (h5 wird anderswo genutzt) - stattdessen nur die beiden Grid-
   Sections gescoped, an die Boxen-Titel-Groesse angeglichen (Schaetzwert).
   Bitte live gegenchecken.
   ---------------------------------------------------------------- */
#shopify-section-template--31616257655114__product_list_WCk8kE .resource-list--grid h5,
#shopify-section-template--31616257655114__product_list_gPQqGm .resource-list--grid h5 {
  font-size: 1.2rem !important;
}
@media screen and (max-width: 749px) {
  #shopify-section-template--31616257655114__product_list_WCk8kE .resource-list--grid h5,
  #shopify-section-template--31616257655114__product_list_gPQqGm .resource-list--grid h5 {
    font-size: clamp(1rem, 4vw, 1.2rem) !important;
  }
}

/* ---------------------------------------------------------------- 48. BOXEN-
   KARUSSELL/GRID: KEINE HOVER-VERGROESSERUNG DES TITELS AUF MOBIL Box-Titel
   (jetzt im Raster, Abschnitt 47) sollen auf dem Handy nicht mehr animiert
   groesser werden. Betroffene Regel (transform:scale(1.12), Abschnitt 17) auf
   Mobil zurueckgenommen, Desktop-Hover bleibt.
   ---------------------------------------------------------------- */
@media screen and (max-width: 749px) {
  #shopify-section-template--31616257655114__product_list_cyt63E .product-card:hover .product-card__content p[role="heading"],
  #shopify-section-template--31616257655114__product_list_cyt63E .product-card.pv-hover-inview .product-card__content p[role="heading"] {
    transform: none !important;
  }
}

/* ---------------------------------------------------------------- 49. BOXEN-
   GRID: "JETZT FUELLEN"-BUTTONS UNTEN AUSRICHTEN Im Raster haben Karten je
   nach Textlaenge unterschiedliche Innenhoehe, der Button sitzt dadurch
   versetzt. Fix: Karte + Content-Container auf volle Zeilenhoehe, Button
   bekommt margin-top:auto (Standard-Flexbox-Muster). Best effort ohne Live-
   Zugriff, bitte gegenchecken.
   ---------------------------------------------------------------- */
@media screen and (max-width: 749px) {
  #shopify-section-template--31616257655114__product_list_cyt63E .product-card {
    height: 100% !important;
  }
  #shopify-section-template--31616257655114__product_list_cyt63E .product-card__content {
    height: 100% !important;
  }
  #shopify-section-template--31616257655114__product_list_cyt63E .pv-product-btn {
    margin-top: auto !important;
  }
}

/* ---------------------------------------------------------------- 50. "DEIN
   ENERGIEKICK FUER DEN TAG": WIEDER VERKLEINERN Abschnitt 36 Punkt 7 hatte
   dies um +25% vergroessert, um sich abzuheben. Seit Abschnitt 45 (h6 wieder
   kleiner) wirkt der Wert jetzt zu gross. Auf ca. 70% reduziert (Schaetzwert,
   bitte gegenchecken) - gewinnt per !important + spaeterer Position gegen
   Abschnitt 36 Punkt 7.
   ---------------------------------------------------------------- */
body .text-block--AV1BRNS9lQ1ZYMVhXV__text_R3WjXt.h6 :is(h1, h2, h3, h4, h5, h6) {
  /* KORREKTUR (Round 27, 4. Batch): Merle "minimal kleiner" - um ca. 8-9%
     reduziert (war 1.75vw). Schaetzwert fuer "minimal", bitte gegenchecken. */
  font-size: 1.6vw !important;
}
/* NEU (Round 27): "Dein Energiekick fuer den Tag" - Merle "font-weight light
   und #b3cc84". Unscoped, da Font-Weight/Farbe unabhaengig vom Breakpoint
   gelten sollen (nur die Schriftgroesse ist bereits an mehreren Stellen
   breakpoint-abhaengig geregelt, siehe oben/unten).
   KORREKTUR (Round 27, 4. Batch): Merle erneut "weniger font-weight". Live
   geprueft (document.fonts): die hier verwendete Schriftart "co-headline"
   hat NUR zwei echte Schriftschnitte geladen - 400 (normal) und 700 (fett).
   "lighter" (bzw. jeder Wert unter 400, z.B. 100/300) hat KEINE eigene Datei
   und faellt deshalb automatisch auf den 400er-Schnitt zurueck - der Browser
   kann eine Schrift nicht "erfinden", die nicht geladen ist. Das heisst: die
   bisherige Regel aendert am tatsaechlichen Erscheinungsbild nichts (sieht
   exakt wie font-weight:400 aus), und ich kann es per font-weight technisch
   NICHT weiter reduzieren, ohne dass ein echter duennerer Schriftschnitt
   (z.B. "co-headline Light/Thin", 100 oder 300) im Theme hochgeladen/
   eingebunden wird. Als Ersatz-Option (nicht umgesetzt, erst auf
   Rueckmeldung): Opacity leicht reduzieren, um die Schrift optisch "leichter"
   wirken zu lassen, ohne den Schriftschnitt selbst zu aendern - bitte sagen,
   ob das gewuenscht ist. */
body .text-block--AV1BRNS9lQ1ZYMVhXV__text_R3WjXt.h6 :is(h1, h2, h3, h4, h5, h6) {
  font-weight: lighter !important;
  color: #b3cc84 !important;
}
@media screen and (max-width: 749px) {
  /* AB 7.10. (Teil 8): Merle meldet "Dein Energiekick fuer den Tag ist auch
     zu klein" - Root Cause: diese Regel hier (Abschnitt 50, steht WEITER
     UNTEN in der Datei als Abschnitt 36 Punkt 7 und gewinnt deshalb bei
     gleicher Spezifitaet) hatte die Groesse auf ca. 70% zurueckgenommen, was
     die dortige Vergroesserung faktisch unwirksam gemacht hat. Jetzt wieder
     angehoben (war clamp(0.8rem, 3.8vw, 1.1rem)), diesmal etwas ueber den
     Abschnitt-36-Wert hinaus, wie gewuenscht.
     KORREKTUR (7.10., Teil 12): Merle "Energiekick fuer den Tag kleiner" -
     um ca. 13% reduziert (war clamp(1.15rem, 5.2vw, 1.5rem)). Schaetzwert,
     bitte live gegenchecken. */
  body .text-block--AV1BRNS9lQ1ZYMVhXV__text_R3WjXt.h6 :is(h1, h2, h3, h4, h5, h6) {
    font-size: clamp(1rem, 4.5vw, 1.3rem) !important;
  }
}

/* ---------------------------------------------------------------- 51. PV-
   TAGLINE: LETZTE PILLE WIRD ABGESCHNITTEN Vermutlich: die Mobil-Regel fuer
   kurze Pillen erzwingt "white-space: nowrap !important" - bei langem Text
   reicht das auf schmalen Screens nicht mehr. Der Anti-Scroll-Fix
   (overflow-x:clip, Abschnitt 32) verhindert das Wegscrollen, der Ueberstand
   wird dadurch sichtbar abgeschnitten. Fix: nowrap zurueckgenommen + harte
   max-width als Netz.
   ---------------------------------------------------------------- */
@media screen and (max-width: 749px) {
  body .pv-tagline {
    white-space: normal !important;
    max-width: 92vw !important;
    overflow-wrap: break-word !important;
  }
}

/* ---------------------------------------------------------------- 52. ICON-
   TITEL-TEXT-SEKTIONEN (section_rPB8Wx & section_KtXkqU): SCHRIFT WIEDER
   ETWAS GROESSER Dieselbe Section-Art wie Abschnitt 9. h2/p laufen ueber die
   native Theme-Formel, daher relativ zur Theme-Variable gerechnet statt
   Absolutwert geraten. AB 2.10., Merles Wunsch ("wieder etwas größer" bei p,
   "minimal" bei den Ueberschriften): Faktoren von 0.75/0.55 auf 0.85/0.60
   angehoben (Schaetzwerte, bitte live gegenchecken und bei Bedarf weiter
   nachjustieren). Zusaetzlich jetzt auch auf section_KtXkqU gespiegelt - laut
   section-ids-referenz.md identisch aufgebaut, bisher aber nur rPB8Wx
   gescoped.
   ---------------------------------------------------------------- */
#shopify-section-sections--31616257786186__section_rPB8Wx h2,
#shopify-section-sections--31616257786186__section_KtXkqU h2 {
  font-size: calc(var(--font-h2--size) * 0.60) !important; /* war 0.55 (nur rPB8Wx) */
}
#shopify-section-sections--31616257786186__section_rPB8Wx p,
#shopify-section-sections--31616257786186__section_KtXkqU p {
  font-size: calc(var(--font-paragraph--size) * 0.85) !important; /* war 0.75 (nur rPB8Wx) */
}

/* NEU (Round 28/Batch 14): Merle "kannst du die Icons sowie die h2
   (Gekühlte Lieferung, Haltbarkeit etc.) doch 8% kleiner machen? und den h2
   dort vielleicht ein minimales letterspacing geben? 0.01em oder so?" -
   genau diese Section (live bestaetigt: h2-Text "Gekühlte Lieferung" liegt
   in section_rPB8Wx). Live gemessen VOR dieser Aenderung (950px-Fenster):
   Icon 52x52px, h2 27.36px, letter-spacing normal.
   Icons per transform:scale(0.92) verkleinert statt width/height, damit die
   umgebende Flex-/Grid-Box ihre urspruengliche Groesse behaelt und sich
   nichts in der Zeile verschiebt (dieselbe Technik wie an anderen Stellen
   dieser Datei fuer reine optische Verkleinerungen). Die bestehende
   h2-Formel oben (0.60-Faktor) wird fuer die zusaetzlichen 8% um denselben
   Faktor (*0.92) erweitert, statt eine zweite, konkurrierende Regel
   anzuhaengen - rechnerisch identisch zu 0.552, aber die Herkunft (0.60 *
   die neuen 8%) bleibt im Code nachvollziehbar. */
#shopify-section-sections--31616257786186__section_rPB8Wx h2,
#shopify-section-sections--31616257786186__section_KtXkqU h2 {
  font-size: calc(var(--font-h2--size) * 0.60 * 0.92) !important;
  letter-spacing: 0.01em !important;
}
#shopify-section-sections--31616257786186__section_rPB8Wx img,
#shopify-section-sections--31616257786186__section_KtXkqU img {
  transform: scale(0.92) !important;
}
/* NEU (Round 28, 21. Batch): Merle "icons im footer gerne auf dem handy noch
   6% kleiner" - zusaetzlich zur bestehenden, siteweiten 8%-Reduktion oben
   (scale(0.92)), nur auf Mobil. 0.92 * 0.94 (weitere 6%) = 0.8648,
   gerundet 0.865. Desktop bleibt unveraendert bei 0.92. */
@media screen and (max-width: 749px) {
  #shopify-section-sections--31616257786186__section_rPB8Wx img,
  #shopify-section-sections--31616257786186__section_KtXkqU img {
    transform: scale(0.865) !important;
  }
}

/* NEU (Round 28/Batch 18): Merle, Footer-Icon-Titel-Abstand - "auf allen
   Queries 20% weniger Abstand zwischen Iconbild und Titel, auf dem Handy
   zusaetzlich ueber dem Icon 10% mehr Platz".
   KORREKTUR (Round 28/Batch 19): der Batch-18-Selektor war eine Annahme
   (".group-block.group-block--height-fit..."), Merle hat jetzt die
   tatsaechlichen, live bestaetigten Klassen durchgegeben: der aeussere
   Reihen-Container (haelt alle Icon+Titel-Gruppen nebeneinander, wird per
   ".mobile-column" auf Mobil zur Spalte - DAS ist der "Platz ueber dem
   naechsten Icon" zwischen den GRUPPEN) und der innere Spalten-Container pro
   einzelner Gruppe (Icon ueber Titel - DAS ist der "Abstand zwischen
   Iconbild und Titel"). Alte Regel (oben beschrieben) ersetzt. */
#shopify-section-sections--31616257786186__section_KtXkqU .group-block-content.layout-panel-flex.layout-panel-flex--column.mobile-column,
#shopify-section-sections--31616257786186__section_rPB8Wx .group-block-content.layout-panel-flex.layout-panel-flex--column.mobile-column {
  gap: calc(var(--gap, 16px) * 0.8) !important;
}
/* NEU (Round 28, 21. Batch): Merle "die gaps geringer... etwas noch
   runterdrehen" - derselbe Selektor wie direkt oben (Icon<->Titel-Abstand
   innerhalb einer Gruppe), zusaetzlich fuer Mobil weiter reduziert (0.8 ->
   0.65 des Theme-Gaps). Desktop bleibt beim 0.8-Faktor oben. */
@media screen and (max-width: 749px) {
  #shopify-section-sections--31616257786186__section_KtXkqU .group-block-content.layout-panel-flex.layout-panel-flex--column.mobile-column,
  #shopify-section-sections--31616257786186__section_rPB8Wx .group-block-content.layout-panel-flex.layout-panel-flex--column.mobile-column {
    gap: calc(var(--gap, 16px) * 0.65) !important;
  }
}
@media screen and (max-width: 749px) {
  #shopify-section-sections--31616257786186__section_KtXkqU .spacing-style.layout-panel-flex.layout-panel-flex--row.section-content-wrapper.mobile-column,
  #shopify-section-sections--31616257786186__section_rPB8Wx .spacing-style.layout-panel-flex.layout-panel-flex--row.section-content-wrapper.mobile-column {
    gap: calc(var(--gap, 16px) * 1.1) !important;
  }
}

/* ---------------------------------------------------------------- 57.
   BOXENRASTER: H6-ABSTAND NACH OBEN NEU Neue Regel, gab es noch nicht.
   ---------------------------------------------------------------- */
.text-block--AeFJqMm91Ri9Jc0Zra__text_FFyJjp h6 {
  padding-block-start: 7px;
}
/* AB 7.10. (Mobil-Feedback-Batch): duenner (weniger font-weight), auf
   Wunsch - gilt bewusst ueberall (Desktop + Mobil). */
.text-block--AeFJqMm91Ri9Jc0Zra__text_FFyJjp h6 {
  font-weight: 400 !important;
}
/* AB 7.10. (2. Korrektur): die Verkleinerung (90%) war faelschlich
   ungescoped und griff dadurch auch auf dem Desktop - sollte aber nur fuer
   Mobil-Hochformat gelten. Jetzt auf den Breakpoint beschraenkt. */
@media screen and (max-width: 749px) and (orientation: portrait) {
  .text-block--AeFJqMm91Ri9Jc0Zra__text_FFyJjp h6 {
    font-size: 90% !important;
  }
}
/* NEU (Round 26): Merles Meldung "'Frisch von Planet V gekocht, ab Erhalt
   mindestens 20 Tage haltbar [...]' wird viel zu gross" bei den schmaleren
   Desktop-Fensterbreiten. Live per Chrome nachvollzogen und root-caused
   (KEINE Schaetzung): die generische Ueberschriften-Regel oben in dieser
   Datei ("Abschnitt 4: body h6 { font-size: clamp(1.05rem, 4.2vw, 1.55rem)
   !important; }", gescoped auf max-width:1199px) wurde fuer Mobilgeraete
   gedacht, hat aber eine rechnerische Luecke: der bevorzugte Wert 4.2vw
   erreicht den oberen clamp()-Deckel (1.55rem = 24.8px) bereits bei
   24.8/0.042 = ca. 590px Fensterbreite - ab da bis zur 1199px-Obergrenze
   bleibt die Schrift konstant auf dem Mobil-Maximalwert (24.8px) haengen,
   statt wie auf echtem breitem Desktop (>=1200px, dort greift die native
   Theme-Groesse) auf ca. 16px zurueckzufallen (live bei 1400px gemessen:
   genau 16px = 1rem). Dieser "Plateau-Bereich" (590-1199px) deckt sich
   praktisch exakt mit allen von Merle getesteten schmaleren
   Fensterbreiten (737/761/830/1101px). Fix: fuer genau dieses Textelement
   in diesem Bereich hart auf den Desktop-Wert (1rem) zurueckgesetzt, statt
   an der generischen h3-h6-Regel selbst zu schrauben (die bleibt fuer
   andere h6-Elemente unangetastet). */
@media screen and (min-width: 590px) and (max-width: 1199px) {
  .text-block--AeFJqMm91Ri9Jc0Zra__text_FFyJjp h6 {
    font-size: 1rem !important;
  }
}
/* Die "Trennlinie darunter" ist KEIN ::after/hr an der Text-Block-Klasse
   selbst, sondern ein eigenstaendiges, natives "Divider"-Block-Element
   direkt als naechstes Geschwister im DOM (live gefunden am 7.10., ueber
   mehrere Sessions hinweg gesucht). Die Dicke wird dort nicht per
   border-width, sondern per CSS-Custom-Property "--divider-border-thickness"
   (aktuell inline 3px) auf dem inneren .divider__line-Element gesetzt - hier
   gezielt fuer genau diesen einen Divider duenner gesetzt. */
.divider-AWHZyeDJzeW9Jd0thY__divider_dy8VM4 .divider__line {
  --divider-border-thickness: 1px !important;
}

/* ---------------------------------------------------------------- 58.
   BOXENRASTER: PREIS NUR AUF MOBIL KLEINER (Gerichtanzahl/Titel/Beschreibung/
   Button bleiben unberuehrt - nur der sichtbare Boxpreis selbst.)
   ---------------------------------------------------------------- */
@media screen and (max-width: 749px) {
  #shopify-section-template--31616257655114__product_list_cyt63E .price {
    font-size: 85% !important;
  }
}

/* ---------------------------------------------------------------- 53.
   FOOTER-NEWSLETTER-BLOCK: LOGO/INSTAGRAM-FIX ROBUSTER GEMACHT Der
   urspruengliche Hoehen-Bug wurde im Theme-Editor behoben, der Flex-
   Container wird jetzt als "--column.mobile-column" beschrieben (vorher "--
   row.mobile-column", siehe Abschnitt 41) - die Basis-Richtung hat sich
   offenbar geaendert. Der bestehende Fix (align-self:center/order) sollte
   davon unabhaengig funktionieren, verliess sich aber darauf, dass der
   Container weiterhin align-items:flex-end hat, damit Instagram rechts
   bleibt. Falls sich das geaendert hat, wuerde das Icon nicht mehr
   zuverlaessig rechts stehen. Hier daher zusaetzlich explizites align-
   self:flex-end direkt auf dem Icon, unabhaengig vom Container-Wert -
   funktioniert in Zeile und Spalte gleichermassen (align-self meint immer die
   Querachse).
   ---------------------------------------------------------------- */
#shopify-section-sections--31616257786186__footer_m9NzUG .logo-block {
  align-self: center !important;
  order: 1 !important;
}
#shopify-section-sections--31616257786186__footer_m9NzUG .social-icons__wrapper {
  align-self: flex-end !important;
  order: 2 !important;
  margin-top: 12px !important;
}

/* ---------------------------------------------------------------- 54.
   .gbbProductsFooterHTMLForMobile: PADDING-BOTTOM AUF 0 (29.9., Folge-Runde
   13). AB 7.10. (Punkt 24) auf Wunsch zu komplettem padding:0 erweitert. */
body .gbbProductsFooterHTMLForMobile {
  padding: 0 !important;
}
/* AB 7.10. (Punkt 22): Merles eigener Live-Test hatte hier schon
   padding-bottom:1px auf .gbbFooterActionContainer gesetzt - auf ihren
   explizit genannten Wunschwert (2px) korrigiert. */
body .gbbProductsFooterHTMLForMobile .gbbFooterActionContainer {
  padding-bottom: 2px !important;
}

/* ---------------------------------------------------------------- 55. NAV-
   DRAWER WIRD WIEDER VON .gbbBundleFooter VERDECKT TROTZ HOEHEREM Z-INDEX:
   STACKING-CONTEXT-FALLE Der Drawer (z-index:100000) wird wieder von
   .gbbBundleFooter (9999) verdeckt, obwohl 100000 > 9999. Ursache: die native
   Regel ".header-section:has(#header-component[sticky="always"]) { position:
   sticky; z-index: var(--layer-menu-drawer); }" gibt der aeusseren .header-
   section beim gestickten Header einen eigenen z-index und erzeugt damit
   einen neuen Stacking-Context. Ein position:fixed-Element befreit sich zwar
   aus dem Dokumentfluss, nicht aber aus dem Stacking-Context eines Vorfahren
   - der Drawer-z-index wird also nur gegen seine Geschwister innerhalb der
   Section verglichen, nicht gegen .gbbBundleFooter (das auf Body-Ebene
   liegt). Die eigentliche Konkurrenz findet eine Ebene hoeher statt: .header-
   section (niedriger Theme-Wert) gegen .gbbBundleFooter (9999) - und verliert
   mit allem, was in ihr liegt. Fix: .header-section im gestickten Zustand
   einen deutlich hoeheren z-index geben als alle anderen Werte in dieser
   Datei. KORREKTUR: die erste Fassung war unscoped und griff auf jeder Seite
   - danach verschwand auf der Alle-Gerichte-Seite die (vermutlich selbst
   sticky) Filter-Sidebar unter dem jetzt viel hoeheren Header. Das Nav-
   Drawer-Problem tritt aber nur bei offenem Hamburger-Menue auf - dafuer gibt
   es bereits die native Klasse ".page-wrapper--drawer-open". Fix darauf
   eingegrenzt, Header wird nur bei offener Schublade hochgezogen. */
.page-wrapper--drawer-open .header-section:has(#header-component[sticky="always"]),
.page-wrapper--drawer-open .header-section:has(#header-component[sticky="scroll-up"][data-sticky-state="active"]) {
  z-index: 100001 !important;
}

/* AB 2.10. (Phase 2): laut Merle immer noch verdeckt trotz obigem Fix.
   Zusaetzliche Absicherung, da zwei Dinge unklar sind: (1) ob .gbbBundleFooter
   ueberhaupt ein DOM-Nachkomme von .page-wrapper ist (falls Easy Bundles den
   Drawer direkt an <body> anhaengt, greift die Abstammungs-Regel oben gar
   nicht, egal wie hoch der z-index wird), und (2) ob irgendeiner der beiden
   Drawer technisch per <dialog>/Popover-API gerendert wird - dort zaehlt fuer
   die Stapelreihenfolge nicht der z-index-Wert, sondern nur die
   Oeffnungs-Reihenfolge im Browser-"Top-Layer". Statt weiter um einen
   hoeheren z-index zu konkurrieren: solange die Schublade offen ist (Klasse
   .page-wrapper--drawer-open), wird der EB-Cart-Drawer direkt unsichtbar +
   nicht-interaktiv gemacht - er wird waehrend offenem Hamburger-Menue ohnehin
   nicht gebraucht. :has() an body gebunden statt als Abstammungs-Selektor,
   damit es unabhaengig davon funktioniert, wo im DOM .gbbBundleFooter
   tatsaechlich sitzt.
   KORREKTUR (7.10., per Screenshot bestaetigt): Merle zeigte den Hamburger-
   Nav-Drawer offen, WAEHREND darunter/daneben weiterhin die untere Leiste
   mit Mengen-Ausklapp-Button ("^7"), Preis-Schieberegler und "zur Kasse"-
   Button sichtbar blieb. Root Cause: diese untere Leiste gehoert laut
   easy-bundles-sdk-reference.md NICHT zu .gbbBundleFooter (das sitzt weiter
   oben im Dokumentfluss, zusammen mit Box-Auswahl/Rabatt-Fortschritt),
   sondern zu einem eigenen, zweiten Container ".gbbProductsFooterHTMLForMobile"
   (enthaelt u.a. .gbbDrawer.gbbCartDrawer, .gbbFooterTotalContainer und
   .gbbFooterActionContainer mit dem "zur Kasse"-Button) - der bisher
   NICHT mitgescoped war und deshalb weiterhin ueber dem Nav-Drawer lag.
   Fix: beide Container gemeinsam ausblenden, solange die Schublade offen
   ist. */
/* AB 7.10. (Fix 2): ".page-wrapper--drawer-open" existiert in diesem Theme
   nicht (live geprueft: die Klasse taucht im DOM nie auf) - der Selektor hat
   deshalb nie gegriffen. Das Nav-Drawer-Menue ist technisch ein natives
   <details class="menu-drawer-container"> innerhalb von <header-drawer>,
   das beim Oeffnen das Attribut "open" sowie die Klasse "menu-open" erhaelt.
   Darauf jetzt korrekt gescoped. */
body:has(header-drawer details[open]) .gbbBundleFooter,
body:has(header-drawer details[open]) .gbbProductsFooterHTMLForMobile {
  visibility: hidden !important;
  pointer-events: none !important;
}
/* ---------------------------------------------------------------- 60.
   TAGLINE-SEKTION (section_fB7FHf): "V"-LOGO ALS HINTERGRUND HINTER DEN
   TAGLINE-PILLEN. Selektor ueber :has() direkt an die Pillen-Reihen
   (.pv-tagline-row) gebunden, damit zuverlaessig nur das Div dahinter
   getroffen wird, nicht die ganze Sektion.
   AB 7.10.: Merle hat sich GEGEN die Animation entschieden (bisherige
   @keyframes-Regel daher entfernt statt nur auskommentiert, "animation"
   unten ebenfalls raus) - das Logo steht jetzt fest. Merle moechte
   ausserdem das per mask-image eingebundene SVG noch AUSTAUSCHEN
   (aktuell "Element_60.svg" als Platzhalter) - sobald die neue Datei da
   ist, bitte nur die beiden mask-image-URLs unten ersetzen, der Rest
   (Groesse/Farbe/Position) bleibt gleich. Die alte doppelt eingefuegte URL
   in der -webkit-mask-image-Zeile war ein Copy-Paste-Fehler (URL stand
   zweimal hintereinander) - hier bereinigt. */
#shopify-section-template--31616257655114__section_fB7FHf div:has(> .pv-tagline-row) {
  position: relative !important;
}
#shopify-section-template--31616257655114__section_fB7FHf div:has(> .pv-tagline-row)::before {
  content: "" !important;
  position: absolute !important;
  /* KORREKTUR (Round 27): Merle hat live im Inspector top:45% (war 50%)
     getestet und per Screenshot bestaetigt. */
  top: 45% !important;
  left: 50% !important;
  /* KORREKTUR (Round 19): Merle "oh gott bitte kleiner" - von 260px/85% auf
     160px/55% verkleinert. Schaetzwert (ca. 40% kleiner als vorher), bitte
     live gegenchecken ob das klein genug ist. Gilt weiterhin als Basis-/
     Mobil-Groesse, Desktop hat eine eigene, groessere Breakpoint-Regel
     weiter unten. */
  width: 160px !important;
  max-width: 55% !important;
  aspect-ratio: 1 / 1 !important;
  /* KORREKTUR (Round 27): Merle hat live #b3cc84 getestet (war #a4cb8d) und
     per Screenshot bestaetigt. */
  background-color: #b3cc84 !important;
  /* KORREKTUR (Round 18/19): schrittweise auf 0.1 abgeschwaecht.
     KORREKTUR (Round 27): Merle hat live 0.7 getestet und per Screenshot
     bestaetigt - deutlich kraeftiger als die bisherigen 0.1. */
  opacity: 0.7 !important;
  /* AB 7.10. (Teil 12): Platzhalter "Element_60.svg" durch Merles finale
     Datei ersetzt. */
  -webkit-mask-image: url("/cdn/shop/files/pvtaglinebg.svg?v=1791401317") !important;
  mask-image: url("/cdn/shop/files/pvtaglinebg.svg?v=1791401317") !important;
  -webkit-mask-size: contain !important;
  mask-size: contain !important;
  -webkit-mask-repeat: no-repeat !important;
  mask-repeat: no-repeat !important;
  -webkit-mask-position: center !important;
  mask-position: center !important;
  pointer-events: none !important;
  z-index: 0 !important;
  transform: translate(-50%, -50%) !important;
}
#shopify-section-template--31616257655114__section_fB7FHf div:has(> .pv-tagline-row) > * {
  position: relative !important;
  z-index: 1 !important;
}
/* KORREKTUR (Round 23, Merles Wunsch "svg groesser auf dem Desktop", Antwort
   auf meine Rueckfrage "welches SVG?"): die Verkleinerung aus Round 19 (260px/
   85% -> 160px/55%) war ohne Breakpoint, galt also ueberall, auch auf
   Desktop. Hier auf echtem breitem Desktop wieder naeher an die urspruengliche
   Groesse herangefuehrt (220px/75% - zwischen dem alten 260px/85% und dem
   jetzigen mobilen 160px/55%, da unklar ist, ob Merle die GENAU alte Groesse
   oder nur "etwas groesser" meint). Mobil/iPad/Handy-Quer bleiben unveraendert
   bei 160px/55%. Schaetzwert, bitte live gegenchecken und sagen ob mehr/
   weniger gewuenscht ist.
   KORREKTUR (Round 26): Merle "SVG kann 10% groesser noch" - von 220px/75%
   um 10% auf 242px/82.5% erhoeht.
   KORREKTUR (Round 26, 2. Teil): Bedingung um den dritten "quadratischer/
   hochformatiger Desktop"-Zweig erweitert - siehe die ausfuehrliche
   Begruendung beim ersten Vorkommen dieser Media Query weiter oben in der
   Datei (Webkit-Text-Stroke-Abschnitt). Ohne diesen Zweig blieb das SVG in
   einem quadratischen/hochformatigen Desktop-Fenster auf der kleineren
   Mobil-Groesse (160px/55%) haengen. */
@media screen and (min-width: 1200px), screen and (min-width: 750px) and (orientation: landscape) and (min-height: 501px), screen and (min-width: 750px) and (max-width: 1199px) and (orientation: portrait) {
  #shopify-section-template--31616257655114__section_fB7FHf div:has(> .pv-tagline-row)::before {
    /* KORREKTUR (Round 27): Merle hat live 262px/100.5% getestet und per
       Screenshot bestaetigt (war 242px/82.5%). */
    width: 262px !important;
    max-width: 100.5% !important;
  }
}
/* NEU (Round 28/Batch 17): Merle, Tagline-Feedback (a) - "auf dem Desktop
   before svg noch 14% weniger Opacity". Nur fuer echten breiten Desktop
   (>=1200px), NICHT fuer den schmaleren Bereich direkt darunter (siehe
   naechste Regel) und nicht fuer Mobil (behaelt die Basis-Opacity 0.7
   weiter oben). 0.7 * 0.86 = 0.602. */
@media screen and (min-width: 1200px) {
  #shopify-section-template--31616257655114__section_fB7FHf div:has(> .pv-tagline-row)::before {
    opacity: 0.602 !important;
  }
}
/* NEU (Round 28/Batch 17): Merle, Tagline-Feedback (b) - "wenn man das
   Browserfenster schmaler zieht, werden die tagline pills nicht mehr
   gesperrt sondern zentriert, dann schneidet das before-svg die 100%-Zeile".
   Root Cause: dieser "schmalere Desktop"-Bereich (750-1199px, Maus) bekam
   bisher DIESELBE grosse SVG-Groesse (262px) wie der echte breite Desktop
   (Regel direkt oberhalb) - bei weniger verfuegbarer Breite ragt das SVG
   dadurch ueber/durch die jetzt zentrierte statt gesperrte Pillen-Reihe.
   Eigene, kleinere Zwischengroesse nur fuer genau diesen Bereich (zwischen
   der Mobil-Groesse 160px/55% und der Desktop-Groesse 262px/100.5%) -
   Schaetzwert, bitte live gegenchecken ob es jetzt nicht mehr schneidet.
   Der z-index-Wunsch ("wenn schon ueberlappend, dann dahinter") ist bereits
   erfuellt - die Pillen stehen ueber dem SVG (z-index 1 vs. 0, siehe
   Abschnitt "60." oben). */
@media screen and (min-width: 750px) and (max-width: 1199px) and (orientation: portrait) {
  #shopify-section-template--31616257655114__section_fB7FHf div:has(> .pv-tagline-row)::before {
    width: 190px !important;
    max-width: 66% !important;
  }
}

/* NEU (Round 28/Batch 18): Merle "das before svg hinter der pv tagline row
   ist noch da: bitte verschwinden lassen bei sehr kleinen Bildschirmen".
   AUSDRUECKLICHER HINWEIS: kein exakter Breakpoint genannt - 400px als
   Schaetzwert fuer "sehr klein" gewaehlt (deckt z.B. iPhone SE/kleinere
   Android-Handys hochkant ab, bleibt aber deutlich unter der allgemeinen
   Mobil-Grenze von 749px, damit "normale" Handy-Breiten das Hintergrund-SVG
   weiterhin zeigen). Bitte live gegenchecken, ob die Grenze an der richtigen
   Stelle liegt.
   KORREKTUR (Round 28, 54. Batch): Merle meldet erneut, das Geister-Logo-SVG
   sei auf kleinen Bildschirmen weiterhin sichtbar - die 400px-Grenze war zu
   eng gefasst (dieselbe Art "Breakpoint-Luecke" wie an anderen Stellen in
   diesem Projekt): viele normale Handy-Breiten liegen ueber 400px (z.B.
   414-430px bei groesseren iPhones), fielen durch diese Regel und zeigten
   das SVG weiterhin. Auf den im Projekt etablierten Standard-Schwellwert
   fuer "kleine Bildschirme" (749px, Handy hochkant) angehoben - deckt jetzt
   alle Handy-Breiten ab, nicht nur die kleinsten. */
@media screen and (max-width: 749px) {
  #shopify-section-template--31616257655114__section_fB7FHf div:has(> .pv-tagline-row)::before {
    display: none !important;
  }
}
/* NEU (Round 28, 28. Batch): Merle, per Screenshot bestaetigt - auf Handy
   quer (Breite deutlich ueber 400px, also von der Regel direkt oberhalb
   nicht erfasst) ist das Geister-Logo-SVG weiterhin sichtbar hinter den
   Tagline-Pillen. Gleiche Idee wie bei der "sehr kleine Bildschirme"-Regel
   oben, nur zusaetzlich fuer Querformat mit geringer Fensterhoehe (dieselbe
   "Handy quer"-Bedingung wie an anderen Stellen dieser Datei, z.B. bei der
   Gutschein-Seite). */
@media screen and (orientation: landscape) and (max-height: 500px) {
  #shopify-section-template--31616257655114__section_fB7FHf div:has(> .pv-tagline-row)::before {
    display: none !important;
  }
}

/* NEU (Round 28, 28. Batch): Merle "pvtaglinepills bitte in der Breite auf
   den Inhalt beschraenken, dass der pinke/rosa Hintergrund nicht die
   gesamte Seite fuellt" (Screenshot: Handy quer, die langen Satz-Pillen
   wie "In wenigen Minuten servierfertig", "Moderne Rezepte von Koechen mit
   Koennen"). AUSDRUECKLICHER HINWEIS/Korrektur eigener Annahme: ich hatte
   zuerst eine eigene Klasse ".pv-tagline--long" vermutet (weiter oben in
   dieser Datei definiert) - live nachgeprueft (echte Seite): diese Klasse
   kommt im aktuellen Markup NIRGENDS vor (0 Treffer), die langen Satz-
   Pillen sind technisch ganz normale ".pv-tagline.bio/.innovativ/.lecker"-
   Elemente, nur mit laengerem Textinhalt - sie sind bereits inline-flex/
   content-breit (kein eigenes width:100%). Das "volle Seite"-Aussehen auf
   Handy quer kommt vermutlich einfach daher, dass ein langer Satz ohne
   eigene max-width-Grenze schon fast die komplette Zeilenbreite braucht,
   um in eine Zeile zu passen. Fix: auf Handy quer/kleinen Bildschirmen eine
   max-width ergaenzen, die kleiner ist als die volle Reihenbreite - der Satz
   bricht dadurch auf 2 Zeilen um, die Pille (und ihr rosa Hintergrund beim
   Scroll-Trigger) bleibt schmaler. Wirkt sich nur auf die LANGEN Pillen aus
   (die kurzen "100% X"-Pillen sind ohnehin schon deutlich schmaler als
   dieser Wert). SCHAETZWERT (75%), bitte live gegenchecken, ob die
   Zeilenumbrueche so aussehen wie gewuenscht - ggf. weiter verkleinern. */
@media screen and (orientation: landscape) and (max-height: 500px) {
  body .pv-tagline {
    max-width: 75% !important;
  }
}

/* KORREKTUR (Round 26): Merle "wird [die Tagline-Sektion] schmaler, brauchen
   die Taglines mehr Abstand zueinander [...] das passiert ab dem Punkt wo
   das Boxraster auch sein Div sprengt" - also im selben "schmaler Desktop"-
   Bereich wie der Box-Raster-Ueberlauf (Abschnitt b2 weiter oben). Die
   Basis-Regel (.pv-tagline-row, ganz oben in der Datei) nutzt dort
   justify-content:space-between mit nur 10px gap - bei Zeilenumbruch in
   diesem Breitenbereich zieht das die Pillen auseinander bis an den
   Rand, der Abstand dazwischen wirkt dadurch viel zu klein. Merle: Schrift-
   /Letter-Spacing-Unterschied zu Mobil ist ausdruecklich okay ("das ist
   eigentlich okay") - hier daher bewusst NUR der Abstand angefasst, nicht
   Schriftgroesse/-sperrung.
   KORREKTUR (Round 26, 2. Feedback-Runde): Obergrenze von 1099px auf 1199px
   angehoben, synchron zur jetzt ueberall einheitlichen "echter Desktop"-
   Grenze (1200px). */
@media screen and (min-width: 640px) and (max-width: 1199px) {
  body .pv-tagline-row {
    justify-content: center !important;
    gap: 22px !important;
    row-gap: 16px !important;
  }
  /* NEU (Round 28/Batch 17): Merle, Tagline-Feedback (d) - "lieber noch
     einen Breakpoint wo 100% pflanzlich und 100% innovativ in einer Reihe
     stehen und 100% lecker darunter", statt dass die Reihe beim Hover durch
     das Groesserwerden "springt" (das Springen selbst entsteht vermutlich,
     weil mal alle 3, mal nur 2 nebeneinander passen, je nach Hover-Zustand).
     Fix: drittes Element (.lecker) bekommt hier erzwungen die volle
     Zeilenbreite als flex-basis - bei flex-wrap:wrap (siehe .pv-tagline-row
     Basisregel) rutscht es dadurch IMMER alleine in die naechste Zeile,
     unabhaengig von Hover-Wachstum/exakter Pixelbreite der ersten zwei. */
  /* KORREKTUR (Round 28, 69. Batch, NOTFALL): der vorherige Scoping-Versuch
     (Round 28, 65. Batch) auf die Headline-SECTION-ID war immer noch falsch
     und hat NICHTS behoben: "Nicht pasteurisiert" ist NICHT "anderswo auf
     der Seite" (falsche Annahme damals), sondern steht im selben Abschnitt
     #section_fB7FHf, nur weiter unten in der langen Vorteils-Pillen-Liste -
     zusammen mit "Frisch gekocht", "Nicht tiefgekuehlt", "Moderne Rezepte
     von Koechen mit Koennen" und "100% recyclebare Verpackung...", die alle
     ebenfalls (inhaltlich voellig zu Recht) die Kategorie-Klasse ".lecker"
     tragen. Die Section-ID-Scope-Regel traf dadurch weiterhin ALLE diese
     Pillen gleichzeitig und zwang sie alle auf volle Breite - sichtbar genau
     so im von Merle geschickten Screenshot. ECHTER Fix jetzt: statt der
     ganzen Section nur noch der tatsaechliche Headline-Wrapper
     ".pv-tagline-headline" (siehe Abschnitt 4/mittlere Datei, "100%
     pflanzlich. 100% innovativ. 100% lecker") als Vorfahre - das ist das
     einzige Element, das NUR die drei "100% X"-Headline-Phrasen enthaelt,
     nicht die lange Pillen-Liste darunter. */
  .pv-tagline-headline .pv-tagline.lecker {
    flex-basis: 100% !important;
  }
}
/* NEU (Round 28/Batch 17): Merle, Tagline-Feedback (c) - "wenn man bei
   schmalerem Fenster einmal die Trigger gehovert hat, bleibt alles pink
   auch bei onmouseout, es muss wieder gruen werden". Das ist das bekannte
   "sticky hover"-Problem auf Touch-Geraeten (kein echtes :hover-Ereignis
   beim Antippen weg) - dasselbe Muster wie an anderen Stellen in dieser
   Datei bereits geloest (siehe z.B. Abschnitt 3, Scroll-in-View). Setzt
   Hintergrund/Groesse explizit zurueck, sobald KEIN echtes Hover-Geraet
   vorhanden ist (@media hover:none) - betrifft also genau die Faelle, in
   denen :hover auf dem Geraet ohnehin nie zuverlaessig funktioniert. */
/* KORREKTUR (Round 28, 20. Batch): Merle "pv taglines werden nicht mit
   rosa" - Root Cause gefunden (Code-Analyse): diese Touch-Sticky-Hover-
   Reset-Regel und die Scroll-Trigger-Farbregel weiter oben
   (".pv-tagline.pv-scroll-active", Abschnitt 18) haben EXAKT dieselbe
   Spezifitaet (body + 2 Klassen) - bei Gleichstand gewinnt die spaetere
   Regel im Stylesheet, das ist hier diese hier. Die Pille traegt beim
   Scroll-Trigger gleichzeitig ihre feste Farb-Klasse (.bio/.innovativ/
   .lecker) UND .pv-scroll-active - die Reset-Regel hier griff dadurch auch
   in genau dem Moment, in dem die Pille eigentlich rosa werden sollte, und
   setzte sie sofort wieder auf Gruen zurueck. Fix: die Reset-Regel per
   :not(.pv-scroll-active) gezielt ausnehmen, wenn der Scroll-Trigger gerade
   aktiv ist - das urspruengliche Sticky-Hover-Problem (Pille bleibt nach
   Antippen rosa haengen, obwohl kein Scroll-Trigger mehr aktiv ist) bleibt
   fuer alle anderen Faelle weiterhin behoben. */
@media (hover: none) {
  body .pv-tagline:hover:not(.pv-scroll-active),
  body .pv-tagline.bio:not(.pv-scroll-active),
  body .pv-tagline.innovativ:not(.pv-scroll-active),
  body .pv-tagline.lecker:not(.pv-scroll-active) {
    background-color: #e3f3c6 !important;
    transform: none !important;
  }
}

/* ---------------------------------------------------------------- 61.
   GROSSER MOBIL-FEEDBACK-BATCH 7.10.2026 (Teil 1) - neue, bisher noch nicht
   vorhandene Regeln aus Merles Mobil-Durchgang (Alle-Gerichte, Hero,
   Box-Raster, PV-Tagline). Alle auf max-width:749px gescopt, wo es sich um
   reine Mobil/Touch-Anpassungen handelt.
   ---------------------------------------------------------------- */

/* Box-Raster: Untertitel-Textblock soll 90vw breit sein. */
@media screen and (max-width: 749px) {
  body [class*="text-block--AK20zZ3gyR0NUQUkyN__text_FdHcdh"].text-block--full-width {
    width: 90vw !important;
  }
}

/* Box-Raster: Boxbilder sollen beim automatisch simulierten Hover
   (.pv-hover-inview, siehe mobile-fixes.js Abschnitt 1 - Scroll-in-View als
   Hover-Ersatz fuer Touch) NICHT mehr vergroessert werden (Layout-Sprung in
   der zweiten Spalte), nur die Farbe darf sich weiter aendern.
   KORREKTUR 8.10.: Merle meldete "die Probierbox wird beim Scrollen ploetzlich
   groesser, das Raster springt" / "Boxbilder Spalte 2 werden beim Hover
   vergroessert" - der Fix oben war die eigentliche URSACHE, nicht die Loesung!
   Live nachgemessen (getComputedStyle + getBoundingClientRect vor/nach Setzen
   von .pv-hover-inview): das Bild selbst traegt sitebreit permanent eine
   eigene Basis-Regel ".product-media-container.media-fit:first-of-type img
   { transform: scale(0.83); }" (etwas verkleinert/rund zugeschnitten, siehe
   oben in dieser Datei) - das ist der NORMALE Ruhezustand, keine Hover-Regel.
   Der Fix oben hat genau diesen Element per ".card-gallery img" miterfasst
   und im Hover/Scroll-Zustand auf "transform:none" (= volle Groesse, 1.0)
   gesetzt - dadurch ist das Bild beim Reinscrollen von 0.83 auf 1.0
   gewachsen, also um satte +20%, statt wie beabsichtigt gleich zu bleiben.
   .card-gallery selbst und .product-media hatten nie eine eigene Skalierung
   (live bestaetigt: transform vorher UND nachher "none") - die betreffen also
   gar nichts, nur das <img> war das eigentliche Problem. Fix: das Bild im
   Hover/Scroll-Zustand stattdessen explizit auf seiner Ruhe-Skalierung
   (0.83) festhalten, statt auf "none" zurueckzusetzen - damit bleibt es
   optisch exakt gleich gross, es aendert sich nur noch die Farbe. */
@media screen and (max-width: 749px) {
  #shopify-section-template--31616257655114__product_list_cyt63E .product-card:hover .product-media-container.media-fit:first-of-type img,
  #shopify-section-template--31616257655114__product_list_cyt63E .product-card.pv-hover-inview .product-media-container.media-fit:first-of-type img {
    transform: scale(0.83) !important;
  }
}

/* Box-Raster: die Boxbilder sind zu klein, weil auf den .card-gallery-Divs
   (ueber Inline-Custom-Properties, "spacing-style"/"border-style") diverse
   Paddings liegen (--padding-block-start/-end, --padding-inline-start/-end).
   Alle auf 0 gesetzt, damit das Bild den vollen Platz ausfuellt. ACHTUNG:
   danach vermutlich wieder uneinheitlich (je nach Bild-Seitenverhaeltnis) -
   Merles Idee war, dann ggf. nochmal 5% kleiner zu gehen; das NICHT
   vorab mit eingebaut, da sie das noch nicht final entschieden hat - bitte
   nach dem Live-Check sagen, ob/um wie viel. */
#shopify-section-template--31616257655114__product_list_cyt63E .card-gallery {
  --padding-block-start: 0px !important;
  --padding-block-end: 0px !important;
  --padding-inline-start: 0px !important;
  --padding-inline-end: 0px !important;
}

/* KORREKTUR (7.10.): Merle meldet weiterhin ein "springendes" Probier-Box-
   Bild. Live per getComputedStyle/getAttribute nachgemessen: die Padding-
   Regel oben GREIFT bereits korrekt (computed padding-top: 0px) - das
   eigentliche Springen kommt von einer anderen, bisher unbeachteten
   Inline-Custom-Property auf demselben Element: "--gallery-aspect-ratio"
   (von Horizons eigenem card-gallery-Custom-Element gesetzt, Werte live
   gemessen zwischen 0,994 und 0,999 - je Karte LEICHT unterschiedlich,
   vermutlich aus dem jeweils tatsaechlichen Bild-Seitenverhaeltnis
   berechnet). Dazu kommt ein inline gesetztes "min-height" in Pixeln, das
   bei manchen Karten beim ersten Messen noch fehlte (vermutlich von
   Horizons eigenem, asynchron nachlaufendem Hoehen-Sync-Skript gesetzt) -
   dieses verspaetete Nachsetzen war die urspruengliche Erklaerung fuer das
   sichtbare "Springen". Ursprünglicher Fix (seitdem wieder geaendert, siehe
   Korrektur direkt darunter): eigene, synchron beim ersten Rendern
   feststehende aspect-ratio (fester Wert statt der variierenden
   --gallery-aspect-ratio) plus min-height:0, damit die Kartenhoehe nie mehr
   von einem nachtraeglich laufenden Skript abhaengt.

   KORREKTUR (7.10., nach Merles eigenem Live-Fund per Theme-Editor-
   Inspector): genau diese "min-height:0 !important"-Zeile war der ECHTE,
   lange gesuchte Root Cause fuer den Groessenunterschied zwischen Probier-
   Box und Single-Box (nicht Badge-Elemente, nicht Safari-Eigenheiten, wie
   zwischenzeitlich vermutet) - Merle hat live im Theme Editor nachgewiesen:
   deaktiviert man NUR diese min-height:0-Zeile (aspect-ratio:1/1 bleibt),
   werden beide Boxen sofort gleich gross. Deshalb hier entfernt.
   EHRLICHER HINWEIS ZUR URSPRUENGLICHEN BEGRUENDUNG: diese Zeile wurde
   damals genau deshalb eingefuehrt, um das oben beschriebene "springende
   Bild" (Horizons asynchrones Hoehen-Sync-Skript) zu verhindern - durch das
   Entfernen koennte dieses Springen theoretisch zurueckkommen. Da Merles
   Messung aber eindeutig zeigt, dass die Zeile in der Praxis mehr Schaden
   (falsche Kartengroessen) als Nutzen anrichtet, wird sie trotzdem erstmal
   entfernt. Bitte auf dem Handy beobachten: wenn das alte "Springen" beim
   Laden wieder auftaucht, bitte melden - dann brauchen wir einen gezielteren
   Fix statt der pauschalen min-height:0-Regel (z. B. per JS die Hoehe erst
   NACH dem Laden des Bildes einmalig fixieren, statt sie dauerhaft auf 0 zu
   zwingen). */
#shopify-section-template--31616257655114__product_list_cyt63E .card-gallery {
  aspect-ratio: 1 / 1 !important;
}

/* KORREKTUR (7.10., Teil 6): du meldest weiterhin "Single-Box ist immer noch
   zu gross" (echter, wiederholt gemessener Unterschied auf deinem Geraet -
   bei mir im Sandbox-Test leider nicht nachstellbar, da dort gar keine
   echten Produktbilder laden/koennen, siehe Chat). Live am DOM gefunden:
   jede ".card-gallery" traegt ein Attribut "data-image-ratio" mit dem Wert
   "adapt" - das ist (nach allem, was der Name + Horizons bekanntes Verhalten
   nahelegt) eine Shopify-Horizon-eigene Einstellung, die die Box bewusst an
   das Seitenverhaeltnis DES JEWEILIGEN BILDES anpasst, statt sie fix zu
   quadrieren - vermutlich ueber ein eigenes, asynchron nachlaufendes Skript
   (daher auch nur auf dem Handy mit echten, nacheinander ladenden Bildern
   sichtbar, nicht in meinem bilderlosen Test). Das erklaert, warum meine
   aspect-ratio:1/1-Regel das nur TEILWEISE aussticht: sie gewinnt den
   Ratio-Kampf meistens, aber offenbar nicht IMMER/zuverlaessig gegen das
   staendig neu nachgesetzte Skript. ZUSAETZLICH zur bestehenden Regel oben
   jetzt auch die Breite hart fixiert (nicht nur das Verhaeltnis) UND das Bild
   selbst aus dem normalen Fluss genommen (absolute, volle Flaeche, object-fit
   cover) - damit kann auch ein individuelles Bild-Seitenverhaeltnis die Box
   nicht mehr beeinflussen, selbst wenn das Skript weiterhin eigene Werte
   nachsetzt. WICHTIGER HINWEIS: die vermutlich zuverlaessigere Lösung waere,
   im Theme-Editor fuer diesen Produktlisten-Block die Einstellung
   "Bildverhaeltnis"/"Image ratio" von "An Bild anpassen" ("Adapt") auf
   "Quadratisch"/"Square" umzustellen, falls Horizon das dort anbietet - das
   wuerde das Skript direkt an der Quelle abschalten statt es nur zu
   ueberschreiben. Bitte einmal nachsehen, das waere der robustere Fix. */
#shopify-section-template--31616257655114__product_list_cyt63E .card-gallery {
  width: 100% !important;
}
/* Live nachgemessen: zwischen .card-gallery (korrekt exakt quadratisch,
   264.1x264.1px) und dem <img> liegen noch ".product-media-container" und
   ".product-media" - beide hatten eine EIGENE, leicht abweichende Groesse
   (265x265.672px - nicht quadratisch), unabhaengig von der quadratischen
   Groesse ihres Grosselternelements. Alle drei Ebenen jetzt hart per
   position:absolute/inset:0 auf 100% des (bereits quadratischen)
   .card-gallery gepinnt - live verifiziert: Probier-Box und Single-Box
   danach beide exakt 264.1x264.1px.
   KORREKTUR (7.10., Teil 13): Merle meldet "bei der Probier-Box springts
   immer noch" - Versuch: <img> per aspect-ratio/height:auto von der
   (potenziell schwankenden) Container-Hoehe entkoppeln statt height:100%.
   SOFORT WIEDER ZURUECKGENOMMEN (7.10., Teil 14): dieser Versuch hat auf
   Merles echtem iPhone eine viel schlimmere Regression verursacht - bei den
   Mehrbild-Karten (We-are-family-Box, Mystery-Box) wurde das eigentliche
   Produktfoto auf einen winzigen Rest oben links zusammengeschrumpft,
   dahinter wurde ein riesiger rosa Kreis sichtbar (vermutlich der native
   Platzhalter-/Ladefarbe-Kreis hinter dem Bild, der vorher exakt vom Foto
   verdeckt wurde). Die genaue Ursache (vermutlich ein Safari-spezifisches
   Zusammenspiel von aspect-ratio + object-fit + position:absolute + einem
   Prozent-width auf dem <img> bei dieser Karussell-Struktur) ist NICHT
   abschliessend geklaert - dafuer braeuchte es Live-Zugriff auf das
   tatsaechliche DOM. Da der Schaden (fast verschwindendes Produktbild)
   erheblich schlimmer ist als das urspruengliche, seltene Springen, hier
   komplett auf den vorherigen, bekannt stabilen Stand zurueckgesetzt
   (position:absolute/inset:0/height:100% fuer Container UND <img>, wie vor
   diesem Versuch). Das Springen-Problem selbst bleibt dadurch wieder offen -
   siehe Aufgabenliste, braucht beim naechsten Anlauf eine Live-Untersuchung
   statt eines weiteren Rate-Versuchs. */
#shopify-section-template--31616257655114__product_list_cyt63E .card-gallery .product-media-container,
#shopify-section-template--31616257655114__product_list_cyt63E .card-gallery .product-media {
  position: absolute !important;
  inset: 0 !important;
  width: 100% !important;
  height: 100% !important;
}
#shopify-section-template--31616257655114__product_list_cyt63E .card-gallery img {
  position: absolute !important;
  inset: 0 !important;
  width: 100% !important;
  height: 100% !important;
  object-fit: cover !important;
}

/* ECHTER ROOT CAUSE GEFUNDEN UND BEHOBEN (live auf der Startseite
   reproduziert): die drei Regeln direkt oberhalb haben das Mystery-Box-Bild
   komplett verschwinden lassen. Grund: Karten mit MEHREREN Bildern (Mystery-
   Box, nicht die Einzelbild-Karten wie Probier-/Single-Box) liegen gar nicht
   direkt in ".card-gallery > a.contents > .product-media-container", sondern
   in einer zusaetzlichen, verschachtelten Karussell-Struktur dazwischen:
   .card-gallery > ... > <slideshow-component> > <slideshow-container> >
   <slideshow-slides> (position:relative, display:flex) > <slideshow-slide>
   (= genau das Element mit Klasse ".product-media-container"). Die Regel
   oben macht jedes ".product-media-container" zu position:absolute - dadurch
   fiel es aus dem Flex-Fluss von <slideshow-slides> heraus, und weil das der
   EINZIGE Inhalt war, der <slideshow-slides> ueberhaupt eine Hoehe gab,
   kollabierte dieser Container auf 0px Hoehe. Das "inset:0" der absolut
   positionierten Slide bezieht sich dann auf einen 0px hohen Rahmen -> das
   Bild selbst wird dadurch ebenfalls 0px hoch und unsichtbar (bei
   Einzelbild-Karten ohne dieses Karussell-Zwischenlayer gibt es dieses
   Problem nicht, deshalb hat der Fix dort funktioniert). Fix: die komplette
   Karussell-Kette bekommt eine erzwungene Hoehe/Breite von 100%, damit sie
   unabhaengig vom jetzt absolut positionierten Slide-Inhalt immer die volle
   Groesse von .card-gallery behaelt. */
#shopify-section-template--31616257655114__product_list_cyt63E .card-gallery slideshow-component,
#shopify-section-template--31616257655114__product_list_cyt63E .card-gallery slideshow-container,
#shopify-section-template--31616257655114__product_list_cyt63E .card-gallery slideshow-slides {
  width: 100% !important;
  height: 100% !important;
}

/* Box-Raster: mehr Abstand zwischen den Reihen, dafuer etwas weniger
   zwischen den beiden Spalten (Schaetzwerte, bitte live gegenchecken -
   genauer Ausgangswert kam aus einer Theme-eigenen CSS-Variable, die ich
   nicht auslesen kann). */
@media screen and (max-width: 749px) {
  #shopify-section-template--31616257655114__product_list_cyt63E .resource-list__carousel slideshow-slides {
    row-gap: 24px !important;
    column-gap: 6px !important;
  }
}

/* Box-Raster: Beschreibungstext breiter (95% statt 90%), nur auf Mobil -
   die 90%-Basisregel (Abschnitt "Einzelne Text-Bloecke") bleibt fuer
   Desktop unveraendert bestehen. */
@media screen and (max-width: 749px) {
  body [class*="text-block--Aa3pheDByY0ViLzV1N__text_rycJiT"] {
    width: 95% !important;
  }
}

/* ---------------------------------------------------------------- 62.
   BOX-RASTER: SPALTEN GLEICH BREIT (7.10., Merles Feedback "Single/Mystery
   sind viel groesser, scheint an der zweiten column zu liegen - unbedingt
   aendern!"). Root-Cause live gemessen: das Theme setzt fuer die 2-spaltige
   Mobil-Ansicht "grid-template-columns: repeat(2, 1fr)". Ein nacktes "1fr"
   ist aber implizit "minmax(auto, 1fr)" - jede Spalte bekommt dadurch
   MINDESTENS die Breite ihres eigenen Inhalts (hier: die durchgestrichenen
   Vergleichspreise in Spalte 2, z. B. "€71,88", sind breiter als alles in
   Spalte 1). Live gemessen (281px-Breite): Spalte 1 kam dadurch auf 167.5px,
   Spalte 2 auf 175.3px - UND in Summe ueberstieg das sogar die eigene
   Grid-Breite (gemessen: Grid-Box 249px, tatsaechlicher Inhalt 360px) -
   das Raster lief also zusaetzlich unsichtbar (overflow:visible, kein
   Scrollbalken) ueber seinen eigenen Rahmen hinaus. Fix: "minmax(0, 1fr)"
   statt nacktem "1fr" - dadurch duerfen beide Spalten echt gleich breit
   werden (kein Mindestbreiten-Fussabdruck mehr durch den Inhalt), das
   Raster bleibt innerhalb seiner Box. Live verifiziert: beide Spalten
   exakt 112.6px, keine Ueberlaufbreite mehr. HINWEIS: dadurch werden die
   Karten insgesamt schmaler als vorher (vorher durch den Overflow-Bug
   optisch "zu gross") - falls Merle die Karten dann zu klein findet, bitte
   zurückmelden, dann ueber mehr Breite fuer die Section oder weniger
   Padding/Gap nachdenken, statt wieder ungleiche Spalten zuzulassen. */
@media screen and (max-width: 749px) {
  #shopify-section-template--31616257655114__product_list_cyt63E [data-testid="resource-list-grid"] {
    grid-template-columns: repeat(2, minmax(0, 1fr)) !important;
  }
}

/* NEU (Round 28/Batch 14): Merle "kannst du einen kleinen Breakpoint
   zwischen Handy und Desktop einbauen, der 2 Spalten auf 3 Spalten
   umstellt?" - Screenshot zeigt ein eigenes, schmales Format (616x646px,
   Safari Responsive-Design-Modus). Bei dieser Breite wirken 2 Spalten
   (Karten ca. 280px) unnoetig grob/leer - 3 Spalten passen bei ca. 165-235px
   Kartenbreite (je nach genauer Fensterbreite in diesem Bereich) noch
   komfortabel. Bewusst NICHT an Hover/Pointer gekoppelt (genau wie die
   2-Spalten-Basisregel oben) - gilt also sowohl fuer schmale Tablet-/
   Phablet-Formate als auch fuer ein entsprechend schmal gezogenes
   Desktop-Fenster. Untere Grenze bei 540px gewaehlt (Kartenbreite dort
   ca. 165px, derselbe Minimalwert, den Merle fuer den Desktop-Bereich
   750-1199px bereits akzeptiert hat, siehe Abschnitt 66 oben) - darunter
   (echte, schmale Handy-Hochformate) bleibt es bei den bisherigen 2
   Spalten. Titel-Schriftgroesse/Trennung sowie die ueblichen
   Overflow-Absicherungen (min-width:0 etc.) 1:1 von den anderen
   schmalen-Spalten-Fixes (Handy-Quer, 750-1199px-Fix) uebernommen, da bei
   165-235px breiten Karten dieselbe Umbruch-/Overflow-Gefahr besteht.
   UNVERIFIZIERT in meiner Sandbox (dort nur 700px- und 950px-Fenster
   verlaesslich erreichbar, 616px nicht) - bitte bei genau dieser
   Fensterbreite gegenchecken, insbesondere ob 540px als untere Grenze
   passt oder du lieber einen anderen Umschaltpunkt haettest. */
@media screen and (min-width: 540px) and (max-width: 749px) {
  #shopify-section-template--31616257655114__product_list_cyt63E [data-testid="resource-list-grid"] {
    grid-template-columns: repeat(3, minmax(0, 1fr)) !important;
  }
  #shopify-section-template--31616257655114__product_list_cyt63E .product-card,
  #shopify-section-template--31616257655114__product_list_cyt63E .product-card__content {
    width: 100% !important;
    min-width: 0 !important;
    max-width: 100% !important;
  }
  #shopify-section-template--31616257655114__product_list_cyt63E .product-card__content * {
    min-width: 0 !important;
  }
  #shopify-section-template--31616257655114__product_list_cyt63E .product-card__content p[role="heading"] {
    font-size: 20px !important;
    line-height: 1.15 !important;
    overflow-wrap: normal !important;
    word-break: normal !important;
    hyphens: auto !important;
  }
}

/* KORREKTUR (Round 20): Merle "Handy Quer: auch bei den Boxen 5 Spalten,
   damit alle nebeneinander passen - falls es mal 6 Boxen waeren, dann
   stattdessen karussellmaessig seitlich scrollen". Aktuell existieren 5
   Boxen (Probier/Single/Family/Mystery/Office) - die 5-Spalten-Regel deckt
   den Ist-Zustand ab. Der Karussell-Fallback fuer eine moegliche 6. Box ist
   rein vorausschauend und wurde NICHT live getestet (es gibt aktuell keine
   6. Box) - bitte nach Hinzufuegen einer weiteren Box unbedingt gegenchecken.
   Technik: :has(> :nth-child(6)) erkennt rein per CSS, ob ein 6. Kind-Element
   existiert, ohne die Anzahl zu kennen/zu raten - nur dann wird von Grid auf
   ein horizontal scrollendes Flex-Karussell umgeschaltet (via
   scroll-snap-type), sonst bleibt es beim normalen 5-Spalten-Grid.
   KORREKTUR (Bugfix nach Video-Feedback): max-width:749px erkennt Handy-Quer
   nicht zuverlaessig, da echte Handys im Querformat oft breiter als 749px
   sind (z.B. iPhone 14 quer ca. 844px) - die Regel griff dadurch nie. Statt
   Breite wird jetzt die Hoehe geprueft (Handy-Quer ist immer flach, <=500px,
   waehrend Tablet-Quer deutlich hoeher ist). */
@media screen and (orientation: landscape) and (max-height: 500px) {
  #shopify-section-template--31616257655114__product_list_cyt63E [data-testid="resource-list-grid"] {
    grid-template-columns: repeat(5, minmax(0, 1fr)) !important;
  }
  /* KORREKTUR (Bugfix nach erneutem Feedback, "Boxen komplett gequetscht und
     ueberlaufen sich"): live nachgestellt (Grid testweise auf 844px Breite
     gezwungen, wie ein echtes Quer-Handy) - genau dieses Bild kam dabei
     raus: .product-card selbst schrumpft korrekt auf die 1fr-Spaltenbreite,
     aber .product-card__content (haelt Titel/Beschreibung/Preis/Button) tut
     das NICHT - Grund ist derselbe "min-width:auto"-Grid/Flex-Stolperstein
     wie beim 2-Spalten-Fix weiter oben in dieser Datei (Suche "minmax(0,
     1fr)"), nur dass die viel schmaleren 5er-Spalten den Effekt erst
     sichtbar machen: der nicht umbrechende Inhalt (lange Fliesstexte) zwingt
     .product-card__content zu seiner natuerlichen (viel breiteren)
     Mindestbreite, obwohl die Karte selbst schon schmal ist - dadurch lief
     der Inhalt sichtbar in die Nachbarspalte(n) hinein (overflow:visible,
     kein Clipping). Fix: Karte UND Content-Box hart auf 100% der (schmalen)
     Spaltenbreite gesetzt, inklusive aller Kind-Elemente auf min-width:0 -
     danach wickelt sich der Text korrekt in der eigenen Spalte ein. Live
     verifiziert (844px-Simulation): keine Ueberlappung mehr, Titel/Preis/
     Button jeweils sauber in der eigenen Spalte. */
  #shopify-section-template--31616257655114__product_list_cyt63E .product-card,
  #shopify-section-template--31616257655114__product_list_cyt63E .product-card__content {
    width: 100% !important;
    min-width: 0 !important;
    max-width: 100% !important;
  }
  #shopify-section-template--31616257655114__product_list_cyt63E .product-card__content * {
    min-width: 0 !important;
  }
  /* KORREKTUR (Round 23, Merles Feedback "Probierbox bricht komisch um, bitte
     beim Bindestrich, We-are-family ist ebenfalls zu klein"): live
     nachgestellt (Grid auf 700px bzw. 844px Breite gezwungen) - bei den sehr
     schmalen 5er-Spalten reicht die Spaltenbreite oft nicht einmal fuer den
     Textabschnitt VOR dem Bindestrich (z.B. "Probier-"), der Browser bricht
     dann mitten im Wort ("Probie" / "r-Box" statt "Probier-" / "Box"), weil
     overflow-wrap:break-word als letzten Ausweg ueberall brechen darf, nicht
     nur an sinnvollen Stellen. Fix: kleinere Schrift (mehr Luft pro Spalte)
     + "hyphens:auto" statt "overflow-wrap:break-word" - der Browser nutzt
     dann die deutsche Trennwoerterbuch-Logik (html hat lang="de", live
     bestaetigt) und bricht an echten Silbengrenzen ("Pro-" / "bier-" / "Box",
     "Myste-" / "ry-Box"), nicht mehr willkuerlich mitten im Wort. Live
     verifiziert (700px-Simulation): korrekte Trennung bei allen 5 Titeln,
     kein Abschneiden mehr. */
  #shopify-section-template--31616257655114__product_list_cyt63E .product-card__content p[role="heading"] {
    font-size: 20px !important;
    line-height: 1.15 !important;
    overflow-wrap: normal !important;
    word-break: normal !important;
    hyphens: auto !important;
  }
  #shopify-section-template--31616257655114__product_list_cyt63E [data-testid="resource-list-grid"]:has(> :nth-child(6)) {
    display: flex !important;
    flex-wrap: nowrap !important;
    overflow-x: auto !important;
    scroll-snap-type: x proximity !important;
  }
  #shopify-section-template--31616257655114__product_list_cyt63E [data-testid="resource-list-grid"]:has(> :nth-child(6)) > * {
    flex: 0 0 20% !important;
    scroll-snap-align: start !important;
  }
}

/* ---------------------------------------------------------------- 65.
   BOX-RASTER AUF IPAD QUERFORMAT: LAEUFT UEBER (Round 25, Merles Meldung
   8.10.: "auf dem ipad querformat laeuft das boxraster irgendwie ueber").
   Root Cause: unsere "echter Desktop"-Erkennung ist bisher rein breiten-/
   orientierungsbasiert (min-width:750px, Landschaft, Hoehe >500px) - ein
   iPad im Querformat (z.B. 1024x768px) erfuellt diese Bedingung genauso wie
   ein breiter Monitor und bekommt dadurch exakt dieselben 5 Grid-Spalten wie
   echter Desktop. Bei nur ~1024px Gesamtbreite sind 5 Spalten aber spuerbar
   schmaler als auf einem typischen Desktop-Monitor - dieselbe Ueberlauf-
   Gefahr (CSS-Grid/Flex "min-width:auto"-Falle), die wir fuer Handy-Quer in
   Abschnitt "Box-Karten ueberlappten sich" (Round 22) schon einmal gefixt
   hatten, nur diesmal bei einer Breite, die NICHT in die Handy-Quer-Hoehen-
   Bedingung (max-height:500px) faellt.
   Erkennung: bewusst NICHT ueber eine weitere Breiten-Grenze, sondern ueber
   echte Touch-Faehigkeit (hover:none + pointer:coarse), genau wie schon bei
   R57/R58 (iPad-Hochkant-Erkennung) - ein Maus-/Trackpad-Desktop-Fenster
   matcht dadurch NIE, egal wie schmal es gezogen wird (siehe dazu auch
   meine Antwort zu deiner Frage "kann die Handy-Hochkant/iPad-Variante bei
   schmalem Desktop greifen" im Chat). min-height:501px grenzt zusaetzlich
   gegen Handy-Quer ab (das hat bereits seine eigene 5-Spalten-Regel oben).
   Fix: 3 Spalten statt 5 (deine Option "Columns kleiner machen" bzw. "zwei
   Reihen a drei Boxen" - bei 5 Boxen ergibt das automatisch 3+2 durch Grids
   eigenen Zeilenumbruch, kein manuelles Eingreifen noetig), zusaetzlich
   dieselbe min-width:0-Absicherung wie beim Handy-Quer-Fix, falls trotzdem
   mal ein einzelnes Element nicht mitschrumpft.
   AUSDRUECKLICHER HINWEIS: ich konnte das NICHT auf einem echten iPad oder
   mit einer echten 1024px-Viewport-Breite live nachstellen - meine Chrome-
   Sandbox kann die Fensterbreite nicht aendern, und das Grid berechnet seine
   Spaltenbreiten per Shopify-eigenem JS anhand der ECHTEN Fensterbreite
   (nicht per reinem CSS/Prozent) - ein erzwungenes CSS-width auf den
   Grid-Container allein loest diese JS-Neuberechnung nicht aus, ich kann
   das Überlaufen dadurch in meiner Sandbox nicht 1:1 reproduzieren. Die
   3-Spalten-Loesung selbst ist aber eine einfache, risikoarme CSS-Aenderung
   (nur grid-template-columns), bitte auf einem echten iPad oder im Browser-
   Fenster-Resize gegenchecken. */
@media (hover: none) and (pointer: coarse) and (orientation: landscape) and (min-height: 501px) {
  #shopify-section-template--31616257655114__product_list_cyt63E [data-testid="resource-list-grid"] {
    grid-template-columns: repeat(3, minmax(0, 1fr)) !important;
  }
  #shopify-section-template--31616257655114__product_list_cyt63E .product-card,
  #shopify-section-template--31616257655114__product_list_cyt63E .product-card__content {
    width: 100% !important;
    min-width: 0 !important;
    max-width: 100% !important;
  }
  #shopify-section-template--31616257655114__product_list_cyt63E .product-card__content * {
    min-width: 0 !important;
  }
}

/* ---------------------------------------------------------------- 66.
   BOX-RASTER (STARTSEITE, "Probier-Box/Single-Box/.../Office-Box") AUF
   "SCHMALER DESKTOP" (Maus-Fenster): LAEUFT UEBER.
   KORREKTUR (Round 26, 3. Feedback-Batch): Merles Rueckmeldung "immer noch
   nicht geloest, bei annaehernd quadratischem Desktopformat laeuft die Box-
   Section weiterhin ueber" bezieht sich auf GENAU den Fix direkt hier - die
   erste Fassung (fixe 3-Spalten-Regel, NUR im Bereich 750-1199px). Live
   nachgestellt (Grid auf 1026px Innenbreite geklemmt, 3-Spalten-Regel
   erzwungen - genau Merles gemeldeter Fall bei 1106px Fensterbreite): dabei
   trat KEIN Overflow auf, alle 5 Karten exakt gleich breit (297px), sauber
   3+2 umgebrochen. Die Regel selbst funktioniert also, WENN sie greift - der
   wahrscheinlichste Rest-Grund ist die feste Obergrenze bei 1199px: "echter
   Desktop" beginnt schon bei 1200px und bekommt dort wieder das NATIVE
   5-Spalten-Grid (EBs/Shopifys eigene, aus der realen Fensterbreite
   berechnete Px-Werte) - ein Fenster knapp oberhalb von 1199px (z.B.
   1250-1350px) faellt dadurch wieder zurueck in dieselbe Enge, nur ohne
   unsere Korrektur. Eine weitere feste Obergrenze zu erraten (1300px? 1400px?)
   waere wieder nur eine Vermutung ohne echte Gewissheit.
   NEUE LOESUNG (nach Merles eigenem Vorschlag: "einfach scrollbar machen
   oder alle fuenf nebeneinander skalieren"): keine feste Spalten-Anzahl an
   einer festen Breiten-Grenze mehr, sondern ein Flex-Karussell OHNE
   Obergrenze. Jede Karte bekommt eine Mindestbreite (220px, knapp unter
   ihrer natuerlichen Breite bei vollem Desktop von live gemessenen 248.8px)
   und waechst per flex:1 1 0 sonst gleichmaessig mit, um die volle Breite zu
   fuellen - bei viel Platz (normaler breiter Monitor) sieht das optisch
   identisch zum bisherigen 5-Spalten-Grid aus. Reicht der Platz nicht fuer 5
   Karten bei Mindestbreite, schaltet overflow-x:auto automatisch auf
   horizontales Scrollen (mit Scroll-Snap) um - ueberlaufen kann das Raster
   dadurch bei KEINER Fensterbreite mehr, unabhaengig von exakten Breakpoint-
   Grenzen. Gilt weiterhin nur fuer Maus/Trackpad (hover:hover/pointer:fine) -
   Touch-Geraete (Handy/iPad) behalten ihre eigenen, oben stehenden
   Grid-Regeln unveraendert, dort aendert sich nichts.
   AUSDRUECKLICHER HINWEIS: das automatische Scrollen selbst konnte ich aus
   demselben Sandbox-Grund wie bei den anderen Breiten-Fixes nicht live bei
   einer echten schmalen Fensterbreite beobachten - die Mechanik (Flexbox mit
   fester Mindestbreite + overflow-x:auto) ist aber Standard-CSS-Verhalten
   ohne Sonderfaelle, und die "kein Overflow"-Eigenschaft wurde oben live
   geprueft (Breite geklemmt + Spalten-Regel erzwungen, s.o.). Bitte trotzdem
   unbedingt gegenchecken, vor allem ob 220px pro Karte optisch noch
   komfortabel genug ist oder lieber etwas groesser sein sollte. */
/* KORREKTUR (Round 28/Batch 14, PRIORITAET): Merle "bei annaehernd
   quadratischem Browserfenster wird das Boxraster hochkant scrollbar, die
   Abstaende zwischen den Karten werden riesig, Office-Box wird auf die
   gesamte Breite hochskaliert - bitte hier direkt das Layout von Hochkant-
   Handy nehmen, nur bei sehr schmalem Desktop-Browserfenster". Live
   reproduziert bei 950px echter Mausfenster-Breite: das Flex-Karussell
   unten wrapped die 5 Karten in "3+2" (siehe Kommentar weiter unten,
   "950px: 3 Karten Zeile 1 je 283px, 2 Karten Zeile 2 je 430px") - genau
   DAS ist der gemeldete Bug: die 2 Karten der zweiten Zeile (die zweite
   davon ist Office-Box) wachsen per flex:1 1 0 auf 430px, fast anderthalb
   mal so breit wie die 283px der ersten Zeile. Deshalb jetzt mit
   min-width:1200px eingegrenzt - das Flex-Karussell (urspruenglich bewusst
   OHNE Breiten-Obergrenze gebaut, siehe Abschnitt 66 oben) greift ab jetzt
   nur noch auf echtem breiten Desktop (ab 1200px, derselbe Schwellenwert,
   den "echter Desktop" an anderer Stelle in dieser Datei bereits verwendet,
   z.B. beim Hero/SVG). Fuer den gesamten Mausfenster-Bereich darunter
   (750-1199px) uebernimmt die neue Regel direkt nach Abschnitt 66 unten
   das echte 2-spaltige Hochkant-Handy-Grid (gleich breite Spalten statt
   wachsendem Flex) - exakt Merles Wunsch. Durch die 1200px-Grenze auf
   BEIDEN Seiten (Gate hier + neue Regel bis max-width:1199px) entsteht
   keine neue Luecke dazwischen, anders als bei der in Round 26 verworfenen
   festen 3-Spalten-Loesung. Live verifiziert (950px, nach Einbau der neuen
   Regel unten): alle 5 Karten exakt gleich breit (430px), kein Overflow,
   kein Scrollbalken - 2+2+1 gestapelt wie am Hochkant-Handy. */
@media screen and (hover: hover) and (pointer: fine) and (min-width: 1200px) {
  #shopify-section-template--31616257655114__product_list_cyt63E [data-testid="resource-list-grid"] {
    display: flex !important;
    flex-wrap: nowrap !important;
    overflow-x: auto !important;
    scroll-snap-type: x proximity !important;
  }
  #shopify-section-template--31616257655114__product_list_cyt63E [data-testid="resource-list-grid"] > * {
    flex: 1 1 0 !important;
    min-width: 220px !important;
    scroll-snap-align: start !important;
  }
  #shopify-section-template--31616257655114__product_list_cyt63E .product-card,
  #shopify-section-template--31616257655114__product_list_cyt63E .product-card__content {
    width: 100% !important;
    min-width: 0 !important;
    max-width: 100% !important;
  }
  #shopify-section-template--31616257655114__product_list_cyt63E .product-card__content * {
    min-width: 0 !important;
  }
}
/* UEBERSCHRIEBEN (9.10., Round 27 Batch 13): Merle "bei desktop ganz schmal
   greift irgendwie keine andere media query mehr, das boxraster wird
   abgeschnitten nicht auf mehrere reihen umgebrochen. das war vorher
   besser glaube ich" - genau der oben in Batch 11 als "bewusster
   Kompromiss" beschriebene Fall, jetzt von Merle selbst als unerwuenscht
   bestaetigt. Live nachgestellt (echtes schmales Desktop-Fenster, Maus,
   950px): bei 220px-Mindestbreite passen nur 3-4 der 5 Karten nebeneinander,
   der Rest wurde bisher per overflow-x:hidden abgeschnitten statt
   umzubrechen. Fix: flex-wrap von nowrap auf wrap umgestellt (ueberschreibt
   die nowrap-Regel weiter oben, da diese Regel spaeter in der Datei steht)
   - reicht der Platz fuer 5 Karten bei 220px Mindestbreite nicht, brechen
   die ueberschuessigen jetzt in eine zweite Zeile um (bei 5 Karten je nach
   Breite z. B. 3+2), statt abgeschnitten zu werden. scroll-snap/overflow-x
   dadurch gegenstandslos, siehe naechste Regel. Live verifiziert (950px):
   3 Karten Zeile 1 (je 283px), 2 Karten Zeile 2 (je 430px), kein
   Ueberlauf, kein Scrollbalken. */
@media screen and (hover: hover) and (pointer: fine) and (min-width: 1200px) {
  #shopify-section-template--31616257655114__product_list_cyt63E [data-testid="resource-list-grid"] {
    flex-wrap: wrap !important;
    row-gap: 24px !important;
  }
}
/* NEU (Round 27, 4. Batch): Merle erneut "es taucht immer noch ein
   Scrollbalken auf" - trotz des weiter oben (Abschnitt "Box-Raster, Punkt 1")
   gesetzten overflow-x:hidden. Root Cause live im DOM gefunden (echter
   "spaetere Regel gewinnt"-Fall, siehe auch die bereits dokumentierte
   Masche bei .pv-product-btn/der 96%-Breite): die Regel direkt oberhalb
   dieses Kommentars (Round 26, "schmaler Desktop ohne Obergrenze"-Karussell)
   setzt auf demselben Element ERNEUT overflow-x:auto !important, steht aber
   WEITER UNTEN in der Datei als der Fix oben - und gewinnt deshalb. Bei
   aktuell 5 Boxen und genuegend Platz WACHSEN die Karten zwar gleichmaessig
   per flex:1 1 0 (sieht optisch wie ein normales 5-Spalten-Grid aus), aber
   durch Rundungsungenauigkeiten bei der Flex-Berechnung ragt der Inhalt auch
   hier um ein paar Px ueber die eigene Breite hinaus (live gemessen:
   scrollWidth 1327px vs. clientWidth 1320px, 7px - exakt derselbe
   Rundungsbetrag wie beim urspruenglichen Grid-Fix) - overflow-x:auto macht
   daraus sofort eine sichtbare Scrollleiste. Fix: overflow-x hier (innerhalb
   derselben Maus/Trackpad-Bedingung, also NACH der obigen Regel) nochmal
   explizit auf hidden gesetzt - laut Merles wiederholtem Wunsch soll das
   5-Boxen-Raster grundsaetzlich NIE scrollen, genau wie das Gerichte-Raster.
   Live verifiziert (Screenshot nach Fix): keine Scrollleiste mehr, alle 5
   Karten weiterhin gleichmaessig verteilt.
   SCHAETZUNG/BITTE GEGENCHECKEN: bei einem wirklich sehr schmalen
   Desktop-Fenster (wo die Karten unter die 220px-Mindestbreite aus der Regel
   oben rutschen wuerden) fuehrt "hidden" dazu, dass die ueberschuessigen
   Boxen rechts abgeschnitten statt wegscrollbar sind - das ist ein bewusster
   Kompromiss fuer "nie scrollen", kann ich in meiner Sandbox (feste
   Fensterbreite) nicht live nachstellen. Falls das bei dir in einem schmalen
   Fenster auftritt, bitte melden, dann loesen wir es gezielt (z.B. eigene
   schmalere Mindestbreite statt striktem Verbergen). */
@media screen and (hover: hover) and (pointer: fine) and (min-width: 1200px) {
  #shopify-section-template--31616257655114__product_list_cyt63E [data-testid="resource-list-grid"] {
    overflow-x: hidden !important;
  }
}

/* KORREKTUR (Round 28/Batch 14, nach Merles Live-Test): die erste Fassung
   hier erzwang ein 2-spaltiges Grid fuer den ganzen Mausfenster-Bereich
   750-1199px (siehe vorheriger Kommentar/Code, per Edit ersetzt). Merles
   Rueckmeldung per Screenshot + eigenem Safari-Responsive-Design-Mode-Test:
   "bei so einer Breite bricht es schon in 2 columns um" - bei ihr genau bei
   996x590px. Auf Nachfrage klar entschieden: lieber alle 5 Boxen so lange
   wie moeglich nebeneinander lassen (Karten duerfen dafuer auf ca.
   165-220px schrumpfen), statt frueh auf 2 Spalten zu springen.
   Fix: festes 5-Spalten-Grid (statt 2-Spalten) fuer genau diesen
   Mausfenster-Bereich (750-1199px) - dieselbe Technik, die die Section
   bereits fuer Handy-Quer (siehe Abschnitt "Handy Quer: auch bei den Boxen
   5 Spalten" weiter oben) und iPad-Quer nutzt: festes Grid statt Flex,
   schrumpft gleichmaessig statt ungleichmaessig zu wachsen/umzubrechen.
   WICHTIGER FUND dabei: das alte, eigentlich auf >=1200px gegatete
   Flex-Karussell (Abschnitt 66) setzt auf dem GRID-KIND (".../item", nicht
   die Karte selbst) zusaetzlich "min-width:220px !important" - diese Regel
   liegt ausserhalb des hier sichtbaren Codes und wuerde, falls sie aus
   irgendeinem Grund (z.B. Browser-/Theme-Editor-Cache) noch aktiv waere,
   die 5 Karten unterhalb von ca. 1074px wieder zum Overflow zwingen (Karte
   bleibt bei 220px fest, obwohl die Grid-Spalte schon schmaler ist). Um
   davon unabhaengig zu sein, wird dieser Mindestwert hier zusaetzlich
   explizit auf 0 zurueckgesetzt. Die Schrift-/Trennungs-Anpassung
   (font-size 20px + hyphens:auto) ist 1:1 von der bereits bewaehrten
   Handy-Quer-Regel uebernommen, damit die Titel bei den schmaleren
   165-220px-Karten nicht mitten im Wort umbrechen.
   Live verifiziert bei 950px (echtes Mausfenster): alle 5 Karten exakt
   gleich breit (165px), kein Overflow, kein Scrollbalken, Titel/Preis/
   Button sauber in der eigenen Spalte (Screenshot gegengecheckt). Bei
   Merles gemeldeten 996px sollte das Grid dadurch jetzt bei ca. 174px pro
   Karte bleiben, statt auf 2 Spalten zu springen. */
@media screen and (hover: hover) and (pointer: fine) and (min-width: 750px) and (max-width: 1199px) {
  #shopify-section-template--31616257655114__product_list_cyt63E [data-testid="resource-list-grid"] {
    display: grid !important;
    flex-wrap: unset !important;
    overflow-x: hidden !important;
    grid-template-columns: repeat(5, minmax(0, 1fr)) !important;
  }
  #shopify-section-template--31616257655114__product_list_cyt63E [data-testid="resource-list-grid"] > * {
    flex: unset !important;
    min-width: 0 !important;
    scroll-snap-align: unset !important;
  }
  #shopify-section-template--31616257655114__product_list_cyt63E .product-card,
  #shopify-section-template--31616257655114__product_list_cyt63E .product-card__content {
    width: 100% !important;
    min-width: 0 !important;
    max-width: 100% !important;
  }
  #shopify-section-template--31616257655114__product_list_cyt63E .product-card__content * {
    min-width: 0 !important;
  }
  #shopify-section-template--31616257655114__product_list_cyt63E .product-card__content p[role="heading"] {
    font-size: 20px !important;
    line-height: 1.15 !important;
    overflow-wrap: normal !important;
    word-break: normal !important;
    hyphens: auto !important;
  }
}

/* ---------------------------------------------------------------- 67.
   BOX-RASTER WIRD WIEDER SCROLLBAR/GEQUETSCHT BEI OFFENEM WARENKORB
   (Round 28/Batch 14, Merles Meldung "wenn der Warenkorb ausgezogen ist,
   wird das Boxrasterdiv ebenfalls wieder scrollbar").
   Live verifiziert (echtes 1920px-Fenster, nativen Warenkorb per Klick
   geoeffnet): das Theme setzt dabei tatsaechlich ".page-wrapper--drawer-
   open" auf .page-wrapper (margin-right: 480px = 30rem, die native
   --theme-drawer-width-Variable) - dieselbe Klasse, die in dieser Datei
   bereits an zwei anderen Stellen fuer andere Raster kompensiert wird
   (siehe ".product-grid" und ".gbbProductsContainer" weiter oben, beide
   auf 3 Spalten reduziert, wenn die Schublade offen ist).
   Bei 1920px Fensterbreite blieb unser Boxraster trotz der 480px
   Einquetschung knapp ueberlauffrei (Flex-Karussell, 1360px Rasterbreite
   reichte noch). ABER: unsere Breakpoints oben richten sich nach der
   FENSTERBREITE, nicht nach der durch die Schublade tatsaechlich noch
   verfuegbaren Breite - bei einem schmaleren "echten Desktop"-Fenster
   (z.B. 1250-1600px) bliebe nur noch ca. 770-1120px uebrig, das
   Flex-Karussell (Abschnitt 66/67 oben, min-width:1200px) wuerde dabei
   in 2-3 Karten pro Reihe umbrechen und genau den eingangs gefixten
   "Office-Box waechst ungleichmaessig auf 430px"-Bug erneut ausloesen
   (flex:1 1 0 laesst die Karten der kuerzeren Zeile wieder ungleichmaessig
   wachsen). Fix: bei offener Schublade auf ein festes, gleichmaessig
   schrumpfendes Grid umschalten statt des wachsenden Flex-Karussells -
   dieselbe Technik wie im 750-1199px-Bereich oben, nur mit 3 statt 5
   Spalten (analog zur bestehenden 3-Spalten-Kompensation bei
   ".product-grid"/".gbbProductsContainer").
   ZUSAETZLICH, DEFENSIV (fuer den 750-1199px-Bereich selbst): ich konnte
   live NICHT feststellen, dass die Schublade dort ueberhaupt im
   "schiebenden" Modus (mit Einquetschung) statt im vollflaechigen
   "Modal"-Modus (ohne Einquetschung, Seite bleibt unveraendert) oeffnet -
   bei 950px (innerhalb dieses Bereichs) oeffnete sie sich live
   nachweislich NUR als Modal (margin-right blieb 0px, .page-wrapper
   bekam KEINE --drawer-open-Klasse). Es ist daher gut moeglich, dass die
   Einquetschung in diesem Breitenbereich nie eintritt und die folgende
   Regel nie greift - sie ist rein defensiv (greift nur, wenn
   .page-wrapper--drawer-open UND dieser Breitenbereich gleichzeitig
   zutreffen) und kostet nichts, falls sie ungenutzt bleibt.
   Spezifitaet: ".page-wrapper--drawer-open" vor dem Section-Selektor
   erhoeht die Spezifitaet gegenueber den bestehenden Breakpoint-Regeln
   oben automatisch (dieselbe Technik wie bei ".product-grid" weiter oben
   in dieser Datei) - die Reihenfolge in der Datei spielt dadurch keine
   Rolle. */
@media screen and (hover: hover) and (pointer: fine) and (min-width: 1200px) {
  .page-wrapper--drawer-open #shopify-section-template--31616257655114__product_list_cyt63E [data-testid="resource-list-grid"] {
    display: grid !important;
    flex-wrap: unset !important;
    overflow-x: hidden !important;
    grid-template-columns: repeat(3, minmax(0, 1fr)) !important;
  }
  .page-wrapper--drawer-open #shopify-section-template--31616257655114__product_list_cyt63E [data-testid="resource-list-grid"] > * {
    flex: unset !important;
    min-width: 0 !important;
    scroll-snap-align: unset !important;
  }
  .page-wrapper--drawer-open #shopify-section-template--31616257655114__product_list_cyt63E .product-card__content p[role="heading"] {
    font-size: 20px !important;
    line-height: 1.15 !important;
    overflow-wrap: normal !important;
    word-break: normal !important;
    hyphens: auto !important;
  }
}
@media screen and (hover: hover) and (pointer: fine) and (min-width: 750px) and (max-width: 1199px) {
  .page-wrapper--drawer-open #shopify-section-template--31616257655114__product_list_cyt63E [data-testid="resource-list-grid"] {
    grid-template-columns: repeat(2, minmax(0, 1fr)) !important;
  }
  .page-wrapper--drawer-open #shopify-section-template--31616257655114__product_list_cyt63E .product-card__content p[role="heading"] {
    font-size: 20px !important;
    line-height: 1.15 !important;
    overflow-wrap: normal !important;
    word-break: normal !important;
    hyphens: auto !important;
  }
}

/* ---------------------------------------------------------------- 68.
   SCHLAGSCHATTEN BEI AUSGEZOGENEM WARENKORB (Round 28, 27. Batch): Merle
   "bei ausgezogenem Warenkorb muss der before-shadow von
   .product-media-container.media-fit:first-of-type::before zu scale(0.82)
   translate(-4px, 8px), aber NUR bei ausgezogenem Warenkorb - eingeklappt
   ist alles top. Auf der Alle-Gerichte-Seite muesste der Schatten bei
   ausgeklapptem Cart ebenfalls etwas hochrutschen."
   Die unscoped Desktop-Basisregel (ganz oben in dieser Datei, Abschnitt
   "Rundes Schlagschatten-Bild") ist die einzige auf echtem Desktop
   (>=1200px) aktive Regel fuer dieses Element - sie gilt gleichermassen fuer
   das Boxraster, die Alle-Gerichte-Seite UND jede andere Desktop-Sektion mit
   diesem Schatten (die mobil-spezifischen Section-Overrides weiter oben
   greifen nur unterhalb 1199px). Ein einziger ".page-wrapper--drawer-open"-
   gescopter Override deckt dadurch automatisch alle von Merle genannten
   Stellen gleichzeitig ab, ohne jede Sektion einzeln listen zu muessen -
   ".page-wrapper--drawer-open" erhoeht die Spezifitaet gegenueber der
   Basisregel unabhaengig von der Reihenfolge in der Datei (siehe selbe
   Technik bei den Box-Raster-Regeln oben). Nur fuer echten Desktop
   (min-width:1200px), da Merles Wunsch ausdruecklich mit "DESKTOP:"
   eingeleitet wurde - der Warenkorb oeffnet auf Mobil ohnehin meist als
   vollflaechiges Modal statt schiebender Schublade, mobile Schatten bleiben
   unveraendert. */
@media screen and (min-width: 1200px) {
  .page-wrapper--drawer-open .product-media-container.media-fit:first-of-type::before {
    transform: scale(0.82) translate(-4px, 8px) !important;
  }
}

/* GEPRUEFT, NICHT UEBERNOMMEN (9.10., Round 27 Batch 11): hier probeweise
   ein padding-right versucht, live per DevTools-Injection VOR dem
   Ausliefern gegengetestet - Ergebnis: wirkungslos bis kontraproduktiv.
   Bei der Fensterbreite, wo hier tatsaechlich geclippt wird, passen die 5
   Karten (220px Mindestbreite je Karte) ohnehin schon nicht nebeneinander
   - alle Karten sitzen bereits exakt auf der 220px-Mindestbreite fest
   (kein Spielraum zum Schrumpfen mehr), zusaetzliches padding-right nimmt
   dem Raster nur noch mehr vom sowieso zu knappen Platz weg und verschiebt
   die Clip-Kante sogar NACH LINKS (schlimmer statt besser). Die Ursache
   hier ist nicht "ein bisschen zu wenig Rand", sondern "5 Karten passen
   bei dieser Fensterbreite grundsaetzlich nicht" - das ist der bereits an
   anderer Stelle (220px-Mindestbreite, siehe Kommentar oben) beschriebene
   und von dir bestaetigte bewusste Kompromiss. Falls dein Screenshot genau
   von dieser (eher schmalen) Desktop-Fensterbreite stammt, waere der
   naechste sinnvolle Schritt, die 220px-Mindestbreite testweise zu
   verkleinern (z. B. auf ~180px), damit 5 Karten wieder reinpassen - das
   aendert aber das Kartenlayout sichtbar (schmalere Karten) und sollte
   nicht spontan um Mitternacht vor deiner Praesentation geraten werden.
   Bitte zuerst kurz bestaetigen, ob der Effekt bei dir eher "ganze letzte
   Karte wirkt gequetscht/angeschnitten" (dann: dieser Fall) oder "Karte
   sieht normal aus, nur die Bubble ragt drueber hinaus" (dann eher die
   Karussell-Variante weiter oben in dieser Datei) ist.
   NACHTRAG (Batch 13): durch den weiter oben neu ergaenzten flex-wrap:wrap-
   Fix (Karten brechen jetzt um statt abgeschnitten zu werden) duerfte
   dieser ganze Fall hier ohnehin seltener auftreten - eine umgebrochene
   letzte Karte hat meistens wieder echten Nachbarn/Freiraum in ihrer
   eigenen Zeile, nicht mehr zwingend die Rasterkante direkt neben sich.
   Bitte nach dem Einspielen von Batch 13 nochmal neu pruefen, ob die
   Spar-Bubble hier ueberhaupt noch abgeschnitten ist, bevor hier weiter
   nachgebessert wird. */

/* Box-Raster: KEINE Skalier-Animation mehr beim automatisch simulierten
   Scroll-Hover (Merles Wunsch: "jede scale animation soll auf dem handy
   hochformat wegfallen, sie verschieben das raster"). Betroffen ist der
   "Jetzt fuellen"-Button (.pv-product-btn) - er steht in mobile-fixes.js
   Abschnitt 1 in der Liste der Elemente, die beim Vorbeiscrollen automatisch
   ".pv-hover-inview" bekommen, sobald er zu 60% im Viewport ist; die
   zugehoerige CSS-Regel (Abschnitt "Jetzt packen.-Button", @media
   (hover:none)) laesst ihn dabei auf 110% skalieren. In der engen,
   zweispaltigen Box-Grid-Zelle fuehrt dieses +10%-Wachsen optisch zu einem
   kurzen Ruckler/Verschieben des Rasters, sobald beim Scrollen der Button
   ins Bild kommt. Fix: Skalierung nur INNERHALB dieses Box-Rasters auf
   Mobil entfernen (Farbwechsel bleibt bestehen); ausserhalb des Box-Rasters
   (andere "Jetzt packen."-Buttons) bleibt das bisherige Verhalten
   unveraendert. Per !important + spaetere Position in der Kaskade
   gegenueber der Original-Regel in @media (hover:none) (konnte in diesem
   Test-Setup nicht live mit echter Touch-Emulation gegengeprueft werden,
   da (hover:none) hier nicht auslösbar ist - bitte auf dem Handy selbst
   nochmal gegenchecken). */
@media screen and (max-width: 749px) {
  #shopify-section-template--31616257655114__product_list_cyt63E .pv-product-btn:hover,
  #shopify-section-template--31616257655114__product_list_cyt63E .pv-product-btn.pv-hover-inview {
    transform: none !important;
  }
}
/* ERGAENZT (Round 28/Batch 18): die neue "Ausgangszustand kleiner machen"-
   Regel (scale(0.95), siehe Abschnitt "Jetzt packen."-Button weiter oben)
   gilt jetzt generell auf Mobil bis 1199px (vorher gab es GAR KEINEN
   Ruhezustand-Transform). Damit das oben beschriebene, bewusst animations-
   freie Verhalten INNERHALB des Box-Rasters erhalten bleibt (kein Ruckler
   beim Scrollen), wird hier zusaetzlich auch der RUHEZUSTAND (nicht nur
   :hover/.pv-hover-inview wie oben) auf "kein Transform" zurueckgesetzt -
   ID-Selektor gewinnt unabhaengig von der Positions-Reihenfolge gegen die
   allgemeine Klassen-Regel. */
@media screen and (max-width: 1199px) {
  #shopify-section-template--31616257655114__product_list_cyt63E .pv-product-btn {
    transform: none !important;
  }
}

/* ---------------------------------------------------------------- 64.
   ZWEITER GROSSER MOBIL-FEEDBACK-BATCH 8.10. Live auf der echten Seite
   gegengeprueft (Chrome, 281px-Emulation), wo immer das moeglich war. */

/* Alle-Gerichte-Seite: Abstand oben am Ergebnis-Bereich reduzieren
   (Merles Wunsch, mit exakter ID). */
#shopify-section-template--31616257720650__main #ResultsList {
  padding-top: 0.5vh !important;
}
/* Alle-Gerichte-Seite: Filter-Button-Leiste - bisheriges Padding komplett
   zuruecksetzen, stattdessen nur oben 2vh (Merles Wunsch, mit exaktem
   Screenshot-Wert). */
#shopify-section-template--31616257720650__main .facets-toggle {
  padding: 0 !important;
  padding-block-start: 2vh !important;
}
/* KORREKTUR (7.10., Teil 13): Merle "Filter ist jetzt ganz links, braucht
   einen kleinen margin-left" - durch die Padding-Regel oben (padding:0)
   sitzt der Button-Text jetzt direkt am linken Rand. Schaetzwert, bitte
   live gegenchecken. Nur Mobil, da die Padding-Regel oben ebenfalls nur
   hier im Mobil-Feedback-Abschnitt entstand (auch wenn sie selbst technisch
   ungescopt ist). */
@media screen and (max-width: 749px) {
  #shopify-section-template--31616257720650__main .facets-toggle {
    margin-left: 0.8em !important;
  }
}

/* TOTER CODE ENTFERNT (7.10., Teil 13): diese Regel (ohne "body"-Praefix,
   also niedrigere Spezifitaet als die "body .hero-text-group__siegel-
   wrapper"-Regeln weiter oben in dieser Datei) hatte nie irgendeine
   sichtbare Wirkung - sie wurde von den spezifischeren Regeln komplett
   ueberschrieben. right:3%/bottom:3% ist jetzt direkt in der tatsaechlich
   wirksamen Regel gesetzt (Suche nach "KONSOLIDIERT"). */

/* Box-Raster: Boxbilder-Spalte 2 Reihen-Abstand vergroessern, Spalten-
   Abstand verkleinern (Merles Wunsch "mehr gap zwischen den rows" /
   "gap zwischen den columns kleiner"). Schaetzwerte, bitte live
   gegenchecken.
   KORREKTUR (7.10.): Merle wollte nach dem letzten Stand (34px) noch mehr
   Abstand zwischen den Reihen ("bitte den abstand zwischen den reihen
   größer!") - auf 46px angehoben.
   KORREKTUR (7.10., Teil 13): laut Screenshot (rote Markierung zwischen
   "Jetzt füllen"-Button-Reihe und der Bilder-Reihe darunter) reichte 46px
   immer noch nicht - weiter auf 64px angehoben. Schaetzwert, bitte live
   gegenchecken, ob das jetzt reicht oder noch mehr werden soll. */
@media screen and (max-width: 749px) {
  #shopify-section-template--31616257655114__product_list_cyt63E .resource-list__carousel slideshow-slides {
    row-gap: 64px !important;
    column-gap: 3px !important;
  }
}

/* KORREKTUR (7.10., Teil 15): Merles Vorschlag - zusaetzlich margin-bottom
   direkt auf den Karten selbst, statt (nur) ueber row-gap am Karussell-
   Container. ACHTUNG, bitte beim Gegenchecken beachten: das kommt zum
   row-gap:64px oben noch OBENDRAUF (addiert sich, ersetzt es nicht) - macht
   den Gesamtabstand also ca. 76px statt 64px. Falls das jetzt zu viel
   wird, sag Bescheid, dann reduziere ich row-gap oben entsprechend, statt
   beides gleichzeitig hochzuhalten. */
@media screen and (max-width: 749px) {
  #shopify-section-template--31616257655114__product_list_cyt63E .product-card,
  #shopify-section-template--31616257655114__product_list_cyt63E .product-card__content {
    margin-bottom: 12px !important;
  }
}

/* Box-Raster: Beschreibungstext noch etwas breiter (Merles Wunsch: 95%
   !important, statt der bisherigen 95%-Regel ohne !important - manche
   Theme-Regeln waren spezifischer und haben das bisher teilweise
   ueberstimmt). */
@media screen and (max-width: 749px) {
  body [class*="text-block--Aa3pheDByY0ViLzV1N__text_rycJiT"] {
    width: 95% !important;
  }
}

/* EB Mix&Match: Box-Auswahl-Kacheln (.gbbBoxSelectionContainer) waren links
   UND rechts bis an den Bildschirmrand angeschnitten (live mit Zoom-
   Screenshot bestaetigt - die Kacheln selbst sitzen laut Layout-Messung
   bereits symmetrisch, aber ohne jeden Rand zum Viewport). Fix: kleiner
   expliziter Rand links/rechts, live gegengeprueft (vorher/nachher-
   Screenshot-Vergleich). */
.gbbBoxSelectionContainer {
  margin-left: 6px !important;
  margin-right: 6px !important;
}

/* ALT (Backup, Round 26, 7. Batch): ungleiche Spaltenbreiten, damit der
   Probier-Box-Kachel (bzw. ihr Textinhalt) mehr Platz bekommt:
.gbbBoxSelectionContainer {
  grid-template-columns: 38.33% 28.33% 33.34% !important;
}
*/
/* NEU (Round 27, 3. Batch): Merle "alle gbbBoxSelectionItem gleich breit" -
   nimmt die Breiten-Ungleichheit von Round 26 (7. Batch) bewusst zurueck.
   WICHTIG, gleiche Technik wie dort: Prozent statt fr, weil dieses Widget
   fr-Einheiten bei grid-template-columns nachweislich ignoriert (siehe ALT-
   Kommentar oben) - hier 3x 33.33%/33.34% statt "repeat(3,1fr)". Hinweis:
   das nimmt die Round-26-Korrektur zurueck, die extra Breite fuer die
   Probier-Box-Kachel vorgesehen hatte (ihr Text war vorher zu eng) - bitte
   nach dem Einspielen kurz pruefen, ob der Text in der Probier-Box-Kachel
   bei gleicher Breite (jetzt zusaetzlich etwas niedriger, siehe die
   gestaffelte Hoehe weiter unten) noch bequem Platz hat. */
.gbbBoxSelectionContainer {
  grid-template-columns: 33.33% 33.33% 33.34% !important;
  /* Merle "die Schrift ... unten auf einer Linie ausrichten, nur das
     Eltern-Div nach oben hin schrittweise groesser machen" (Photoshop-
     Skizze: 3 Kacheln, gemeinsame Unterkante, von links nach rechts
     zunehmend hoeher). align-items:end sorgt dafuer, dass jede Kachel an
     der UNTERKANTE der Reihe ausgerichtet wird, unabhaengig von ihrer
     eigenen (jetzt bewusst unterschiedlichen) Hoehe. */
  align-items: end !important;
}
/* NEU (Round 28/Batch 18): Merle, Handy-EB-Feedback - die Box-Auswahl
   (.gbbBoxSelectionContainer) sitzt auf dem Handy nicht mittig, die dritte
   Kachel stoesst im Drawer UND ausserhalb rechts an bzw. hat weniger Rand
   als links. Vermuteter Root Cause: unsere feste Prozent-Aufteilung oben
   (33.33%/33.33%/33.34%) addiert sich bei CSS Grid NICHT automatisch mit
   einem vorhandenen Spalten-Gap - ist ein Gap vorhanden, ueberschreitet das
   Grid dadurch seine eigene Breite um die Summe der Gaps, was optisch wie
   "nicht mittig/rechts abgeschnitten" wirkt (klassische Grid-Prozent+Gap-
   Falle). Fr-Einheiten sind fuer DIESES Widget laut obigem Kommentar
   nachweislich wirkungslos, koennen das also nicht ersetzen. Merles eigener
   Vorschlag: "veraendern oder wegmachen" - hier auf Mobil komplett
   zurueckgenommen, EB faellt dort auf sein eigenes natives Spalten-
   Verhalten zurueck. AUSDRUECKLICHER HINWEIS: konnte nicht live
   gegengeprueft werden (Chrome-Verbindung getrennt) - falls die Kacheln
   dadurch auf Mobil ungleich breit werden, bitte melden, dann muesste
   stattdessen mit einem konkreten, von dir gemessenen Gap-Wert gerechnet
   werden (z.B. "repeat(3, calc((100% - 2 * <Gap>) / 3))"). Desktop (siehe
   Regel oben) bleibt unveraendert, da dort kein Problem gemeldet wurde. */
/* KORREKTUR (Round 28, 20. Batch): Merle "auf dem Handy sind die selection
   box items jetzt untereinander, das geht nicht" - das war genau die
   befuerchtete Nebenwirkung von "grid-template-columns: unset" (siehe
   Kommentar oben): EB faellt dabei offenbar auf sein eigenes natives
   Mobil-Verhalten zurueck, das hier (anders als vermutet) KEIN 3-spaltiges
   Grid ist, sondern Einspaltig/untereinander. "unset" war also die falsche
   Lösung.
   Diesmal LIVE VERIFIZIERT (echte 500px-Breite via Chrome-Erweiterung,
   Produktseite/EB-Builder direkt): der tatsaechliche Grid-Gap dieses
   Containers ist 8px (live gemessen per getComputedStyle, nicht
   geschaetzt). Fix: 3 Spalten per calc() unter Beruecksichtigung dieses
   Gaps, damit die Spalten-Summe + 2 Gaps wieder exakt die Container-Breite
   ergibt (vorher, mit 33.33%/33.33%/33.34%, ueberschritt die Summe die
   Container-Breite um genau 2*8px=16px - dieselbe Rechnung wie im
   urspruenglichen Root-Cause-Kommentar oben, nur nicht mehr geschaetzt
   sondern mit echtem Live-Wert). Direkt nach dem Setzen per JS in der
   Chrome-Konsole gegengeprueft: die 3 Kacheln sitzen danach exakt flush mit
   den Container-Raendern, keine Ueberschneidung/kein Umbruch mehr. Falls
   der native EB-Gap doch noch irgendwo von 8px abweicht, bitte kurz
   Bescheid geben. */
@media screen and (max-width: 1199px) {
  body .gbbBoxSelectionContainer {
    grid-template-columns: repeat(3, calc((100% - 2 * 8px) / 3)) !important;
  }
}
/* Gestaffelte Hoehe je Kachel (1.=Probier-Box am kleinsten, 3.=We-are-
   family-Box am groessten, wie in der Skizze) - Schaetzwerte (15px-Schritte),
   bitte live gegenchecken, ob das Verhaeltnis so passt oder die Schritte
   groesser/kleiner werden sollen. */
.gbbBoxSelectionContainer .gbbBoxSelectionItem:nth-child(1) {
  min-height: 100px !important;
}
.gbbBoxSelectionContainer .gbbBoxSelectionItem:nth-child(2) {
  min-height: 115px !important;
}
.gbbBoxSelectionContainer .gbbBoxSelectionItem:nth-child(3) {
  min-height: 130px !important;
}
/* Textinhalt jeder Kachel (Heading+Subtext) war bisher vertikal ZENTRIERT
   (nativ align-items:center) - bei unterschiedlich hohen Kacheln soll der
   Text aber an der gemeinsamen Unterkante sitzen, nicht in der (je nach
   Kachel unterschiedlichen) Mitte. */
body .gbbBoxSelectionItem {
  align-items: end !important;
}
/* KORREKTUR (neue Anfrage): Merle meldet, auf Desktop-Box-Seiten sitzen die
   Beschriftungen ("Single-Box"/"We-are-family-Box") nicht mittig in ihren
   Kacheln. Root Cause: die obige Regel ist UNSCOPED, gilt also auch auf
   Desktop - sie wurde aber nur wegen der gestaffelten Kachel-Hoehen (siehe
   Kommentar oben, "gemeinsame Unterkante" laut Merles Skizze) eingefuehrt;
   fuer Desktop wurde nie eine Unterkanten-Ausrichtung gewuenscht, nur jetzt
   explizit eine mittige Beschriftung gemeldet. Fix: fuer "echter Desktop"
   (dieselbe Bedingung wie beim Hero an mehreren Stellen dieser Datei) wieder
   auf center zurueckgesetzt - Handy und Handy-Quer bleiben unveraendert bei
   "end", da dort kein Problem gemeldet wurde. */
@media screen and (min-width: 1200px), screen and (min-width: 750px) and (orientation: landscape) and (min-height: 501px), screen and (min-width: 750px) and (max-width: 1199px) and (orientation: portrait) {
  body .gbbBoxSelectionItem {
    align-items: center !important;
  }
}

/* NEU (neue Anfrage): Merle meldet (nicht aktiver Zustand), ".gbbBoxSelectionItem
   ist nicht zentriert in seiner Spalte von .gbbBoxSelectionContainer" - das
   ist eine ANDERE Achse als die obige Regel (die regelt die Ausrichtung des
   TEXTINHALTS INNERHALB der Kachel; hier geht es um die Position der ganzen
   Kachel INNERHALB ihrer Grid-Spalte). Root Cause: .gbbBoxSelectionContainer
   ist ein CSS-Grid, .gbbBoxSelectionItem hat eine eigene, feste (runde)
   Groesse statt die Spaltenbreite auszufuellen - per Grid-Spezifikation
   verhaelt sich "justify-items" (Standardwert "normal") fuer ein Kind mit
   eigener, definierter Groesse wie "start" statt "stretch/center", die
   Kachel klebt dadurch am Spaltenanfang statt mittig zu sitzen (klassischer
   CSS-Grid-Stolperstein bei auto-groessen Items). Fix: justify-items:center
   explizit gesetzt, zentriert jede Kachel horizontal in ihrer eigenen Spalte.
   Unscoped (gilt fuer alle Breiten - sollte auf Mobil nicht schaden, da dort
   i.d.R. 1-3 gleich breite Spalten ohnehin meist schon mittig wirken). */
body .gbbBoxSelectionContainer {
  justify-items: center !important;
}

/* KORREKTUR (direkte Folgemeldung zum obigen justify-items:center-Fix):
   Merle meldet jetzt per Screenshot einen neuen Folgefehler - die Kacheln
   sitzen nicht mehr mittig im gbbBundleFooter, haben keinen Abstand
   zueinander mehr und ueberschneiden sich teils (Single-Box-Kachel ragt
   sichtbar in beide Nachbarn hinein).
   Root Cause: .gbbBoxSelectionItem hat eine EIGENE, vom Textinhalt
   abhaengige Breite (siehe Kommentar weiter oben, "feste runde Groesse"),
   die NICHT durch ihre Grid-Spalte begrenzt wird. "justify-items:center"
   zentriert diese eigene Breite nur INNERHALB der Spalte, verhindert aber
   nicht, dass die Kachel breiter als die Spalte selbst wird - ist das der
   Fall (z.B. weil der Footer/Drawer an dieser Stelle schmaler ist als die
   Spalten-Rechnung sonst erwartet), ragt die Kachel gleichmaessig in beide
   Nachbarspalten hinein = genau die gemeldete Ueberlappung, und es bleibt
   kein Abstand zu den Nachbarn mehr.
   Fix (Merles eigener, bereits praeziser Vorschlag): Kachel-Breite hart auf
   ihre Spalte begrenzen (max-width:100%, relativ zur Grid-Spalte - cappt
   die tatsaechlich genutzte Breite IMMER, unabhaengig davon, wie breit die
   Kachel von sich aus sein wollte) + expliziter Gap zwischen den Spalten,
   damit auch bei maximaler Breite ein garantierter Mindestabstand bleibt.
   Reicht die dadurch gecappte Breite nicht mehr fuer den Text, darf die
   Kachel laut Merle stattdessen "nach oben in die Hoehe wachsen" - da der
   Rahmen-Radius hier laut obigem Kommentar ein fester Pixelwert (43px) ist,
   keine aspect-ratio:1/1-Erzwingung, bleibt das optisch weiterhin eine
   Pillenform statt eines verzerrten/gestauchten Kreises, wenn die Hoehe die
   Breite uebersteigt - height bleibt dafuer bewusst unangetastet (kein
   max-height irgendwo gesetzt). */
body .gbbBoxSelectionItem {
  max-width: 100% !important;
  box-sizing: border-box !important;
}
body .gbbBoxSelectionContainer {
  gap: 10px !important;
}

/* EB Mix&Match: "(inkl. Versand)" / "(versandkostenfrei)" - die Klammern
   sollen jetzt mitschrumpfen. Die Klammern selbst stehen im DOM als
   normale Textknoten AUSSERHALB des .pv-inkl-versand-Spans (reiner Text,
   kein Element) - per CSS laesst sich ein Textknoten nicht gezielt
   ansprechen, das geht nur, wenn er mit INNERHALB des Spans liegt. Fix
   dafuer in mobile-fixes.js Abschnitt 12 (die Klammern werden dort jetzt
   mitgewrappt) - hier bleibt nur noch die Schriftgroessen-Regel fuer den
   (jetzt groesseren) Span-Inhalt bestehen. */
body .gbbBoxSelectionSubtext .pv-inkl-versand {
  font-size: 0.7em !important;
}

/* AB 7.10. (Teil 7): Merles Wunsch - ".pv-inkl-versand" soll eine eigene
   Zeile bekommen (statt im Fliesstext von .gbbBoxSelectionSubtext zu
   haengen) UND eine eigene, noch kleinere Zeilenhoehe, damit die
   Box-Auswahl-Kacheln (.gbbBoxSelectionItem) dadurch insgesamt weniger hoch
   werden koennen. display:block erzwingt den Umbruch auf eine eigene Zeile
   (der Span sitzt im DOM mitten in einem Textknoten - block statt inline
   reicht dafuer aus, kein zusaetzliches <br> noetig). */
@media screen and (max-width: 749px) {
  .pv-inkl-versand {
    display: block !important;
    line-height: 1 !important;
  }
  /* Da "(inkl. Versand)"/"(versandkostenfrei)" jetzt eine eigene, kompakte
     Zeile hat statt im Fliesstext zu haengen, braucht die Kachel insgesamt
     weniger Innenabstand als die vorherigen 22px (die extra Hoehe wegen
     Ueberlaufens in die Rundung gebraucht wurden, bevor es diese eigene
     Zeile gab). Schaetzwert, bitte live gegenchecken und ggf. nachjustieren -
     falls Subtext/Klammer-Zeile wieder in die Rundung rutscht, bitte
     Bescheid geben, dann wieder leicht erhoehen statt noch weiter senken. */
  body .gbbBoxSelectionItem {
    padding-block: 14px !important; /* war 22px */
  }
}

/* EB Mix&Match: Produktkarten-Preise ein wenig kleiner (Merles Wunsch). */
@media screen and (max-width: 749px) {
  body .gbbProductPrice,
  body .gbbProductCompareAtPrice {
    font-size: 0.85em !important;
  }
}

/* ---------------------------------------------------------------- 65.
   HEADERNAV VERSCHWINDET BEIM SCROLLEN (echter Root Cause gefunden, live auf
   /products/box reproduziert und verifiziert). Der native Mechanismus
   (siehe Abschnitt weiter oben, "KOMPLETT ZURUECKGENOMMEN"-Logbuch): die
   aeussere .header-section bekommt position:sticky (haelt sie oben am
   Viewport fest), der innere #header-component bekommt nativ NUR dann
   position:absolute;top:0, wenn Horizon zusaetzlich das Attribut
   "transparent" auf das Element setzt (eigene, undokumentierte
   Theme-Logik, vermutlich an denselben instabilen Sticky-State-Mechanismus
   gekoppelt, der schon vorher als "flackert, ResizeObserver-Rueckkopplung,
   nicht durch uns patchbar" protokolliert wurde). Live per DOM-Abfrage
   waehrend echtem Scrollen bestaetigt: in bestimmten Momenten fehlt dieses
   Attribut, #header-component faellt dadurch auf natives position:static
   zurueck - und alles, was INNERHALB des Headers absolut positioniert ist
   (Logo, Hamburger-Icon, Konto-/Warenkorb-Icons), verliert damit seinen
   Bezugsrahmen (das naechste positionierte Element) und rutscht an eine
   voellig andere Stelle bzw. wird optisch unsichtbar. Das IST das von Merle
   gemeldete "Headernav verschwindet komplett".
   WICHTIG: kein position:fixed/absolute auf #header-component erzwingen -
   das wurde bereits einmal versucht und laut Logbuch oben ausdruecklich
   zurueckgenommen (kollidiert mit der sticky .header-section). Stattdessen
   ein viel vorsichtigerer Fallback: position:relative AUSSCHLIESSLICH wenn
   "transparent" fehlt. position:relative aendert nichts an der sichtbaren
   Position des Headers selbst (bleibt wie static im normalen Fluss), legt
   aber einen gueltigen Bezugsrahmen fuer seine absolut positionierten Kinder
   fest - die Icons bleiben dadurch an ihrem Platz, auch wenn Horizons
   eigener Mechanismus gerade nicht greift. Live verifiziert (Icons/Logo
   bleiben jetzt auch im vorher kaputten Zustand sichtbar). */
@media screen and (max-width: 749px) {
  #header-component:not([transparent]) {
    position: relative !important;
  }
}

/* ---------------------------------------------------------------- 61.
   OFFICE-BOX (UND POTENZIELL WEITERE BOXEN): PREIS VON EASY BUNDLES SELBST
   VERSTECKT (Round 19). Merle meldet: "bei der Office-Box fehlt auf dem
   Handy und dem Desktop der Preis", per DevTools gefunden: Easy Bundles
   selbst (nicht unser CSS) setzt die Modifier-Klasse
   ".gbbExtProductCardPrice--hidden" auf die beiden Preis-Spans
   (price-item__group.price und .compare-at-price). Live im eigenen
   Sandbox-Browser nachgesehen (echtes DOM auf der Startseite): die Klasse
   setzt tatsaechlich NUR "visibility:hidden" (display bleibt regulaer
   inline-block wie bei allen anderen funktionierenden Boxen) - kein
   display:none, kein Platzproblem. Fix ist dadurch exakt (kein Rate-
   Versuch): nur visibility zurueck auf visible, sonst nichts veraendert.
   Warum EB das bei dieser einen Box ueberhaupt setzt, bleibt offen -
   vermutlich ein EB-Builder-Konfigurationsunterschied bei genau dieser Box
   (eigener eigener Preis-Mechanismus, der bei ihr aus irgendeinem Grund
   nicht gefeuert hat und die native Theme-Anzeige dadurch faelschlich
   verdeckt blieb). Falls dieselbe Klasse spaeter bei einer anderen Box
   auftaucht, deckt diese Regel das automatisch mit ab (nicht auf Office-Box
   verengt). */
#shopify-section-template--31616257655114__product_list_cyt63E .gbbExtProductCardPrice--hidden {
  visibility: visible !important;
}

/* ---------------------------------------------------------------- 61b.
   OFFICE-BOX: AKTUELLER PREIS UND DURCHGESTRICHENER VERGLEICHSPREIS SOLLEN
   IMMER NEBENEINANDER STEHEN (Round 24, Merles Meldung 8.10.: "bei der
   office box die preise sollten im besten fall nebeneinander stehen. es
   ist der einzige dreistellige preis deswegen verschwindet er vielleicht
   auch"). Die Office-Box hat als einzige Box einen dreistelligen Preis
   (209,99€ statt zweistellig bei den anderen Boxen) - bei knapperer
   Kartenbreite (z.B. Handy-Quer mit jetzt 4 statt 5 Spalten, siehe weiter
   oben "Produktraster bitte 4 columns") reicht der Platz fuer Preis +
   Vergleichspreis nebeneinander dann nicht mehr, beide brechen
   untereinander um - das wirkt wie "gestapelt" statt nebeneinander.
   AUSDRUECKLICHER HINWEIS: ich hatte in dieser Runde KEINEN funktionierenden
   Zugriff auf meinen Chrome-Sandbox, konnte das NICHT live nachstellen -
   dieser Fix ist eine Schaetzung auf Basis der in Abschnitt 61 bereits live
   bestaetigten Klassen ".price"/".compare-at-price", bitte an der Office-
   Box live gegenchecken. Fix: das gemeinsame Elternelement beider Preis-
   Spans (per :has() ermittelt, ohne die genaue Elternklasse zu kennen) auf
   eine Reihe mit flex-wrap:nowrap erzwungen, beide Preis-Spans selbst
   zusaetzlich auf white-space:nowrap, damit auch der laengere dreistellige
   Text nicht umbricht. Falls der Platz dann bei der Office-Box trotzdem
   nicht ausreicht, muesste als naechstes die Schrift gezielt fuer diese eine
   Box verkleinert werden - dafuer bräuchte ich einen Screenshot/die genaue
   Produkt-ID der Office-Box.
   KORREKTUR (Round 26, 4. Feedback-Batch, ECHTER FEHLER VON MIR): Merles
   neue Screenshots zeigen den Vergleichspreis (z. B. "€71,88") bei JEDER
   Box (nicht nur Office-Box) mitten im Text abgeschnitten, sowohl auf Handy
   hoch/quer als auch auf schmalerem Desktop. Root Cause: genau diese Regel
   hier - "flex-wrap:nowrap" + "flex-shrink:0" auf BEIDEN Preis-Spans wurde
   fuer ALLE Boxen gesetzt (per :has(), nicht auf die Office-Box verengt),
   obwohl Merles urspruengliche Meldung sich nur auf die Office-Box bezog
   (einzige Box mit dreistelligem Preis). Bei den anderen, schmaleren Karten
   reicht der Platz fuer Preis+Vergleichspreis nebeneinander oft nicht -
   durch das erzwungene nowrap+flex-shrink:0 kann der Vergleichspreis dann
   weder umbrechen noch schrumpfen und laeuft sichtbar ueber den Kartenrand
   hinaus, wo er abgeschnitten wird. Fix: die allgemeine Regel zurueck auf
   "darf umbrechen/schrumpfen" (wrap statt nowrap, flex-shrink:1 statt 0) -
   das ist die robuste Standardeinstellung, die bei JEDER Kartenbreite
   garantiert nicht mehr abschneidet. NUR fuer die Office-Box (ueber ihren
   Produkt-Link im href erkannt, kein Rateversuch bei der ID noetig) bleibt
   zusaetzlich die urspruengliche nowrap-Regel bestehen, die genau das
   Problem loest, fuer das sie gedacht war. */
#shopify-section-template--31616257655114__product_list_cyt63E *:has(> .price):has(> .compare-at-price) {
  display: flex !important;
  flex-direction: row !important;
  flex-wrap: wrap !important; /* war nowrap - siehe Korrektur oben */
  align-items: baseline !important;
  gap: 4px !important;
}
#shopify-section-template--31616257655114__product_list_cyt63E .price,
#shopify-section-template--31616257655114__product_list_cyt63E .compare-at-price {
  white-space: nowrap !important; /* der einzelne Preis-Text selbst soll nicht MITTEN im Text brechen */
  flex-shrink: 1 !important; /* war 0 - darf jetzt schrumpfen statt zu ueberlaufen */
}
/* Office-Box-Sonderfall: bleibt bei erzwungenem nebeneinander (ihr einziger
   dreistelliger Preis soll nicht untereinander "gestapelt" wirken). */
#shopify-section-template--31616257655114__product_list_cyt63E .product-card:has(a[href*="/products/office-box"]) *:has(> .price):has(> .compare-at-price) {
  flex-wrap: nowrap !important;
}
#shopify-section-template--31616257655114__product_list_cyt63E .product-card:has(a[href*="/products/office-box"]) .price,
#shopify-section-template--31616257655114__product_list_cyt63E .product-card:has(a[href*="/products/office-box"]) .compare-at-price {
  flex-shrink: 0 !important;
}
/* NEU (Round 28, 21. Batch): Merle "Preise sind gefixt, nicht mehr
   abgeschnitten - fände es nur schöner, wenn bei der Family-Box (We-are-
   family-Box) wie bei der Office-Box der Vergleichspreis NEBEN dem
   Verkaufspreis stünde" - derselbe Office-Box-Sonderfall (nowrap statt
   Umbruch), 1:1 uebernommen, nur auf den Family-Box-Produkthandle gescopt
   (live bestaetigt: "/products/we-are-family-box"). */
#shopify-section-template--31616257655114__product_list_cyt63E .product-card:has(a[href*="/products/we-are-family-box"]) *:has(> .price):has(> .compare-at-price) {
  flex-wrap: nowrap !important;
}
#shopify-section-template--31616257655114__product_list_cyt63E .product-card:has(a[href*="/products/we-are-family-box"]) .price,
#shopify-section-template--31616257655114__product_list_cyt63E .product-card:has(a[href*="/products/we-are-family-box"]) .compare-at-price {
  flex-shrink: 0 !important;
}

/* ---------------------------------------------------------------- 62.
   EB MIX&MATCH: ABSTAND ZWISCHEN "GESAMT (INKL. VERSAND)" UND DEM PREIS
   (Round 19). Merle hat die exakte Ursache selbst per DevTools gefunden und
   benannt: der grid-gap/gap von .gbbFooterTotalContainer (greift, sobald
   Label und Preis - z. B. durch den Zur-Kasse-Button-Overflow-Fix in
   Abschnitt 60 oben - auf zwei Zeilen umbrechen) war zu gross. Auf 0
   gesetzt, wie von ihr vorgeschlagen (Alternative waere 1px gewesen).
   Unscoped (keine Media Query) - der Baustein wird laut SDK-Referenz sowohl
   im mobilen Footer-Wagen als auch auf Desktop verwendet. */
body .gbbFooterTotalContainer {
  gap: 0px !important;
}

/* ---------------------------------------------------------------- 63.
   BIO-/PFLANZLICH-SIEGEL IM PRODUKT-POPUP: LINKS STATT MITTIG (Round 19).
   Die Regel direkt oberhalb (Abschnitt zu .image-block--AK3Q5M2xnWEc0ZFAvW__
   image_LPpgVz, "Auf den Produkt-POPUP-Seiten sollen die Siegel nicht
   rechtsbuendig sein") hatte das bewusst auf "center" gestellt - Merles
   neuer Wunsch dreht das weiter: im Popup auf Mobil sollen die Siegel LINKS
   sitzen, nicht mittig. Diese Regel steht bewusst NACH der center-Regel
   (gleiche Spezifitaet, spaeter im Stylesheet gewinnt) und ueberschreibt sie
   gezielt nur im Popup-Kontext - die echte Produktseite (erste Regel ganz
   oben, rechtsbuendig) bleibt davon unberuehrt. */
@media screen and (max-width: 749px) {
  body dialog.quick-view-modal *:has(> .image-block--AK3Q5M2xnWEc0ZFAvW__image_LPpgVz) {
    justify-content: flex-start !important;
    justify-items: start !important;
  }
}

/* ---------------------------------------------------------------- 64.
   OEKO-SIEGEL-BILD (z. B. im "Dieses Gericht ist"-Akkordeon der Mystery-Box,
   oekosiegel.png) MUSS DUNKEL SEIN (Round 20). Live per Canvas-Pixel-Sample
   nachgemessen statt geraten: das Logo ist ein grossteils transparentes PNG,
   dessen Linienwerk in einem hellen Gelb-Gruen (rgb(157,191,68), aehnlich der
   "PLANT-BASED"-Badge-Farbe) gezeichnet ist - auf dem hellen, blassgruenen
   Seitenhintergrund praktisch unsichtbar (kaum Kontrast). Fix: Bild per
   Filter komplett auf Schwarz (Silhouette, Alphakanal/Form bleibt erhalten)
   gesetzt - eindeutig "dunkel", ohne einen konkreten Grün-/Dunkel-Ton zu
   raten. Falls ein bestimmter Gruenton (statt Schwarz) gewuenscht ist, bitte
   Bescheid geben, dann per hue-rotate/Filter-Kombination gezielt nachjustiert. */
body .image-block--AMTNEMlQ4RWs2cUpRV__image_XLb6Pz img {
  filter: brightness(0) !important;
}

/* ---------------------------------------------------------------- 65.
   "ALLE GERICHTE"-SEITE: FILTER-CHECKBOXEN (Round 26, 6. Feedback-Batch).
   Merles exakte Werte fuer facet-inputs-component uebernommen - kein
   Rateversuch, nur die beiden angegebenen Eigenschaften gesetzt. */
facet-inputs-component .checkbox__label-text {
  -webkit-text-stroke-width: 0.4px !important; /* nur die Breite gesetzt (Langform), damit eine evtl. vorhandene Stroke-Farbe nicht versehentlich mit zurueckgesetzt wird */
}
facet-inputs-component .checkbox__label {
  border-radius: 0.4em !important;
}

/* ---------------------------------------------------------------- 66.
   EB-SEITE: HINTERGRUNDFARBE #e5f6cc (Round 27, 5. Batch). Merle nennt die
   Farbe explizit selbst fuer die "EB page" - kein Rateversuch bei einer
   Seiten-Hintergrundfarbe, da direkt von ihr vorgegeben. Live per Baum-Scan
   das tatsaechlich sichtbare Hintergrund-Element gefunden: NICHT <body>
   (das waere seitenuebergreifend und wuerde auch Nicht-EB-Seiten treffen),
   sondern das EB-Widget-Wrapper-Div selbst (.gbbBundleWrapper.gbbFullPageBundle,
   live gemessen vorher #d4eca9), das die komplette EB-Seite flaechig
   hinterlegt - sauber auf die EB-Seite begrenzt.

   ERGAENZT (Round 27, 6. Feedback-Batch): die drei Easy-Bundles-eigenen
   Navigations-Banner-Fortschritts-Variablen (Office-Box-Seite, "1/4
   Lieferung" etc.) MUESSEN genau HIER (auf diesem Wrapper-Div) gesetzt
   werden, nicht in unserem allgemeinen :root-Variablenblock oben in der
   Datei - live getestet: ein :root-Override (ohne !important) wird von
   Easy Bundles' eigener, naeher am Element liegender Default-Deklaration
   fuer diese Variablen ueberschattet (Custom-Property-Vererbung: die
   naechstgelegene deklarierende Stelle im DOM-Baum gewinnt unabhaengig von
   :root) und kommt dadurch nie bei den eigentlichen Kreisen/Fuellbalken an.
   Erst Scope direkt auf .gbbBundleWrapper.gbbFullPageBundle (= naeher dran
   als die Easy-Bundles-eigene Stelle) PLUS !important hat live sichtbar
   funktioniert (Kreis-Rahmenfarben + Fuellbalken + Titel-Text alle korrekt
   dunkelgruen nachgemessen). --gbb-cart-footer-bg-color ist eine NATIVE,
   von Easy Bundles selbst gesetzte Variable (live gemessen #092F01) - exakt
   identisch mit unserer eigenen --pv-green-darkest, deshalb hier bewusst
   --pv-green-darkest verwendet statt des Hex-Werts nochmal einzutippen.
   Komplettes-Schritt-Fortschritt + Fuellbalken: dunkelgruen wie gewuenscht.
   Die unvollstaendige Border bewusst auf --pv-green-dark (heller als
   --pv-green-darkest) gesetzt, Merles Wunsch "weniger dunkel, aber passend
   zum Hintergrund" - war vorher #cccccc (neutral-grau, nativer Default). */
.gbbBundleWrapper.gbbFullPageBundle {
  /* GEAENDERT (9.10., Round 27 Batch 13): Merles neuer Wunsch - #e5f6cc
     ersetzt durch #e9f6d7. Live per Grep geprueft: dieser Hex-Wert kam im
     gesamten base.css nur an genau zwei Stellen vor - hier (Seiten-
     Hintergrund) und bei den Strichlücken des Office-Box-Tick-Rahmens
     (Abschnitt weiter unten) - beide jetzt auf den neuen Ton umgestellt.
     Produktkarten-Hintergrund (.gbbProductItem) ist bereits transparent
     (siehe dort) und zieht die neue Farbe automatisch mit, ohne eigene
     Aenderung. Keine Schriftfarbe im File verwendet denselben Hex-Wert -
     daher sonst nichts weiter anzupassen gefunden. */
  background-color: #e9f6d7 !important;
  --gbb-navigation-banner-step-completion-color: var(--pv-green-darkest) !important;
  --gbb-navigation-banner-step-progress-bar-filled-color: var(--pv-green-darkest) !important;
  /* GEAENDERT (Round 27, 7. Feedback-Batch): Merles eigener Vorschlag
     #637353 statt --pv-green-dark (war #143c1f) - zufaellig derselbe Ton,
     den Easy Bundles selbst vorher als nativen Default fuer die
     completion-/progress-Variablen genutzt hatte (siehe Abschnitt 66 oben),
     jetzt gezielt fuer die incomplete-border-Variable wiederverwendet. */
  --gbb-navigation-banner-step-incomplete-border-color: #637353 !important;
}

/* ---------------------------------------------------------------- 67.
   EB BOX-AUSWAHL (.gbbBoxSelectionItem): RAHMEN WEG, STATTDESSEN OUTLINE
   (Round 27, 5. Batch). Merle "die border bei den nicht ausgewaehlten
   wieder weg, stattdessen die outline nutzen, #ddffbb, 0.8px". Ersetzt den
   2px-Border aus Batch 3 (als Kommentar erhalten) - outline statt border
   hat den Vorteil, keinen Platz im Boxmodell einzunehmen (verschiebt also
   nichts), ausserdem ueberschreibt es damit zugleich die native graue
   1px-Outline, die hier vorher zusaetzlich sichtbar war (live gemessen:
   rgb(227,227,227), kein eigener Ursprung von uns). */
body .gbbBoxSelectionItem[aria-pressed="false"],
body .gbbBoxSelectionItem[data-is-active="false"] {
  /* ALT (Backup, Round 27, 3. Batch): border: 2px solid #ddffbb !important; */
  border: none !important;
  /* KORREKTUR (Round 28, 29. Batch): Merle "die unausgewaehlten
     Selection-Boxen, die NICHT im Footer sondern ueber der Suchleiste
     sind, sollen eine WEISSE Outline haben, die Hintergrundfarbgebung ist
     jetzt richtig" - war #ddffbb (zartes Gruenweiss), jetzt reines Weiss.
     Das hier ist die UNSCOPED Basis-Regel (gilt fuer jede
     .gbbBoxSelectionItem, ob im Footer/Drawer oder darueber im
     Produktraster) - fuer den Footer/Drawer-Kontext wird die alte Farbe
     (#ddffbb) direkt darunter in Abschnitt 67c wieder gezielt
     hergestellt (hoehere Spezifitaet durch ".gbbBundleFooter"-Vorfahren-
     Pruefung, siehe dort), damit NUR die "ausserhalb des Footers"-Kacheln
     die neue weisse Outline bekommen. */
  outline: 0.8px solid #ffffff !important;
}

/* ---------------------------------------------------------------- 67b.
   EB BOX-AUSWAHL (.gbbBoxSelectionItem): 4-WEGE-FARBSCHEMA NACH MERLES
   EIGENER, EXAKTER SPEZIFIKATION (Round 28, 21. Batch).
   GEFUNDENER BUG: die bisherige Fassung dieser Regel (Batch 19) unterschied
   "im Cart" vs. "ausserhalb" anhand der DOM-Verschachtelung
   (".gbbDrawer.gbbCartDrawer" als Vorfahre) - Merle meldet jetzt, dass auf
   echtem DESKTOP die unausgewaehlten Boxen eine falsche (zu dunkle) Schrift
   zeigen. Root Cause: auf Desktop sitzen die Box-Auswahl-Kacheln NIE
   innerhalb von ".gbbDrawer.gbbCartDrawer" (bereits in Batch 19 live
   bestaetigt: "nur EINE Instanz im DOM, in .gbbBundleFooter") - die DOM-
   basierte Unterscheidung hat Desktop daher IMMER faelschlich in den
   "ausserhalb"-Zweig (helle Kacheln, dunkle Schrift) einsortiert, obwohl
   Desktop laut Merles eigener Beschreibung der NORMALFALL fuer "im Cart"
   ist (".gbbBundleFooter" hat dort den dunkelgruenen #092f01-Hintergrund).
   Fix: Unterscheidung komplett auf Breite/Ausrichtung umgestellt, passend zu
   Merles eigener Beschreibung ("im Cart" = 90% der Desktop-Scalings,
   "ausserhalb, ueber den Produkten" = Handy-Hochformat UND wenn der Desktop
   extrem schmal/hochkant gezogen wird, eventuell iPad Hochformat) - dieselbe,
   bereits etablierte Breakpoint-Technik wie beim Hero
   ("max-width:1199px and orientation:portrait" deckt sowohl echtes Handy-
   Hochformat als auch ein schmal gezogenes, dadurch hochkant werdendes
   Desktop-Fenster ab). "Im Cart" (Rules 1+3 aus Merles Spezifikation) ist
   dadurch jetzt der UNGESCOPTE Normalfall (gilt ueberall ausser im
   Portrait-Mobil-Bereich), "ausserhalb, ueber den Produkten" (Rules 2+4) ist
   auf genau diesen Portrait-Bereich gescoped.
   AUSDRUECKLICHER HINWEIS: die exakte Grenze (1199px/portrait) ist aus den
   bereits etablierten Hero-Breakpoints dieser Datei uebernommen, nicht neu
   live gemessen - bitte gegenchecken, ob sie fuer die Box-Auswahl genauso
   passt. */
/* Regel 1 (Merle): AUSGEWAEHLT, im Cart (Normalfall/Desktop) - hellgruener
   Hintergrund #F1FFDE, weisse Outline, DUNKLE Schrift. */
body .gbbBoxSelectionItem[aria-pressed="true"],
body .gbbBoxSelectionItem[data-is-active="true"] {
  background-color: #F1FFDE !important;
  border: none !important;
  outline: 1.5px solid #ffffff !important;
  color: var(--pv-green-dark, #143c1f) !important;
}
body .gbbBoxSelectionItem[aria-pressed="true"] .gbbBoxSelectionHeading,
body .gbbBoxSelectionItem[aria-pressed="true"] .gbbBoxSelectionSubtext,
body .gbbBoxSelectionItem[data-is-active="true"] .gbbBoxSelectionHeading,
body .gbbBoxSelectionItem[data-is-active="true"] .gbbBoxSelectionSubtext {
  color: var(--pv-green-dark, #143c1f) !important;
}
/* Regel 3 (Merle): UNAUSGEWAEHLT, im Cart (Normalfall/Desktop) -
   dunkelgruener Hintergrund #092f01, helle Schrift + Outline #F1FFDE.
   ARCHIVIERT (Round 28, 28. Batch): durch Abschnitt 67c (Dateiende, echte
   ".gbbBundleFooter"-Vorfahren-Pruefung statt Breite/orientation) ersetzt -
   border/outline oben in Abschnitt 67 (Zeile ~10259) bleibt unveraendert
   bestehen, nur Hintergrund/Schriftfarbe wandern in die neue Regel.
body .gbbBoxSelectionItem[aria-pressed="false"],
body .gbbBoxSelectionItem[data-is-active="false"] {
  background-color: #092f01 !important;
  border: none !important;
  outline: 0.8px solid #F1FFDE !important;
  color: #F1FFDE !important;
}
body .gbbBoxSelectionItem[aria-pressed="false"] .gbbBoxSelectionHeading,
body .gbbBoxSelectionItem[aria-pressed="false"] .gbbBoxSelectionSubtext,
body .gbbBoxSelectionItem[data-is-active="false"] .gbbBoxSelectionHeading,
body .gbbBoxSelectionItem[data-is-active="false"] .gbbBoxSelectionSubtext {
  color: #F1FFDE !important;
}
*/
/* Regeln 2+4 (Merle): "ausserhalb des Carts, ueber den Produkten" - Handy-
   Hochformat UND schmal/hochkant gezogener Desktop/iPad. */
@media screen and (max-width: 1199px) and (orientation: portrait) {
  /* Regel 4: UNAUSGEWAEHLT - helle Schrift-auf-hell-Optik, dunkle Schrift,
     weisse Outline. KORREKTUR (Round 28, 24. Batch): Merle meldet "Handy
     hoch, nicht ausgewaehlte Boxen IM DRAWER CART sind dunkelgruen, muessen
     aber hell sein". Root Cause: "background-color:transparent" (bisher,
     "genau wie es auf dem Handy jetzt ist") funktioniert nur, WEIL die
     Kachel in dem Fall ueber dem hellen Seitenhintergrund lag - sitzt
     dieselbe Kachel stattdessen im dunkelgruenen Cart-Drawer-Panel
     (".gbbBundleFooter"/Drawer, #092f01), scheint durch "transparent" genau
     dieser dunkle Hintergrund durch. Die urspruengliche Breakpoint-Regel
     ging faelschlich davon aus, dass "Handy hoch" und "im Cart" sich
     gegenseitig ausschliessen (siehe Kommentar bei Abschnitt 67b oben) - das
     stimmt aber nur fuer die Hero-Situation, nicht fuer die Box-Auswahl: auf
     Handy hoch kann die Auswahl sowohl ueber den Produkten ALS AUCH im
     Drawer erscheinen, und Merle moechte in BEIDEN Faellen hell. Fix: echte,
     blickdichte helle Hintergrundfarbe statt transparent (dieselbe
     Creme-/Hellgruen-Farbe wie der Seitenhintergrund, #e3f3c6) - bleibt
     dadurch unabhaengig vom jeweiligen Eltern-Hintergrund sichtbar hell.
     ARCHIVIERT (Round 28, 28. Batch): Merle meldet erneut falsche Farben im
     Drawer auf genau dieser Handy-Hochformat-Breite - Root Cause: diese
     Breite/orientation-Abfrage kann nicht unterscheiden, ob die Kachel GERADE
     im geoeffneten dunklen Drawer sitzt oder ueber dem hellen Produktraster
     (live heute bestaetigt: beide Faelle kommen auf Handy-Hochformat vor).
     Ersetzt durch Abschnitt 67c (Dateiende), das stattdessen echte
     DOM-Zugehoerigkeit zu ".gbbBundleFooter" prueft - funktioniert dadurch
     automatisch richtig in BEIDEN Faellen, unabhaengig von der Breite.
  body .gbbBoxSelectionItem[aria-pressed="false"],
  body .gbbBoxSelectionItem[data-is-active="false"] {
    background-color: #e3f3c6 !important;
    border: none !important;
    outline: 2px solid #ffffff !important;
    color: var(--pv-green-dark, #143c1f) !important;
  }
  body .gbbBoxSelectionItem[aria-pressed="false"] .gbbBoxSelectionHeading,
  body .gbbBoxSelectionItem[aria-pressed="false"] .gbbBoxSelectionSubtext,
  body .gbbBoxSelectionItem[data-is-active="false"] .gbbBoxSelectionHeading,
  body .gbbBoxSelectionItem[data-is-active="false"] .gbbBoxSelectionSubtext {
    color: var(--pv-green-dark, #143c1f) !important;
  }
  */
  /* Regel 2: AUSGEWAEHLT - etwas dunkleres Gruen als der Seitenhintergrund
     (#e3f3c6), ganz duenne dunkelgruene Outline. */
  body .gbbBoxSelectionItem[aria-pressed="true"],
  body .gbbBoxSelectionItem[data-is-active="true"] {
    background-color: #d9edbe !important;
    border: none !important;
    outline: 1px solid var(--pv-green-dark, #143c1f) !important;
    color: var(--pv-green-dark, #143c1f) !important;
  }
  body .gbbBoxSelectionItem[aria-pressed="true"] .gbbBoxSelectionHeading,
  body .gbbBoxSelectionItem[aria-pressed="true"] .gbbBoxSelectionSubtext,
  body .gbbBoxSelectionItem[data-is-active="true"] .gbbBoxSelectionHeading,
  body .gbbBoxSelectionItem[data-is-active="true"] .gbbBoxSelectionSubtext {
    color: var(--pv-green-dark, #143c1f) !important;
  }
}

/* ---------------------------------------------------------------- 67c.
   EB BOX-AUSWAHL (.gbbBoxSelectionItem), NICHT AUSGEWAEHLT: KONSOLIDIERTE
   FASSUNG NACH ECHTER DOM-ZUGEHOERIGKEIT STATT VIEWPORT-BREITE (Round 28,
   28. Batch).
   Merles neue, praezisierte Anfrage: unausgewaehlte Kacheln sollen IMMER
   die Hintergrundfarbe des Eltern-Divs uebernehmen (am robustesten per
   background:transparent, nicht per Breite/orientation geraten). Innerhalb
   des Carts/Drawers (".gbbBundleFooter", nativ #092f01 dunkelgruen) soll die
   Schrift #F1FFDE sein, ausserhalb (ueber dem Produktraster/Suchfeld) soll
   die Schrift #092F01 sein.
   ROOT-CAUSE-FUND (heute, live am echten mobilen Drawer getestet, ca. 500px
   Portrait-Breite): ".gbbBundleFooter" ist TATSAECHLICH der zuverlaessige
   Vorfahre sowohl im aufgeklappten Cart-Drawer auf dem Handy als auch im
   Desktop-Sidebar-Fall (per getBoundingClientRect()/closest() direkt
   nachgeprueft - die Kacheln im geoeffneten Drawer haben ".gbbBundleFooter"
   als Vorfahren). Die bisherigen Fassungen (Abschnitt 34b/Batch 14 weiter
   oben + Abschnitt 67b/Batch 21/24 direkt oberhalb) haben stattdessen auf
   Bildschirmbreite/orientation geraten (Workaround fuer einen damals falsch
   gewaehlten Selektor, ".gbbDrawer.gbbCartDrawer" statt ".gbbBundleFooter")
   - das fuehrt genau zu Merles aktuellem Problem: auf Handy-Hochformat wird
   die Kachel IMMER als "ausserhalb" behandelt, obwohl sie beim geoeffneten
   Drawer tatsaechlich DRIN sitzt (helle Kachel auf dunklem Drawer-Hintergrund
   bzw. umgekehrt, je nach Zwischenstand der letzten Batches - in jedem Fall
   nicht das gewuenschte Ergebnis). Mit dem echten Vorfahren-Selektor ist die
   Breite/orientation-Abfrage nicht mehr noetig und funktioniert automatisch
   in BEIDEN Faellen richtig.
   Die drei frueheren, sich ueberschneidenden Fassungen (Abschnitt 34b/Batch
   14 + Abschnitt 67b/Batch 21/24, Regeln 3+4) sind oben als ARCHIVIERT
   markiert und NICHT geloescht, aber auskommentiert, damit nur noch EINE
   aktuelle Quelle fuer "nicht ausgewaehlt" existiert ("zwei Regeln, selber
   Selektor"-Falle, s. mehrere vorherige Batches). Die "ausgewaehlt"-Regeln
   (Regel 1+2, "true"/"active") sind von diesem Fix NICHT betroffen und
   bleiben unveraendert bestehen.
   HINWEIS: background:transparent wie von Merle gewuenscht - zeigt dadurch
   automatisch immer die tatsaechliche Hintergrundfarbe des Eltern-Divs,
   unabhaengig von Bildschirmbreite oder spaeteren Farbaenderungen am
   Drawer/Seitenhintergrund. Falls das irgendwo doch unerwartet durchscheint
   (z.B. durch ein bisher unbekanntes, selbst dunkles Element dazwischen),
   bitte Screenshot melden - dann auf feste Hex-Werte (#092F01 im Footer,
   #F1FFDE ausserhalb) umstellen, die Merle als Fallback explizit genannt
   hat. NICHT live verifiziert werden konnte Merles genauer Ursprungs-
   Screenshot ("BG#092f01 Text:#092f01" im Drawer) - ein eigener Live-Test
   heute (Drawer geoeffnet, Handy-Hochformat-Breite) zeigte dort KEINE
   unlesbare Kombination, sondern die (falsche, aber lesbare) "ausserhalb"-
   Farbgebung aus Abschnitt 67b. Moeglich, dass der Screenshot von einem
   aelteren Zwischenstand stammt (vor Batch 24s Entfernen von transparent) -
   bitte nach dem Einfuegen dieser Datei einmal frisch gegenchecken. */
body .gbbBoxSelectionItem[aria-pressed="false"],
body .gbbBoxSelectionItem[data-is-active="false"] {
  background-color: transparent !important;
  color: #092F01 !important;
}
body .gbbBoxSelectionItem[aria-pressed="false"] .gbbBoxSelectionHeading,
body .gbbBoxSelectionItem[aria-pressed="false"] .gbbBoxSelectionSubtext,
body .gbbBoxSelectionItem[data-is-active="false"] .gbbBoxSelectionHeading,
body .gbbBoxSelectionItem[data-is-active="false"] .gbbBoxSelectionSubtext {
  color: #092F01 !important;
}
body .gbbBundleFooter .gbbBoxSelectionItem[aria-pressed="false"],
body .gbbBundleFooter .gbbBoxSelectionItem[data-is-active="false"] {
  background-color: transparent !important;
  color: #F1FFDE !important;
}
body .gbbBundleFooter .gbbBoxSelectionItem[aria-pressed="false"] .gbbBoxSelectionHeading,
body .gbbBundleFooter .gbbBoxSelectionItem[aria-pressed="false"] .gbbBoxSelectionSubtext,
body .gbbBundleFooter .gbbBoxSelectionItem[data-is-active="false"] .gbbBoxSelectionHeading,
body .gbbBundleFooter .gbbBoxSelectionItem[data-is-active="false"] .gbbBoxSelectionSubtext {
  color: #F1FFDE !important;
}
/* NEU (Round 28, 29. Batch): siehe Kommentar bei Abschnitt 67 (Zeile
   ~10457) - die dortige Basis-Outline wurde von #ddffbb auf #ffffff
   (weiss) geaendert, weil Merle das fuer die Kacheln AUSSERHALB des
   Footers/Drawers so wollte. Hier (hoehere Spezifitaet dank
   ".gbbBundleFooter"-Vorfahren-Pruefung) wird fuer den Footer/Drawer-
   Kontext gezielt wieder die alte Farbe (#ddffbb) hergestellt, da Merle
   nur die Kacheln "ueber der Suchleiste" (ausserhalb des Footers)
   erwaehnt hat - im Footer/Drawer bleibt dadurch alles wie vorher. */
body .gbbBundleFooter .gbbBoxSelectionItem[aria-pressed="false"],
body .gbbBundleFooter .gbbBoxSelectionItem[data-is-active="false"] {
  outline: 0.8px solid #ddffbb !important;
}

/* NEU (Round 28, 31. Batch): Merle "unausgewaehlte Selection-Boxen
   AUSSERHALB des Carts/Footers, ueber der Suchleiste, brauchen auf Handy-
   Hochformat eine 2px dicke Outline" - die Basis-Regel (Abschnitt 67, oben)
   setzt dafuer aktuell 0.8px. Hier gezielt auf Mobil-Hochformat angehoben.
   Die Footer/Drawer-Variante direkt darueber (0.8px #ddffbb) ist davon NICHT
   betroffen: deren Selektor hat durch den ".gbbBundleFooter"-Vorfahren eine
   hoehere Spezifitaet und gewinnt dort weiterhin, unabhaengig von dieser
   Media Query. Zum Hintergrund ("der Background ist noch nicht"): nicht
   eindeutig, WAS genau an der Hintergrundfarbe noch fehlt - Abschnitt 67c
   setzt dafuer bereits background-color:transparent; bitte genauer
   beschreiben oder Screenshot mit markierter Stelle, dann gezielt nachbessern. */
@media screen and (max-width: 1199px) and (orientation: portrait) {
  body .gbbBoxSelectionItem[aria-pressed="false"],
  body .gbbBoxSelectionItem[data-is-active="false"] {
    outline: 2px solid #ffffff !important;
  }
}

/* ---------------------------------------------------------------- 68.
   EB BOX-AUSWAHL: PROBIER-BOX NOCH MINIMAL NIEDRIGER (Round 27, 5. Batch).
   Merle "Probier-Box noch minimal weniger hoch, damit der Unterschied zur
   Single-Box groesser wird". War 100px (Batch 3), jetzt 90px - Schaetzwert
   fuer "minimal", bitte live gegenchecken ob der Abstand zur Single-Box
   (115px) so ausreicht oder noch mehr werden soll. Single-Box/We-are-
   family-Box-Werte unveraendert. */
.gbbBoxSelectionContainer .gbbBoxSelectionItem:nth-child(1) {
  min-height: 90px !important; /* war 100px */
}

/* ---------------------------------------------------------------- 69.
   EB KATEGORIE-TABS: WEITERHIN UNTEN ANGESCHNITTEN (Round 27, 5. Batch).
   Root-Cause-Update: der Tab-Reihen-Container (.gbbCategoriesTabsContainer)
   hat eine FESTE, nativ per JS gesetzte Zeilenhoehe (grid-template-rows,
   live gemessen 70.3984px) - diese wird einmalig beim Laden/Mounten der
   Komponente gemessen und NICHT laufend an CSS-Aenderungen angepasst. Live
   bestaetigt: weder !important-Overrides auf grid-template-rows/min-height
   noch auf overflow greifen nachtraeglich (nur per direktem JS-Zugriff
   aenderbar, nicht per CSS-Datei) - echte technische Grenze, kein Kaskaden-
   Problem wie sonst oft. Gemessen ausserdem: scrollHeight (72px) liegt
   knapp (2px) ueber clientHeight (70px) - das reicht fuer das leichte
   Anschneiden, das Merle weiterhin sieht.
   Da ich die fixe Zeilenhoehe selbst nicht per CSS beeinflussen kann, bleibt
   nur der andere Hebel: den Tab-INHALT noch etwas kompakter machen, damit
   er unter die (unveraenderliche) 70px-Grenze passt. Padding nochmal
   reduziert (war 8px aus Batch 3, jetzt 6px).
   WICHTIG/EINSCHRAENKUNG: da die native Komponente ihre Zeilenhoehe nur
   EINMALIG beim Laden misst, kann ich diesen Fix in meiner Sandbox nicht
   zuverlaessig live verifizieren (meine Live-Tests injizieren CSS immer
   NACH dem bereits erfolgten Laden/Messen) - das kann nur ein echter
   Neuladen-Test mit bereits eingefuegter neuer CSS beantworten. Bitte nach
   dem Einspielen pruefen, ob das Anschneiden jetzt weg ist. Umgesetzt direkt
   an der bestehenden Desktop-Regel (siehe Abschnitt "Kategorie-Tabs Gap/
   Padding" weiter oben in der Datei), NICHT als neue Regel hier - sonst
   haette die hier (niedrigere Spezifitaet ohne "body"-Praefix) die
   bestehende 8px-Regel gar nicht schlagen koennen. */

/* ---------------------------------------------------------------- 70.
   OFFICE-BOX-SEITE: NAVIGATIONS-BANNER (Round 27, 6. Feedback-Batch).
   Die drei Fortschritts-Variablen (--gbb-navigation-banner-step-*) stehen
   NICHT hier, sondern oben bei Abschnitt 66 (.gbbBundleWrapper.gbbFullPageBundle,
   "EB-SEITE: HINTERGRUNDFARBE") - dort ist der live getestete, einzig
   funktionierende Scope dafuer, siehe Kommentar dort fuer den Grund.

   1) margin-bottom vom Items-Container komplett weg (live gemessen vorher
      9.59375px).
   2) .gbbNavigationTitle bewusst per EIGENER, separater Regel auf dunkelgruen
      gesetzt (--pv-green-darkest, identisch mit --gbb-cart-footer-bg-color) -
      AUSDRUECKLICH NICHT ueber die native, von GBB aus dem Editor gesetzte
      Variable --gbb-navigation-banner-step-text-color (Merles eigene Sorge:
      "wenn ich die anfasse, dass ich dann noch etwas anderes kaputtmache").
      Diese Variable bleibt hier vollstaendig unberuehrt.

   Separat festgestellt, aber NICHT Teil dieser Anfrage: die Schritt-Kreise
   ("1/4 Lieferung" etc.) werden oben vom stickyen Seiten-Header leicht
   angeschnitten - live bestaetigt, dass das bereits OHNE jede unserer
   Aenderungen so ist (Vergleich mit/ohne Test-Styles), also ein
   vorbestehendes, separates Problem und keine Nebenwirkung dieses Batches.
   Falls gewuenscht, bitte als eigenen Punkt melden. */
body .gbbNavigationItemsContainer {
  margin-bottom: 0px !important; /* war 9.59375px */
}
body .gbbNavigationTitle {
  color: var(--pv-green-darkest) !important;
}

/* ---------------------------------------------------------------- 71.
   OFFICE-BOX-SEITE: WEITERE EINZELPUNKTE (Round 27, 7. Feedback-Batch).
   Scope: ausdruecklich "NUR bei der Office Box" - dafuer body[data-offer-
   id="SDK-023099"] verwendet statt einer URL-Pruefung: live bestaetigt,
   dass Easy Bundles diese Offer-ID selbst als Attribut auf <body> UND auf
   .gbbBundleWrapper setzt, und dass die normale Box-Seite (/products/box)
   eine ANDERE eigene Offer-ID hat (SDK-587069) - robuster Scope, der auch
   funktioniert, falls der Produkt-Handle/die URL sich mal aendert. */

/* 1) .gbbNavigationStepIndicator: padding auf 0, damit das Icon den Kreis
   voll ausfuellt. Live gemessen: war 4px rundum (Kreis-Durchmesser bleibt
   gleich, 40px - nur der Innenabstand faellt weg). Per Zoom-Screenshot
   vorher/nachher verglichen: vorher duenner heller Ring um das Icon,
   nachher Icon randfuellend. FERTIG, LIVE VERIFIZIERT (mein Testbrowser). */
body[data-offer-id="SDK-023099"] .gbbNavigationStepIndicator {
  padding: 0 !important;
}

/* 1b) NEU (Round 27, 8. Batch), drei weitere Office-Box-Wuensche:
   - Tick-Haekchen (abgeschlossener Schritt): das SVG steckt in einem
     ".gbbTickMark"-Div (nicht ".gbbTick", wie zuerst genannt - live im DOM
     nachgesehen), aktuell 30x30px per Attribut, jetzt auf 40x40 (passend zur
     40px-Kreisgroesse des Indicators).
   - Aktiver Schritt (".gbbNavigationStepIndicator[data-step-status=active]"):
     Rahmen war 4px solid (native Farbe = unsere --pv-green-darkest, siehe
     Batch 6), jetzt gestrichelt statt durchgezogen.
   - Inkompletter Schritt: das Icon selbst (".gbbNavigationImage") bekommt
     0.8 Opacity, um ihn optisch zurueckzunehmen (war bisher 1, live
     gemessen).
   KORREKTUR (9.10., Round 27 Batch 11): "feiner stricheln und dunkelgrün
   mit hintergrundhellgrün abwechseln, nicht weiß" - der gestrichelte
   Rahmen war noch 4px dick (nativer Ausgangswert), auf 2px reduziert
   ("feiner"). Die Luecken zwischen den Strichen zeigten bisher Weiss (wohl
   ein nativer heller Hintergrund des Kreis-Elements) - jetzt per eigenem
   background-color auf #e5f6cc (= unser bereits etablierter
   EB-Seitenhintergrund, siehe Batch 5) gesetzt, damit die Luecken hellgruen
   statt weiss erscheinen. HINWEIS: das ist eine Annaeherung an "zwei Farben
   abwechselnd" (dunkelgruener Strich auf hellgruenem Grund), nicht ein
   echtes zweifarbiges Strichmuster - ein "echtes" zweifarbiges Dash (jeder
   zweite Strich eine andere Farbe) braucht einen Gradient-Trick
   (border-image mit repeating-linear-gradient), der auf einem runden
   Element (border-radius) browserübergreifend unzuverlaessig ist, deshalb
   bewusst nicht verwendet. Bitte gegenchecken, ob diese einfachere Loesung
   schon reicht, oder ob wirklich ein echtes zweifarbiges Muster noetig ist.
   KORREKTUR (Round 28, 51. Batch): Merle moechte den gestrichelten Rahmen
   beim aktiven Schritt doch nicht mehr gestrichelt, sondern dick und
   durchgezogen ("solid") haben - damit entfaellt die oben beschriebene
   Luecken-Farbe-Problematik automatisch (ein durchgezogener Rahmen hat keine
   Luecken). "border-style" auf "solid" zurueckgesetzt, "border-width" von
   2px auf 4px erhoeht (= der urspruengliche, native Ausgangswert vor der
   Batch-11-Verduennung - entspricht "dick"). Die Hintergrundfarbe
   (#e9f6d7) bleibt unveraendert bestehen (fuellt weiterhin die Flaeche
   hinter dem Icon, unabhaengig vom Rahmenstil). NICHT LIVE VERIFIZIERT
   (Chrome-Erweiterung diese Runde nicht verbunden). */
body[data-offer-id="SDK-023099"] .gbbTickMark svg {
  width: 40px !important;
  height: 40px !important;
}
body[data-offer-id="SDK-023099"] .gbbNavigationStepIndicator[data-step-status="active"] {
  border-style: solid !important;
  border-width: 4px !important;
  /* GEAENDERT (Batch 13): mitgezogen auf den neuen Seitenhintergrund-Ton,
     siehe Korrektur bei .gbbBundleWrapper.gbbFullPageBundle weiter oben. */
  background-color: #e9f6d7 !important;
}
body[data-offer-id="SDK-023099"] .gbbNavigationStepIndicator[data-step-status="incomplete"] .gbbNavigationImage {
  opacity: 0.8 !important;
}

/* 2) Progress-Bar-Subtitel ("Woche 1 – 2" etc.) darf bei Bedarf hinter
   "Woche" umbrechen. Live geprueft: white-space war bereits "normal" (kein
   nowrap von uns oder nativ), der Text bricht bei erzwungener schmaler
   Spaltenbreite bereits sauber genau hinter "Woche" um (zweite Zeile "1 –
   2"), kein Abschneiden. Diese Regel hier ist dadurch ein reiner
   Sicherheits-Zusatz (identisches Muster wie Abschnitt 60 oben bei der
   Gesamtpreis-Pille), kein inhaltlicher Fix - falls dein echtes Geraet bei
   einer anderen Bedingung doch noch abschneidet, bitte mit Screenshot
   melden. */
body[data-offer-id="SDK-023099"] .gbbDiscountStepsProgressBarStepSubtitle {
  white-space: normal !important;
  overflow-wrap: normal !important;
  word-break: normal !important;
}

/* NEU (Round 28/Batch 14): Merle "auf der EB-Seite bricht versandkostenfrei
   komisch um, am liebsten gar nicht umbrechen". Live auf der Single-Box-
   Seite (950px) nachgemessen: der Subtitel-Container ist nur ca. 100-107px
   breit, "versandkostenfrei" braucht aber ca. 113px am Stueck - bricht
   dadurch (ohne erkennbares Hyphenation-Muster) mitten im Wort um. Fix:
   white-space:nowrap - Live-Test zeigt, dass der Text dann zwar ca. 6-13px
   ueber seinen eigenen Container hinaussteht, aber genug Abstand zu den
   Nachbar-Markierungen ("5,99€/Gericht" etc.) hat, um nicht zu ueberlappen
   (Screenshot gegengecheckt). BEWUSST AUSGENOMMEN: body[data-offer-id=
   "SDK-023099"] (Office-Box) - dort steht in genau diesem Subtitel-Feld
   "Woche 1 - 2" statt "versandkostenfrei", und die direkt oberhalb stehende
   Regel erlaubt dort ABSICHTLICH weiterhin den Umbruch hinter "Woche"
   (bereits live verifiziert, siehe Kommentar dort) - ein globales nowrap
   wuerde das wieder zerstoeren. */
body:not([data-offer-id="SDK-023099"]) .gbbDiscountStepsProgressBarStepSubtitle {
  white-space: nowrap !important;
}

/* 3) .gbbFooterTotalItemsInCart: zusaetzliches padding oben.
   AUSDRUECKLICHER HINWEIS: ich konnte dieses Element in meiner Sandbox in
   keinem der von mir getesteten Zustaende (Schritt 1, 0/1 Gericht
   ausgewaehlt, Wagen auf-/zugeklappt) tatsaechlich finden/rendern - anders
   als bei den beiden Punkten oben, daher komplett UNVERIFIZIERT. 8px ist
   eine reine Schaetzung fuer "etwas mehr Luft", bitte unbedingt live
   gegenchecken, ob die Regel ueberhaupt greift (an welcher Stelle siehst
   du dieses Feld genau?) und ob der Wert passt. */
body[data-offer-id="SDK-023099"] .gbbFooterTotalItemsInCart {
  padding-top: 8px !important; /* Schaetzwert, unverifiziert */
}

/* ---------------------------------------------------------------- 36. HERO
   HOCHFORMAT: "Z-INDEX KAPUTT" - Deko-Food-Fotos lagen vor der Headline.
   Merles Screenshot (schmales/hohes Browserfenster UND echtes Handy) zeigt
   die Headline teilweise hinter den runden Deko-Food-Fotos verschwindend
   ("Frisch" nur als "sch" sichtbar usw.) - von ihr als "Z-Index kaputt"
   beschrieben. ECHTER ROOT CAUSE live bewiesen (500x701, echter Chrome-Tab):
   ".hero-text-group" steht in diesem Breitenbereich bewusst auf
   "position:static" (Abschnitt 16 oben, aus Hoehen-Fluss-Gruenden so
   gewaehlt) - und genau DESHALB hat ein auf ihr gesetzter z-index ÜBERHAUPT
   KEINE WIRKUNG (z-index gilt per CSS-Spezifikation NUR fuer positionierte
   Elemente). Die Deko-Fotos (".image-block", direkte Geschwister-Elemente
   von ".hero-text-group" innerhalb von ".hero__content-wrapper") sind
   dagegen "position:absolute" - ein positioniertes Element stapelt sich
   IMMER ueber normal fliessenden ("static") Inhalt, unabhaengig von jedem
   z-index-Wert auf der static-Seite. Live bewiesen: probeweises
   Ausblenden/Zuruecksetzen des z-index des konkreten Fotos behob die
   Ueberlappung sofort (Screenshot vorher/nachher verglichen). Das ist
   vermutlich kein neuer Bug, sondern war schon immer so - nur bei den
   KLEINEREN Schriftgroessen frueherer Runden hat die Headline die Deko-Fotos
   nie physisch erreicht, wodurch es nie sichtbar wurde. Fix: die Deko-Fotos
   in genau diesem Breitenbereich auf einen definitiv niedrigen z-index
   gesetzt, damit sie zuverlaessig HINTER der Textgruppe bleiben, egal wie
   gross/klein diese gerade ist. Bewusst nur auf Deko-Fotos innerhalb des
   Hero-Containers begrenzt (nicht unconditional/sitewide fuer ".image-block"),
   um keine anderen Bildbloecke auf der Seite zu beeinflussen.
   ERGAENZT (noch im selben Fund): nicht nur die Food-Foto-".image-block"-
   Elemente liegen vor der Headline, sondern aus demselben Grund (position:
   absolute vs. .hero-text-group's position:static) auch die grosse
   dekorative Wellenform ".planet-wave" (z-index:4, live gefunden) - sie
   ueberlappt bei "gekocht" (zweite Headline-Zeile) genauso die Textfarbe.
   Gleicher Fix, gleiche Breitenbegrenzung.
   KORREKTUR 3 (Round 28, 39. Batch, GRUNDLEGENDER FIX): Merle meldete nach
   dem 38. Batch, dass der z-index-Fehler in mehreren Szenarien weiterhin
   auftritt (schmales Desktop-Fenster, echtes Handy-Hochformat: Welle liegt
   wieder vor Text/Logo). Ursache gefunden und live bewiesen (CSS2.1 Anhang E
   Stapelreihenfolge, per injiziertem Style-Override direkt an der Live-Seite
   getestet): ".hero-text-group" ist NUR innerhalb bestimmter Breiten/Modi
   (z.B. der "grosse Desktop-OR-Block", min-width:750px) tatsaechlich
   position:relative - ausserhalb davon (z.B. genau in den schmalen/
   Hochkant-Bereichen, die diese Media-Query abdeckt) bleibt sie
   position:static. Fuer STATISCHEN Inhalt gilt: JEDER position:absolute-
   Nachfahre mit einem z-index von 0 oder hoeher (egal wie "niedrig" die Zahl
   ist, z.B. 4) rendert IMMER ueber dem statischen Text, weil positionierte
   Elemente mit explizitem z-index>=0 eine hoehere Stapelebene belegen als
   normaler statischer Inhalt. Ein positiver Vergleichswert (0 vs. 4 vs. 5
   vs. 6) funktioniert also nur zufaellig dort, wo die Textgruppe ZUSAETZLICH
   selbst positioniert+z-indexed ist - nicht ueberall.
   ECHTER, UNIVERSELLER FIX: alle dekorativen, absolut positionierten Elemente
   (Deko-Fotos, Welle) bekommen stattdessen NEGATIVE z-index-Werte. Negative
   Werte liegen in der Stapelreihenfolge IMMER unter statischem Inhalt UND
   unter jedem positiven/auto-z-index-Inhalt - das ist unabhaengig davon, ob
   ".hero-text-group" an einem gegebenen Breakpoint gerade static oder
   relative+z-index:6 ist. Live per Screenshot-Experiment bestaetigt (Text
   blieb auch bei erzwungenem position:static vollstaendig lesbar, sobald die
   Deko-Elemente auf negative Werte standen). Deko-Fotos: 0 -> -2. Welle:
   4 -> -1 (Welle bleibt damit weiterhin VOR den Deko-Fotos/Planeten,
   zwischen Planeten(-2) und Text/Logo(egal ob static oder positiv)). */
@media screen and (max-width: 1199px) and (orientation: portrait) {
  body .hero__container .image-block,
  body .hero__media-grid .image-block {
    z-index: -2 !important;
  }
  /* KORREKTUR (Round 28, 38. Batch): Merle "Planet V Logo muss hinter die
     Welle in z-index" - sowohl fuer echtes Handy-Hochformat als auch fuer
     schmales Hochkant-Desktop (beide fallen in diesen gemeinsamen Bereich).
     Die Welle stand bisher genauso wie die Deko-Fotos auf z-index:0 - das
     Logo (siehe Abschnitt 16, "echtes Handy")/die narrow-desktop-Regel
     steht aber auf z-index:5, lag also VOR der Welle. Fix: Welle aus der
     obigen Deko-Foto-Regel herausgeloest und auf einen Wert ueber dem
     Logo (5) angehoben.
     KORREKTUR 2 (noch selbe Pruefung, LIVE GEFUNDEN): ein erster Versuch mit
     z-index:10 wurde live getestet (Sandbox-Override-Injektion) und zeigte
     einen neuen Fehler - 10 liegt auch UEBER der Hero-Text-Gruppe (6, siehe
     Abschnitt 16/"grosser Desktop-OR-Block"), wodurch die Welle ploetzlich
     die Headline selbst ueberlappte ("gekocht" teilweise verdeckt). Fix:
     Welle auf 4 gesetzt (gleicher Wert wie in der aelteren, nur fuer
     "echtes Handy" <749px geltenden ID-spezifischen Regel weiter oben,
     siehe "Ziel-Stapelreihenfolge" - Planeten(0), Welle(4), Logo(5),
     Headline-Gruppe(6)) - damit liegt die Welle zuverlaessig VOR den
     Deko-Fotos/Planeten UND dem Logo, aber weiterhin HINTER der
     Headline-Gruppe. Live gegengeprueft: Headline/Logo nicht mehr verdeckt.
     KORREKTUR 3 (Round 28, 39. Batch): siehe grosser Kommentar oberhalb
     dieser Media-Query - 4 war nur zufaellig richtig, wenn die Textgruppe
     selbst positioniert war. Fix: Welle auf -1 (negativ) gesetzt, damit sie
     IMMER hinter Text/Logo bleibt, egal ob diese static oder positioniert
     sind - bleibt dabei weiterhin vor den Deko-Fotos/Planeten (-2). */
  body .hero__container .planet-wave {
    z-index: -1 !important;
  }
}

/* ---------------------------------------------------------------- 36.
   HILFSKLASSEN FUER BILDER IN "CUSTOM LIQUID"-BLOECKEN (Round 28, 44. Batch).
   Merle moechte in einem Custom-Liquid-Block eingefuegte <img>-Tags
   "breitenfuellend" machen koennen, ohne jedes Mal Inline-Styles schreiben zu
   muessen. Zwei Klassen, je nach gewuenschtem Ergebnis - koennen auch
   kombiniert werden:

   1) ".pv-fullwidth-img": macht das Bild so breit wie die Spalte/der
      Container, in dem der Custom-Liquid-Block selbst steht (ueblicher Fall,
      wenn der Block in einer normalen, bereits auf die Seitenbreite
      begrenzten Sektion liegt). Seitenverhaeltnis bleibt erhalten
      (height:auto), display:block verhindert den kleinen Weissraum, den
      <img>-Tags sonst durch ihre Inline-Natur am unteren Rand haben.

   2) ".pv-fullwidth-img--bleed" (zusaetzlich zur ersten Klasse): zieht das
      Bild ueber die normale Seiten-/Container-Begrenzung hinaus bis an den
      linken UND rechten Bildschirmrand (echtes "Full Bleed", bricht aus der
      normalen Seitenbreite aus). Funktioniert mit der ueblichen
      "100vw + negativer Rand"-Technik - setzt voraus, dass der Custom-
      Liquid-Block selbst innerhalb eines zentrierten Containers liegt (bei
      Shopify Horizon normalerweise der Fall).

   Verwendung im Custom-Liquid-Block, z. B.:
   <img src="{{ 'mein-bild.jpg' | asset_url }}"
        alt="Beschreibung"
        class="pv-fullwidth-img">
   - oder, fuer randlos ueber die volle Bildschirmbreite:
   <img src="{{ 'mein-bild.jpg' | asset_url }}"
        alt="Beschreibung"
        class="pv-fullwidth-img pv-fullwidth-img--bleed">

   Beide Klassen sind bewusst eigene, neue Namen (keine Shopify-eigene Klasse
   wird hier ueberschrieben), daher ohne Breakpoint-Einschraenkung - gelten
   auf allen Bildschirmgroessen gleich.

   3) ".pv-fullwidth-img--crop" (NEU, Round 28, 45. Batch, zusaetzlich zur
      ersten Klasse, optional kombinierbar mit "--bleed"): Merle moechte,
      dass das Bild IMMER die komplette Breite ausfuellt und dafuer notfalls
      oben/unten beschnitten wird, statt wie bei der reinen "--fullwidth"-
      Variante sein Seitenverhaeltnis zu behalten (die macht das Bild zwar
      auch breitenfuellend, aber die Hoehe ergibt sich dann aus dem
      Seitenverhaeltnis - kein Zuschnitt). Dafuer braucht ein <img> mit
      "object-fit:cover" zwingend eine EXPLIZITE Hoehe (sonst hat die
      "cover"-Berechnung keine Zielbox, in die hinein zugeschnitten werden
      koennte) - diese Hoehe ist hier bewusst ueber eine CSS-Variable
      einstellbar (Standard 50vh, falls nicht anders angegeben), damit nicht
      fuer jede gewuenschte Bildhoehe eine eigene Klasse noetig ist. Beispiel
      mit Standardhoehe (50% der Fensterhoehe):
      <img src="https://cdn.shopify.com/.../mein-bild.jpg"
           alt="Beschreibung"
           class="pv-fullwidth-img pv-fullwidth-img--bleed pv-fullwidth-img--crop">
      - oder mit eigener, fester Hoehe (z. B. 400px), direkt per Inline-Style
      auf genau diesem Bild gesetzt (ueberschreibt nur die Variable, der Rest
      der Regel bleibt unangetastet):
      <img src="https://cdn.shopify.com/.../mein-bild.jpg"
           alt="Beschreibung"
           class="pv-fullwidth-img pv-fullwidth-img--bleed pv-fullwidth-img--crop"
           style="--pv-img-crop-height: 400px;">
      "object-position:center" (Standard, siehe unten) sorgt dafuer, dass
      beim Zuschneiden gleich viel oben wie unten (bzw. links wie rechts)
      wegfaellt - die Bildmitte bleibt immer sichtbar.

      NACHTRAG (Round 28, 46. Batch): Merle moechte den "Ausschnitt im
      Passepartout" (also welcher Teil des Bildes beim Zuschneiden sichtbar
      bleibt) nach oben/unten verschieben koennen, statt immer die Bildmitte
      zu zeigen. Dafuer ist "object-position" jetzt ebenfalls ueber eine
      CSS-Variable einstellbar (Standard weiterhin "center", falls nicht
      anders angegeben) - per Inline-Style auf dem jeweiligen Bild, genau
      wie schon bei der Hoehe:
      <img src="https://cdn.shopify.com/.../mein-bild.jpg"
           alt="Beschreibung"
           class="pv-fullwidth-img pv-fullwidth-img--bleed pv-fullwidth-img--crop"
           style="--pv-img-crop-position: top;">
      Moegliche Werte: "top" (zeigt den oberen Bildbereich, der untere wird
      stattdessen weggeschnitten), "bottom" (umgekehrt), "center" (Standard,
      Bildmitte), oder ein praeziser Prozentwert wie "center 20%" (20% von
      oben statt mittig) bzw. "center 80%" (weiter unten). Kombinierbar mit
      "--pv-img-crop-height" (siehe oben) fuer volle Kontrolle ueber Hoehe
      UND Ausschnitt-Position in einem Aufwasch.

   4) ".pv-img-stack" + ".pv-img-overlay" (NEU, Round 28, 46. Batch):
      Merle moechte zusaetzlich runde Bilder (z. B. Siegel, Logos, kleine
      Fotos) UEBER einem der obigen Bilder platzieren koennen, innerhalb
      desselben Custom-Liquid-Blocks. ".pv-img-stack" ist eine Wrapper-
      Klasse (gehoert auf ein umschliessendes <div>, nicht auf ein Bild
      selbst) - sie macht diesen Wrapper zum Bezugspunkt fuer alles, was
      innerhalb davon ueberlagert werden soll. ".pv-img-overlay" gehoert auf
      jedes <img>, das rund/ueberlagert dargestellt werden soll - macht es
      automatisch rund (border-radius:50%, setzt also ein quadratisches
      Ausgangsbild voraus) und positioniert es frei ueber CSS-Variablen:
      - "--pv-overlay-size": Durchmesser in px (Standard 80px).
      - "--pv-overlay-top" ODER "--pv-overlay-bottom": Abstand von oben
        bzw. unten (nur EINEN von beiden angeben, nicht beide gleichzeitig).
      - "--pv-overlay-left" ODER "--pv-overlay-right": Abstand von links
        bzw. rechts (ebenfalls nur einen von beiden).
      Beispiel - ein rundes Siegel 20px von oben und 20px von rechts, 100px
      Durchmesser, ueber dem breitenfuellenden Hauptbild:
      <div class="pv-img-stack">
        <img src="https://cdn.shopify.com/.../hauptbild.jpg"
             alt="Beschreibung"
             class="pv-fullwidth-img pv-fullwidth-img--bleed pv-fullwidth-img--crop">
        <img src="https://cdn.shopify.com/.../rundes-siegel.jpg"
             alt="Beschreibung"
             class="pv-img-overlay"
             style="--pv-overlay-top: 20px; --pv-overlay-right: 20px; --pv-overlay-size: 100px;">
      </div>
      Mehrere Overlay-Bilder im selben Stack sind problemlos moeglich -
      einfach mehrere <img class="pv-img-overlay" ...> mit jeweils eigenen
      Positionswerten in denselben Wrapper legen. */
body .pv-fullwidth-img {
  display: block !important;
  width: 100% !important;
  height: auto !important;
}
body .pv-fullwidth-img.pv-fullwidth-img--bleed {
  width: 100vw !important;
  max-width: 100vw !important;
  margin-left: calc(50% - 50vw) !important;
  margin-right: calc(50% - 50vw) !important;
}
body .pv-fullwidth-img.pv-fullwidth-img--crop {
  height: var(--pv-img-crop-height, 50vh) !important;
  object-fit: cover !important;
  object-position: var(--pv-img-crop-position, center) !important;
}
body .pv-img-stack {
  position: relative !important;
  display: block !important;
}
body .pv-img-overlay {
  position: absolute !important;
  width: var(--pv-overlay-size, 80px) !important;
  height: var(--pv-overlay-size, 80px) !important;
  border-radius: 50% !important;
  object-fit: cover !important;
  top: var(--pv-overlay-top, auto) !important;
  bottom: var(--pv-overlay-bottom, auto) !important;
  left: var(--pv-overlay-left, auto) !important;
  right: var(--pv-overlay-right, auto) !important;
  z-index: 2 !important;
}

/* ---------------------------------------------------------------- 35.
   VERIFIKATION Diese Datei wurde nach diesem Batch mit tinycss2 (Python)
   gegen Parse-Fehler geprueft (0 Fehler) - siehe base-css-changelog.md fuer
   die genaue Regel-/Zeilenzahl.
   ---------------------------------------------------------------- */

/* ====================================================================
   ROUND 28, 47. BATCH: GROSSES FEEDBACK-PAKET (17 Punkte) - Mobile
   Landscape (EB-Widget-Kompaktierung), Mobile Portrait (Quick-View-Popup,
   Leerraum), Footer (Tap-to-expand), EB-Cartdrawer-Rotations-Bug.
   ==================================================================== */

/* ---------------------------------------------------------------- 70.
   MOBILE LANDSCAPE: .gbbProductImageContainer::before - TRANSFORM WEG
   Merle: "get rid of the transform rule of gbbproductimagecontainer::before"
   (Screenshot 1, DevTools). Das ist unsere EIGENE Regel (Abschnitt ganz am
   Anfang der Datei, "Farbiger Kreis-Schatten hinter dem Bild") - gilt
   bisher unscoped auf jeder Breite/Ausrichtung. Da Merles Screenshot/Wunsch
   laut ihrer eigenen Kategorisierung ausdruecklich "mobile landscape"
   betrifft, hier NUR fuer echtes Handy-Quer deaktiviert (transform:none),
   Desktop/Hochformat bleiben unangetastet - siehe auch den Kommentar bei
   Abschnitt 36 oben: dieser Schatten ist auf Mobil ohnehin laut Merles
   eigenem Safari-Test meist unsichtbar (verschwindet hinter einem
   Geschwisterelement), die eigentlich sichtbare Schattenquelle ist der
   drop-shadow-Filter auf .gbbProductImage selbst (unveraendert). */
@media screen and (orientation: landscape) and (max-height: 500px) {
  body .gbbProductImageContainer::before {
    transform: none !important;
  }
}

/* ---------------------------------------------------------------- 71.
   MOBILE LANDSCAPE: BOX-AUSWAHL-KACHELN (.gbbBoxSelectionItem) KOMPAKTER
   Merle: "get rid of the min height by .gbbBoxSelectionContainer
   .gbbBoxSelectionItem:nth-child(1) or decrease it" + "maybe you can put
   two gbbBoxSelectionItem in one row and the third beneath? they are still
   taking up too much space". Die Grundregeln (90px/115px/130px je Kachel,
   3 gleich breite Spalten nebeneinander) gelten bisher ueberall unveraendert.
   Hier auf echtem Handy-Quer: 1) alle drei min-height komplett entfernt
   (unset statt "decrease" - deutlichster Gewinn an Hoehe), 2) Layout auf
   2-oben/1-unten umgestellt (grid-template-areas), dritte Kachel dabei
   mittig und schmaler (50%), wie von Merle vorgeschlagen.
   Bewusst in DERSELBEN Media Query wie der bereits live bestaetigte Cart-
   Drawer-Sidebar-Fix weiter oben (Abschnitt bei "min-width:640px") platziert
   (bzw. hier sogar ohne eigene min-width-Untergrenze, siehe Kommentar bei
   Abschnitt 291/Batch 47 oben) - das deckt zugleich den im selben Batch
   gemeldeten EB-Rotations-Bug mit ab (siehe Abschnitt 76 unten), da genau
   diese Kacheln Teil des "bloaht wirkenden" Footers im Querformat sind.
   NICHT live verifiziert (Chrome-Sandbox-Breitenbeschraenkung) - bitte auf
   deinem Handy im Querformat gegenchecken, ob die 2+1-Aufteilung so passt
   oder die dritte Kachel breiter/schmaler werden soll.
   KORREKTUR (Round 28, 49. Batch): Merle meldet (Screenshot) "probierbox
   und singlebox gleich groß / breite des elterndivs gleichmäßig aufteilen
   -> probierbox breiter, singlebox schmaler" - die beiden oberen Kacheln
   ueberlappen sich sichtbar, Text beider Kacheln laeuft ineinander. Root
   Cause live gefunden: die "schmaler Desktop"-Regel weiter oben (Punkt b2,
   gueltig 640-1199px, deckt real jedes Handy-Quer-Geraet mit ab) setzt
   "body .gbbBoxSelectionContainer { width: fit-content !important;
   margin-inline: auto !important; }" fuer die Zentrierung auf schmalem
   Desktop. In Kombination mit den HIER gesetzten "1fr 1fr"-Spalten fuehrt
   "width:fit-content" auf einem Grid-Container aber dazu, dass die fr-
   Spalten NICHT mehr gleichmaessig die verfuegbare Breite teilen, sondern
   sich (mangels definierter verfuegbarer Breite) am eigenen Inhalt
   orientieren (effektiv wie "max-content") - dadurch wird die Spalte mit
   laengerem Text (Single-Box: "12x Gerichte - 65,99€ (versandkostenfrei)")
   breiter als die mit kuerzerem Text, beide ueberlappen sich gegenseitig
   bzw. den Containerrand. Zusaetzlich fehlte "min-width:0" auf den Kacheln
   selbst - ohne das verhindert die native CSS-Grid-Mindestbreite
   ("min-width:auto" = Breite des unzerbrochenen Inhalts) das Schrumpfen auf
   die Spaltenbreite, ein zweiter, unabhaengiger Blowout-Grund.
   Fix: "width:100%" direkt hier ergaenzt (gewinnt gegen die fit-content-
   Regel, da gleiche Spezifitaet UND diese Regel steht spaeter im File) -
   die beiden Spalten teilen sich dadurch wieder zuverlaessig 50/50 die volle
   Containerbreite. Zusaetzlich "min-width:0" auf beiden oberen Kacheln, und
   "overflow-wrap:break-word" auf ihren Text-Elementen, damit laengerer Text
   bei Platzmangel in die Hoehe statt in die Breite ausweicht (Merles
   ausdruecklicher Wunsch: "der txt muss im Div der selectionbox bleiben,
   notfalls müssen diese dafür in der höhe wachsen"). NICHT live verifiziert
   (dieselbe Sandbox-Grenze, kein echtes Handy-Quer simulierbar) - bitte auf
   deinem Handy gegenchecken, ob die beiden Kacheln jetzt sauber nebeneinander
   sitzen statt zu ueberlappen.
   KORREKTUR (Round 28, 57. Batch): Merle schickt ein grosses neues Punkte-
   Paket zu dieser Seite ("HANDY QUER EB SEITE"), das mehrere Werte hier
   direkt wieder aendert:
   1) "grid-template-columns: 1fr 1fr" soll WEG. Die grid-template-areas
      (2-oben/1-unten-Aufteilung) bleiben wie gewuenscht bestehen - ohne
      explizite Spaltenbreiten sizen die beiden oberen Spalten sich jetzt
      aber automatisch nach ihrem eigenen Inhalt (CSS-Grid-Standardverhalten
      bei reinen grid-template-areas ohne grid-template-columns). EHRLICHER
      HINWEIS: genau diese Content-basierte Spaltengroesse war die Ursache
      des Ueberlapp-Bugs, den die direkt oben dokumentierte 49.-Batch-
      Korrektur beheben sollte (deshalb war "1fr 1fr" damals ueberhaupt erst
      eingefuehrt worden) - "width:100%" + "min-width:0" + "overflow-wrap"
      auf den Kacheln bleiben als Sicherheitsnetz bestehen, aber falls
      Single-Box (laengerer Text) nach diesem Batch wieder spuerbar breiter
      wird als Probier-Box und beide sich wieder ueberlappen, bitte melden -
      dann waere "grid-template-columns:1fr 1fr" (gleich breite Spalten)
      trotz Merles Wunsch die sicherere Wahl.
   2) nth-child(2) ("Single-Box", live per DOM-Text bestaetigt - siehe
      Ueberschrift "Single-Box" in gbbBoxSelectionHeading) bekommt jetzt
      zusaetzlich eine eigene min-height von 120% (ueberschreibt die
      "unset"-Regel direkt oben wieder, da hier spaeter im Block und damit
      bei gleicher Spezifitaet gewinnend).
   3) nth-child(3) ("We-are-family-Box", unterste Kachel) wird von 50% auf
      85% Breite vergroessert.
   4) alle drei Kacheln bekommen zusaetzlich "align-items:end" (Live auf dem
      Desktop-Viewport war das bereits der native Ist-Zustand - hier zur
      Sicherheit explizit erzwungen, falls sich das durch Punkt 1 aendert). */
@media screen and (orientation: landscape) and (max-height: 500px) {
  body .gbbBoxSelectionContainer .gbbBoxSelectionItem:nth-child(1),
  body .gbbBoxSelectionContainer .gbbBoxSelectionItem:nth-child(2),
  body .gbbBoxSelectionContainer .gbbBoxSelectionItem:nth-child(3) {
    min-height: unset !important;
    align-items: end !important;
  }
  body .gbbBoxSelectionContainer {
    width: 100% !important;
    grid-template-areas: "pvbox1 pvbox2" "pvbox3 pvbox3" !important;
  }
  body .gbbBoxSelectionContainer .gbbBoxSelectionItem:nth-child(1) {
    grid-area: pvbox1 !important;
    min-width: 0 !important;
  }
  body .gbbBoxSelectionContainer .gbbBoxSelectionItem:nth-child(2) {
    grid-area: pvbox2 !important;
    min-width: 0 !important;
    /* Singlebox: min-height jetzt bewusst wieder gesetzt (120%), siehe
       Kommentar oben Punkt 2 - gewinnt gegen die "unset"-Regel oben im
       selben Block. */
    min-height: 120% !important;
  }
  body .gbbBoxSelectionContainer .gbbBoxSelectionItem:nth-child(1) .gbbBoxSelectionHeading,
  body .gbbBoxSelectionContainer .gbbBoxSelectionItem:nth-child(1) .gbbBoxSelectionSubtext,
  body .gbbBoxSelectionContainer .gbbBoxSelectionItem:nth-child(2) .gbbBoxSelectionHeading,
  body .gbbBoxSelectionContainer .gbbBoxSelectionItem:nth-child(2) .gbbBoxSelectionSubtext {
    overflow-wrap: break-word !important;
    word-break: normal !important;
    white-space: normal !important;
  }
  body .gbbBoxSelectionContainer .gbbBoxSelectionItem:nth-child(3) {
    grid-area: pvbox3 !important;
    width: 85% !important;
    min-width: 0 !important;
    justify-self: center !important;
  }
}

/* ---------------------------------------------------------------- 72.
   MOBILE LANDSCAPE: "LEEREN"-BUTTON KLEINER, INHALT AUSGEBLENDET
   Merle: "gbbFooterClearItemsButtonWrapper please make it ways smaller so,
   make its padding 3px 8px, oh and please hide gbbFooterClearItemsContent
   on mobile landscape". Die Hintergrundfarben-Regel fuer
   .gbbFooterClearItemsButtonWrapper (Abschnitt weiter oben) bleibt
   unveraendert, hier nur Padding ergaenzt. .gbbFooterClearItemsContent ist
   laut unserer DOM-Referenz (easy-bundles-sdk-reference.md) noch nicht an
   anderer Stelle in dieser Datei referenziert - Klassenname direkt aus
   Merles eigener Nachricht uebernommen, NICHT selbst live nachgeprueft
   (konnte den "Leeren"-Button-Zustand mit befuellter Box in dieser Session
   nicht herstellen) - falls der Klassenname nicht exakt stimmt, bitte den
   echten Namen per Inspector durchgeben. */
@media screen and (orientation: landscape) and (max-height: 500px) {
  body .gbbFooterClearItemsButtonWrapper {
    padding: 3px 8px !important;
  }
  body .gbbFooterClearItemsContent {
    display: none !important;
  }
}

/* ---------------------------------------------------------------- 73.
   MOBILE LANDSCAPE: .gbbFooterBundleTitle GROESSE + PADDING-BOTTOM
   URSPRUENGLICH: Merle "make the .gbbFooterBundleTitle smaller" -> Schaetzwert
   0.75em.
   KORREKTUR (Round 28, 57. Batch): Merle meldet jetzt das Gegenteil - Titel
   soll GROESSER sein (1.3em) und ihr eigener padding-bottom soll komplett weg
   (0). Live auf /products/box nachgemessen (Chrome verbunden, Desktop-
   Viewport, Media Query hier daher NICHT aktiv gewesen - Werte sind die
   Basis-/Nicht-Handy-Quer-Werte): font-size 25px, padding-bottom 10px (beide
   vermutlich aus der unscoped Grundregel ganz am Anfang der Datei, nicht aus
   dieser Media-Query-Regel). Hier wie gewuenscht ueberschrieben, NUR fuer
   echtes Handy-Querformat. */
@media screen and (orientation: landscape) and (max-height: 500px) {
  body .gbbFooterBundleTitle {
    font-size: 1.3em !important;
    padding-bottom: 0 !important;
  }
}

/* ---------------------------------------------------------------- 74.
   MOBILE LANDSCAPE: .gbbDiscountContainer PADDING-TOP
   URSPRUENGLICH: Merle ".gbbDiscountContainer loose the padding top" -> 0.
   KORREKTUR (Round 28, 57. Batch): Merle meldet jetzt, dass doch wieder ein
   kleiner Abstand gewuenscht ist (2% padding-top), vermutlich weil der
   Titel darueber (Abschnitt 73) jetzt groesser ist und sonst zu eng
   anliegt. */
@media screen and (orientation: landscape) and (max-height: 500px) {
  body .gbbDiscountContainer {
    padding-top: 2% !important;
  }
}

/* ---------------------------------------------------------------- 75.
   MOBILE LANDSCAPE: .gbbDiscountMessageContainer MARGIN 8PX
   Merle: ".gbbDiscountMessageContainer make margin 8px". Grundregel (ganz
   am Anfang der Datei) setzt margin-block:12px unscoped - hier fuer
   Querformat auf das gewuenschte margin:8px (alle vier Seiten) umgestellt. */
@media screen and (orientation: landscape) and (max-height: 500px) {
  body .gbbDiscountMessageContainer {
    margin: 8px !important;
  }
}

/* ---------------------------------------------------------------- 76.
   MOBILE LANDSCAPE: .gbbFooterTotalItemsInCart SCHRIFT HALBIERT
   Merle: "the font size of gbbFooterTotalItemsInCart needs to be half of
   the current size". Native/aktuelle Groesse auf Desktop 16px - 0.5em
   relativ gesetzt (halbiert die jeweils geerbte/native Groesse, robuster
   als ein fixer px-Wert, falls die native Groesse sich noch unterscheidet). */
@media screen and (orientation: landscape) and (max-height: 500px) {
  body .gbbFooterTotalItemsInCart {
    font-size: 0.5em !important;
  }
}

/* ---------------------------------------------------------------- 77.
   MOBILE LANDSCAPE: FOOTER-TEXT (ZWEI TEXTBLOECKE) VERKLEINERT
   Merle: "in footer the p text in ...section_rPB8Wx and the
   ...section_KtXkqU is way to big (except 'Wir liefern mit dpd'). please
   make the p half as big. and the headline above 60% as big, the icons
   are fine". Live bestaetigt (DOM-Pruefung): die <p>/<h2>-Elemente in
   diesen beiden Footer-Sections tragen selbst KEINE eigene Klasse (nur ihre
   jeweiligen Eltern-Textbloecke, mit pro Block unterschiedlichen, auto-
   generierten Hash-Klassen) - deshalb hier ueber die ID der beiden Sections
   gescopt (stabiler als die vielen einzelnen Hash-Klassen). Die Ausnahme
   "Wir liefern mit dpd foods." sitzt nachweislich im eigenen Textblock
   ".text-block--AbEFnbWdlb0lBdXJPZ__text_nkgUM3" (einziger Absatz in
   section_KtXkqU mit DIESER Klasse) - wird direkt danach wieder auf 100%
   zurueckgesetzt, bleibt dadurch unveraendert. font-size:50%/60% ist relativ
   zur jeweils GEERBTEN (Eltern-)Schriftgroesse, nicht exakt "halb/60% der
   bisherigen EIGENEN Groesse" (p erbt nativ bereits 0.85em seines Elternteils,
   h2 eine komplexere, zweistufige Kette) - eine mathematisch exakte Halbierung
   waere nur mit einem auf die native Kette zugeschnittenen em-Wert moeglich.
   Ergebnis sollte sehr nah an "halb/60%" liegen, aber bitte live
   gegenchecken, ob die Groesse exakt passt oder noch angepasst werden soll.
   Nur auf Mobil-Querformat gescopt, wie von Merle unter "mobile landscape"
   eingeordnet. */
@media screen and (orientation: landscape) and (max-height: 500px) {
  #shopify-section-sections--31616257786186__section_rPB8Wx p,
  #shopify-section-sections--31616257786186__section_KtXkqU p {
    font-size: 50% !important;
  }
  #shopify-section-sections--31616257786186__section_rPB8Wx h2,
  #shopify-section-sections--31616257786186__section_KtXkqU h2 {
    font-size: 60% !important;
  }
  /* Ausnahme: "Wir liefern mit dpd foods." bleibt unveraendert */
  #shopify-section-sections--31616257786186__section_KtXkqU
    .text-block--AbEFnbWdlb0lBdXJPZ__text_nkgUM3 p {
    font-size: 100% !important;
  }
}

/* ---------------------------------------------------------------- 78.
   [ENTFERNT, Round 28, 48. Batch] FOOTER TAP-ZUM-AUFKLAPPEN: GENERISCHER
   FALLBACK-MECHANISMUS - JETZT UEBERFLUESSIG.
   Hintergrund: Merle meldete "der footer text laesst sich durch tappen auf
   das jeweilige p nicht aufklappen". Die damalige Annahme war, dass gar
   kein Tap-Mechanismus existiert, daher wurde hier (Abschnitt 78) + in
   mobile-fixes.js (vormals Block 23) ein neuer, generischer
   scrollHeight/clientHeight-basierter Fallback gebaut.
   Live-Diagnose in dieser Runde (direkte DOM/CSS-Inspektion in Chrome) ergab
   aber: es gab bereits einen funktionierenden, aelteren Mechanismus (Klasse
   "pv-expanded", in mobile-fixes.js Block 3, siehe Abschnitt 9 oben) - der
   Klick hat dort immer schon korrekt die Klasse gesetzt, nur die CSS-Regel
   zum Aufheben des Clamps hatte eine zu niedrige Spezifitaet gegen die
   ID-gescopte native Clamp-Regel in Abschnitt 9 und konnte strukturell nie
   gewinnen (siehe Korrektur-Kommentar dort). Nach Behebung DIESES
   eigentlichen Bugs ist der hier generische Fallback-Mechanismus redundant
   und wurde entfernt (ebenso sein JS-Gegenstueck, vormals Block 23, in
   mobile-fixes.js) um doppelte/kollidierende Klick-Handler auf denselben
   Footer-Elementen zu vermeiden. */

/* ---------------------------------------------------------------- 79.
   MOBILE PORTRAIT (+ DESKTOP PORTRAIT): QUICK-VIEW-POPUP PRODUCT-
   INFORMATION-GRID/GROUP-BLOCK OHNE PADDING/GAP
   Merle: "in the product popup on mobile portrait and on desktop portrait
   can you move up the ProductInformation-template--...__main? its fine on
   desktop landscape but on desktop portrait there is the same problem. i
   believe body .quick-view-modal__content .product-information__grid, body
   .quick-view-modal__content .group-block the padding block needs to be
   set to 0px and the gap has to be deleted". Merles eigene Selektoren 1:1
   uebernommen. WICHTIG: bewusst ueber orientation:portrait gescopt (nicht
   ueber eine Breiten-Grenze wie die bestehende 749px-Regel oben) - genau das
   deckt sowohl "Mobil Hochkant" als auch "Desktop Hochkant" (ein schmales,
   hohes Fenster/Display) gleichzeitig ab, waehrend "Desktop Querformat"
   (laut Merle bereits in Ordnung) unangetastet bleibt. Steht bewusst NACH
   der bestehenden 749px-Regel (Abschnitt 33 oben) im File, gewinnt dadurch
   bei gleicher Spezifitaet innerhalb des ueberlappenden Bereichs
   (Hochformat UND <749px). */
@media screen and (orientation: portrait) {
  body .quick-view-modal__content .product-information__grid,
  body .quick-view-modal__content .group-block {
    padding-block: 0 !important;
    gap: 0 !important;
  }
}

/* ---------------------------------------------------------------- 80.
   EB-CARTDRAWER-ROTATIONS-BUG: ROOT CAUSE BESTAETIGT (NICHT PER CSS
   VOLLSTAENDIG LOESBAR)
   Merle meldet: beim Drehen des Handys von Hochkant auf Querformat
   erscheint der EB-Cart-Drawer, aber "die falsche"/"aufgeblaehte" Variante
   des Footers (Screenshot 5), obwohl der Footer laut ihrem eigenen DevTools-
   Test bereits im strukturell richtigen Eltern-Element (.gbbCategoriesContainer
   statt ausserhalb von .gbbBundleContent) sitzt.
   ROOT CAUSE (live bestaetigt, diese Session): Easy Bundles' eigene Breiten-
   Weiche (side-footer-bundle.min.js, Funktion isMobileView(), live aus dem
   Code gelesen: "window.innerWidth<=600") entscheidet NICHT nach Geraetetyp,
   sondern rein nach Pixelbreite - jedes reale Handy im Querformat (typisch
   667-926px) liegt WEIT ueber dieser 600px-Grenze und wird von EB selbst
   intern als "Desktop" behandelt, obwohl es ein kleines Handy-Display ist.
   Das deckt sich exakt mit einem bereits frueher in dieser Datei dokumentierten,
   unabhaengig gefundenen Wert (Abschnitt bei .gbbBundleFooter/max-width:639px:
   "EBs eigene interne JS-Weiche wechselt bei ca. 600-640px").
   Das bedeutet: das "richtige Eltern-Element" ist korrekt (unser eigener
   Parent-Fix aus Batch 41 greift weiterhin), aber der INHALT, den EB in
   dieses Element hineinbaut, ist bereits beim Bauen (buildBundleFooter() in
   side-footer-bundle.min.js) als Desktop-Variante entschieden - das ist
   keine reine CSS-Frage (unterschiedliche Kindelemente, nicht nur
   unterschiedliches Styling derselben Elemente), laesst sich also NICHT
   durch einen einzelnen CSS-Selektor vollstaendig "zurueckdrehen".
   PRAKTISCHE ABHILFE (umgesetzt): alle kompaktierenden Regeln dieses Batches
   fuer die Footer-Bestandteile (Abschnitte 71-77 oben: Box-Auswahl-Kacheln,
   "Leeren"-Button, Bundle-Titel, Rabatt-Container/-Nachricht,
   Gerichte-Anzahl) sind bewusst ueber "orientation:landscape and
   max-height:500px" gescopt (Geraete-Erkennung ueber Displayform, NICHT
   ueber Pixelbreite) - das erfasst JEDES echte Handy im Querformat
   UNABHAENGIG von EBs eigener 600px-Grenze und sollte den "aufgeblaehten"
   Eindruck aus Screenshot 5 dadurch bereits deutlich reduzieren, auch wenn
   die zugrunde liegende EB-Entscheidung selbst unveraendert bleibt.
   BITTE GEGENCHECKEN: nach Einspielen dieser Datei auf dem echten Handy
   drehen und schauen, ob der Footer jetzt kompakt genug wirkt. Falls nicht,
   brauche ich einen frischen Screenshot/DevTools-Export GENAU in diesem
   gedrehten Zustand, um die noch fehlenden Kindelemente gezielt
   nachzuziehen. */

/* ---------------------------------------------------------------- 81.
   MOBILE LANDSCAPE (DIREKTER SEITENAUFRUF IM QUERFORMAT): INHALT LAEUFT
   UEBER DAS CART-DIV HINAUS
   Merle: "wenn man die eb seite gleich quer laedt, der inhalt [laeuft]
   ueber das div, bitte alle inhalte nur so breit wie das cart div. die
   selectionboxitems muessen dann sehr schmal aber das macht nichts".
   Root Cause (Code-Analyse, siehe auch Abschnitt 80 oben zur "breakpoint
   gap"): die bestehende "echtes Handy quer"-Spaltenregel fuer
   ".gbbCategoriesBodyContainer" (oben, Punkt b4/"NEU UMGESETZT..." im
   Abschnitt "EASY BUNDLES: 3-SPALTEN-BREITE...", min-width:640px-Bereich)
   setzt zwar die Grid-SPALTEN (58fr/42fr) korrekt, haertet aber die
   KINDELEMENTE nicht gegen intrinsische Mindestbreiten ab - anders als die
   "schmaler Desktop"-Regel (Punkt b2) weiter oben, die genau dafuer bereits
   ein "min-width:0" auf ".gbbProductItem" UND seine Kinder gesetzt hat. Ohne
   dieses Sicherheitsnetz koennen Produktkarten/Box-Auswahl-Kacheln ihre
   Grid-Zelle sprengen (Inhalt breiter als Zelle), was in Summe den ganzen
   Cart-Div-Bereich nach rechts aus dem Viewport schiebt. Fix: dieselbe
   "min-width:0"-Absicherung jetzt auch fuer die Handy-Quer-Spaltenregel
   ergaenzt, zusaetzlich auf ".gbbBoxSelectionContainer"/".gbbBoxSelectionItem"
   erweitert (Merles ausdruecklicher Hinweis: die Box-Auswahl-Kacheln duerfen
   dafuer sehr schmal werden, das ist ausdruecklich okay).
   NICHT live verifizierbar in dieser Sandbox (siehe Abschnitt 80: kein
   echtes Querformat/keine echte reduzierte Breite simulierbar, "resize_window"
   aendert window.innerWidth nachweislich nicht) - bitte auf deinem Handy
   gegenchecken, ob der direkte Quer-Seitenaufruf jetzt ohne Ueberlauf laedt. */
@media screen and (orientation: landscape) and (max-height: 500px) and (min-width: 640px) {
  body .gbbProductItem,
  body .gbbProductItem * {
    min-width: 0 !important;
  }
  body .gbbBoxSelectionContainer {
    min-width: 0 !important;
    max-width: 100% !important;
  }
  body .gbbBoxSelectionItem {
    min-width: 0 !important;
  }
  body .gbbCategoriesBodyContainer,
  body .gbbProductsContainer {
    min-width: 0 !important;
    max-width: 100% !important;
  }
}

/* ---------------------------------------------------------------- 82.
   MOBILE LANDSCAPE: PRODUKT-SLOTS (AUSGEWAEHLTE GERICHTE IM WAGEN) KLEINER,
   BLEIBEN ABER QUADRATISCH
   Merle (Folgeanfrage im selben Feedback-Batch): "die slots fuer die
   produkte verkleinern, die sollen aber quadratisch bleiben". Die
   Quadrat-Erzwingung selbst (siehe Abschnitt 37 oben, ".gbbProductSlotContainer"
   mit aspect-ratio:1/1 + align-self:start + height:auto) bleibt unveraendert
   bestehen - sie berechnet die Hoehe immer automatisch aus der Breite ihrer
   Spalte, daher reicht es, den GESAMTEN Container schmaler zu machen: die 6
   Spalten (repeat(6,1fr)) teilen die neue, kleinere Breite weiterhin
   gleichmaessig auf, wodurch jedes einzelne Slot-Quadrat automatisch kleiner
   wird, ohne seine quadratische Form zu verlieren. SCHAETZWERT (70%), bitte
   live gegenchecken, ob das die gewuenschte Groesse trifft oder noch mehr/
   weniger werden soll.
   KORREKTUR (Round 28, 57. Batch): Merle moechte jetzt im Rahmen des
   "HANDY QUER EB SEITE"-Pakets genau das Gegenteil - die Produkt-Slots
   sollen "in 6 columns ueber die ganze Breite des gbbFooterBundleItemsContainer"
   aufgeteilt werden ("ich glaube: body .gbbProductSlotsContainer margin
   inline und max-width weg!"). Die 6-Spalten-Aufteilung selbst kommt
   bereits aus Abschnitt 32/37 oben (repeat(6,1fr), dort unveraendert) - hier
   daher die seit diesem Batch wieder unerwuenschte 70%-Einschraenkung +
   Zentrierung entfernt, stattdessen wieder auf volle Breite (100%,
   kein auto-margin) gesetzt, damit der Container wieder die gesamte Breite
   seines Eltern-Elements (.gbbFooterBundleItemsContainer) ausfuellt. */
@media screen and (orientation: landscape) and (max-height: 500px) {
  body .gbbProductSlotsContainer {
    max-width: 100% !important;
    margin-inline: 0 !important;
  }
}

/* ---------------------------------------------------------------- 83.
   MOBILE LANDSCAPE: "PROGRESS MESSAGE" (SCHRITT-HINWEISTEXT) WEITER
   VERKLEINERT
   Merle (Folgeanfrage im selben Feedback-Batch): "die groesse der progress
   message verkleinern". Grundregel (Abschnitt "Punkt 11" oben,
   ".gbbDiscountMessage") setzt bereits unscoped font-size:0.85em - hier
   zusaetzlich nur fuer echtes Handy-Querformat nochmal verkleinert.
   SCHAETZWERT (0.65em), bitte live gegenchecken. */
@media screen and (orientation: landscape) and (max-height: 500px) {
  body .gbbDiscountMessage {
    font-size: 0.65em !important;
  }
}

/* ---------------------------------------------------------------- 84.
   B2B-SEITE: "FUENF KOMPETENZEN - EIN PARTNER"-SEKTION, FUENF SPALTEN
   GLEICH BREIT
   Merle: in der Section section--page-width
   color-custom-template--32697460982090__section_43eWbb (neue B2B-Seite)
   sollen die fuenf Spalten (Gastronomie & Foodservice / LEH /
   Produktentwicklung / Kooperationen bei Ausschreibungen / Lohn- &
   Auftragsproduktion) alle gleich breit sein.
   Root Cause (live in Chrome gemessen): der umschliessende Flex-Container
   (".group-block-content.layout-panel-flex--row") setzt auf jedem Kind
   bereits korrekt "flex-grow:1; flex-basis:0%" - das wuerde fuer sich genommen
   bereits gleiche Breiten erzeugen. Das browser-eigene Default
   "min-width:auto" auf Flex-Items bedeutet aber, dass jedes Kind trotzdem
   NICHT unter seine eigene intrinsische Mindestbreite (den laengsten
   zusammenhaengenden Textbaustein, z. B. "Lebensmitteleinzelhandel")
   schrumpfen darf - dadurch blieben Spalten mit laengeren Woertern breiter
   als die anderen, obwohl alle dieselbe Flex-Formel haben (dieselbe
   Fehlerklasse wie bereits mehrfach bei Easy-Bundles-Grids in dieser Datei
   gefunden, siehe z. B. Abschnitt 81).
   Fix: "min-width:0" auf jede der fuenf Spalten - damit kann die
   Flex-Engine die Breite jetzt tatsaechlich rein nach der flex-grow/
   flex-basis-Formel gleichmaessig aufteilen, unabhaengig vom Textinhalt.
   LIVE VERIFIZIERT (diese Session, direkt am echten DOM gemessen): vorher
   159.7/210.5/164.9/205.6/199.1px (deutlich ungleich) - nach dem Fix
   177.2/177.2/177.2/177.2/177.2px (exakt gleich). Gilt nur ab 750px
   (Desktop-Spaltenlayout); unter 750px stapelt Horizon diese Sektion
   nativ ueber "mobile-column" ohnehin einspaltig, dort nicht noetig. */
@media screen and (min-width: 750px) {
  body .section--page-width.color-custom-template--32697460982090__section_43eWbb
    .group-block-content.layout-panel-flex--row
    > .group-block {
    min-width: 0 !important;
  }
}

/* ---------------------------------------------------------------- 85.
   B2B-SEITE: KONTAKT-/GESCHAEFTSINFO-SEKTION - SPALTEN AN INHALT ANGEPASST
   (REVIDIERT: Merle wollte die zuvor hier erzwungene gleichmaessige
   2/7+2/7+2/7+1/7-Aufteilung wieder zurueckgenommen haben, zugunsten von
   an den jeweiligen Inhalt angepassten Spaltenbreiten.)
   Merle (neuer Wunsch, ersetzt den vorherigen 2/7+2/7+2/7+1/7-Fix): in der
   Section section--page-width
   color-custom-template--32697460982090__section_hV7Vjm sollen die vier
   Spalten (Ihr b2b-Kontakt / Weitere Kontaktmoeglichkeiten /
   Geschaeftsinformationen / Logo) sich wieder an ihrem jeweiligen Inhalt
   orientieren statt auf ein festes Verhaeltnis gezwungen zu werden. Zwei
   explizite Vorgaben dabei: (1) "stefan.pruefer@planet-v.com" darf dabei
   nie umbrechen; (2) die Adresse/USt-ID-Geschaeftsinfos sollen wieder wie
   urspruenglich in zwei Spalten nebeneinander stehen (nicht mehr
   untereinander gestapelt, wie es der vorherige Fix bewirkt hatte).
   Fix, Teil 1 (Spaltenbreite an Inhalt anpassen): "--size-style-width" fuer
   alle vier Spalten auf das Schluesselwort "fit-content" gesetzt (ein
   gueltiger CSS-"flex-basis"-Wert) statt fixer Prozentwerte - dadurch
   bestimmt wieder der tatsaechliche Inhalt jeder Spalte deren Breite,
   anstatt eines erzwungenen Verhaeltnisses.
   Fix, Teil 2 (E-Mail-Schutz ohne eigene Regel): das vorher hier gesetzte
   "min-width:0" auf den Spalten wurde ENTFERNT (nicht durch etwas anderes
   ersetzt) - dadurch gilt wieder der Browser-Standardwert "min-width:auto"
   auf jeder Spalte. Genau dieser Standardwert ist es, der verhindert, dass
   eine Spalte unter die eigene intrinsische Mindestbreite schrumpft - bei
   der Kontakt-Spalte ist das der zusammenhaengende Text
   "stefan.pruefer@planet-v.com" (ein einzelnes langes Token ohne
   Leerzeichen, kann nicht umbrechen) - die Spalte kann also nicht enger
   werden, als die E-Mail-Adresse selbst breit ist, ganz ohne zusaetzliche
   Regel dafuer.
   Fix, Teil 3 (verschachtelte Adresse/USt-ID-Zeile zurueckgesetzt): die im
   letzten Batch hinzugefuegten Regeln fuer die innere, verschachtelte
   Zweispalten-Zeile in "Geschaeftsinformationen" ("flex-wrap:wrap" +
   "flex-basis:100%", die Adresse und USt-ID/Amtsgericht-Block UNTEREINANDER
   gestapelt hatten) wurden ersatzlos entfernt - diese Zeile verhaelt sich
   dadurch wieder wie urspruenglich: zwei Felder nebeneinander
   ("width:fit-content", "flex-grow:0").
   EHRLICHER HINWEIS (nicht live verifizierbar diese Runde - die
   Chrome-Erweiterung war in dieser Session nicht verbunden): durch Fix 3
   lebt der in der letzten Runde als eigenstaendiger, vorbestehender Bug
   gefundene Zeilenumbruch bei "Gewerbestraße 1-5" potenziell wieder auf -
   dieser Umbruch bestand bereits VOR allen Breiten-Fixes dieser und der
   letzten Runde und haengt an der inneren Zeile selbst, nicht an der
   Aussenspaltenbreite. Ob die jetzt inhaltsbasierte (statt feste) Breite
   der Aussenspalte zufaellig genug zusaetzlichen Platz schafft, um den
   Umbruch zu vermeiden, konnte diese Runde nicht am echten DOM gemessen
   werden - bitte nach dem Einfuegen einmal gegenchecken, ob
   "Gewerbestraße 1-5" einzeilig bleibt; falls nicht, sag Bescheid, dann
   bringe ich den vorherigen gezielten Fix dafuer (flex-wrap/flex-basis nur
   auf die innere Zeile, ohne die Aussenspalten wieder auf feste Prozente
   zu zwingen) in einer eigenen, schlankeren Variante zurueck.
   Gilt weiterhin nur ab 750px (Desktop-Zeilenlayout); unter 750px stapelt
   Horizon diese Sektion nativ ueber "mobile-column" ohnehin einspaltig mit
   eigener "--size-style-width-mobile:100%". */
@media screen and (min-width: 750px) {
  body .section--page-width.color-custom-template--32697460982090__section_hV7Vjm
    > .custom-section-content
    > .layout-panel-flex--row.section-content-wrapper
    > .group-block:nth-child(1),
  body .section--page-width.color-custom-template--32697460982090__section_hV7Vjm
    > .custom-section-content
    > .layout-panel-flex--row.section-content-wrapper
    > .group-block:nth-child(2),
  body .section--page-width.color-custom-template--32697460982090__section_hV7Vjm
    > .custom-section-content
    > .layout-panel-flex--row.section-content-wrapper
    > .group-block:nth-child(3),
  body .section--page-width.color-custom-template--32697460982090__section_hV7Vjm
    > .custom-section-content
    > .layout-panel-flex--row.section-content-wrapper
    > .group-block:nth-child(4) {
    --size-style-width: fit-content !important;
  }
}

/* ---------------------------------------------------------------- 86.
   B2B- UND UEBER-UNS-SEITE: FUENF SITEWEITE SECTIONS AUSBLENDEN
   (nur Shop-relevante Infos, auf diesen beiden Seiten nicht noetig)
   Merle: auf "b2b" und "Über uns" sollen folgende fuenf Sections nicht
   erscheinen, weil deren Inhalte nur fuer die Shop-Seiten relevant sind:
   shopify-section-sections--31616257786186__section_rPB8Wx,
   shopify-section-sections--31616257786186__section_KtXkqU,
   shopify-section-sections--31616257786186__divider_bFiz9d,
   shopify-section-sections--31616257786186__footer_m9NzUG,
   shopify-section-sections--31616257786186__section_x9fTHp.
   WICHTIGER HINWEIS: alle fuenf IDs gehoeren zum Praefix
   "sections--31616257786186__" (ohne "template--") - das sind siteweite
   "Section Group"-Sections (dieselbe Gruppe wie der globale Footer), die
   standardmaessig auf JEDER Seite erscheinen. Es gibt dafuer keinen
   eingebauten Theme-Editor-Schalter "nur auf dieser einen Seite
   ausblenden" - daher der folgende Mechanismus ueber eine JS-gesetzte
   body-Klasse (siehe mobile-fixes.js, Block 25) kombiniert mit reinen
   CSS-"display:none"-Regeln, die nur greifen, wenn diese Klasse gesetzt
   ist. ACHTUNG, zur Kontrolle bitte gegenchecken: "footer_m9NzUG" ist laut
   Projekt-Referenzdokumentation die KOMPLETTE Site-Footer-Section
   (Newsletter-Anmeldung, Planet-V-Logo, Social-Icons,
   Zahlungsarten-Badges, Copyright-Zeile) - mit dieser Regel verschwindet
   also der gesamte Footer auf "b2b" und "Über uns", nicht nur ein
   Teilbereich davon. Falls das nicht beabsichtigt war, bitte Bescheid
   geben, dann nehme ich "footer_m9NzUG" aus dieser Liste wieder heraus.
   Technisch rein CSS-Loesung (Projekt-Konvention): die eigentliche
   Ausblend-Regel steht hier als CSS, nur die Seiten-Erkennung selbst (die
   CSS nicht leisten kann, da es keinen Pfad-Selektor gibt) passiert
   minimal in JS. NICHT LIVE VERIFIZIERT diese Runde (Chrome-Erweiterung
   war nicht verbunden) - bitte nach dem Einfuegen auf beiden Seiten
   gegenchecken, dass die fuenf Sections dort verschwunden sind und auf
   allen anderen Seiten (Shop, Collections, Startseite etc.) weiterhin wie
   gewohnt erscheinen. */
body.pv-hide-shop-global-sections #shopify-section-sections--31616257786186__section_rPB8Wx,
body.pv-hide-shop-global-sections #shopify-section-sections--31616257786186__section_KtXkqU,
body.pv-hide-shop-global-sections #shopify-section-sections--31616257786186__divider_bFiz9d,
body.pv-hide-shop-global-sections #shopify-section-sections--31616257786186__footer_m9NzUG,
body.pv-hide-shop-global-sections #shopify-section-sections--31616257786186__section_x9fTHp {
  display: none !important;
}

/* ---------------------------------------------------------------- 87.
   KLEINE BILDSCHIRME: EIN BESTIMMTES IMAGE-BLOCK-ELEMENT AUSBLENDEN
   Merle: auf kleinen Bildschirmen (schmaler Desktop, Handy hoch und Handy
   quer) soll das Bild mit der Klasse
   "image-block--ANnNDVGpJbXl2TmpMa__image_hEwWMB" nicht erscheinen.
   Umsetzung: "klein" = alles außer echtem breiten Desktop - dieselbe
   Kombination aus "schmaler Desktop + Handy hoch" (max-width:1199px) UND
   "echtes Handy quer" (orientation:landscape + max-height:500px, robust
   auch bei Breiten >1199px) wie an mehreren anderen Stellen in dieser Datei
   verwendet. NICHT LIVE VERIFIZIERT (Chrome-Erweiterung diese Runde nicht
   verbunden) - bitte gegenchecken, auf welcher Seite dieses Bild steht und
   ob es auf allen drei genannten kleinen Bildschirmformen jetzt
   verschwindet, auf echtem breiten Desktop aber weiterhin erscheint. */
@media screen and (max-width: 1199px), screen and (orientation: landscape) and (max-height: 500px) {
  body .image-block.image-block--ANnNDVGpJbXl2TmpMa__image_hEwWMB {
    display: none !important;
  }
}

/* ---------------------------------------------------------------- 88.
   B2B-SEITE: "IHR B2B-KONTAKT" DARF NICHT UMBRECHEN
   Merle: die Überschrift "Ihr b2b-Kontakt" (Spalte 1 der Kontakt-/
   Geschäftsinfo-Sektion, siehe Abschnitt 85) soll nicht umbrechen.
   Hintergrund: seit der Umstellung auf inhaltsbasierte Spaltenbreiten
   (Abschnitt 85, 51. Batch) kann die Spalte durch Flex-Shrink enger werden
   als die GESAMTE Überschrift breit ist - der Browser-Standard
   "min-width:auto" schützt zwar vor dem Schrumpfen unter die Breite des
   LÄNGSTEN WORTS, "Ihr b2b-Kontakt" enthält aber einen Bindestrich
   ("b2b-Kontakt") und mehrere Leerzeichen, an denen ganz normal umgebrochen
   werden kann, auch ohne unter die reine Wortbreite zu schrumpfen.
   Fix: "white-space:nowrap" direkt auf die Überschrift-Textzeile in Spalte 1
   (per "[role=heading]"-Attribut angesprochen, demselben Muster wie bereits
   an anderer Stelle in diesem Projekt für Produkttitel verwendet, siehe
   claude/section-ids-referenz.md "Homepage – Produkt-Karusselle"), zusätzlich
   mit den gängigen Überschrift-Tags (h1-h6) als Fallback, falls es sich doch
   um ein natives Heading-Element statt eines ARIA-Rollen-Absatzes handelt.
   NICHT LIVE VERIFIZIERT (Chrome-Erweiterung diese Runde nicht verbunden) -
   bitte gegenchecken, ob die Überschrift damit zuverlässig einzeilig
   bleibt. */
@media screen and (min-width: 750px) {
  body .section--page-width.color-custom-template--32697460982090__section_hV7Vjm
    > .custom-section-content
    > .layout-panel-flex--row.section-content-wrapper
    > .group-block:nth-child(1) [role="heading"],
  body .section--page-width.color-custom-template--32697460982090__section_hV7Vjm
    > .custom-section-content
    > .layout-panel-flex--row.section-content-wrapper
    > .group-block:nth-child(1) h1,
  body .section--page-width.color-custom-template--32697460982090__section_hV7Vjm
    > .custom-section-content
    > .layout-panel-flex--row.section-content-wrapper
    > .group-block:nth-child(1) h2,
  body .section--page-width.color-custom-template--32697460982090__section_hV7Vjm
    > .custom-section-content
    > .layout-panel-flex--row.section-content-wrapper
    > .group-block:nth-child(1) h3,
  body .section--page-width.color-custom-template--32697460982090__section_hV7Vjm
    > .custom-section-content
    > .layout-panel-flex--row.section-content-wrapper
    > .group-block:nth-child(1) h4,
  body .section--page-width.color-custom-template--32697460982090__section_hV7Vjm
    > .custom-section-content
    > .layout-panel-flex--row.section-content-wrapper
    > .group-block:nth-child(1) h5,
  body .section--page-width.color-custom-template--32697460982090__section_hV7Vjm
    > .custom-section-content
    > .layout-panel-flex--row.section-content-wrapper
    > .group-block:nth-child(1) h6 {
    white-space: nowrap !important;
  }
}

/* ---------------------------------------------------------------- 89.
   OFFICE-BOX-SEITE (body[data-offer-id="SDK-023099"]): WEITERE EINZELPUNKTE
   (Round 28, 51. Batch). Scope wie etabliert (Abschnitt 71) ueber die
   Offer-ID, nicht ueber die URL.

   1) .gbbDiscountMessage fett.
   2) .gbbStepHeaderContainer komplett ausgeblendet.
   3) .gbbNavigationItem, dessen .gbbNavigationTitle den Text "Lieferung"
      enthaelt, komplett ausgeblendet. CSS kann Text-Inhalt nicht direkt
      prüfen - daher setzt mobile-fixes.js (neuer Block 26) die Klasse
      "pv-hide-lieferung-nav-item" auf das jeweilige Navigations-Item, diese
      Regel blendet es dann rein per CSS aus.
      KORREKTUR (Round 28, 55. Batch): Merle meldet, dass es tatsaechlich
      MEHRERE "Lieferung"-Eintraege gibt (jeder zweite Eintrag), und dass
      es zusaetzlich zu .gbbNavigationItem noch EIGENE, separate Element(e)
      fuer die Verbindungslinie gibt (.gbbStepsProgressBarTrack/
      .gbbStepsProgressBarContainer) - die von unserer Ausblend-Regel
      bisher NICHT erfasst wurden, da sie nicht innerhalb von
      .gbbNavigationItem verschachtelt sind. Die Regel unten wurde daher
      von ".gbbNavigationItem.pv-hide-lieferung-nav-item" auf die reine
      Klasse ".pv-hide-lieferung-nav-item" verallgemeinert (ohne die
      Element-Art vorauszusetzen), damit mobile-fixes.js (erweiterter
      Block 26) dieselbe Klasse jetzt auch auf die dazugehoerigen
      Track-Segmente setzen kann, falls die 1:1-Zuordnung (gleiche
      Geschwister-Reihenfolge wie bei den Navigations-Items) zutrifft. */
   4) .gbbFooterBundleSubtext darf ueber sein eigenes Div hinauslaufen, aber
      nicht ueber den Cart-Drawer selbst hinaus: "overflow:visible" +
      "white-space:normal" direkt auf dem Subtext-Element UND seinem
      unmittelbaren Eltern-Container (damit das Clipping nicht einfach eine
      Ebene hoeher erneut zuschlaegt), waehrend der umschliessende Cart-
      Drawer (".gbbDrawer.gbbCartDrawer") an keiner Stelle dieser Datei ein
      eigenes "overflow:hidden" verliert - er bleibt also weiterhin die
      aeusserste Grenze.
   NICHT LIVE VERIFIZIERT (Chrome-Erweiterung diese Runde nicht verbunden) -
   besonders Punkt 4 ist eine Annaeherung ohne Kenntnis der exakten
   Container-Verschachtelung; bitte alle vier Punkte auf der Office-Box-
   Seite gegenchecken. */
body[data-offer-id="SDK-023099"] .gbbDiscountMessage {
  font-weight: bold !important;
}
body[data-offer-id="SDK-023099"] .gbbStepHeaderContainer {
  display: none !important;
}
body[data-offer-id="SDK-023099"] .pv-hide-lieferung-nav-item {
  display: none !important;
}
body[data-offer-id="SDK-023099"] .gbbFooterBundleSubtext,
body[data-offer-id="SDK-023099"] .gbbFooterBundleSubtext > * {
  overflow: visible !important;
  white-space: normal !important;
  text-overflow: clip !important;
}

/* NEU (Round 29, 90. Batch): Merle "Office-Box, Handy hoch: gbbDiscountMessage
   in BEIDEN Zustaenden (ein- und ausgeklappt) wieder einblenden, dafuer
   gbbDiscountStepsProgressBarStepSubtitleWrapper ausblenden - nur auf der
   Office-Box-Seite". Die globale Ausblend-Regel fuer .gbbDiscountMessage auf
   Handy hoch (Abschnitt "Punkt 11", max-width:749px and orientation:portrait)
   bleibt fuer alle anderen Boxen unveraendert bestehen - hier nur fuer die
   Office-Box (per body[data-offer-id="SDK-023099"], hoehere Spezifitaet als
   die globale Regel) wieder aufgehoben. Keine Unterscheidung zwischen
   ein-/ausgeklapptem Footer-Zustand noetig (Merles ausdruecklicher
   Vereinfachungswunsch) - gilt daher ohne Ruecksicht auf diesen Zustand. */
@media screen and (max-width: 749px) and (orientation: portrait) {
  body[data-offer-id="SDK-023099"] .gbbDiscountMessage {
    display: block !important;
  }
  body[data-offer-id="SDK-023099"] .gbbDiscountStepsProgressBarStepSubtitleWrapper {
    display: none !important;
  }
}

/* ---------------------------------------------------------------- 90.
   SHOP-STARTSEITE: "VERSANDKOSTENFREI" IN KAPITAELCHEN (ROUND 28,
   54. BATCH). Gehoert zum JS-Mechanismus in mobile-fixes.js ("ROUND 28,
   38. BATCH", jetzt in dieser Runde ueberarbeitet), der jeden Textknoten,
   dessen Inhalt exakt "versandkostenfrei" ist, in einen eigenen <span>
   (Klasse "pv-versand-split-text") einwickelt. Merle moechte diesen Text
   JETZT AUF ALLEN FORMATEN (Mobil wie Desktop, kein Media-Query noetig) in
   Kapitaelchen (Small Caps) dargestellt haben - diese Regel gilt daher
   unconditional.
   "font-variant: small-caps" ist die Kurzform-Eigenschaft (breitere
   Browser-Unterstuetzung als nur "font-variant-caps"); macht aus
   Kleinbuchstaben kleine Grossbuchstaben, bereits vorhandene
   Grossbuchstaben (hier das "V") bleiben in normaler Grossbuchstaben-
   Groesse - das ist die ueblich erwartete Wirkung von "Kapitaelchen".
   KORREKTUR (Round 28, 65. Batch): Merle moechte diesen Text jetzt wieder
   ganz normal klein geschrieben (keine Kapitaelchen) - Entscheidung aus
   Batch 54 damit bewusst rueckgaengig gemacht. Der Zeilenumbruch-Schutz
   selbst (Soft-Hyphen-Wrapping in mobile-fixes.js) bleibt unveraendert
   bestehen, nur die optische Kapitaelchen-Darstellung entfaellt. */
body .pv-versand-split-text {
  font-variant: normal !important;
}

/* ---------------------------------------------------------------- 91.
   B2B-SEITE: LOGO-SPALTE (4. Spalte "Logo" in section_hV7Vjm, siehe
   Abschnitt 85) AUF KLEINEN BILDSCHIRMEN ZENTRIERT UND AUF HALBE GROESSE
   VERKLEINERT (ROUND 28, 54. BATCH).
   Scope "kleine Bildschirme" wie im Projekt etabliert (siehe z.B.
   Abschnitt 87): max-width:749px (Handy/schmaler Desktop hochkant) ODER
   Querformat mit geringer Fensterhoehe (Handy quer) - NICHT
   breiten-abhaengig von der row/column-Umschaltung dieser Section selbst,
   daher bewusst ohne das sonst in Abschnitt 85 verwendete
   ".layout-panel-flex--row"-Klassen-Segment im Selektor (das gilt nur ab
   750px) - hier wird ueber ".section-content-wrapper" gegriffen, das
   sowohl in der Row- als auch in der Column/"mobile-column"-Variante
   vorhanden sein sollte.
   "Halbe Groesse": per "transform: scale(0.5)" umgesetzt statt einer
   festen Breitenangabe - dadurch unabhaengig davon, WIE die aktuelle
   Groesse zustande kommt (z.B. ueber eine prozentuale
   "--size-style-width", die wir nicht sicher kennen), wird das Bild
   zuverlaessig auf exakt die Haelfte seiner JEWEILIGEN aktuellen
   gerenderten Groesse reduziert. "transform-origin: center" (Standardwert,
   hier zur Klarheit explizit gesetzt) sorgt dafuer, dass die Verkleinerung
   mittig erfolgt (kein Verrutschen zu einer Seite).
   "Zentriert": zusaetzlich zur mittigen Skalierung wird die 4. Spalte
   selbst als Flex-Container mit "justify-content:center" UND
   "text-align:center" (deckt beide Faelle ab, falls das Bild kein reines
   Flex-Kind, sondern z.B. inline ist) zentriert - damit das Logo
   unabhaengig von seiner vorherigen Ausrichtung innerhalb der (auf
   kleinen Bildschirmen typischerweise volle Breite einnehmenden) Spalte
   mittig steht.
   NICHT LIVE VERIFIZIERT (Chrome-Erweiterung zum Zeitpunkt der Umsetzung
   nicht verbunden) - insbesondere das genaue Markup des Logos (vermutlich
   ein einzelnes <img>, aber ohne stabile eigene Klasse live bestaetigt)
   konnte nicht gegengeprueft werden. Bitte auf kleinen Bildschirmen auf
   der B2B-Seite gegenchecken. */
@media screen and (max-width: 749px), screen and (orientation: landscape) and (max-height: 500px) {
  body .section--page-width.color-custom-template--32697460982090__section_hV7Vjm
    > .custom-section-content
    > .section-content-wrapper
    > .group-block:nth-child(4) {
    display: flex !important;
    justify-content: center !important;
    text-align: center !important;
  }
  body .section--page-width.color-custom-template--32697460982090__section_hV7Vjm
    > .custom-section-content
    > .section-content-wrapper
    > .group-block:nth-child(4) img {
    transform: scale(0.5) !important;
    transform-origin: center !important;
  }
}

/* ---------------------------------------------------------------- 92.
   OFFICE-BOX-SEITE: (ENTFERNT, ROUND 28, 56. BATCH) - hier stand testweise
   eine Ueberschreibung von "--gbb-progress-icon-gap" auf
   body[data-offer-id="SDK-023099"] (55. Batch, Merles eigener Vorschlag).
   Live im DevTools nachgeprueft (Chrome war diese Runde verbunden): die
   Variable wird von Easy Bundles per STYLESHEET-Regel (nicht inline) direkt
   auf ".gbbStepsProgressBarContainer" selbst gesetzt (25px) - eine
   Ueberschreibung auf dem <body> haette diese eigene, naeher am Element
   sitzende Deklaration gar nicht erreicht (geerbte Werte verlieren immer
   gegen eine am Element selbst gesetzte Deklaration, unabhaengig von
   "!important" auf einem Vorfahren). Ausserdem haette ein pauschal auf 0
   gesetzter Abstand ALLE Luecken verkleinert, auch die zwischen zwei
   WIRKLICH sichtbaren Schritten. Die eigentliche Luecke lag an einer ganz
   anderen Stelle (separate Verbindungslinien-Segmente) und wird jetzt
   gezielt in mobile-fixes.js (Block 30) geloest - siehe dort fuer den
   live verifizierten Fix. Diese Regel bleibt daher ersatzlos entfernt. */

/* ---------------------------------------------------------------- 93.
   MOBILE LANDSCAPE (NORMALE BOX-SEITE /products/box): GROSSES SAMMEL-PAKET
   "HANDY QUER EB SEITE" (ROUND 28, 57. BATCH)
   Merle schickte 18 einzelne, sehr konkrete CSS-Anweisungen fuer diese
   Seite im Querformat. Der groesste Teil davon wurde direkt in die bereits
   bestehenden, passenden Mobile-Landscape-Regeln oben eingearbeitet
   (Abschnitte 71/73/74 editiert, Abschnitt 82 zurueckgenommen, Gap/Border-
   Radius bei den Produkt-Slots in Abschnitt 32/37-Bereich ergaenzt/geaendert
   - siehe jeweils die "KORREKTUR (Round 28, 57. Batch)"-Kommentare dort).
   Live gegengeprueft (Chrome war diese Runde verbunden, echte Seite
   https://i0eqi9-cb.myshopify.com/products/box, offerId SDK-587069):
   - nth-child-Zuordnung der Box-Auswahl-Kacheln bestaetigt: (1) Probier-Box,
     (2) Single-Box, (3) We-are-family-Box.
   - Die Ursache fuer "versandkostenfrei bricht an dieser Stelle in zwei
     Zeilen" (Merles Punkt zu .gbbDiscountStepsProgressBarStepSubtitle) ist
     live bestaetigt eine NOCH NICHT auf der Live-Seite eingespielte, aber in
     dieser Datei bereits laengst vorbereitete Korrektur: live zeigte das
     Element "Versand-<br>kostenfrei" (harter Zeilenumbruch, die ALTE
     38.-Batch-Fassung) statt des seit dem 54. Batch in mobile-fixes.js
     bereits vorhandenen weichen Trennzeichens. Mit den naechsten, neu
     eingespielten Dateien sollte dieser Punkt sich von selbst loesen (der
     bereits bestehende, unconditional geltende "white-space:nowrap" aus
     Abschnitt weiter oben bleibt zusaetzlich bestehen) - KEINE neue Regel
     hier noetig, bitte nach dem Einspielen gegenchecken.
   - Die von Merle angegebene Variable "--gbbDiscountStepNodeHalfWidth" wird
     von Easy Bundles selbst (side-footer-bundle.min.css, live per fetch()
     gelesen) direkt auf ".gbbDiscountStepsProgressBarStepTitleWrapper"/
     ".gbbDiscountStepsProgressBarStepSubtitleWrapper" gesetzt (steuert
     "right: calc(-50% + var(--gbbDiscountStepNodeHalfWidth))", die
     horizontale Zentrierung jedes Schritt-Labels unter seinem Fortschritts-
     Punkt). Merles Deklaration wird hier wortgleich, DIREKT auf denselben
     beiden Elementen (nicht auf einem Vorfahren - sonst verliert unsere
     Regel wieder gegen die naeher sitzende EB-Deklaration, siehe Abschnitt
     92 oben), uebernommen - die Selbstreferenz "var(--gbbDiscountStepNode-
     HalfWidth)" im eigenen calc() loest beim Browser automatisch zum
     GEERBTEN/vorherigen Wert auf (hier: EBs eigener Wert), verschiebt diesen
     also gezielt um -58%, statt ihn zu ersetzen. */
@media screen and (orientation: landscape) and (max-height: 500px) {
  body .gbbBundleFooter {
    gap: 0px !important;
  }
  body .gbbDiscountStepsProgressBarStepTitleWrapper,
  body .gbbDiscountStepsProgressBarStepSubtitleWrapper {
    --gbbDiscountStepNodeHalfWidth: calc(-58% + var(--gbbDiscountStepNodeHalfWidth)) !important;
  }
  /* SCHAETZWERT: Merle "line height normal weg, durch einen kleinen Wert
     ersetzen" - der geerbte Wert des Elternteils (".gbbBundleTotalWrapper")
     war live kein kleiner, sondern ein unpassend GROSSER Wert (22.4px bei
     nur 10.88px Schriftgroesse) - daher hier bewusst NICHT "line-height:
     inherit", sondern ein eigener, knapper Wert (1.1). Bitte live
     gegenchecken, ob das zu eng/weit wirkt. */
  body .gbbFooterTotalLabel {
    line-height: 1.1 !important;
  }
  body .gbbFooterTotalContainer {
    text-align: center !important;
  }
}

/* =========================================================================
   NEUER BLOCK (ROUND 28, 63. BATCH)
   Vier neue, einzeln live im Chrome-DevTools-Styleeditor gegen die echte
   Seite getestete und bestaetigt funktionierende Korrekturen aus Merles
   Sammelnachricht (Office Box / Hero+Ankuendigungsleiste / Alle Gerichte).
   Die beiden Office-Box-Punkte "Produkt-Slots ueberschneiden sich" und
   "Produktbild wird kreisfoermig" wurden NICHT hier angehaengt, sondern
   direkt in die bereits bestehenden .gbbProductSlotsContainer /
   .gbbProductSlotImageContainer-Regeln weiter oben eingearbeitet (dort, wo
   die Grid-Regeln fuer Mobil/Querformat bzw. Desktop ohnehin schon standen).
   ========================================================================= */

/* 1. OFFICE BOX: gbbNavigationItemsContainer - Spalten zu breit.
   Live-Root-Cause: das native EB-Grid nutzt fr-basierte Spuren
   (minmax(20px,6fr)-Stil), die sich IMMER auf die volle Containerbreite
   aufteilen, egal wie wenige Items gerade sichtbar sind - bei nur 3
   sichtbaren "Box packen"-Schritten wurde dadurch jede Spalte 276px breit
   (gefuehlt viel zu breit). Fix live getestet: feste Spaltenbreite per
   auto-fit/minmax statt fr-Verteilung, dazu zentriert statt gestreckt.
   KORREKTUR (Round 29, 91. Batch): Merle meldet, dass die verbleibenden
   vier sichtbaren Schritte ("Lieferung" bleibt zwei Mal ausgeblendet,
   siehe .pv-hide-lieferung-nav-item) trotzdem nicht alle vier nebeneinander
   passen. Merles eigene Root-Cause-Vermutung: "auto-fit, minmax(60px,90px)"
   bemisst die Spaltenzahl an der verfuegbaren Breite in festen 60-90px-
   Schritten, nicht an der TATSAECHLICHEN Anzahl sichtbarer Items - je nach
   Containerbreite kann das zu einer anderen Spaltenzahl als 4 fuehren
   (umbricht dann in eine zweite Zeile oder laesst Luecken). Fix (Merles
   eigener Vorschlag, direkt uebernommen): feste SpaltenANZAHL (4, die
   bekannte, stabile Anzahl "Box packen"-Schritte der Office-Box nach Abzug
   der beiden ausgeblendeten "Lieferung"-Schritte) statt variabler
   auto-fit-Spaltenbreite - "minmax(20px,1fr)" teilt die volle Breite
   gleichmaessig auf alle vier Spalten auf (schrumpft nie unter 20px),
   garantiert dadurch unabhaengig von der Containerbreite genau vier
   Spalten nebeneinander. NICHT LIVE VERIFIZIERT (kein Browser-Zugriff
   diese Runde) - bitte gegenchecken, ob die Breite insgesamt noch passt. */
body[data-offer-id="SDK-023099"] .gbbNavigationItemsContainer {
  grid-template-columns: repeat(4, minmax(20px, 1fr)) !important;
  justify-content: center !important;
}

/* 2. HERO/ANKUENDIGUNGSLEISTE: Merle "vom .announcement-bar__slides auch
   einfach die max-width wegnehmen, dann ist der Text einzeilig - das
   entschaerft die Heroskalierungsproblematik". Live getestet: ohne
   max-width faellt der Ankuendigungstext tatsaechlich auf eine Zeile
   zusammen (vorher zweizeilig), wodurch die Ankuendigungsleiste insgesamt
   weniger Hoehe braucht - das nimmt dem ganzen Hero-Hoehen-/
   Skalierungs-Mechanismus (fitHero()) direkt Druck weg. */
body .announcement-bar__slides {
  max-width: none !important;
}

/* 3. ALLE GERICHTE: Schlagschatten-Transform des ersten Produktbilds auf
   dieser Seite anpassen. Selektor-Muster/Scoping-Technik 1:1 wie bei den
   bereits bestehenden Varianten dieser Regel fuer andere Seiten
   uebernommen (siehe weiter oben im File, z.B. die Variante fuer
   max-width:749px auf genau dieser Section) - hier bewusst eine eigene,
   NUR fuer Desktop/Tablet (min-width:750px) geltende neue Regel ergaenzt,
   damit die bereits separat fein-justierte Mobil-Variante dieser Section
   unangetastet bleibt. */
@media screen and (min-width: 750px) {
  #shopify-section-template--31616257720650__main .product-media-container.media-fit:first-of-type::before {
    transform: scale(0.8) translate(-6px, 20px) !important;
  }
}

/* =========================================================================
   NEUER BLOCK (ROUND 28, 64. BATCH)
   ========================================================================= */

/* 1. B2B-SEITE: zwei Textzeilen sollen nie umbrechen. Die eigentliche
   Erkennung passiert in mobile-fixes.js (Block 34, ueber Textinhalt statt
   ueber die von Merle genannten, nicht eindeutigen Hash-Klassennamen - siehe
   dortigen Kommentar) - hier nur das CSS-Gegenstueck zu den beiden selbst
   gesetzten Klassen. Bei der Adresse bleiben die harten "<br>"-Umbrueche
   zwischen den drei Zeilen (Firma/Strasse/Ort) unberuehrt, nur das
   zusaetzliche Umbrechen INNERHALB einer Zeile wird verhindert. */
body .pv-b2b-nowrap,
body .pv-b2b-adresse-nowrap {
  white-space: nowrap !important;
}

/* 2. OFFICE BOX + MIX-AND-MATCH: Logo im Hero wird per JS (fitHero(), siehe
   mobile-fixes.js) bereits dynamisch positioniert/skaliert - Merles Wunsch
   "Logo einfach etwas kleiner" ist dort als 10%-Reduktion der gemessenen
   Basisgroesse umgesetzt (Block direkt in fitHero(), nicht hier). Kein CSS
   noetig fuer diesen Punkt.

   Hinweis zur Gesamt-Pille (Punkt 3 unten): dort GENAU umgekehrt - das ist
   ein reiner CSS-Bug, kein JS-Thema. */

/* 3. EASY BUNDLES "GESAMT (ZZGL. VERSAND)"-PILLE: auf echtem breiten
   Desktop (NICHT nur im schmalen Handy-Querformat) weder zentriert noch mit
   der bereits an anderer Stelle gesetzten Zeilenhoehen-Korrektur versehen.
   ROOT CAUSE live per CSSOM-Durchsuchung gefunden: alle bisherigen
   Korrekturen dafuer (u.a. "line-height:1.1" aus dem 57. Batch, und
   "text-align:center" auf ".gbbFooterTotalLabel") stehen in dieser Datei
   NUR unter der engen Media-Query "orientation:landscape and
   max-height:500px" (= echtes schmales Handy-Querformat) - nicht unter der
   gleichzeitig fuer die ganze Pille selbst (Hintergrund/Rahmen/Flex-Layout)
   verwendeten, deutlich breiteren Bedingung "min-width:750px, ODER
   orientation:landscape and max-height:500px". Auf normalem breiten
   Desktop (nur min-width:750px, kein Querformat-mit-wenig-Hoehe) greifen die
   beiden Korrekturen dadurch nie - ".gbbBundleTotalWrapper" ist aber per
   eigener, UNSCOPED Regel "width:100% !important" immer volle Breite der
   Pille, wodurch der naturgemaess linksbuendige Text ("text-align:start",
   Browser-Default) optisch nicht zentriert wirkt, UND "line-height:normal"
   zusammen mit dem nativen harten "<br>" in "Gesamt<br> (zzgl. Versand)"
   wirkt bei der ohnehin kleinen Schriftgroesse (0.68em) unverhaeltnismaessig
   hoch. Fix: dieselben zwei Korrekturen zusaetzlich unter der breiteren,
   bereits fuer die Pille selbst verwendeten Media-Query ergaenzt - gewinnt
   gegen die alten, enger gescopten Regeln (gleiche Spezifitaet, aber spaeter
   in der Datei). Schriftgroesse selbst (0.68em) bewusst NICHT angefasst -
   das war eine bewusste frühere Entscheidung (vermutlich damit der Text in
   die schmale Pille passt), bitte erst Rueckmeldung von Merle abwarten, ob
   sie dort wirklich eine andere Zahl moechte. */
@media screen and (min-width: 750px), screen and (orientation: landscape) and (max-height: 500px) {
  body .gbbFooterTotalContainer .gbbFooterTotalLabel {
    white-space: normal !important;
    text-align: center !important;
    line-height: 1.1 !important;
  }
  body .gbbFooterTotalContainer .gbbFooterDiscountedTotalValue {
    text-align: center !important;
  }
  body .gbbFooterTotalContainer {
    text-align: center !important;
  }
}

/* ---------------------------------------------------------------- 68.
   NOTFALL-BATCH (Round 28, 68. Batch), kurz vor Merles Upload-Deadline.
   ---------------------------------------------------------------- */

/* Header-Logo-padding-left (68. Batch) auf Merles Wunsch (82. Batch) wieder
   entfernt - Logo soll wieder direkt am Viewport-Rand sitzen, kein
   zusaetzlicher Abstand. */

/* Box-Raster-Untertitel (".text-block--AK20zZ3gyR0NUQUkyN__text_FdHcdh",
   Text "Einfach Deine Box befuellen, easy bezahlen..."): Merle meldet "viel
   zu gross". Root Cause: dieser Textblock traegt die Klasse ".h6" auf dem
   WRAPPER-Div selbst (nicht auf einem echten <h6>-Tag) - greift dadurch
   NICHT in die Batch-65-Korrektur ("body h6 { ... }", Abschnitt 4, reine
   Tag-Selektor-Regel), sondern in die native ".h6.h6"/".text-block.h6 > *"
   Regel weiter oben in dieser Datei, die ueber die native CSS-Variable
   --font-h6--size geht - das erklaert, warum der fruehere h6-Fix hier nie
   gewirkt hat, obwohl er "schon behoben" schien. Fix: eng auf genau diesen
   Textblock gescopt, mit hoeherer Spezifitaet (Attribut- + Klassen-
   Selektor) gegen die native Regel. Schaetzwert (gleicher clamp wie der
   allgemeine h6-Fix, Abschnitt 4), bitte live gegenchecken. */
/* KORREKTUR (Round 28, 72. Batch): der vorherige Fix (direkt auf das Element
   mit der Klasse ".h6") hat NICHTS bewirkt, weil Oxygens eigene native Regel
   (siehe oben, ".h6.h6, .text-block.h6 > *, .text-block.h6 :is(h1...h6)")
   die Schriftgroesse nicht auf den Wrapper-Div selbst setzt, sondern auf
   dessen Kind-Element (direktes Kind ODER eine verschachtelte echte
   Ueberschrift) - geerbte Werte vom Elternteil verlieren gegen eine eigene,
   direkt am Kind gesetzte Regel, auch mit !important am Elternteil. Jetzt
   auf beide moeglichen Kind-Varianten gescopt, damit es unabhaengig vom
   genauen Markup greift. */
body [class*="text-block--AK20zZ3gyR0NUQUkyN__text_FdHcdh"].h6 > *,
body [class*="text-block--AK20zZ3gyR0NUQUkyN__text_FdHcdh"].h6 :is(h1, h2, h3, h4, h5, h6) {
  font-size: clamp(1.05rem, 4.2vw, 1.55rem) !important;
}
/* NEU (Round 28, 73. Batch): Merle "die h6 braucht einen kleinen margin
   links und rechts" - kleiner Seitenabstand, damit der Text nicht direkt an
   der Kante/Nachbarelementen klebt. Auf dem WRAPPER selbst (nicht dem Kind),
   da margin die Box-Platzierung betrifft, nicht die Textdarstellung - davon
   ist die Kind-vs-Wrapper-Problematik von oben (Schriftgroesse) nicht
   betroffen. Schaetzwert (12px), bitte live gegenchecken. */
body [class*="text-block--AK20zZ3gyR0NUQUkyN__text_FdHcdh"].h6 {
  margin-left: 12px !important;
  margin-right: 12px !important;
}
/* NEU (Round 28, 74. Batch): Merle direkt "bitte width 96%" fuer genau
   diesen Textblock. Zusaetzlich margin-left/right:auto, damit die
   schmalere Box weiterhin zentriert bleibt (sonst wuerde "width:96%" bei
   einem Block-Element links haengen bleiben statt mittig zu sitzen). */
body [class*="text-block--AK20zZ3gyR0NUQUkyN__text_FdHcdh"].h6 {
  width: 96% !important;
  margin-left: auto !important;
  margin-right: auto !important;
}