/**
 * Bonza, global HEADER, row 2 primary nav links and action icons.
 * ClickUp 86eypb6ab.
 *
 * Config investigated: the center nav menu ("Superfoods"/"Supplements"/
 * "Health hub for dogs") and the account/wishlist/cart action icons are
 * both rendered natively by Blocksy's header builder (`.ct-menu-link`,
 * `.ct-header-account .ct-icon`, `.ct-header-wishlist .ct-icon`,
 * `.ct-header-cart svg`) -- confirmed live via curl of the raw page
 * HTML. No Customizer control exists for nav-link color/weight/letter-
 * spacing or action-icon size/color; Blocksy ships its own theme
 * defaults for both (icons at a fixed 15x15px, nav text at a
 * theme-default weight/color), which is what the full-site audit
 * caught rendering un-branded.
 *
 * FIX (CU-86eyv2c1y, header/footer font audit): the font-family exemption
 * this docblock used to carry (no @font-face for "Nominee" existed) no
 * longer holds -- custom/css/fonts.css registers it (ClickUp 86eyv0pqj, PR
 * #740), now merged to main alongside this fix (PR #741). Nav links now
 * declare Nominee directly, matching the Figma "Link" component (29093:24719: fontFamily
 * "Nominee", weight 900, 12px, line-height 16px, UPPERCASE, #2E2A2A),
 * confirmed via direct Figma node inspection this pass. That inspection
 * also caught the font-size below was 14px, not the 12px Figma actually
 * specifies -- a prior round's "confirmed via getComputedStyle()" note
 * compared against production's own pre-existing (wrong) render, not
 * against the Figma node itself; fixed to 12px here. Weight, letter-
 * spacing and color were already correct.
 *
 * The icon SHAPE (solid-fill glyph vs Figma's "Vector Stroke" /
 * "Union Stroke" layer naming) is also not touched: Blocksy's own SVGs
 * are single filled paths with no stroke-based variant to swap in
 * without replacing the SVG source entirely, a larger asset change out
 * of this pass's scope. Size and color are fixed, matching the bulk of
 * the audit finding (icons render at 15x15px in the wrong color).
 *
 * Contrast: #494545 (this file's general body-text ink) measures 9.46:1
 * against the white header background (both the header row and the icon
 * container are #FFFFFF, confirmed live), well above the 4.5:1 text /
 * 3:1 UI-component thresholds. #494545 no longer renders anywhere in
 * this file, though -- the nav links and the action icons both ship the
 * darker #2E2A2A (14.18:1 for the icons, see their own inline notes),
 * which only improves on 9.46:1. Kept here because the header card's
 * 95%-opaque background note below still cites the 9.46:1 figure.
 *
 * editor-friendly-ok: styles Blocksy's own header-builder markup, not a
 * page/post content area -- no Gutenberg block or pattern counterpart
 * exists for the site header. Same is_checkout()-style unconditional
 * pattern as header-utility-bar.css, applied sitewide since the header
 * itself is sitewide.
 *
 * @package Blocksy_Child
 * @client  Bonza
 * @date    2026-09-03
 */

/* editor-friendly-ok: same exemption as the docblock above (Blocksy's own
   header-builder markup, no Gutenberg block/pattern counterpart exists). */

/* ---------------------------------------------------------------------
 * FIX (CU-86eypb6ab item 2, reported 2026-09-04): row 2 (logo/nav/search/
 * icons) rendered as a plain edge-to-edge white bar with no radius, no
 * shadow and no inset -- confirmed live via getComputedStyle() on
 * `#header [data-row="middle"]` (Blocksy's own native middle-row wrapper,
 * no class, targeted by its own data attribute): background rgb(255,255,
 * 255), border-radius 0, box-shadow none, width 100vw. Figma's desktop
 * header (148:18019) draws this same row as a floating rounded card
 * (component "Content" #7219:135926): background rgba(255,255,255,0.95),
 * border-radius 16px, box-shadow 0px 2px 42px 0px rgba(0,0,0,0.1), inset
 * 64px from each side (matching the utility-bar row's own 64px horizontal
 * padding directly above it) with a 16px gap between the two rows. The
 * header's own background is set to the utility bar's cream (#F8EDE3) so
 * the inset gap this margin creates reads as one continuous cream section
 * with the card floating in it, not a stray gap showing the page's near-
 * white body background (confirmed live: body background is rgb(250,251,
 * 252), not cream, so the gap would otherwise look unintentional).
 * Contrast: ink text #494545 on rgba(255,255,255,0.95) over #F8EDE3 is
 * effectively unchanged from the existing 9.46:1 measurement above (95%
 * opaque white leaves only a negligible cream tint through).
 * --------------------------------------------------------------------- */
/* editor-friendly-ok: same exemption as the file docblock.
 * FIX (CU-86eypb6ab QA round, 2026-09-17, item 2 -- "make the row with logo/
 * nav/search/icons sticky; the promo/USP row above it must scroll away
 * normally"): confirmed live via a scripted scroll test (scrollTo(0,900) then
 * re-read getBoundingClientRect()) that NEITHER row currently sticks --
 * `#header` stayed `position: relative`, no `.is-sticky`/`.ct-header-sticky`
 * class was ever added to it or to `<body>`, and its own top scrolled to
 * -856px along with the rest of the page. Config-first check run first
 * (`figma-config-check.sh --setting "Blocksy Header Builder: Sticky Header"
 * --result unset`): this build has never had Blocksy's native sticky-header
 * toggle turned on, and enabling it is a wp-admin Customizer action outside
 * this session's toolset (no WP-CLI/browser access), so this implements the
 * behavior in CSS (fix-hierarchy level 3) instead of leaving it unfixed;
 * flagged in the ClickUp report for whoever has Customizer access to
 * consider the native toggle as an alternative to this rule later.
 *
 * `.bhu-bar` (row 1, the promo/USP bar) is NOT a descendant of `#header` --
 * confirmed via `curl` of the raw page HTML: `#main-container` renders
 * `.bhu-bar`, then `#header`, then `.bhnv-bar` as three separate direct-
 * child siblings (the `blocksy:header:before` hook this file's own docblock
 * already documents prepends row 1 OUTSIDE `#header`, not inside it). That
 * turns out to make this fix simple rather than needing the `.is-sticky`
 * class-toggle + height/opacity-collapse approach header-utility-bar.css's
 * docblock speculated about for a DIFFERENT assumed DOM shape (row 1 nested
 * inside the same sticky box as row 2): since `#header` itself contains only
 * row 2 (the `[data-row="middle"]` card), position:sticky on `#header` alone
 * sticks row 2 to the top of the viewport while row 1, an earlier sibling in
 * normal flow, simply scrolls away above it like any other content -- no JS,
 * no class toggle, no collapse animation needed. `#header`'s own containing
 * block for sticky purposes is `#main-container` (the nearest ancestor that
 * is not `position: static`... `#header` itself is the only positioned node
 * in this chain, so its OWN sticky containing block is its parent,
 * `#main-container`, which spans nearly the full page height -- unlike
 * making the shorter `[data-row="middle"]` element sticky INSIDE the ~97px
 * `#header` box, which was tried first and rejected: that box is barely
 * taller than the child itself, so the "stuck" window would only last a few
 * pixels of scroll, not the whole page. z-index 100 clears row 1 (auto),
 * the hero/page content below (auto) and Blocksy's own base #header z-index
 * of 50, while staying well under the mobile drawer/backdrop (9999/9998) and
 * MyStickyMenu's own promo bar (9999999, already documented in navbar-
 * overlay.css as a separate, unrelated z-index arms race).
 */
/* editor-friendly-ok: same exemption as the file docblock (background-color
   unchanged from the original rule this sticky fix merges into). */
#header.ct-header {
	background-color: #F8EDE3;
	position: sticky;
	top: var(--bhu-pin, 0px); /* z8udzke6c8: sits below the utility bar while it is pinned on scroll up */
	/* Paired with header-utility-bar.css `.bhu-bar { z-index: 120 }`: raising
	   this above 50 once put the utility bar's dropdowns behind the header
	   card. If this number moves again, that one has to move with it. */
	z-index: 100;
	/* FIX (86eypb6m6): the cream fill behind the white header card. Sampling
	   the rendered Figma hero down its far-left column shows the photo
	   starting immediately under the cream utility bar, at CSS y=83 of the
	   1512 frame, and running on behind the card: there is no cream band
	   around the card at all, only photo. This fill painted one in, so the
	   card sat in a beige gutter instead of floating on the photograph.
	   Transparent from 768 up, where the card is an inset pill with a radius
	   and the photo shows around it. Below 768 the card is full-width, solid
	   white and edge to edge, so there is nothing to see through and the
	   fill is left alone. */
	background-color: transparent;
}

#header [data-row="middle"] {
	margin: 16px 64px 0;
	background-color: rgba(255, 255, 255, 0.95); /* ~9.46:1 for #494545 ink, negligible change from opaque white */
	border-radius: 16px;
	box-shadow: 0px 2px 42px 0px rgba(0, 0, 0, 0.1);
}

/* editor-friendly-ok: same exemption as the file docblock.
 * FIX (claude[bot] review on PR #701, 2026-09-04): the 64px inset was
 * unconditional, so past 991px it stopped matching the utility bar's own
 * horizontal padding directly above it (header-utility-bar.css:302-337
 * steps that padding down to 24px at <=991px, 16px at <=767px), breaking
 * the "one continuous cream section" this card is meant to sit inside and
 * eating extra width from the row exactly where nav+search+icons are
 * already tight. Mirrors those two breakpoints here.
 * CORRECTION (Fable 5.1 audit, 2026-09-07): moved 991px -> 1099px to match
 * Blocksy's real tablet/desktop DOM-branch switch on this site (see the
 * item-1 grid-fix comment below for the full explanation); keeps this
 * card's own inset transition aligned with the utility bar's.
 * SECOND CORRECTION (same audit): below this same breakpoint the new
 * tablet/mobile nav row (`.bhnv-bar`, added this round for item 5) sits
 * flush against this card's bottom edge with its own `border-radius: 0 0
 * 16px 16px` -- but this card kept its full 16px radius on ALL corners,
 * so its own rounded bottom corners left a small cream-colored notch
 * where they met the nav's squared-off top edge (visible seam, caught by
 * the audit). Squaring this card's bottom corners only where the nav row
 * is actually present (this same breakpoint) makes the two read as one
 * continuous shape. */
@media (max-width: 1439px) {
	#header [data-row="middle"] {
		margin: 16px 24px 0;
		border-radius: 16px 16px 0 0;
	}
}

/* editor-friendly-ok: same exemption as the file docblock.
 * FIX (client-reported, 2026-09-08): re-pulled the real Mobile HEADER Figma
   variant (#20168:149054, decoy-corrected node -- see item-6 comment further
   down for the full "34685:55738 is a decoy STICKY frame" writeup) and
   downloaded its reference image for this specific complaint. Confirmed both
   via get_figma_data and the downloaded screenshot: at mobile width Figma's
   logo/icon row (#29180:61947), search row (#29180:61975), and nav-links row
   (#34374:82784) all have `sizing.horizontal: fill` with NO side inset --
   just their own 16px internal padding -- and NONE of them carry a
   border-radius or box-shadow; it reads as a flat, edge-to-edge white bar,
   not a floating card. The desktop/tablet "floating card" treatment (margin
   inset + radius + shadow) added earlier in this file is a desktop/tablet-
   only Figma pattern that never applied at mobile; this block previously
   only shrank the inset (16px) instead of removing the card treatment
   entirely. Zeroed the margin and the two "floating card" properties;
   background stays opaque white per Figma's own `fills: #FFFFFF` on this
   row (the 0.95-alpha white above is the desktop/tablet card's own value,
   not mobile's). */
@media (max-width: 767px) {
	#header [data-row="middle"] {
		margin: 0;
		border-radius: 0;
		box-shadow: none;
		background-color: #FFFFFF;
	}
}

/* ---------------------------------------------------------------------
 * FIX (full-site audit, 2026-09-03, major): primary nav links render in
 * the wrong weight (700 not 900), letter-spacing (normal not 0.02em)
 * and color (#3A4F66 Blocksy-default blue-gray, not Bonza's #494545
 * ink). Confirmed live via curl: nav renders inside
 * `#header-menu-1 .menu-container .ct-menu-link` (config comment in
 * header-utility-bar.css already documents this exact selector chain).
 * --------------------------------------------------------------------- */
/* editor-friendly-ok: same exemption as the file docblock. */
#header-menu-1 .ct-menu-link {
	font-family: var( --wp--preset--font-family--bhp-heading, "Nominee", var( --theme-font-family, sans-serif ) ); /* --theme-headings-font-family tier removed: defined nowhere in any deployed stylesheet (hover-type-contract.md typography section), was a dead fallback link */
	font-weight: 900;
	font-size: 12px; /* corrected from 14px -- Figma's Link component (29093:24719) specifies 12px, not 14px; see docblock */
	line-height: 16px;
	letter-spacing: 0.02em;
	text-transform: uppercase; /* Figma's Link component textCase is UPPER; this rule never set it explicitly before */
	color: #2E2A2A; /* editor-friendly-ok: same exemption as the file docblock. CORRECTION (Fable 5.1 audit, 2026-09-07): Figma's Link text fill is #2E2A2A, not #494545 (this file's general body-text ink) -- #2E2A2A is darker, so contrast on the white header row only improves vs the prior 9.46:1 measurement. */
}

/* editor-friendly-ok: same exemption as the file docblock.
 * FIX (CU-86eypb6ab QA round, 2026-09-07, item 1): two confirmed mismatches
 * against Figma's Content row (instance #29266:41226 -> frame "Content"
 * #7219:135926 -> Container #29180:58722 "Link" x3), re-pulled fresh this
 * round since the client's new QA screenshots are against this exact
 * instance. The Link component set (#29093:24720) was inspected for its
 * variants/states (Main/Default, Hover, Active; Child and Courtesy variants
 * are used elsewhere for sale/gift-card badges, not this nav) -- Active
 * shows a 2px bottom stroke in #FFA825 (current-page indicator), added
 * below via the WP-native `current-menu-item` class; Hover's own stroke
 * swatch is 0-alpha (no color change), so only a text underline is added,
 * matching this file's existing `.bhu-bar` hover convention.
 *
 * (a) Nav-link gap: Figma's nav Container has an explicit 16px flex `gap`
 * between the three Link instances, on top of each Link's own 4px/12px
 * padding. Confirmed live via getComputedStyle(): `#header-menu-1 > ul.menu`
 * is `display:flex; gap:0px` -- links only separate by their own
 * `.ct-menu-link` padding (`0px 12.5px`, no vertical padding), so adjacent
 * links sit 25px apart instead of Figma's 12+16+12=40px. Added the missing
 * gap and matched the Link component's own 4px vertical / 12px horizontal
 * padding (was 0/12.5, confirmed via getComputedStyle()).
 *
 * (b) Nav column position: Figma's Content row is a flex `space-between`
 * of exactly 3 hug/fixed children (logo 162.99px fixed, nav Container hug,
 * search+icons Container 480px fixed) -- with `space-between`, the two
 * internal gaps (logo<->nav, nav<->search-group) are always equal by
 * definition. Confirmed live via getBoundingClientRect() at 1440px that
 * Blocksy instead renders this row as a CSS grid with the two OUTER
 * columns forced equal to each other (402.5px / 484.9px / 402.5px,
 * confirmed via getComputedStyle().gridTemplateColumns) regardless of the
 * logo's and icon-group's own much narrower natural widths -- this
 * measured as a 250px logo<->nav gap against a 24px nav<->search gap, a
 * visibly off-center nav that reads as "positioned wrong" against Figma's
 * equal-gap layout. `auto 1fr auto` sizes the two outer columns to their
 * own content instead, so the nav's flexible middle column reproduces the
 * same equal-gap arithmetic as Figma's `space-between` (nav already sits
 * centered within its own column via Blocksy's grid `justify-items`, so
 * only the column widths needed correcting, not the nav's own alignment).
 * `!important` on the grid-template-columns override: Blocksy's own
 * dynamic-CSS rule sets it with the same `.ct-container` class specificity
 * this selector already exceeds via `#header`, but the computed 402.5px
 * values are re-derived from a container-width calc() on every resize, so
 * only `!important` reliably wins on every recompute, not just first paint.
 * Desktop-only (>991px): confirmed live via getComputedStyle() that this
 * whole `.ct-container` grid row is a SEPARATE, `display:none`-below-991px
 * DOM branch from the tablet/mobile row Blocksy renders instead (a second,
 * distinct `[data-row="middle"]` element with no nav menu of its own at
 * all) -- see header-utility-bar.css's tablet/mobile nav-row addition for
 * that separate branch, out of scope for this desktop-only selector.
 */
/* Scoped to >991px: confirmed live that the tablet/mobile row renders a
   SEPARATE `.ct-container` instance (2-column start/end grid, no nav of
   its own) -- an earlier, unscoped version of this rule would have forced
   that 2-column grid into 3 columns too. See the tablet/mobile fixes
   further down in this file for that separate instance's own rules.
 *
 * CORRECTION (Fable 5.1 comprehensive audit, 2026-09-07): a plain `1fr`
 * grid track has an IMPLICIT minimum size of `auto` (its content's own
 * min-content width), not 0 -- a well-documented CSS Grid gotcha. Once
 * this same round's own item-1 nav-gap/padding fix (16px gap + 4px/12px
 * padding per link) grew the nav's min-content width to ~494px, the
 * middle column could no longer shrink below that, so between ~1100 and
 * ~1170px viewport width the grid could not fit `auto` (logo) + 494px
 * (nav floor) + `auto` (search+icons) in the available row width -- a NEW
 * regression the audit caught live (nav overlapping/clipping into the
 * search field, "HEALTH HUB FO..." cut off), not present before this
 * round's own item-1 fix. `minmax(0, 1fr)` removes that content-based
 * floor so the middle column can genuinely shrink to 0 under pressure;
 * combined with `overflow-x: hidden` on the nav's own `<ul>` (immediately
 * below), it clips gracefully instead of overlapping its neighbors at
 * this narrow, Figma-unspecified in-between width (Figma has no anchor
 * frame in the 1100-1170px range; graceful clipping there is a
 * judgement call, not a Figma-confirmed spec, same as this file's other
 * documented judgement calls).
 *
 * SECOND CORRECTION (same audit): the 991px/992px boundary used
 * throughout this file's tablet-scoped rules (inherited from this task's
 * pre-existing convention, PR #701 onward) was itself never live-verified
 * against Blocksy's ACTUAL DOM-branch switch for this specific header on
 * this specific site -- confirmed live by the audit that Blocksy keeps
 * showing its tablet/mobile header row (hamburger-only, no desktop nav)
 * all the way to ~1099px, not 991px, on bonza-retheme.blz.au (Blocksy's
 * tablet breakpoint is admin-configurable per site, so 991 was a
 * reasonable but wrong guess carried over from elsewhere). Between 992
 * and 1099px, this desktop-only block was applying to a `.ct-container`
 * Blocksy had NOT yet switched to (harmless, since it's a separate
 * `display:none` DOM branch there either way), but the corresponding
 * tablet-scoped rules elsewhere in this file and in header-utility-bar.css
 * (icon gaps, divider, meta-group hide, nav-row visibility) stopped at
 * 991px too, leaving that same 992-1099px band with NEITHER the tablet
 * fixes NOR a desktop nav -- the exact "no nav at all" / utility-bar
 * overlap the audit caught at 1024px. Moved this boundary (and every
 * other 991/992px tablet-scope boundary this round touches) to 1099/1100
 * to match Blocksy's real switch point.
 */
@media (min-width: 1440px) {
	#header [data-row="middle"] .ct-container {
		grid-template-columns: auto minmax(0, 1fr) auto !important;
	}

	/* editor-friendly-ok: same exemption as the file docblock.
	   HD-05 (86eypb6ab, 86eyv0k44 parity audit round 2, runs/verify-Header-2.json):
	   the desktop card (`[data-row="middle"]`, styled at the top of this file)
	   has never had an explicit height/padding of its own -- confirmed live it
	   was purely content-driven at 120px with 0 padding vs Figma's Content
	   component 29266-41226/7219-135926 (1384x81, padding 16px 20px). Fixed
	   sizing here (not min-height/min-padding) since Figma's own node is
	   FIXED, not hug/auto. box-sizing:border-box keeps the 81px an OUTER
	   total, matching how the audit measures the card element itself, not
	   the .ct-container child's own separate ~11px inset (Blocksy core CSS,
	   unrelated to this padding and not touched here). After HD-03's 49px
	   search-input fix, the tallest desktop child (49px) plus this 32px
	   vertical padding is exactly Figma's 81px, so no child is clipped.
	   FIX (86eypb6ab, visual audit, 2026-09-18 -- "header background container
	   looks off with its elements inside"): HD-05 above never closed the loop
	   on Blocksy's own sizing mechanism. `#header [data-row] > div` (Blocksy
	   core, main.min.css) is `min-height: var(--shrink-height, var(--height))`,
	   and `.ct-container` IS that direct child (confirmed live via outerHTML,
	   not assumed) -- so `.ct-container` was still pinned to the Customizer's
	   own `--height:120px` (Blocksy's dynamic global.css, `[data-row*="middle"]
	   {--height:120px}`) regardless of this rule's own 81px card height.
	   Measured live: card 60-141px (81 tall), `.ct-container` 76-196px (120
	   tall) -- a 55px overflow, with the logo (116-156) rendering below the
	   card's own bottom edge into the cream page background. `--height` /
	   `--shrink-height` are the two custom properties Blocksy's own rule
	   reads, in that priority order -- setting both here, scoped to this same
	   `min-width:1100px` block, keeps this a config-variable override (the
	   mechanism Blocksy itself uses for responsive height) rather than a
	   fight against its selector. 49px is this same rule's own already-
	   audited number two lines up (HD-05: 81px card - 32px vertical padding =
	   49px content area = the tallest child's own height, so nothing clips).
	   Verified live via CSS injection before writing: `.ct-container` drops
	   to exactly 49px, logo/search/icons all land inside the card's padding
	   box, no bleed past the bottom edge. Config-first note: the real fix is
	   Blocksy's own Customizer "Header Middle Row Height" field (currently
	   120px there, disagreeing with this file's own 81px card) -- this
	   session has no wp-admin/Customizer access to set it there, so this
	   overrides the same CSS variable Customizer would otherwise write,
	   which is the closest CSS-level equivalent to a config change rather
	   than a layout hack. Flagged in the ClickUp report for whoever has
	   Customizer access to reconcile the source setting. */
	#header [data-row="middle"] {
		box-sizing: border-box;
		height: 81px;
		padding: 16px 20px;
		--height: 49px;
		--shrink-height: 49px;
	}

	#header-menu-1 {
		min-width: 0;
		overflow: hidden;
	}

	#header-menu-1 > ul.menu {
		flex-wrap: nowrap;
		overflow: hidden;
	}
}

#header-menu-1 > ul.menu {
	gap: 16px;
}

#header-menu-1 .ct-menu-link {
	padding: 4px 12px;
}

#header-menu-1 .menu-item.current-menu-item > .ct-menu-link,
#header-menu-1 .menu-item.current_page_item > .ct-menu-link {
	box-shadow: inset 0 -2px 0 0 #FFA825; /* Figma Link "Main, State=Active" bottom stroke */
}

#header-menu-1 .ct-menu-link:hover {
	/* source:FIGMA (partial) -- Link "Main, State=Hover" (29093:24720, hover-type-contract.md
	   L53) measures text + underline dark -> gold #FFA825. NOT implemented here: #FFA825 on
	   this row's #FFFFFF background computes to 1.93:1 (relative-luminance formula, matches
	   this file's own method elsewhere e.g. the 14.18:1 icon note above) -- fails WCAG 2.2 AA
	   4.5:1 for text and even the 3:1 large-text/non-text floor (WCAG 1.4.3/1.4.11), under
	   Bonza's contractual WCAG 2.2 AA guarantee. NEEDS HUMAN: flagging the contradiction rather
	   than silently keeping the old "0-alpha, no change" read (also wrong -- the delta is real,
	   just unshippable as measured) or silently picking a different passing color Figma never
	   specified. Underline kept as the only hover signal until design confirms a compliant
	   hover color. */
	text-decoration: underline;
}

/* editor-friendly-ok: same exemption as the file docblock. */
/* ---------------------------------------------------------------------
 * FIX (client-reported, 2026-09-04): the earlier pass (full-site audit,
 * 2026-09-03) only resized and recolored Blocksy's OWN default account/
 * wishlist/cart glyphs -- its own docblock said swapping the actual shape
 * was "a larger asset change out of this pass's scope". The client's
 * screenshots show that decision was wrong: the icon SHAPE itself needs
 * to match Figma, not just the bounding box. Re-pulled 148:18019 directly
 * (frames #34097:269450 "Vector (Stroke)", #34097:269452 "Union (Stroke)
 * (Stroke)", #34097:269454 "Shop / bag_variant") and exported the real
 * SVGs to custom/assets/header-icons/. Also caught in this same re-pull:
 * the earlier pass's fill color, #494545 (this file's general body-text
 * ink), was never actually the icon's own Figma fill -- these three ICON
 * nodes use #2E2A2A specifically (`fill_66e64b97` in the extracted data),
 * a different, slightly darker tone. Corrected here; 14.18:1 on the white
 * header row (WCAG relative-luminance formula), still clears 4.5:1/3:1.
 * Swap technique: Blocksy's native `<svg><path>` markup is kept in the DOM
 * (preserves click target, ARIA, existing JS event bindings on the
 * `.ct-offcanvas-trigger`/cart-fragment elements) but visually hidden
 * (`display:none` on its own `path`, not the whole `<svg>`, so the SVG
 * element's own box/positioning context Blocksy's JS may depend on stays
 * intact); the real shape is painted via `mask-image` on the icon
 * container with `background-color: currentColor`, the standard technique
 * for swapping a monochrome icon's glyph without touching markup.
 * --------------------------------------------------------------------- */
.ct-header-account .ct-icon {
	width: 22.5px;
	height: 25.5px;
	color: #2E2A2A; /* 14.18:1 on the white header row -- Figma's own icon fill, not this file's general #494545 ink */
	background-color: currentColor;
	-webkit-mask-image: url( '../assets/header-icons/header-account-icon.svg' );
	mask-image: url( '../assets/header-icons/header-account-icon.svg' );
	-webkit-mask-size: contain;
	mask-size: contain;
	-webkit-mask-repeat: no-repeat;
	mask-repeat: no-repeat;
	-webkit-mask-position: center;
	mask-position: center;
}

.ct-header-wishlist .ct-icon {
	width: 25.5px;
	height: 23.54px;
	color: #2E2A2A; /* 14.18:1 on the white header row */
	background-color: currentColor;
	-webkit-mask-image: url( '../assets/header-icons/header-wishlist-icon.svg' );
	mask-image: url( '../assets/header-icons/header-wishlist-icon.svg' );
	-webkit-mask-size: contain;
	mask-size: contain;
	-webkit-mask-repeat: no-repeat;
	mask-repeat: no-repeat;
	-webkit-mask-position: center;
	mask-position: center;
}

.ct-header-account .ct-icon path,
.ct-header-wishlist .ct-icon path {
	display: none;
}

/* editor-friendly-ok: same exemption as the file docblock.
 * CORRECTION (re-audit on PR #703): sizing this container to a flat 28x28
 * square (Figma's own frame padding math, "44x44 container, 8px padding
 * -> 28x28") was still wrong once the SVG itself was cropped to its real
 * path bounding box (22.12x25.14, non-square). `mask-size: contain` inside
 * a SQUARE box scales a NON-square asset up to fill the box's larger
 * dimension, rendering the icon at 24.64x28 -- 11% larger than Figma's
 * actual glyph size, not the 1:1 reproduction the account/wishlist icons
 * already get (their own containers are sized to their exact tight-crop
 * dimensions, 22.5x25.5 and 25.5x23.54, not a generic square). Matched
 * that same pattern here instead: container sized to the icon's own real
 * 22.12x25.14, so `mask-size: contain` becomes an exact 1:1 fit like the
 * other two icons, not a scale-up.
 */
.ct-header-cart .ct-icon-container svg {
	width: 22.12px;
	height: 25.14px;
	color: #2E2A2A; /* 14.18:1 on the white header row -- see the account/wishlist correction above */
	background-color: currentColor;
	-webkit-mask-image: url( '../assets/header-icons/header-cart-icon.svg' );
	mask-image: url( '../assets/header-icons/header-cart-icon.svg' );
	-webkit-mask-size: contain;
	mask-size: contain;
	-webkit-mask-repeat: no-repeat;
	mask-repeat: no-repeat;
	-webkit-mask-position: center;
	mask-position: center;
}

.ct-header-cart .ct-icon-container svg path {
	display: none;
}

/* editor-friendly-ok: same exemption as the file docblock.
 * FIX (client-reported regression, CU-86eypb6jt/86eypb6m6, 2026-09-20):
 * "the position of the header cart icon quantity number regressed, its too
 * far upper right". Confirmed live via document.styleSheets + el.matches()
 * against `.ct-dynamic-count-cart` at 1440/768/375 (identical at all three
 * -- this rule isn't breakpoint-scoped): the ONLY matching rule anywhere on
 * the page is Blocksy CORE's own `[class*="ct-dynamic-count"]`, shipped in
 * `wp-content/themes/blocksy/static/bundle/woocommerce.min.css`
 * (`top: -9px; inset-inline-end: -9px;`). That file is outside this repo
 * and is never edited directly. Grepped this repo (`sites/bonza/custom/`)
 * for `ct-dynamic-count` first -- the only hit is markup in
 * `cart-drawer-filled.php`, no styling -- so there was never a child-theme
 * override here to restore; whatever previously countered Blocksy's -9px/
 * -9px lived outside this monorepo (or in Customizer CSS) and is gone now.
 * Measured live (2 items in cart), badge vs the ACTUAL cart svg's own
 * rendered box (this file's own `.ct-header-cart .ct-icon-container svg`
 * rule above sizes that svg to 22.12x25.14, confirmed matching live at all
 * 3 widths): badge right edge sat 20px right of the svg's right edge and
 * 18px above the svg's top edge -- the badge floats almost entirely off
 * the icon's upper-right corner, matching the client's own description.
 * Figma: the only header cart-count badge in the pinned offline export
 * (`projects/bonza/reference/figma-context-20260917`) is on the Mobile/425
 * board, `HEADER (425)` frame, path `HEADER > HEADER 4 > Content > Button >
 * heroicons-outline/shopping-cart > Frame 76` (node id
 * `I23313:52709;14061:188846;22:41834;505:4661`, cornerRadius:100, a red
 * fill, containing a centered numeral -- unambiguously the count badge, not
 * the unrelated "Ellipse 41/42" or "Badges" nodes also in that frame, which
 * sit ~700-900px away in a completely different section of the page and
 * are actually product-card sale badges). No separate Tablet/Desktop header
 * frame exists in this export to cross-check -- this is the only header
 * cart-badge node available, matching how the live rule also applies
 * unscoped at every width. Read directly off that node's own geometry vs
 * its parent icon instance's visible glyph (`Vector`, the actual drawn
 * cart-shape path, not the 24x24 instance's outer hit-slop box): badge
 * overhangs the glyph's top-right corner by only +3px right / -3px up in
 * Figma's own units -- the badge sits ON the icon's corner, not floating
 * 20/18px off it. CAVEAT: that Figma node is itself `visible:false` in the
 * export (this particular header mock shows an empty cart, badge hidden) --
 * its stored position is very likely the real designed placement (Figma
 * does not typically relocate a toggled-off instance), but this is inferred
 * from a hidden node's layout data, not a rendered screenshot, so treat the
 * exact px as directional rather than pixel-perfect-certain.
 * Converting Figma's small +3/-3px overhang onto this site's actual svg
 * size (22.12x25.14, non-uniformly scaled from Figma's 19x18 glyph -- a
 * pre-existing, out-of-scope discrepancy, not touched here) two ways
 * (proportional to badge size, proportional to icon size) both land in the
 * same ~3-4px range, and independently agree with this container's own
 * already-audited 8px padding (see the CORRECTION comment on
 * `.ct-header-cart .ct-icon-container` above) -- pulling the badge in from
 * Blocksy's -9px/-9px to a small POSITIVE inset (inside the padded box,
 * flush near the svg's own corner) rather than another negative value
 * outside it. Not a literal Figma pixel readout at this exact breakpoint
 * (no Desktop/Tablet header board exists to confirm against), so flagged
 * as a derived/cross-validated estimate for whoever reviews this rather
 * than an exact spec value -- see CU-86eypb6jt for the source investigation
 * and ClickUp thread.
 * Selector specificity: three classes (0,3,0) beats Blocksy core's single
 * attribute selector (0,1,0) outright, so no `!important` is needed and
 * source order does not matter.
 */
.ct-header-cart .ct-icon-container .ct-dynamic-count-cart {
	top: 4px;
	right: 6px;
}

/* editor-friendly-ok: same exemption as the file docblock.
   HD-08 (86eypb6ab, 86eyv0k44 parity audit round 2, runs/verify-Header-2.json):
   Figma's cart ICONS component (mobile 23313-52675/29180-61974, desktop
   29266-41226/34097-269453) is a 44x44 hit-target frame with 8px padding
   on every side wrapping a 28x28 glyph -- live had no hit-box at all
   (`.ct-icon-container` sized to whatever its svg child naturally is,
   confirmed live at 22.12x25.14 with 0 padding, no 44x44 touch target).
   Sizes the WRAPPER only, not the glyph itself: the svg above keeps its
   own accurate 22.12x25.14 tight-crop size (see that rule's own
   CORRECTION comment for why forcing it to a flat 28x28 box would distort
   a non-square asset) -- centered via flex inside this 44x44/8px-padding
   box, which nets a 28x28 available area, matching Figma's own nested
   44 -> 28 structure without stretching the glyph to fill it. */
.ct-header-cart .ct-icon-container {
	box-sizing: border-box;
	width: 44px;
	height: 44px;
	padding: 8px;
	display: flex;
	align-items: center;
	justify-content: center;
}

/* editor-friendly-ok: same exemption as the file docblock.
   HD-09 (86eypb6ab, 86eyv0k44 parity audit round 2, runs/verify-Header-2.json):
   Figma's mobile/tablet menu-trigger Frame 2147230099 (23313-52675/
   35745-55724) is 44x44, justify-content:center, wrapping "Essentional/
   menu" at 32x32 -- live `button.ct-header-trigger` had no sizing of its
   own at all (confirmed live at 18x18, Blocksy's own unstyled default),
   which is also why the logo/trigger group measured narrower than Figma
   at every width this round's audit checked (the trigger's own shortfall,
   not the logo). Unscoped: Blocksy's own markup only renders this button
   inside the mobile/tablet DOM branch (`data-device="mobile"`), which is
   itself hidden at desktop via Blocksy core CSS, so no desktop media
   query is needed here. `.ct-icon` inside is this button's own inline SVG
   (24x24 intrinsic, CSS-driven render size) -- sized here to Figma's 32x32
   glyph spec. */
button.ct-header-trigger {
	box-sizing: border-box;
	width: 44px;
	height: 44px;
	display: flex;
	align-items: center;
	justify-content: center;
}

button.ct-header-trigger .ct-icon {
	width: 32px;
	height: 32px;
	color: #2E2A2A; /* Figma Essentional/menu stroke colour, 14.18:1 on the white header row */
	background-color: currentColor;
	-webkit-mask-image: url( '../assets/header-icons/header-menu-icon.svg' );
	mask-image: url( '../assets/header-icons/header-menu-icon.svg' );
	-webkit-mask-size: contain;
	mask-size: contain;
	-webkit-mask-repeat: no-repeat;
	mask-repeat: no-repeat;
	-webkit-mask-position: center;
	mask-position: center;
}

/* Blocksy's own 3-bar rects (20x2, square-ish) stay in the DOM but are hidden;
   Figma draws three 24px lines at 1.5px stroke with round caps, painted by the mask above. */
button.ct-header-trigger .ct-icon rect {
	display: none;
}

/* editor-friendly-ok: same exemption as the file docblock.
 * FIX (client-reported, 2026-09-04): the header logo did not match
 * Figma's actual exported mark at all (wrong color/asset, confirmed
 * against 148:18019 frame #34095:257812 "design", 162.99x40, solid
 * #247B4E). Blocksy's own `<img class="default-logo">` markup and its
 * `src`/`alt`/link stay in the DOM (SEO, accessibility, WooCommerce/theme
 * JS that may reference this element), only the rendered image is swapped
 * via the CSS `content: url()` replacement technique (Chrome/Firefox/
 * Safari 16.4+ support this on `<img>`; this is a marketing site, not a
 * legacy-browser-support target, matching this repo's existing browser
 * baseline elsewhere).
 * CORRECTION (independent audit on PR #703): the shape/color swap above
 * was correct but the logo still rendered 25% larger than Figma's own
 * 162.99x40 spec -- Blocksy's Customizer logo-width setting (203.75px)
 * still drove the box, and the new SVG's 163:40 intrinsic ratio just
 * scaled up to fill it, confirmed live via getBoundingClientRect() on the
 * deployed build.
 * A first attempt at this correction used `aspect-ratio` instead of an
 * explicit `height`, reasoning it would scale proportionally under the
 * mobile `max-width: 96px` rule below without fighting it. Live-tested via
 * style injection on the deployed build and found it does NOT work:
 * Blocksy's own `.site-logo-container { height: var(--logo-shrink-height,
 * var(--logo-max-height, 50px)) }` sets `height` explicitly (not `auto`),
 * and `aspect-ratio` only fills in a dimension left `auto` -- it cannot
 * override an already-explicit `height`, confirmed live (container stayed
 * 203.75x50, aspect-ratio just solved width from the still-locked 50px
 * height). Reverted to explicit literal `height` values instead, matching
 * this codebase's existing convention elsewhere in this file: 40px at
 * desktop, 23.56px at the mobile breakpoint (96 * 40/163, computed to
 * preserve the same ratio rather than guessed). Considered config-first
 * (Blocksy's own Customizer logo-width field) instead, but that field is
 * not breakpoint-scoped to desktop only, and would resize the logo on
 * every template/breakpoint, not just this header row -- a CSS rule
 * scoped to this exact element is the narrower, more correct change.
 */
.site-branding[data-id="logo"] .site-logo-container {
	height: 40px;
}

.site-branding[data-id="logo"] .site-logo-container img.default-logo {
	content: url( '../assets/header-icons/header-logo.svg' );
	width: 163px;
	height: 40px;
}

/* editor-friendly-ok: same exemption as the docblock above. */
/* ---------------------------------------------------------------------
 * FIX (CU-86eypb6ab item 2, reported 2026-09-04): the FiboSearch header
 * search field does not match Figma at all, confirmed live via
 * getComputedStyle() on `[data-id="search"] .dgwt-wcas-search-input`
 * (the only visible desktop search input; a second, hidden `.modal-field`
 * search input exists for the mobile drawer overlay and is untouched):
 *   background      #EEEEEE live   -> Figma #FFFFFF
 *   border          2px transparent-> Figma 1px solid #D1D5DB
 *   border-radius   30px live      -> Figma 9999px (visually already near-pill
 *                                     at this height, corrected for exactness)
 *   padding         13px 24 13 16  -> Figma 12px 16px (all sides)
 *   text color      #3A4F66 live   -> Blocksy's default blue-gray leaking in
 *                                     (same un-branded default the nav-link
 *                                     fix above already corrects elsewhere),
 *                                     set to Bonza ink #2E2A2A
 * NOT changing width: the 480px in Figma (#34097:269421 "Container") belongs
 * to the OUTER frame holding search+divider+icons together (sizing:fixed),
 * not the search input alone (Input Field #34097:269430 is sizing:fill
 * within that row). A first pass wrongly hardcoded 480px onto just the
 * search wrap, which pushed the search field wide enough to clip the nav
 * links at 1440px live -- confirmed visually via a client-side style
 * injection preview before this was corrected. Left at its native flexible
 * width so it keeps sharing space with the nav correctly at every desktop
 * width, same as it already did before this fix.
 * Placeholder color already close (#767676 live vs Figma's #8A909E) --
 * left as a config-level FiboSearch setting, not overridden here to avoid
 * fighting the plugin's own inline style specificity for a near-miss.
 * Contrast: #2E2A2A on #FFFFFF is 15.6:1 (well above 4.5:1); FiboSearch's
 * own placeholder color is unchanged, so not re-measured here.
 * --------------------------------------------------------------------- */
#header [data-id="search"] .dgwt-wcas-sf-wrapp {
	background-color: transparent;
	border-radius: 9999px;
	padding: 0;
}

/* editor-friendly-ok: same exemption as the file docblock -- FiboSearch's
   own plugin markup, not a WP block, colors already audited/measured above. */
#header [data-id="search"] .dgwt-wcas-search-input {
	background-color: #FFFFFF;
	border: 1px solid #D1D5DB;
	border-radius: 9999px;
	padding: 12px 48px 12px 16px; /* CORRECTION below: extra right padding clears the icon button, was 16px all sides */
	color: #2E2A2A; /* 15.6:1 on #FFFFFF */
	/* editor-friendly-ok: same exemption as the file docblock.
	   HD-03 (86eypb6ab, 86eyv0k44 parity audit round 2, runs/verify-Header-2.json,
	   opus adversarial pass 2026-09-14) CORRECTS a false fix from HD-02: HD-02
	   pinned this input to 44px citing Figma Input Field 34097-269430 -- but
	   that node is the MOBILE Input Field (396x44). The tablet Input Field
	   (23310-35540/34374-77672, 241x49) and this same desktop row's actual
	   Input Field (29266-41226/34097-269430, 284x49) are BOTH 49px, not 44.
	   This base/unscoped rule now carries the >=768px (tablet+desktop) value;
	   the true 44px mobile value lives in the @media(max-width:599px) block
	   below as HD-04, so the two breakpoints no longer share one wrong number.
	   box-sizing: border-box + an explicit height still pins the real box
	   regardless of padding/line-height math (same idiom used on .bhu-bar).
	   The submit icon button (below) already centers via top:50%/
	   translateY(-50%), so it is unaffected by this height change. */
	box-sizing: border-box;
	height: 49px;
	/* editor-friendly-ok: same exemption as the file docblock.
	 * FIX (CU-86eypb6ab QA round, 2026-09-17, item 5 -- "search placeholder
	 * font mismatch, should render in Nominee, font-family scope likely
	 * missing"): confirmed live via a scripted getComputedStyle(el,
	 * '::placeholder') check that this input renders in "Roboto, sans-serif"
	 * -- FiboSearch's own plugin default, set directly on
	 * `input.dgwt-wcas-search-input` (an explicit rule on the element itself
	 * beats this file's `fonts.css` `body { !important }` fallback, since
	 * that fallback only reaches this input by INHERITANCE, the weakest
	 * source in the cascade -- `!important` on `body` only wins against
	 * other rules targeting `body`, not a rule the plugin puts directly on a
	 * descendant).
	 * DESIGN-SOURCE DISCREPANCY, kept on record rather than silently
	 * overridden: the real Figma placeholder text node (Input Field
	 * 34097:269430 -> "Search for dog food or supplements", #29049:58895)
	 * has its own `style` block specifying `fontFamily: "Kobe1.1"`, weight
	 * 400 (Regular), 14px -- not Nominee. Nominee is this file's heading/nav
	 * font (900 weight, uppercase), a different register than a lowercase
	 * sentence-case placeholder. Built to the QA ticket's explicit
	 * instruction anyway (Vita's comment names Nominee, and the session lead
	 * confirmed: build what the ticket asks for, don't substitute a Figma
	 * reading for it, that rule only doesn't apply where nobody has
	 * specified a value at all) -- so this renders Nominee, with this note
	 * left here so nobody has to rediscover the Figma node disagreeing with
	 * it. Both fonts have real `@font-face` cuts in `fonts.css` (this same
	 * custom/css/ directory, CU-86eyv0pqj, PR #740/#741), so either choice
	 * actually loads; the `@font-face` CORRECTION comment this replaces was
	 * stale on that point (cited "no @font-face for Kobe1.1" as of
	 * 2026-09-04, since corrected). */
	font-family: var( --wp--preset--font-family--bhp-heading, "Nominee", var( --theme-font-family, sans-serif ) ); /* --theme-headings-font-family tier removed: defined nowhere in any deployed stylesheet (hover-type-contract.md typography section), was a dead fallback link */
}

/* editor-friendly-ok: same exemption as the file docblock.
 * FIX (client-reported, 2026-09-04): the search magnifier icon sat
 * low-left of the search pill instead of centered, confirmed live via
 * getBoundingClientRect(): the pill (`.dgwt-wcas-sf-wrapp`) is 50px tall
 * (93-143px in viewport terms), but FiboSearch's own submit button
 * (`.dgwt-wcas-search-submit`, the plugin's clickable wrapper around the
 * magnifier SVG) is absolutely positioned with a hardcoded `top: 21px`
 * that assumes a different pill height than this fix's own 12px 16px
 * padding produces. At 33px tall the button occupied 21px-54px inside the
 * 50px pill, 4px past the pill's own bottom edge, not centered. Fixed by
 * overriding to `top: 50%; transform: translateY(-50%)`, which centers
 * regardless of the button's own height, instead of another hardcoded
 * pixel value that would only hold at this exact pill height.
 *
 * CORRECTION (client-reported, 2026-09-04): two more defects in this same
 * button, confirmed live via getComputedStyle(): (1) the plugin's own base
 * CSS also hardcodes `left: 23px; right: 0`, and since `width: 33px` is
 * also fixed, the browser's over-constrained-box rule drops `right` and
 * positions purely from `left` -- landing the button near the pill's LEFT
 * edge, overlapping the placeholder text, instead of Figma's right-aligned
 * icon (Input Field #34097:269430, icon is the last flex child, inset from
 * the pill's own 16px right padding). Overridden to `left: auto; right:
 * 8px` so `right` actually takes effect. (2) the icon itself was FiboSearch's
 * own default magnifier glyph, not Figma's extracted icon (heroicons-outline/
 * magnifying-glass, node #I34097:269430;29049:58896, 20x20) -- swapped via
 * the same mask-image technique already used for the account/wishlist/cart
 * icons elsewhere in this file: the plugin's own `<svg><path>` markup stays
 * in the DOM (keeps the click target and the plugin's own JS bindings)
 * but is hidden, and the real shape is painted via `mask-image` with
 * `background-color: currentColor`.
 */
#header [data-id="search"] .dgwt-wcas-search-submit {
	top: 50%;
	bottom: auto;
	left: auto;
	right: 8px;
	transform: translateY( -50% );
}

#header [data-id="search"] .dgwt-wcas-ico-magnifier {
	width: 20px;
	height: 20px;
	/* editor-friendly-ok: same exemption as the file docblock.
	   CORRECTION (independent audit, 2026-09-04): Figma's own extracted stroke color for
	   this icon, #9CA3AF, measures 2.54:1 against this pill's #FFFFFF background (WCAG
	   relative-luminance formula) -- below the 3:1 non-text/UI-component floor, and a
	   real regression: before this fix the icon had no color override and inherited
	   FiboSearch's own dark default (~8.9:1). Bonza carries a contractual WCAG 2.2 AA
	   guarantee, so darkened to #6B7280 (4.84:1, passes comfortably), the closest muted
	   gray to Figma's intent that clears the floor -- same design language, corrected
	   for accessibility the same way this file already treats every other color pairing
	   with a measured ratio in its own comment. */
	color: #6B7280; /* 4.84:1 on #FFFFFF, WCAG-corrected from Figma's own #9CA3AF (2.54:1, fails 3:1 floor) */
	background-color: currentColor;
	-webkit-mask-image: url( '../assets/header-icons/header-search-magnifier.svg' );
	mask-image: url( '../assets/header-icons/header-search-magnifier.svg' );
	-webkit-mask-size: contain;
	mask-size: contain;
	-webkit-mask-repeat: no-repeat;
	mask-repeat: no-repeat;
	-webkit-mask-position: center;
	mask-position: center;
}

#header [data-id="search"] .dgwt-wcas-ico-magnifier path {
	display: none;
}

/* editor-friendly-ok: same exemption as the file docblock.
 * FIX (client-reported, 2026-09-04): Figma's search container (#34097:269421)
 * has a vertical divider line between the search field and the account/
 * wishlist/cart icon group (#34097:269448, 1px stroke #D1D5DB, 12px vertical
 * inset each side) that this build never added -- there is no Blocksy
 * Customizer control for inserting arbitrary chrome between native header
 * items, so this is added as a CSS-only pseudo-element on the account icon's
 * own wrapper rather than new markup, matching the "config exhausted first"
 * note in this file's own docblock.
 *
 * Same fix also corrects the icon-row GAPS to Figma's own row gap (16px,
 * container #34097:269421's own flex `gap`), confirmed live via
 * getBoundingClientRect() to be Blocksy's generic 20px default (each item
 * carries its own `margin-left/right: 10px`, not a flex `gap` on the shared
 * ancestor, confirmed via getComputedStyle() walking the DOM chain -- so
 * these margins are overridden directly rather than fighting a `gap`
 * property that isn't actually there). Search-to-account totals 33px
 * (16px row gap + ~1px divider line + 16px row gap, matching the Figma
 * divider frame's own two-sided inset); account-to-wishlist and wishlist-
 * to-cart both total Figma's flat 16px row gap.
 * SUPERSEDED (2026-09-09): the "16+1+16=33" breakdown above stopped being
 * true once the Fable 5.1 audit below moved the divider's own `left`
 * offset without recomputing this total -- see the 2026-09-09 correction
 * on `.ct-header-account` further down (now 43px, not 33px).
 */
#header .dgwt-wcas-search-wrapp {
	margin-right: 0 !important; /* FiboSearch's own inline style sets this on the element itself, needs !important to win */
}

/* editor-friendly-ok: same exemption as the file docblock.
 * CORRECTION (client-reported, 2026-09-04, live re-check post-deploy): the search-to-
 * account gap measured 43px live, not the intended 33px. Root cause, confirmed via
 * getComputedStyle(): Blocksy's own 10px margin-right lives on the `[data-id="search"]`
 * PARENT wrapper, a SEPARATE element from `.dgwt-wcas-search-wrapp` above (which was
 * already correctly zeroed) -- so the parent's own 10px was still leaking through on
 * top of the intended 33px. Zeroed here too.
 */
#header [data-id="search"] {
	margin-right: 0;
}

/* editor-friendly-ok: same exemption as the file docblock.
 * CORRECTION (Fable 5.1 audit, 2026-09-07): Figma's icon "Container" nodes
 * (#34097:269449/451/453) are 44x44 touch-target boxes with a 16px flex
 * `gap` BETWEEN the boxes -- since each glyph sits centered inside its own
 * 44x44 box (not flush to the box edge), the visible glyph-to-glyph
 * distance is larger than the raw 16px container gap. The original fix
 * applied 16px directly between the raw glyphs (Blocksy renders bare
 * glyphs, no 44x44 box markup), measuring ~20px tighter than Figma's
 * visual result. Audit-measured Figma glyph-to-glyph targets: divider to
 * account ~27px (was 17px), account to wishlist ~36px (was 16px),
 * wishlist to cart ~33px (was 16px); divider height 20px (was 24px, the
 * 44px box height minus 12px inset each side per the divider frame's own
 * spec). Search-to-divider spacing is left as-is (not flagged by the
 * audit as wrong).
 * CORRECTION (client-reported, 2026-09-09, live re-check): "search-to-
 * divider spacing left as-is" above was itself the bug -- this rule's
 * `margin-left` (the FULL search-to-account distance) was left at the
 * pre-audit total of 33px while `::before`'s `left` offset below was
 * moved to -27px to fix the divider-to-account distance, so the leftover
 * (33-27=6px) became the search-to-divider gap by accident, never
 * actually measured. Re-pulled the real Desktop Container (#34097:269421,
 * `gap:16` between [search Input Field]/[divider frame]/[icon group],
 * confirmed via get_figma_data): the divider frame (#34097:269447) is
 * itself zero-width (hug sizing, 0px side padding, its only child a
 * 0-width stroked LINE), so it contributes nothing to layout -- the
 * search-to-divider gap IS the container's raw 16px gap, not whatever
 * margin-left happens to leave over after the divider-to-account half is
 * set. Client's own side-by-side screenshot confirms: live's search pill
 * sits noticeably closer to the divider than Figma's. Fixed by growing
 * margin-left to 43px (16px search-to-divider + the already-correct 27px
 * divider-to-account); `::before`'s `left:-27px` is untouched since that
 * half was already right.
 */
#header .ct-header-account {
	position: relative;
	margin-left: 43px;
	margin-right: 0;
}

#header .ct-header-account::before {
	content: "";
	position: absolute;
	left: -27px;
	top: 50%;
	transform: translateY( -50% );
	width: 1px;
	height: 20px;
	background-color: #D1D5DB; /* contrast-exempt: decorative divider line, reuses this file's existing #D1D5DB border color already used for the search input border */
}

#header .ct-header-wishlist {
	margin-left: 36px;
	margin-right: 0;
}

#header .ct-header-cart {
	margin-left: 33px;
}

/* editor-friendly-ok: same exemption as the file docblock.
 * CORRECTION (independent audit, 2026-09-04): the four rules above were unscoped to
 * any breakpoint, so they also applied inside the existing `@media (max-width: 599px)`
 * block below (line 353), on top of that block's own compact mobile layout -- adding
 * 33/16/16px of extra margin plus a new divider line into a row this task's earlier
 * fix (PR #702) had to specifically rescue from viewport overflow (the plugin's own
 * 230px search-wrap floor pushing content off-screen). Reset at the same breakpoint so
 * the desktop gap/divider fix does not regress the mobile fix it sits beside. Figma's
 * own mobile HEADER is a separate full-screen search panel component (14061:188816),
 * already documented elsewhere in this file as out of scope, so there is no Figma
 * mobile gap value to match here -- reverting to Blocksy's own default spacing is the
 * correct "leave mobile alone" choice, not a guess.
 * CORRECTION (Fable 5.1 audit, 2026-09-07): this reasoning is now stale --
 * this task's own later item-3 work (below) pulled the real Mobile
 * HEADER Figma variant and found a real 6px icon-gap value, so "no Figma
 * mobile gap value to match" is no longer true. Updated 10px -> 6px.
 * (The later `@media (max-width: 1099px)` block below sets 12px for
 * TABLET and, being later in source order, was winning at mobile widths
 * too despite this block -- confirmed live by the audit. The mobile-
 * specific override further down this file, in the item-6 section, is
 * what actually makes 6px win at mobile widths; this block is updated
 * too so it no longer contradicts that value if read in isolation.)
 */
@media ( max-width: 599px ) {
	#header .ct-header-account {
		margin-left: 6px;
	}

	#header .ct-header-account::before {
		display: none;
	}

	#header .ct-header-wishlist,
	#header .ct-header-cart {
		margin-left: 6px;
	}
}

/* editor-friendly-ok: same exemption as the file docblock.
 * FIX (CU-86eypb6ab QA round, 2026-09-07, items 3+4+6): the desktop divider
 * and icon-gap rules above (`.ct-header-account`/`::before` -- see the
 * 2026-09-09 correction on that rule for its current value) are NOT
 * scoped away from tablet width -- only the <=599px block above resets
 * them, leaving the full 600-991px tablet range with the DESKTOP divider
 * and gaps leaking in. Confirmed live via getComputedStyle() at 768px:
 * `.ct-header-account` margin-left 33px and its `::before` divider both
 * still applied, exactly the desktop values. Re-pulled the real Tablet
 * HEADER component (#20168:148733 -> `Content` #20168:148754 -> icon
 * `Container` #34374:77384): gap 12px between account/wishlist/cart, and
 * NO divider line node at all in that Container's children (Figma's
 * tablet icon group has never had one -- this was always a desktop-only
 * element leaking down, not a regression). Mobile's own icon Container
 * (#29180:61967, Mobile HEADER #20168:149054) is tighter still: gap 6px,
 * also no divider.
 *
 * Search width (item 4): Tablet's search Input Field (#34374:77672) is
 * `sizing.horizontal:fill` inside the row's own `gap:24` flex ("Content"
 * #20168:148755, row: logo+trigger group, search, icon group), i.e. it
 * is meant to flex to fill the remaining row width, not stay pinned to
 * FiboSearch's own unscoped `.dgwt-wcas-search-wrapp{min-width:230px}`
 * default -- confirmed live via getBoundingClientRect() the input renders
 * at a fixed 253px regardless of the ~350px+ of actual free row width at
 * 768px. `flex:1 1 auto` on the search wrapper plus `width:100%` on its
 * inner form/pill lets it actually grow to fill, same technique already
 * used for the mobile full-width search row below.
 *
 * This tablet block intentionally does NOT touch search PLACEMENT (item
 * 6) -- Tablet's own Figma variant keeps search INLINE in the icon row
 * (`Content` #20168:148755 has search as the middle of 3 hug/fill-width
 * flex children, same row as logo/trigger/icons), unlike Mobile's variant
 * which moves search to its own row below (see the mobile block further
 * down). Item 6's Figma citation (#34685:55738) pointed at a decoy
 * "STICKY" frame with no real header content -- the real Mobile variant
 * is #20168:149054 (found via the HEADER component-set's own children),
 * confirmed by download+visual match against the client's own reference
 * screenshots for this item.
 * CORRECTION (Fable 5.1 audit, 2026-09-07): moved 991px -> 1099px, same
 * Blocksy real-breakpoint correction as the item-1 grid fix above.
 * CORRECTION (client re-report, 2026-09-08, live re-check): flat 12px on
 * every icon was still wrong -- it treated Figma's `gap:12` as the whole
 * visual gap between icon GLYPHS, but that 12px is the flex-gap between
 * the icon Container's three 44x44 hit-target boxes (`layout_2726fe94` on
 * each "ICONS" instance #34374:77390/77391/77392), not between the glyphs
 * themselves. Each glyph sits centered inside its own 44x44 box, so the
 * true visual gap is 12px PLUS both boxes' own centering insets. Exported
 * the real Tablet Content row (#20168:148755) as a PNG and measured glyph
 * ink columns directly: search-to-account ~35px, account-to-wishlist 32px,
 * wishlist-to-cart ~32.5px -- nowhere near the flat 12px this rule shipped.
 * The search-to-account gap is further off because that boundary crosses
 * the OUTER row's own `gap:24` (between [logo group]/[search]/[icon
 * Container], see item-4 note above), not the icon Container's inner
 * `gap:12` -- a second, larger gap this rule never accounted for.
 * Recomputed each margin as (row-or-icon-gap) + (this element's own
 * 44px-box inset) + (previous element's own 44px-box inset), using this
 * file's already-audited icon dimensions (22.5x25.5 account, 25.5x23.54
 * wishlist, 22.12x25.14 cart, all half-inset within a 44px box):
 * account = 24 + (44-22.5)/2 = 34.75px; wishlist = 12 + (44-22.5)/2 +
 * (44-25.5)/2 = 32px; cart = 12 + (44-25.5)/2 + (44-22.12)/2 = 32.19px.
 * The "ICONS" component set (#20027:86445) has no Hover/Focus/Active/
 * Disabled variants -- it is a size/kind icon library (KIND=USER/WISHLIST/
 * CART x Size=24/44), so there is no interactive state this spacing-only
 * change could regress. Mobile's own icon Container (#29180:61967) uses
 * the identical 44x44-box pattern with `gap:6`, so it likely has the same
 * class of bug -- out of scope here (not what was reported this round),
 * left as a known follow-up.
 */
@media (max-width: 1439px) {
	#header .ct-header-account {
		margin-left: 34.75px;
	}

	#header .ct-header-account::before {
		display: none; /* Figma tablet/mobile icon groups have no divider node -- desktop-only */
	}

	#header .ct-header-wishlist {
		margin-left: 32px;
	}

	#header .ct-header-cart {
		margin-left: 32.19px;
	}

	/* CORRECTION (Fable 5.1 audit, 2026-09-07): `flex:1 1 auto` on the search
	   element only controls flex distribution INSIDE the `[data-column="end"]`
	   flex row -- it does not touch the outer `.ct-container` GRID's own
	   division between the `start` (logo+trigger) and `end` (search+icons)
	   columns. Confirmed live: Blocksy sizes that grid as two content-based
	   tracks (measured 266.5px / 424.7px at 768px), leaving a ~75.5px dead
	   gap between the hamburger and the search pill that no amount of
	   flexing inside the end column can reach. `auto minmax(0, 1fr)` lets
	   the end column's track itself claim the row's actual remaining width,
	   same fix pattern as the desktop `.ct-container` grid above. */
	#header [data-row="middle"] .ct-container {
		grid-template-columns: auto minmax(0, 1fr) !important;
	}

	#header [data-row="middle"] [data-column="end"] [data-id="search"] {
		flex: 1 1 auto;
		min-width: 0;
	}

	#header [data-row="middle"] [data-column="end"] [data-id="search"] .dgwt-wcas-search-wrapp,
	#header [data-row="middle"] [data-column="end"] [data-id="search"] .dgwt-wcas-sf-wrapp,
	#header [data-row="middle"] [data-column="end"] [data-id="search"] .dgwt-wcas-search-form {
		width: 100%;
		min-width: 0;
	}
}

/* editor-friendly-ok: same exemption as the file docblock.
   HD-06 (86eypb6ab, 86eyv0k44 parity audit round 2, runs/verify-Header-2.json):
   the tablet card (`[data-row="middle"]`) measured 80px live vs Figma's
   tablet Content band 23310-35540/34374-81059 (696x98 = Content 696x64 +
   nav Container 696x34, the nav-strip half is HD-06's other fix above).
   Scoped to 600-1099px, but that is NOT the site's own mobile/tablet visual
   switch: this element's flat mobile-bar chrome (margin/radius/shadow
   zeroed, see the FIX comment above this block) flips at `max-width:767px`,
   not 600px, and mobile's absolutely-positioned search row (reserving
   extra height via `.ct-container`'s own padding-bottom:62px) is scoped to
   `max-width:599px` only. So 600-767px carries the flat mobile-bar chrome
   (pre-existing site behavior, unrelated to this PR) with this rule's fixed
   64px height layered on top, in normal (non-absolute) flow -- checked the
   arithmetic for that range: the tallest child there (this file's own 49px
   HD-03 search input plus the 44px HD-08/HD-09 hit-boxes) fits inside 64px
   with no content clipped. 1099px keeps this aligned with the pre-existing
   tablet/desktop DOM-branch switch (see the FIX comment above this block).
   box-sizing:border-box keeps 64px an outer total, matching how the audit
   measures the card element itself. */
@media (min-width: 600px) and (max-width: 1439px) {
	#header [data-row="middle"] {
		box-sizing: border-box;
		height: 64px;
	}

	/* editor-friendly-ok: same exemption as the file docblock.
	 * FIX (CU-86eypb6ab QA round, 2026-09-17, items 1+3 -- "second row
	 * padding: reduce top/bottom to hug content, pull the exact value from
	 * Figma dev-mode" / "confirm if the 20px L-R padding applies at all
	 * breakpoints or desktop only"): re-pulled the real Tablet Content card
	 * node (#20168:148754, inside the Tablet HEADER component #23310:35540
	 * -> #20168:148734 -> #34374:78999 -> #34374:81059) directly from this
	 * task's own Figma export: padding 8px top/bottom, 16px left/right, h=64
	 * -- NOT the desktop card's 16px/20px (HD-05, the `@media (min-width:
	 * 1100px)` block above). This box previously carried NO explicit padding
	 * of its own at this breakpoint (only the height fix above), so `.ct-
	 * container`'s inset here was whatever Blocksy's own unvendored default
	 * produced -- confirmed live via the parity-measure tool at 768px:
	 * `.ct-container` sat 14px in from the card's own edge, 2px short of
	 * Figma's 16px, not the exact match this task's "don't eyeball it"
	 * instruction requires. Answers item 3 definitively: the desktop 20px
	 * value is desktop-only, tablet is a smaller and differently-shaped
	 * 8px/16px, confirmed via direct node inspection, not assumed.
	 */
	/* FIX (86eypb6ab, visual audit, 2026-09-18 -- tablet half of the header
	   card overflow, same root symptom as HD-05's desktop fix above): a
	   THIRD stylesheet, not this repo's `custom/` tree and not Blocksy core --
	   `wp-content/themes/blocksy-child/assets/css/components/header.css`
	   (confirmed live by walking `document.styleSheets` and testing
	   `.matches()`, not guessed) -- ships
	   `[data-device="mobile"] > [data-row="middle"] > .ct-container
	   { min-height: 80px !important; grid-template-rows: 80px !important; }`
	   at `(min-width:690px) and (max-width:1080px)`, fighting this same
	   block's own 64px `[data-row="middle"]` height (8px+8px padding below
	   leaves 48px of content box). Measured live at 768px before this fix:
	   card 52-116px (64 tall), `.ct-container` 52-148px (96 tall) -- a 32px
	   overflow, with the account/wishlist/cart icons rendering 4-6px past
	   the card's own bottom edge and visibly clipped where the tablet/mobile
	   nav strip (`.bhnv-bar`, appended right after `#header` in normal flow,
	   see this file's own docblock) paints over that overflow -- confirmed
	   by cropping and zooming a real screenshot, not inferred from the
	   numbers alone. `!important` here is required to match the external
	   rule's own importance level; `#header [data-row="middle"] .ct-container`
	   still wins on specificity regardless of load order (an ID beats that
	   rule's three attribute/class selectors), verified live via CSS
	   injection before writing: `.ct-container` drops to exactly 64px,
	   flush with the card, no more clipped icons. 48px = this same block's
	   64px card height minus its own 16px (8+8) vertical padding, the same
	   "outer height minus this rule's own padding" arithmetic HD-05 already
	   uses for the desktop card two breakpoints up. `grid-template-rows`
	   is reset alongside `min-height` because the external rule sets both --
	   leaving the row-track override in place would have kept forcing 80px
	   of grid track height even with `min-height` corrected.
	   Config-first note: this external stylesheet is not tracked in the
	   `bc-site-customizations` monorepo (outside `custom/`) and this task's
	   file ownership does not cover it -- flagged to the session lead as the
	   file/selector/value to fix at the source (or retire, if it is dead
	   code the config side no longer needs) rather than edited directly. */
	#header [data-row="middle"] .ct-container {
		padding: 8px 16px;
		min-height: 48px !important;
		grid-template-rows: 48px !important;
	}
}

/* editor-friendly-ok: same exemption as the file docblock.
 * FIX (CU-86eypb6ab QA round, 2026-09-07, item 6): Mobile's own Figma
 * variant (#20168:149054) does NOT put search inline with the icon row at
 * all -- confirmed via get_figma_data: row 1 (`Content` #29180:61947) is
 * logo+trigger and the account/wishlist/cart icon Container ONLY (gap
 * 6px between icons, no search, no divider); a SEPARATE row 2 (`Content`
 * #29180:61975, padding "0px 16px 6px") holds just the fill-width search
 * Input Field. The pre-existing mobile CSS (this file, the sr-only /
 * 44px-icon-trigger block just above) approximated "no room for a full
 * search box" by shrinking FiboSearch's own input to a compact trigger
 * icon inline with the icons -- reasonable before this task had the real
 * Mobile Figma variant to check against, but not what Figma actually
 * specifies: a full pill, in its own row, not a trigger icon in the icon
 * row. Overrides that block for mobile: the search wrapper is pulled out
 * of normal flow (`position:absolute`) and anchored to the bottom of the
 * row via reserved `padding-bottom` on `.ct-container` -- a pure-CSS way
 * to place it "below" its DOM siblings (it is nested two levels inside
 * the icon row's own `[data-column="end"]`, not a direct sibling of the
 * row, so it cannot be reflowed onto a second row with `flex-wrap` alone).
 * `#header [data-row="middle"]` already carries the card's own white
 * `rgba(255,255,255,.95)` background at every breakpoint (confirmed live),
 * so the reserved padding-bottom area is not a bare gap onto the page's
 * cream body background -- it reads as part of the same white card.
 * CORRECTION (Fable 5.1 audit, 2026-09-07): the mobile icon gap (account/
 * wishlist/cart) measured 12px live, not the 6px Figma spec documented
 * above -- this block's own `@media (max-width:599px)` matches the
 * TABLET block's `@media (max-width:1099px)` two sections up, and since
 * that tablet block comes LATER in source order with equal specificity,
 * its 12px was winning at mobile widths too. Repeating the override here
 * (this block is later still) makes 6px win definitively regardless of
 * source-order position elsewhere in the file.
 * CORRECTION (client-reported, 2026-09-08): this repeat-override only listed
 * `.ct-header-wishlist`/`.ct-header-cart`, missing `.ct-header-account` --
 * confirmed live via getComputedStyle() at 425px that account's margin-left
 * was still 12px (the tablet block's value) while wishlist/cart correctly
 * read 6px. Added account here too, same reasoning as above.
 */
@media (max-width: 599px) {
	#header .ct-header-account {
		margin-left: 6px;
	}

	/* editor-friendly-ok: same exemption as the file docblock.
	 * FIX (CU-86eypb6ab QA round, 2026-09-17, item 7 -- "mobile icon gaps
	 * (person/heart/bag) don't match Figma spacing token, currently wider/
	 * inconsistent"): the flat 6px this rule used to give wishlist and cart
	 * is the same class of bug the tablet icon-gap CORRECTION two sections
	 * above already caught and fixed for THAT breakpoint, left as an
	 * explicitly-flagged follow-up for mobile at the time ("Mobile's own
	 * icon Container uses the identical 44x44-box pattern with gap:6, so it
	 * likely has the same class of bug -- out of scope here"). Re-pulled the
	 * real Mobile icon Container (#29180:61967, Mobile HEADER #23313:52675
	 * -> #29180:61947 -> #29180:61948 -> #29180:61967) directly this round:
	 * three real 44x44 "ICONS" instances at x=4172/4222/4272 (50px apart,
	 * i.e. exactly the Container's own 44px box width plus its 6px flex
	 * `gap`), confirming Figma's 6px is a box-to-box gap, not a glyph-to-
	 * glyph one -- same pattern as the tablet fix, just not yet applied here.
	 * Since account/wishlist here render as bare glyph-sized boxes (22.5x25.5
	 * / 25.5x23.54, no 44x44 wrapper -- confirmed live, unlike cart, which
	 * already has its own 44x44 `.ct-icon-container` from an earlier fix),
	 * the true visible gap is 6px plus each neighbor's own half-inset within
	 * its notional 44px box, same formula as the tablet CORRECTION:
	 * wishlist = 6 + (44-22.5)/2 + (44-25.5)/2 = 26px (was 6px);
	 * cart = 6 + (44-25.5)/2 + (44-22.11)/2 = 26.2px (was 6px).
	 * `.ct-header-account`'s own margin-left is untouched -- it sets this
	 * icon GROUP's offset from the preceding logo/trigger group (a different,
	 * outer flex distance), not an icon-to-icon gap, so it is not part of
	 * this specific bug.
	 */
	#header .ct-header-wishlist {
		margin-left: 26px;
	}

	#header .ct-header-cart {
		margin-left: 26.2px;
	}

	#header [data-row="middle"] {
		position: relative; /* CORRECTION (client-reported, 2026-09-09): CSS positions an absolutely-positioned
		descendant's `left`/`right` offsets from its containing block's PADDING edge, not its border edge -- see
		the `[data-id="search"]` rule below. `.ct-container` was the containing block, and measured live via
		decoded pixel analysis of a real screenshot: the search pill's inset at 425px was ~44px on both sides,
		not the intended 16px, consistent with SOME non-zero padding on `.ct-container` stacking additively on
		top of this rule's own 16px offset. CORRECTION (independent audit, 2026-09-09): an earlier version of
		this comment cited "steps that padding down to 24px at <=991px, 16px at <=767px" as `.ct-container`'s own
		padding -- that citation is wrong, it describes header-utility-bar.css's `.bhu-bar` element, a different
		element entirely, and even its current (updated) values don't fully account for the measured ~44px (a
		4-12px residual is unexplained). `.ct-container`'s real padding is Blocksy core CSS, not vendored in this
		repo, so its exact value is not verified here. What IS verified: `[data-row="middle"]` carries no padding
		anywhere in this file (only margin/background/radius/shadow, zeroed at this breakpoint by the mobile
		full-width fix above), so anchoring to it instead removes `.ct-container`'s padding -- whatever its real
		value is -- from the equation entirely, which is correct regardless of the exact number. */
	}

	#header [data-row="middle"] .ct-container {
		padding-bottom: 50px; /* 86eypb6ab QA round 3: was 62px. Figma Mobile HEADER search row = 44px input + 6px bottom padding (#29180:61975) */ /* reserves room for the absolutely-positioned search row below -- unrelated to
		which ancestor is the positioning anchor (see `[data-row="middle"]` above), this just gives `.ct-container`
		enough height in normal flow so the search row's absolute box doesn't overlap the nav-links row below it. */
		/* editor-friendly-ok: same exemption as the file docblock.
		 * FIX (CU-86eypb6ab QA round, 2026-09-17, items 1+3): the icon row's own
		 * horizontal inset was this same unverified Blocksy default the comment
		 * above already flags -- confirmed live via the parity-measure tool at
		 * 375px: `.ct-container` sat 23px in from the (edge-to-edge, zero-margin)
		 * mobile card, not Figma's 16px (Mobile HEADER icon-row Content node
		 * #29180:61947, 16px left/right padding, no explicit top/bottom -- hug).
		 * Does not touch the search row below, which already anchors to
		 * `[data-row="middle"]` directly, bypassing `.ct-container` entirely (see
		 * the 2026-09-09 correction above), so this padding cannot double up on
		 * the search pill's own already-correct 16px inset the way adding padding
		 * to `[data-row="middle"]` itself would have.
		 */
		padding-left: 16px;
		padding-right: 16px;
	}

	#header [data-row="middle"] [data-column="end"] [data-items="primary"] {
		position: static; /* the search child below needs to anchor to #header [data-row="middle"] (2026-09-09
		correction above), not this flex row */
	}

	#header [data-row="middle"] [data-column="end"] [data-id="search"] {
		position: absolute;
		left: 16px;
		right: 16px;
		bottom: 6px; /* 86eypb6ab QA round 3: was 8px, Figma search row bottom padding is 6px (#29180:61975) */
		width: auto;
		flex: none;
		margin: 0; /* CORRECTION (Fable 5.1 audit, 2026-09-07): Blocksy's own 10px margin-left on this element survived the absolute positioning (absolute elements are still subject to margin), pushing the pill 10px off-center from its intended 16px/16px left/right insets -- confirmed live. */
	}

	#header [data-row="middle"] [data-column="end"] [data-id="search"] .dgwt-wcas-search-wrapp,
	#header [data-row="middle"] [data-column="end"] [data-id="search"] .dgwt-wcas-sf-wrapp,
	#header [data-row="middle"] [data-column="end"] [data-id="search"] .dgwt-wcas-search-form {
		position: static;
		width: 100%;
		min-width: 0;
		max-width: none;
	}

	/* Undo the pre-Figma compact-trigger-icon approach this file used before
	   the real Mobile variant was available -- restores the real text input
	   (still screen-reader-first per this file's own existing pattern, but
	   full width, matching Figma, not sr-only/1px). */
	/* editor-friendly-ok: same exemption as the file docblock.
	   HD-04 (86eypb6ab, 86eyv0k44 parity audit round 2, runs/verify-Header-2.json):
	   this selector's own extra ancestors already out-specificity the base
	   >=768px rule above (now 49px, HD-03), so it always needed its own
	   explicit value -- `height: auto` let padding/line-height math land
	   at 50px live vs Figma's mobile Input Field 34374-82585 (396x44).
	   box-sizing: border-box + an explicit 44px pins the real box exactly,
	   same idiom as HD-03. Colors on this rule are pre-existing/unchanged --
	   see the base rule above for their measured 15.6:1 ratio. */
	#header [data-row="middle"] [data-column="end"] [data-id="search"] .dgwt-wcas-search-input {
		position: static;
		width: 100%;
		box-sizing: border-box;
		height: 44px;
		padding: 12px 48px 12px 16px;
		margin: 0;
		overflow: visible;
		clip: auto;
		white-space: normal;
		background-color: #FFFFFF;
		border: 1px solid #D1D5DB;
		border-radius: 9999px;
		color: #2E2A2A;
		/* editor-friendly-ok: same exemption as the file docblock. FIX (CU-86eypb6ab
		   QA round, 2026-09-17, item 5): same Nominee fix as the base rule above
		   -- see that rule's own comment for the Figma-vs-ticket discrepancy this
		   was built to (ticket says Nominee, Figma's own text node says Kobe1.1;
		   built to the ticket per the session lead's direction). Restated here
		   since this mobile-scoped selector already re-declares every other
		   property in full rather than relying on the base rule's cascade,
		   matching this file's own established convention. */
		font-family: var( --wp--preset--font-family--bhp-heading, "Nominee", var( --theme-font-family, sans-serif ) ); /* --theme-headings-font-family tier removed: defined nowhere in any deployed stylesheet (hover-type-contract.md typography section), was a dead fallback link */
	}

	#header [data-row="middle"] [data-column="end"] [data-id="search"] .dgwt-wcas-search-submit {
		position: absolute;
		top: 50%;
		bottom: auto;
		left: auto;
		right: 8px;
		transform: translateY(-50%);
		width: 20px;
		height: 20px;
		display: block;
		background-color: transparent;
		border: none;
	}

	#header [data-row="middle"] [data-column="end"] [data-id="search"] .dgwt-wcas-ico-magnifier {
		width: 20px;
		height: 20px;
		color: #6B7280; /* 4.84:1 on #FFFFFF, same WCAG-corrected pairing as the desktop search icon */
	}
}

/* editor-friendly-ok: same exemption as the file docblock.
 * SUPERSEDED (CU-86eypb6ab QA round, 2026-09-07): this block used to shrink
 * FiboSearch's own mobile input down to a compact 44px trigger icon inline
 * with the account/wishlist/cart icons, an approximation made before this
 * task had the real Mobile HEADER Figma variant to check against. Now that
 * #20168:149054 confirms search is a full-width pill in its OWN row below
 * the icon row (not inline, not a trigger icon), that approach is fully
 * replaced by the mobile search block earlier in this file (search item 6)
 * -- removed here rather than left dead, since both blocks targeted the
 * same elements at the same breakpoint and the later one in source order
 * would otherwise silently win regardless of which was intended.
 */

/* editor-friendly-ok: same exemption as the file docblock.
 * FIX (CU-86eypb6ab QA round, 2026-09-07): corrected to the real Mobile
 * HEADER Figma variant (#20168:149054, logo node #34374:82548, 97.8x24) --
 * the previous 96x23.56 value was a live-measured containment fix made
 * before this task had that variant to check against (close, but not the
 * literal Figma value). Height ratio re-derived the same way the previous
 * fix already did (96 * 40/163 -> 23.56); this round's own math is
 * 97.8 * 40/163 = 24, which is also Figma's own literal height for this
 * node -- consistent, not a coincidence.
 */
@media (max-width: 599px) {
	#header .site-branding[data-id="logo"] .site-logo-container,
	#header .site-branding[data-id="logo"] img {
		width: 97.8px;
		height: 24px;
	}
}

/* editor-friendly-ok: same exemption as the file docblock.
 * FIX (client-reported, 2026-09-04): the cart total ("£0.00") rendered in
 * Blocksy's default blue-grey (#3A4F66, confirmed live via
 * getComputedStyle() on `.woocommerce-Price-amount` and its nested
 * `.woocommerce-Price-currencySymbol` span, both carrying the color
 * directly, not just inherited), the same un-branded default the nav-link
 * and search-field fixes elsewhere in this file already correct. Set to
 * Bonza ink #2E2A2A (14.18:1 on the white header row, already measured
 * above for the same color on the same background).
 */
.ct-header-cart .woocommerce-Price-amount,
.ct-header-cart .woocommerce-Price-amount * {
	color: #2E2A2A; /* 14.18:1 on #FFFFFF */
}

/* editor-friendly-ok: same exemption as the file docblock.
 * FIX (CU-86eypb6ab QA round, 2026-09-07, item 5): tablet/mobile-only
 * primary-nav row (`bonza_header_tablet_mobile_nav_render()`, custom.php,
 * hooked `blocksy:header:after`). `display:none` by default (desktop
 * already has its own nav inline in row 2's `.ct-container`, styled
 * above) -- shown only below 991px, matching Figma's Tablet (#20168:
 * 148733 -> `Container` #34374:78674, padding "8px 0px", gap 16px, bg
 * #F8EDE3) and Mobile (#20168:149054 -> `Container` #34374:82784,
 * padding "8px 20px", gap 16px, same bg) HEADER variants.
 *
 * Positioning: `[data-row="middle"]` (the tablet/mobile header card) is
 * a floating rounded card with its own `rgba(255,255,255,.95)`
 * background, 16px radius and `0px 2px 42px 0px rgba(0,0,0,0.1)` shadow
 * (header-navigation.css, shared base rule at the top of this file) and
 * `margin: 16px <inset> 0` (no bottom margin -- confirmed live via
 * getComputedStyle()). Hooking `blocksy:header:after` renders this nav
 * immediately following that card with zero gap by default, so a
 * negative margin was not needed to pull it flush -- matching the
 * client's own reference screenshot (Image #6), where the nav sits
 * directly attached to the card's bottom edge. Same horizontal inset as
 * the card (24px tablet / 16px mobile, mirroring the card's own
 * breakpoint values above) and a matching `border-radius: 0 0 16px 16px`
 * so the two elements read as one continuous rounded shape. The client's
 * reference (Image #6) shows the SAME drop shadow this design system
 * already uses for every floating card in this file (0px 2px 42px 0px
 * rgba(0,0,0,0.1), the "Header" effect, reused verbatim here rather than
 * approximated) sitting below the joined card+nav shape -- applied here
 * since this nav is now the bottom-most element of that shape.
 * CORRECTION (Fable 5.1 audit, 2026-09-07): moved 991px -> 1099px -- this
 * exact rule was the audit's "992-1099px: no nav at all" finding, since
 * Blocksy's real header switch on this site is 1100px, not 991/992. Same
 * correction as the item-1 grid fix earlier in this file.
 */
.bhnv-bar {
	display: none;
}

/* editor-friendly-ok: same exemption as the file docblock.
 * FIX (client-reported, 2026-09-08): the bottom-left/right corners of the
 * header shape (this nav row's own rounded bottom corners, `border-radius: 0
 * 0 16px 16px` below) showed a mismatched near-white notch instead of
 * continuing the cream `#F8EDE3` background. Root cause, confirmed live via
 * getComputedStyle(): `.bhnv-bar` is appended via the `blocksy:header:after`
 * hook, landing as a DIRECT CHILD of `#main-container` (the page's own
 * full-height content wrapper, background transparent) -- NOT inside
 * `#header` itself, whose own `background-color: #F8EDE3` (top of this
 * file) therefore does not extend behind this row at all. Wherever this
 * row's own border-radius clips its corners, the page's near-white body
 * background (`rgb(250,251,252)`) shows through instead of cream. Confirmed
 * shadow effect (`box-shadow` below) was already correct and live-verified
 * -- not touched by this fix.
 * CORRECTION (client-reported, 2026-09-08, live re-check): the first
 * attempt used an UNROUNDED `::before` sized to `.bhnv-bar`'s OWN box
 * (`inset:0`) -- that only reaches the row's own 24px-inset footprint
 * (left:24/right:744 at 768px, confirmed via getBoundingClientRect()), not
 * the wider gap BETWEEN that inset row and the actual viewport edges
 * (x:0-24 and x:744-768), which is where the visible gray strip actually
 * was -- `#header` itself stops at y:128 (the card's own bottom edge), so
 * that side strip next to the nav row was ALSO showing the page's
 * near-white body background, same root cause, different area.
 * SECOND CORRECTION (independent audit, 2026-09-08): the immediately-prior
 * fix widened `::before` to `left/right:-24px` but kept `bottom:0`, on the
 * mistaken assumption that `.bhnv-bar`'s own `border-radius` would clip
 * this pseudo-element to match -- it does not. `border-radius` only
 * shapes an element's OWN background/border paint; it does not clip
 * descendants (including pseudo-elements) unless the element also has
 * `overflow: hidden` (which `.bhnv-bar` does not, and adding it here would
 * also clip away the `-24px` side extension this fix needs, since a
 * negative offset only escapes the padding box when overflow allows it).
 * With `bottom:0`, the unrounded `::before` painted a flat cream rectangle
 * across the FULL width for the row's full height, including underneath
 * the row's own bottom-corner arcs -- the exact same "corners look square"
 * regression as the first attempt, just now also covering the side gaps
 * too. Fixed by stopping the fill 16px short of the row's true bottom
 * (`bottom: 16px`, matching the radius value) instead of `bottom:0` -- it
 * still fills the side gaps for the row's full height minus the corner
 * band, but leaves the actual 16px arc band untouched, so `.bhnv-bar`'s
 * own rounded corners paint there with nothing behind them, correctly
 * revealing the page below (the only place the rounding is meant to be
 * visible). Live-verified via elementFromPoint()/getComputedStyle()
 * sampling down both the side-gap (x=10) and near-edge (x=35) columns at
 * 768px: cream from the row's top to bottom-minus-16px, `.bhnv-bar` itself
 * (not `::before`) for the last 16px band, then real page content below --
 * confirming the fill stops exactly where the arc begins. */
/* editor-friendly-ok: same exemption as the file docblock -- Blocksy
   header-builder markup appended via blocksy:header:after, not a WP block. */
@media (max-width: 1439px) {
	.bhnv-bar {
		/* HD-06 (86eypb6ab, 86eyv0k44 parity audit round 2, runs/verify-Header-2.json)
		   CORRECTS a false fix from HD-02: HD-02 pinned this nav strip to 44px
		   citing a live 42.4px/Figma-44px reading at 375 (mobile) -- but this
		   `@media (max-width:1099px)` block covers TABLET too, and Figma's
		   tablet Frame 2147229969 (23310-35540/34374-81059, 696x98 = Content
		   696x64 + nav Container 696x34) specifies 34px for the tablet nav
		   strip, not 44. 44px is correct ONLY at mobile (Figma mobile nav
		   Container 428x44) -- that value is restored as a mobile-only
		   override in the @media(max-width:599px) block further down, so
		   this default (tablet) value and that override (mobile) are each
		   scoped to their own real breakpoint instead of sharing one number.
		   min-height (not a fixed height, so the row can still grow if
		   content ever wraps) pins the box, same idiom as .bhu-bar's own
		   min-height fix. `.bhnv-bar__list`'s own align-items:center
		   (below) keeps the link row vertically centered once this stretches
		   the box's cross-axis. */
		min-height: 34px;
		display: flex;
		justify-content: center;
		margin: 0 24px;
		background-color: #F8EDE3;
		border-radius: 0 0 16px 16px;
		box-shadow: 0px 2px 42px 0px rgba(0, 0, 0, 0.1);
		/* editor-friendly-ok: same exemption as the file docblock.
		 * FIX (CU-86eypb6ab QA round, 2026-09-17, item 2): once `#header` (the
		 * floating card above this strip) went sticky (see the top-of-file FIX
		 * for the full reasoning), this row -- a separate sibling appended via
		 * `blocksy:header:after`, visually fused to the card's bottom edge by
		 * its own rounded-top-corner-free shape and shared shadow -- needed the
		 * same treatment, or it would simply scroll normally underneath the now-
		 * fixed card and vanish the instant the page scrolls, breaking the
		 * "one continuous shape" this file's own docblock already establishes.
		 * `top` is this same breakpoint's own `#header` rendered height (16px
		 * margin-top + 64px fixed card height = 80px at 768-1099px, confirmed
		 * live via the parity-measure tool), not a guess -- narrower breakpoints
		 * override it below where the card's own margin/height change. */
		position: sticky;
		top: calc(80px + var(--bhu-pin, 0px));
		/* CORRECTION (pre-deploy injection verify, 2026-09-17): the pre-existing
		 * `z-index: 1` was fine while this row was in normal flow (nothing else
		 * on the page shares its stacking level at that position), but once it
		 * went sticky it stays on-screen while the rest of the page scrolls
		 * underneath it -- and this exact site has a hero-section image,
		 * `.hb-hero__wave` (`position:relative; z-index:1`), that ties this
		 * value exactly. Z-index ties resolve by DOCUMENT ORDER, and the hero
		 * section is later in the DOM than `.bhnv-bar`, so once the two
		 * happened to occupy the same screen pixels (confirmed live by
		 * injecting this exact CSS into the page, scrolling, and reading
		 * `document.elementFromPoint()` at the nav strip's own screen
		 * coordinates: it returned the wave `<img>`, not the nav or its
		 * links, even though the links themselves measured `visibility:
		 * visible; opacity:1` in the DOM) the later-painted wave image
		 * covered the nav text completely. Raised to comfortably clear
		 * ordinary page content (matches `#header`'s own sticky z-index of
		 * 100, defined at the top of this file, since the two rows never
		 * occupy the same pixels and any value that beats page content is
		 * equally correct -- reusing 100 avoids inventing a third number). */
		z-index: 100;
	}

	.bhnv-bar::before {
		content: "";
		position: absolute;
		top: 0;
		bottom: 16px; /* stops short of the row's own 16px border-radius so the arc paints unobstructed -- editor-friendly-ok: same exemption as the file docblock. */
		left: 0;
		right: 0;
		background-color: #F8EDE3; /* contrast-exempt: decorative fill matching the row's own background, no text */
		z-index: -1;
	}

	.bhnv-bar__list {
		display: flex;
		flex-direction: row;
		align-items: center;
		justify-content: center;
		gap: 16px;
		padding: 5px 0; /* 24px link target + 2x5px = Figma tablet strip 34px */
		margin: 0;
		list-style: none;
		line-height: 16px; /* the inherited 26.4px body line-height made each <li> 26.4px tall, inflating the strip to 42.4px */
	}

	/* editor-friendly-ok: same exemption as the file docblock.
	   CORRECTION (Fable 5.1 audit, 2026-09-07): `var(--theme-headings-font-family,
	   sans-serif)` resolved to a DIFFERENT font than the desktop nav (`#header-menu-1
	   .ct-menu-link`), which deliberately set no font-family at all so it inherited
	   Blocksy's own body-font chain (see CHANGELOG.md's session recording this
	   correction for the historical exemption text this described) --
	   the two navs rendered in visibly different typefaces. Removed the explicit
	   declaration so this nav inherited the exact same chain as the desktop one.
	   FIX (CU-86eyv2c1y): both navs now declare Nominee explicitly (see the
	   desktop rule and updated docblock above), so this correction's original
	   concern -- the two navs diverging -- is addressed by keeping them in sync
	   with the same explicit font-family rather than the same fallback chain. */
	.bhnv-bar__link {
		display: inline-block;
		font-family: var( --wp--preset--font-family--bhp-heading, "Nominee", var( --theme-font-family, sans-serif ) ); /* --theme-headings-font-family tier removed: defined nowhere in any deployed stylesheet (hover-type-contract.md typography section), was a dead fallback link */
		font-weight: 900;
		font-size: 12px;
		line-height: 16px;
		padding: 4px 0; /* WCAG 2.5.8: 16px text + 8px = 24px minimum target */
		letter-spacing: 0.02em;
		text-transform: uppercase;
		color: #2E2A2A; /* 14.18:1 on #F8EDE3 */
		text-decoration: none;
		white-space: nowrap; /* Figma's Mobile nav frame (#34374:82784) is `overflowScroll:["x"]` -- single-line, scrolls rather than wraps */
	}

	.bhnv-bar__link:hover {
		/* source:FIGMA (partial) -- same Link "Main, State=Hover" delta as the desktop nav
		   above (dark -> #FFA825 on text + underline). NOT implemented: #FFA825 on this
		   row's #F8EDE3 background computes to 1.67:1, fails WCAG 2.2 AA 4.5:1/3:1. Same
		   NEEDS HUMAN flag as the desktop rule; underline-only until design confirms a
		   compliant hover color. */
		text-decoration: underline;
	}

	.bhnv-bar .current-menu-item > .bhnv-bar__link,
	.bhnv-bar .current_page_item > .bhnv-bar__link {
		box-shadow: inset 0 -2px 0 0 #FFA825; /* same Figma Link "Main, State=Active" indicator as the desktop nav */
	}
}

/* editor-friendly-ok: same exemption as the file docblock.
 * Blocksy's real mobile/desktop header switch on this site is 1080/1081px,
 * not 1099/1100 (measured live: the hamburger is gone and `#header-menu-1`
 * is 86px wide from 1081px). Between 1081 and 1099px the desktop header
 * was therefore showing the tablet nav strip AND the desktop nav together,
 * on a card inset 24px instead of the desktop 64px. The strip is hidden
 * and the desktop card chrome restored for that band. */
@media (min-width: 1440px) {
	/* 86eypb6ab r4 (Vita: header "not responsive", 1083px): the 3-column desktop grid
	   above starts at 1100px, but the desktop DOM (logo | nav | search+icons) is live from
	   1081px, so 1081-1099 got the 2-column tablet grid (max-width:1099 block) and the
	   third child wrapped onto a second row under the card. Same grid from 1081. */
	#header [data-row="middle"] .ct-container {
		grid-template-columns: auto minmax(0, 1fr) auto !important;
	}

	.bhnv-bar {
		display: none;
	}

	#header [data-row="middle"] {
		margin: 16px 64px 0;
		border-radius: 16px;
	}
}

/* editor-friendly-ok: same exemption as the file docblock.
 * CORRECTION (independent audit on the mobile-full-width fix above,
 * 2026-09-08): that fix zeroed the CARD's margin/radius/shadow at
 * max-width:767px, but this nav row (the card's own bottom-most
 * continuation, see the item-5 comment above) kept its 16px inset plus
 * the 1099px block's radius/shadow at that same width -- card and nav
 * ended up misaligned (card edge-to-edge, nav still inset), and neither
 * matches Figma's Mobile nav-links row (#34374:82784, `sizing.horizontal:
 * fill`, no inset/radius/shadow) confirmed earlier for the card fix.
 * Mirrors the card's own max-width:767px treatment here so the two stay
 * one continuous full-width shape at every width where the card changes. */
@media (max-width: 767px) {
	.bhnv-bar {
		margin: 0;
		border-radius: 0;
		box-shadow: none;
		/* editor-friendly-ok: same exemption as the file docblock.
		 * FIX (CU-86eypb6ab QA round, 2026-09-17, item 2): `#header`'s own
		 * margin-top zeroes at this same breakpoint (the mobile full-width card
		 * fix above), dropping its rendered height from 80px to 64px (0 margin +
		 * the still-active 64px card height from the max-width:1099px rule
		 * this file already applies down to 0px, not just 768-1099 -- see
		 * that rule's own comment) -- this strip's own sticky `top` (also set
		 * on that same max-width:1099px rule, which is why `position:sticky`
		 * itself does not need restating here, only the narrower `top` value)
		 * has to track the card's real height at this width or it would sit
		 * 16px too low, opening a gap between the stuck card and this stuck
		 * strip. `top` overridden here rather than left to cascade, since
		 * 600-767px genuinely renders the card at 64px, not 80px.
		 */
		top: calc(64px + var(--bhu-pin, 0px));
	}
}

@media (max-width: 599px) {
	/* editor-friendly-ok: same exemption as the file docblock.
	   HD-06 (86eypb6ab, 86eyv0k44 parity audit round 2): restores the real
	   mobile nav-strip height (Figma mobile nav Container 428x44) that the
	   tablet-scoped default above (@media max-width:1099px) now correctly
	   sets to 34px instead -- see that rule's own HD-06 comment for the
	   tablet/mobile split. Later in source order than that block, so this
	   wins definitively at mobile widths regardless of source-order
	   position elsewhere in the file (same pattern this file already uses
	   for the icon-gap mobile overrides above). */
	.bhnv-bar {
		min-height: 44px;
		/* editor-friendly-ok: same exemption as the file docblock.
		 * FIX (CU-86eypb6ab QA round, 2026-09-17, item 2): `#header`'s own
		 * rendered height at true mobile is 112px (0 margin + the icon row's own
		 * content height plus the 62px reserved for the absolutely-positioned
		 * search row below it, confirmed live via the parity-measure tool at
		 * 320/375px), not the 64/80px used at wider breakpoints above -- this
		 * strip's sticky `top` has to track that so it stays flush under the
		 * stuck card instead of opening a gap or overlapping it. `position:
		 * sticky` itself already cascades from the max-width:1099px rule this
		 * block sits inside (0-1099px, not just tablet), so only `top` needs
		 * restating here.
		 */
		top: calc(96px + var(--bhu-pin, 0px)); /* 86eypb6ab QA round 3: header is 96px at mobile now (Figma icon row 46 + search row 50), was 112px */
	}

	/* editor-friendly-ok: same exemption as the file docblock.
	   CORRECTION (Fable 5.1 audit, 2026-09-07): "Health hub for dogs" wrapped
	   to 2 lines at 390px and 4 lines at 320px (a visible glitch the audit
	   caught) -- Figma's own Mobile nav frame (#34374:82784) is
	   `overflowScroll:["x"]`, i.e. single-line with horizontal scroll, not
	   wrap, matching the same pattern already used for the utility bar row
	   above in header-utility-bar.css.
	   HD-07 (86eypb6ab, 86eyv0k44 parity audit round 2, runs/verify-Header-2.json):
	   min-width:0 added -- `.bhnv-bar__list` is a flex item of `.bhnv-bar`
	   (display:flex); without an explicit min-width the browser's flex
	   auto-minimum can still be content-based in some engines even with
	   overflow-x:auto set, letting the row's true content width (which,
	   per the same audit row, exceeds the 320/375px viewports even after
	   the font-size fix below) push the CONTAINING elements wider than the
	   viewport instead of staying inside this scroll region. min-width:0
	   forces this element itself to be the overflow boundary, matching
	   Figma's own `overflowScroll:["x"]` intent: content that doesn't fit
	   scrolls WITHIN this row, it does not widen the page. */
	.bhnv-bar__list {
		padding: 8px 16px;
		gap: 12px; /* 86eypb6ab 9 Oct: with the short label, fits EN in one line from 375px */
		overflow-x: auto;
		flex-wrap: nowrap;
		justify-content: flex-start;
		min-width: 0;
		-webkit-overflow-scrolling: touch;
		scrollbar-width: none;
	}

	/* Centred when the row fits; the auto margins fall to 0 when it scrolls, so the
	   first item is never pushed off the left edge. */
	.bhnv-bar__list > li:first-child {
		margin-left: auto;
	}

	.bhnv-bar__list > li:last-child {
		margin-right: auto;
	}

	/* A row that still scrolls (320px, longer languages) fades at the edge that has
	   more items, so it reads as swipeable rather than cut off. Classes set by
	   navbar-overlay.js. */
	.bhnv-bar__list.is-scrollable:not(.is-at-end) {
		-webkit-mask-image: linear-gradient(to right, #000 calc(100% - 40px), transparent);
		mask-image: linear-gradient(to right, #000 calc(100% - 40px), transparent);
	}

	.bhnv-bar__list.is-scrollable.is-at-end {
		-webkit-mask-image: linear-gradient(to left, #000 calc(100% - 40px), transparent);
		mask-image: linear-gradient(to left, #000 calc(100% - 40px), transparent);
	}

	.bhnv-bar__list::-webkit-scrollbar {
		display: none;
	}

	/* editor-friendly-ok: same exemption as the file docblock.
	   HD-07 (86eypb6ab, 86eyv0k44 parity audit round 2, runs/verify-Header-2.json):
	   measured 12px live vs Figma's Mobile nav Link text (23313-52675/
	   34374-82789..82791, inside Frame 2147230098 388x44) 10px -- every
	   other metric on this link (weight 900, line-height 16px = 1.6 x 10px,
	   letter-spacing 0.02em, uppercase, color) already matched, only the
	   font-size was wrong. Scoped to mobile only -- desktop/tablet nav
	   links are a separate Figma Link component (29093-24719, 12px) and
	   are correctly untouched by this rule. */
	.bhnv-bar__link {
		font-size: 12px; /* WCAG floor 12px (Figma Mobile nav Link 10px), 86eypb6j8 */
	}
}

/* editor-friendly-ok: same exemption as the file docblock (Blocksy's own
   `.ct-dynamic-count-*` badge markup, not block-editor content -- no preset
   color slug applies to a fixed system-UI badge color).

   Header cart/wishlist count badges render Blocksy-default blue, not a Bonza
   choice. Root cause, measured: Blocksy's own rule (themes/blocksy/static/
   bundle/woocommerce.min.css) is `[class*=ct-dynamic-count] { color:
   var(--theme-cart-badge-text, #fff); background: var(--theme-cart-badge-
   background, var(--theme-palette-color-1)) }`. --theme-cart-badge-background
   is defined nowhere on this site, so it falls through to
   --theme-palette-color-1, which here carries two conflicting values (stock
   blue #2872fa and Bonza gold #ffc125) -- the blue is Blocksy leaking
   through. Fighting `background` directly on `.ct-dynamic-count-cart` is the
   wrong move (documented past failure on this codebase -- Blocksy's
   compiled rule wins on specificity/order); setting Blocksy's OWN variable
   here is what cascades into its rule correctly.

   Colour choice: Figma's badge (ICONS > Frame 76, 20x20, cornerRadius 100)
   is not uniformly one colour -- measured across the snapshots, 606
   instances are gold #FFA825 (with cream #F8EDE3 text), 24 are green
   #247B4E (16 cream text, 8 white). Gold dominates, but green is the correct
   pick here: at the badge's rendered 10px text the WCAG threshold is 4.5:1,
   not the 3:1 large-text floor, and gold fails it every way it's paired --
   white text 1.93:1, cream text 1.67:1 (both computed via the WCAG
   relative-luminance formula) -- same as the live blue, white text 4.31:1,
   also failing. Green #247B4E with white text is 5.23:1, passing; green with
   cream as Figma draws it is 4.53:1, passing but only just. Bonza carries a
   contractual WCAG 2.2 AA guarantee, so the passing, real-Figma-variant
   green wins over the more common but failing gold. White text kept
   (5.23:1) over cream (4.53:1) for margin.

   Unscoped to match Blocksy's own selector shape: confirmed live (homepage,
   shop, cart) that only two elements ever carry a class matching
   `ct-dynamic-count` -- `.ct-dynamic-count-cart` and
   `.ct-dynamic-count-wishlist`, both header badges, nothing else on this
   site uses the pattern, so no unwanted counters are in scope. */
[class*="ct-dynamic-count"] {
	--theme-cart-badge-background: #247B4E;
	--theme-cart-badge-text: #FFFFFF;
}


/* ---------------------------------------------------------------------
 * DE nav label "Nahrungsergaenzungsmittel" (CU-86eypb6ab, Vita's approved
 * string). The longer word adds ~55px to the desktop nav. Blocksy folds the
 * whole nav into "More" as soon as the items are wider than the nav column
 * (534-554px on the 1290px container), and at 2560px the 3-item nav no
 * longer fit. Measured live with the long label on /de/: inline at 1600px
 * and up, folded below that, exactly like the short label was.
 * German only (html[lang^="de"]), desktop nav only (>=1100px, where Blocksy
 * shows the desktop row). The mobile/tablet strip is a scroller and is not
 * touched. Tighter link padding and gap and a hair less tracking make the
 * three items ~540px. The "More" dropdown is 200px by default and the long
 * label needs 253px, so its width is raised for German too.
 * --------------------------------------------------------------------- */
@media (min-width: 1440px) {
	html[lang^="de"] #header-menu-1 > ul.menu {
		gap: 2px;
	}

	html[lang^="de"] #header-menu-1 .ct-menu-link {
		padding-inline: 6px;
		letter-spacing: 0.01em;
	}

	html[lang^="de"] #header-menu-1 {
		--dropdown-width: 270px;
	}

	/* French and Spanish folded the whole nav into "More" at 1440 (Figma shows
	   the three items inline). The middle column is 608px; at the default 12px
	   padding, 16px gap and 0.02em tracking the labels need 641px (French) and
	   672px (Spanish). Padding 4px, gap 2px and no tracking brings them to
	   551px and 582px. Dutch fits already and is left alone. */
	html[lang^="fr"] #header-menu-1 > ul.menu,
	html[lang^="es"] #header-menu-1 > ul.menu {
		gap: 2px;
	}

	html[lang^="fr"] #header-menu-1 .ct-menu-link,
	html[lang^="es"] #header-menu-1 .ct-menu-link {
		padding-inline: 4px;
		letter-spacing: 0;
	}
}

/* ==========================================================================
   86eypb6ab header QA round 3 (Vita's "QA header defects" list, items 1, 3, 6b).
   Figma source: HEADER component set 148:18023, Desktop 148:18019, Tablet
   20168:148733, Mobile 20168:149054. Measured on v1 before this block, every
   number below is a live measurement vs a Figma node, not an estimate.

   1. Icon spacing. Figma icon Container boxes are 44px wide with an
      itemSpacing of 16 (desktop), 12 (tablet), 6 (mobile), so centre-to-centre
      pitch is 60 / 56 / 50. Live person-to-heart was already on that pitch,
      heart-to-bag was 67.7 / 67 / 61 because the cart margin counted the bag
      box's own 11px inset twice: the cart link is already a 44px box, the
      earlier margins were worked out as if it were a bare 22px glyph.
      cart margin-left = pitch - heart half-width (12.75) - bag half-box (22).

   2. Row inset. The tablet/mobile .ct-container sits 14-23px inside the row
      (Blocksy container width), and the 16px padding added in the earlier QA
      round stacked on top of it, so the logo sat 30px (tablet) / 39px (mobile)
      from the edge against Figma's 16px. Container now fills the row; its own
      16px padding is the whole inset. Desktop is untouched: Figma Content is
      20px L-R there and live already measured 20px. Answer to item 3: 20px
      is DESKTOP ONLY, tablet and mobile are 16px.

   3. Hamburger sits 10px (mobile) / 12px (tablet) right of the logo, Figma
      Frame 1261154621 itemSpacing. Live was 20px because the logo's 10px
      right margin stacked with the trigger's 10px left margin.
   ========================================================================== */
#header .ct-header-cart {
	margin-left: 25.25px;
}

@media (max-width: 1439px) {
	#header [data-row="middle"] .ct-container {
		width: 100%;
		max-width: none;
		margin-left: 0;
		margin-right: 0;
		box-sizing: border-box;
	}

	#header .ct-header-cart {
		margin-left: 21.25px;
	}

	#header [data-row="middle"] [data-column="start"] .ct-header-trigger {
		margin-left: 2px;
	}
}

@media (max-width: 599px) {
	#header [data-row="middle"] {
		--height: 46px; /* Figma Mobile icon row Content #29180:61947 is 46px tall */
	}

	#header [data-row="middle"] .ct-container {
		min-height: 46px !important;
		grid-template-rows: 46px !important;
	}

	#header .ct-header-cart {
		margin-left: 15.25px;
	}

	#header [data-row="middle"] [data-column="start"] .ct-header-trigger {
		margin-left: 0;
	}
}

/* ==========================================================================
   86eypb6ab: WCAG 2.2 target size (2.5.8) for the account and wishlist links.
   They rendered 22.5x25.5 and 25.5x23.5, under the 24x24 minimum on one axis
   each. Given a 24px minimum box (glyph stays centred, no visual change).
   The account link is 1.5px wider, so the wishlist margin gives back 0.75px
   (centre pitch stays 50 / 56 / 60, Figma icon Container gap 6 / 12 / 16).
   ========================================================================== */
#header .ct-header-account .ct-account-item,
#header .ct-header-wishlist {
	min-width: 24px;
	min-height: 24px;
	box-sizing: border-box;
	flex-shrink: 0;
	justify-content: center;
	align-items: center;
}

#header .ct-header-wishlist {
	margin-left: 35.25px;
}

@media (max-width: 1439px) {
	#header .ct-header-wishlist {
		margin-left: 31.25px;
	}
}

@media (max-width: 599px) {
	#header .ct-header-wishlist {
		margin-left: 25.25px;
	}
}

/* 86eypb6ab: search placeholder per Figma (14px desktop/tablet, 12px mobile, lh 16).
   Placeholder only, so the input keeps 17px and iOS does not zoom on focus. */
#header .dgwt-wcas-search-input::placeholder {
	font-family: var(--wp--preset--font-family--bhp-heading, "Nominee", sans-serif);
	font-size: 14px;
	font-weight: 400; /* Figma placeholder is Regular; FiboSearch default was 300 (Nominee ships a single 900 cut, so no visual change) */
	line-height: 16px;
	text-overflow: ellipsis;
}

/* Figma's desktop field is 284px wide with a 232px text box, narrower than the
   string needs (311px English, 548px German at 14px), so the design itself
   cannot show it whole. Truncate with an ellipsis instead of a hard clip. */
#header .dgwt-wcas-search-input {
	text-overflow: ellipsis;
}

@media (max-width: 599px) {
	#header .dgwt-wcas-search-input::placeholder {
		font-size: 12px;
	}
}

/* 86eypb6ab round 4 (Vita: current page should be a green colour, not an
   underline). Figma MENU Link 29093:24719 has three variants: Default ink,
   Hover #FFA825 text, Selected #247B4E text with its bottom stroke at 0
   opacity. The earlier gold/amber underline read the Hover colour as the
   active state. #247B4E is 5.23:1 on white and 4.6:1 on the strip's #F8EDE3.
   Same token on the desktop nav, the tablet strip, the drawer and the
   utility row's Our Tale trigger when one of its pages is current. */
#header-menu-1 .menu-item.current-menu-item > .ct-menu-link,
#header-menu-1 .menu-item.current_page_item > .ct-menu-link,
#header-menu-1 .menu-item > .ct-menu-link[aria-current],
.bhnv-bar .current-menu-item > .bhnv-bar__link,
.bhnv-bar .current_page_item > .bhnv-bar__link,
.bhnv-bar .bhnv-bar__link[aria-current],
/* G42 (z8udzkgpxc): the strip's markup is li > a[aria-current] > span.bhnv-bar__link,
   so the child combinators above never matched the span that holds the text. */
.bhnv-bar .current-menu-item > a > .bhnv-bar__link,
.bhnv-bar .current_page_item > a > .bhnv-bar__link,
.bhnv-bar a[aria-current] > .bhnv-bar__link {
	box-shadow: none !important;
	color: #247B4E !important;
}

/* editor-friendly-ok: same exemption as the file docblock.
   Hover = the active green (Vita, z8udzke6jk); underline stays as a non-colour
   cue. bhp-green is 5.23:1 on white, 4.6:1 on the strip's #F8EDE3. */
#header-menu-1 .menu-item > .ct-menu-link:hover,
#header-menu-1 .menu-item > .ct-menu-link:focus-visible,
.bhnv-bar .bhnv-bar__link:hover,
.bhnv-bar .bhnv-bar__link:focus-visible {
	color: var( --wp--preset--color--bhp-green, #247B4E ) !important;
}

.bno-drawer__nav-group a[aria-current="page"],
.bhu-disclosure.is-current > .bhu-trigger,
.bhu-disclosure__panel a[aria-current="page"] {
	color: #247B4E;
}

/* Row inset (Vita 9 Sep item 3, "L-R padding on second row: 20px"): Figma's
   1512 frame puts the logo and icons 20px inside the card. Above 1440 the
   inner .ct-container kept Blocksy's 1290px max-width, so the inset grew to
   47px at 1512 and 251px at 1920. 1000-1080: the shared theme's
   components/header.css forces 15px there; Figma tablet is 16px. */
@media (min-width: 1440px) {
	#header [data-row="middle"] > .ct-container {
		max-width: none;
		width: 100%;
	}
}

@media (min-width: 1000px) and (max-width: 1080px) {
	#header [data-row="middle"] > .ct-container {
		padding-left: 16px !important;
		padding-right: 16px !important;
	}
}

/* 86eypb6ab: German nav label cut off at 1440 ("HUNDEGESUNDHEI"). The nav column
   is 1fr beside an auto search column, and the live search field was 349px against
   Figma's 284px (Input Field 34097:269430), so the nav lost 65px: the three German
   items need 540px and the column was 523px, with the last label clipped by the
   nav's overflow hidden. Figma's width gives the nav back its 65px. */
@media (min-width: 1440px) {
	#header [data-id="search"] .dgwt-wcas-search-wrapp {
		width: 284px !important; /* FiboSearch sets its own inline width */
		min-width: 0 !important;
		max-width: 284px;
	}
}

/* 86eypb6ab L1 map: Figma desktop nav Link frames are 44px tall (Container 34097:269287,
   Link 34097:269166 etc., 4px/12px padding, fixed 44px); the live link stretched to the
   49px middle row. Centre the 44px link in the row so the active stroke sits at 44px. */
@media (min-width: 1440px) {
	#header-menu-1 > ul.menu {
		align-items: center;
	}
	#header-menu-1 .ct-menu-link {
		box-sizing: border-box;
		height: 44px;
		display: flex;
		align-items: center;
	}
}

/* editor-friendly-ok: same exemption as the file docblock.
 * 86eypb6ab (Vita, 9 Oct, 1349px: "still not responsive"). The one-row desktop header
 * (logo | nav | search | icons) only fits from 1440px: measured on v1, the last nav label
 * was clipped from 1100px up to 1325px in English, 1375px in German, 1400px in French and
 * 1425px in Spanish and Dutch. Blocksy swaps its desktop and mobile header rows at 1000px
 * and components/header.css keeps the mobile row to 1080px; this keeps the tablet layout
 * (hamburger, search and icons, nav strip below) up to 1439px, so every language fits.
 * The header's own tier rules above moved from 1099/1100px to 1439/1440px with it. */
@media (min-width: 1000px) and (max-width: 1439px) {
	#header [data-device="desktop"] {
		display: none !important;
	}

	#header [data-device="mobile"] {
		display: block !important;
	}

	#offcanvas [data-device="desktop"] {
		display: none !important;
	}

	#offcanvas [data-device="mobile"] {
		display: block !important;
	}
}