/*
 * PDP-008R5: Child-Theme Decision Core Shell Proof (CHILD_THEME_SHELL_FIRST).
 *
 * Places the code-owned Identity / Gallery / Configuration+Purchase regions
 * into the canonical Desktop 46/27/27, Tablet 2-column, Mobile linear
 * layouts, WITHOUT reparenting anything.
 *
 * `add-to-cart-shell.php` wraps `woocommerce_template_single_add_to_cart()`
 * in Flatsome's own `.add-to-cart-container` div (the same wrapper
 * `[ux_product_add_to_cart]` already used, reused here for style
 * consistency) -- so `.pdp-config-purchase-track` (opened/closed by hooks
 * that fire *inside* that call) is actually a grandchild of
 * `.pdp-decision-core`, not a direct child. `display:contents` is applied
 * to `.add-to-cart-container` (Flatsome's own decorative wrapper div, not
 * a native Woo form/table/wrap element) so the track still participates
 * directly in the outer grid -- this is not `form.variations_form`
 * flattening.
 *
 * PDP-008R9 (Defect 1 -- Purchase vertical hole): R8 kept
 * `form.variations_form`'s own box suppressed (`display:contents`) so its
 * native children could be placed directly into the outer track grid, with
 * `.single_variation_wrap` explicitly pinned to the same row as
 * `.pdp-configuration-region`. The owner rejected the result: sharing that
 * row meant `.single_variation_wrap` was stretched (default
 * `align-items:stretch`) to Configuration's height, leaving a large empty
 * hole between the native qty/CTA and the Purchase tail that followed in a
 * later row. `form.variations_form` is a real layout box again here (no
 * `display:contents`). To still let Configuration and Purchase start at
 * the same Y without recreating R8's OWN original defect (a box spanning
 * both outer columns can never share a row with something already
 * occupying one of them), the whole Configuration/Purchase split now
 * happens INSIDE the form -- the form's OWN internal 2-column grid, with
 * `align-items:start` so neither column stretches to match the other's
 * height. `.pdp-configuration-region` now wraps `table.variations` and the
 * Fit-help trigger too (previously only the pre-table content), and the
 * former `.pdp-purchase-region-tail` (Wishlist/Add-on/delivery/payment/
 * meta) is now `.pdp-purchase-region`, rendered *inside*
 * `.single_variation_wrap` directly after the native qty/CTA -- see
 * `pdp-decision-core-boot.php` and `pdp-configuration-fit.php` (the
 * accepted Configuration & Fit module's Availability/Color Family hook
 * moved from `woocommerce_before_add_to_cart_form` to
 * `woocommerce_before_variations_form`, INSIDE the form, for variable
 * products only -- simple products, which have no such hook, are
 * unaffected).
 *
 * Simple products have no `table.variations`/`single_variation_wrap` and
 * no row-sharing conflict, so their composition is unchanged from R7/R8:
 * `.pdp-configuration-region` pre-form, `form.cart:not(.variations_form)`
 * as the whole Purchase region (now itself wrapping a `.pdp-purchase-region`
 * around qty/CTA + tail, for the same natural-height reason).
 *
 * PDP-008R9 (Defect 2 -- Tablet family): the owner's canonical Tablet
 * reference states are authored at 834 (portrait) and 1180 (landscape) --
 * i.e. Tablet family extends past the old 1023.98px cutover. The canonical
 * Desktop Final's own root (`#pdp-root{min-width:1280px}` in
 * "ZIG DESK PDP v1.57 - Final.html") is the real, inspected signal for
 * where Desktop family begins; the canonical Tablet Final carries no such
 * floor. Desktop below therefore starts at 1280px, and Tablet now spans
 * 768-1279.98px, covering both authored states plus the *separate*,
 * pre-existing 1023/1024 Gallery thumbnail-orientation cutover
 * (`pdp-gallery-visual.js` / `single-product.css`, untouched by this task)
 * that now falls inside the Tablet range rather than at its edge.
 *
 * PDP-008R6: a pre-existing, out-of-scope stylesheet (Nickx gallery
 * integration CSS, not a file this task may touch) contains:
 *   .single-product .custom-product-page .row:has(> .col .images.nickx_product_images_with_video)
 *     > .col:has(.images.nickx_product_images_with_video) { flex-basis/max-width: 45.1% ... }
 * Written for the legacy 2-column Row 2 (Gallery got its own dedicated
 * `.col`), this `:has()` selector now also matches the single merged
 * `.col` this task's `.zz-pdp-decision-core-row` uses (it still contains
 * the Nickx gallery markup, just nested one level deeper inside
 * `.pdp-gallery`), incorrectly shrinking the WHOLE Decision Core column
 * (Identity+Gallery+Configuration+Purchase) to ~45%. Overridden here,
 * scoped strictly to this task's own wrapper class, rather than editing
 * the other plugin's stylesheet.
 */

.zz-pdp-decision-core-row > .col {
	flex-basis: 100% !important;
	max-width: 100% !important;
}

.pdp-decision-core {
	display: grid;
	row-gap: 24px;
}

.pdp-decision-core > .pdp-identity {
	grid-column: 1 / -1;
	/* PDP-008R10R1: restores the header->breadcrumb breathing room lost when
	   the Decision Core takeover replaced the legacy UX-Builder row. That
	   row's own column (a real, still-live example on STAGE, the pre-
	   takeover working page) carried a per-instance
	   `#col-<id> > .col-inner { margin-top: 10px }` rule -- confirmed live
	   via matched-CSSOM inspection, not assumed -- which no longer exists
	   for our own plain `.col-inner` (STAGE header-bottom-to-breadcrumb-top
	   measured 10px; DEV measured 0px, i.e. flush against the header,
	   exactly the owner's "stuck directly under the header" report). That
	   10px was a property of the legacy row's own saved settings, not a
	   reusable class, so it is reproduced directly on our own first
	   Decision Core row item rather than restoring UX-Builder content. */
	margin-top: 10px;
}

/* PDP-008R8 (R8-03): `.pdp-identity` is a grid item and therefore
   establishes its own formatting context -- its descendants' margins do
   NOT collapse out through it the way a plain block box's would. The
   accepted Identity Zone module (`.pdp005g-identity`) carries its own
   `margin-bottom: 18px` (an internal trailing-space convention from
   contexts where it is the layout's own spacing owner). Inside this grid
   it instead became 18px of extra, invisible height trapped at the bottom
   of the `.pdp-identity` row, stacking on top of this grid's own 24px
   `row-gap` -- 42px of combined whitespace before Gallery/Configuration/
   Purchase against a measured canonical gap of ~18px (owner-reported
   "excessive gap"). This grid's `row-gap` is the single, sole spacing
   mechanism between rows here, so the nested module's own redundant
   trailing margin is neutralized -- its internal layout/content is
   otherwise untouched. */
.pdp-decision-core > .pdp-identity .pdp005g-identity {
	margin-bottom: 0;
}

/* PDP-008R10R2 (Defect 2 -- Tablet excessive Identity->Decision Core gap):
   the exact same R8-03 problem, for the Tablet-visible sibling shell.
   `.pdp005e-identity` (PDP-005E/F, visible only 550-1279px -- see
   `single-product.css`) carries its own `margin-bottom` (10px at portrait
   550-1023px, 22px at landscape 1024-1279px) as an internal
   trailing-space convention, same as `.pdp005g-identity` above. Inside
   this grid that margin does NOT collapse through the `.pdp-identity`
   grid item, so it stacked on top of this grid's own 24px `row-gap`,
   live-measured via the QA `pdp-tablet-context-geometry` tool as a 34px
   Identity-meta-row-bottom -> Decision-Core-top gap on DEV at 834px vs
   10px on STAGE (the reference, legacy-row page, which owns no such
   grid/row-gap mechanism at all) -- an extra ~24px matching this grid's
   row-gap exactly, confirming it as the double-counted spacing owner.
   `.pdp005d-identity` (Mobile, <550px) and `.pdp005g-identity`
   (Desktop, already neutralized above) are unaffected; each is visible
   at a disjoint width range from this one. Zeroing this makes the grid's
   own 24px row-gap the sole, sole spacing mechanism here too, exactly
   like Desktop already established. */
.pdp-decision-core > .pdp-identity .pdp005e-identity {
	margin-bottom: 0;
}

.pdp-decision-core > .add-to-cart-container {
	display: contents;
}

/* PDP-REG-005: the PDP-008R10 "Ваш вибір" Buy Box shell (selection/guidance
   summary, compact confirmation price, Wishlist relocated inside it) was a
   provisional presentation the owner rejected -- it never existed on
   STAGE, which is the source of truth for Purchase composition. Removed at
   the source (`.pdp-buybox*` rules and the JS that drove them); the
   Wishlist heart mount (`.zigzag-wishlist-pdp`) is unstyled here again --
   its own plugin CSS owns the heart's appearance, same as STAGE. */

/* PDP-REG-006: Purchase controls visual STAGE parity (qty geometry + qty/CTA
   -> Wishlist rhythm). Live-measured on STAGE vs DEV at the same
   product/state across all 6 required widths (1440/1180/834/700/430/390);
   both root causes below were identical at every width.
   ---------------------------------------------------------------------
   ROOT CAUSE 1 (qty looked square/table-like on DEV): STAGE's live-rendered
   `.quantity` wrapper for the native Woo qty stepper carries Flatsome's own
   `form-minimal` class -- measured className on STAGE:
   `ux-quantity quantity buttons_added form-minimal`. Two stylesheets key
   off that class: this child theme's own `global.css`
   (`.ux-quantity.buttons_added.form-minimal` rounded-corner rules, already
   present, just never matching) and Flatsome core's `flatsome.css`
   (`.form-minimal.quantity .qty{border-left:0;border-right:0;
   max-width:2em}`, which removes the doubled vertical border between the
   qty input and its +/- buttons and narrows the input to STAGE's measured
   32px). DEV's equivalently-rendered `.quantity` wrapper for the SAME
   native Woo markup measured `ux-quantity quantity buttons_added` -- no
   `form-minimal` -- at all 6 widths (a template/markup difference upstream
   of CSS, out of this CSS-only task's scope to alter). Reproduced below,
   scoped to `.pdp-decision-core` only, so no other native qty control on
   the site (cart, elsewhere) is touched and no plugin-owned CSS is edited.
   Result after fix matches STAGE's measured qty geometry (outer bbox
   ~80x40, minus/plus corner radii 10/0/0/10 and 0/10/10/0, input 32px, no
   doubled internal borders) at every required width.
   ---------------------------------------------------------------------
   ROOT CAUSE 2 (qty/CTA -> Wishlist gap too tight): STAGE is the legacy
   UX-Builder row, where every content block is separated by an
   intervening empty `<p>` carrying the theme's own default paragraph
   `margin-bottom: 1.3em` (measured live: 20.8px at the page's 16px base
   font-size). Live DOM: qty/CTA row -> empty `<p>` (mb:20.8px) ->
   `.zigzag-wishlist-pdp` (mt:12px); adjacent-sibling margin collapse
   yields exactly the measured 20.8px STAGE gap (max(20.8, 12)). DEV's
   Decision Core purchase region has no such spacer paragraph (that
   markup is legacy UX-Builder content, correctly not reproduced here),
   leaving only the Wishlist plugin's own 12px margin -- measured 12.0px
   on DEV vs 20.8px on STAGE at every width. Reproduced as a plain
   Decision-Core-scoped margin on the mount point; the Wishlist plugin's
   own CSS (`.zigzag-wishlist-pdp` in
   `plugins/zigzag-wishlist/assets/css/control.css`) is untouched, so
   every other placement of the same control (category/listing pages)
   keeps its own unmodified 0.75rem margin. */
.pdp-decision-core .quantity.buttons_added,
.pdp-decision-core .quantity.buttons_added input.qty,
.pdp-decision-core .quantity.buttons_added .minus,
.pdp-decision-core .quantity.buttons_added .plus {
	border-radius: 10px;
}

.pdp-decision-core .quantity.buttons_added .minus {
	border-top-right-radius: 0;
	border-bottom-right-radius: 0;
}

.pdp-decision-core .quantity.buttons_added .plus {
	border-top-left-radius: 0;
	border-bottom-left-radius: 0;
}

.pdp-decision-core .quantity.buttons_added input.qty {
	border-left: 0;
	border-right: 0;
	max-width: 2em;
}

.pdp-decision-core .pdp-purchase-region > .zigzag-wishlist-pdp {
	margin-top: 20.8px;
	margin-bottom: 20.8px;
}

/* PDP-REG-008 (Defect A -- Add-on spacing): live-measured on STAGE vs DEV
   at 1440/834/700/430/390 on the same product/state (SKU 23383, DEV data
   fix already applied so the Add-on card renders). `section.zigzag-
   addon-offers` (`[zigzag_addon_offers placement="product_page"]`, direct
   child of `.pdp-purchase-region`, same tail as Wishlist/Delivery/Payment
   -- see `pdp-decision-core-boot.php`'s `render_purchase_tail()`) measured
   `margin-top:12px` / `margin-bottom:0` at every width on both hosts
   (its own plugin CSS, untouched here). STAGE's next sibling there is
   `.shipping-info-box` (Delivery, `margin-top:0`), and adjacent-sibling
   margin collapse against the Add-on card's own 12px produced a live
   20.797px (~20.8px) STAGE gap -- the SAME already-established 20.8px
   rhythm value this file already uses for the qty/CTA -> Wishlist gap
   above. DEV measured the identical 12px/0 Add-on/Delivery margins but a
   literal 0px gap (fully merged, both cards' borders touching) at
   1440/834/700 -- Delivery has no independent top margin of its own on
   either host, so DEV's Add-on card was simply missing the STAGE-side
   margin that produces the visible separation. Reproduced as a plain
   Decision-Core-scoped margin on the mount point, exactly like the
   Wishlist rule above: the Add-on plugin's own CSS
   (`plugins/zigzag-addon-offers/assets/css/product-page-offers.css`) is
   untouched, so every other placement of the same offer keeps its own
   unmodified margin. Unconditional (no media query): STAGE's 20.8px
   Add-on -> Delivery relationship held at every required width, and this
   card sits in the same single-column Purchase stack at every DEV
   breakpoint (Desktop/Tablet/Mobile alike), so one rule covers all of
   them without inventing a separate value per breakpoint. */
.pdp-decision-core .pdp-purchase-region > section.zigzag-addon-offers {
	margin-bottom: 20.8px;
}

/* ---------------------------------------------------------------- */
/* Desktop: Identity full-span; Gallery 46fr | Configuration+Purchase 27+27fr */
/* ---------------------------------------------------------------- */
@media (min-width: 1280px) {
	.pdp-decision-core {
		/* PDP-008R7: `Nfr` tracks default to a min-content floor, not 0.
		   `minmax(0, Nfr)` removes that floor so the three tracks size by
		   their fr ratio alone (owner-confirmed measured proportions,
		   excluding gaps: 45.68/27.16/27.16 against a 46/27/27 canonical). */
		grid-template-columns: minmax(0, 46fr) minmax(0, 27fr) minmax(0, 27fr);
		column-gap: 32px;
	}

	.pdp-decision-core > .pdp-gallery {
		grid-column: 1;
	}

	.pdp-decision-core > .add-to-cart-container > .pdp-config-purchase-track {
		grid-column: 2 / 4;
		display: grid;
		grid-template-columns: minmax(0, 1fr) minmax(0, 1fr);
		column-gap: 24px;
		align-content: start;
	}

	/* Simple products: no variations table, no config-half split needed
	   inside the form -- the whole (small) form.cart IS the Purchase
	   region; Configuration content for simple products is entirely the
	   pre-form content above (price/availability/color-family), matching
	   this task's "no invented Configuration attributes" requirement.
	   `:not(.variations_form)` is required: WooCommerce's variable-product
	   form carries BOTH `cart` and `variations_form` classes, and an
	   unqualified `form.cart` selector here ties in specificity with (and,
	   by later source order, silently overrode) the `form.variations_form`
	   rule below. */
	.pdp-decision-core > .add-to-cart-container > .pdp-config-purchase-track > .pdp-configuration-region {
		grid-column: 1;
	}

	.pdp-decision-core > .add-to-cart-container > .pdp-config-purchase-track > form.cart:not(.variations_form) {
		grid-column: 2;
	}

	/* PDP-008R9 (Defect 1): `form.variations_form` is a real box again,
	   spanning the whole track -- the ONLY child of `.pdp-config-purchase-track`
	   for variable products, so it can freely take row 1 (nothing else
	   competes for it there). Its OWN internal 2-column grid is where
	   Configuration and Purchase actually split; `align-items: start` is
	   the fix for the owner-reported vertical hole -- without it, the
	   shorter `.single_variation_wrap` would stretch (default
	   `align-items: stretch`) to match the taller `.pdp-configuration-region`
	   in the same row. */
	.pdp-decision-core > .add-to-cart-container > .pdp-config-purchase-track > form.variations_form {
		grid-column: 1 / -1;
		display: grid;
		grid-template-columns: minmax(0, 1fr) minmax(0, 1fr);
		column-gap: 24px;
		align-items: start;
	}

	.pdp-decision-core > .add-to-cart-container > .pdp-config-purchase-track > form.variations_form > .pdp-configuration-region {
		grid-column: 1;
	}

	.pdp-decision-core > .add-to-cart-container > .pdp-config-purchase-track > form.variations_form > .single_variation_wrap {
		grid-column: 2;
	}
}

/* ---------------------------------------------------------------- */
/* Tablet: canonical 2-column -- Gallery | right rail (Config, Purchase) */
/*
 * PDP-REG-001A: PDP-008R10R3 confirmed STAGE (the legacy-row reference
 * page, which owns no Decision Core grid at all) has been two-column,
 * continuously, from 550px upward -- not from 768px as this file
 * previously assumed -- while DEV's own Tablet Identity shell
 * (`.pdp005e-identity`, see the R10R2 comment above) already switches to
 * its Tablet appearance at that same 550px. The old single
 * `768px-1279.98px` two-column block therefore left a real 550px-767.98px
 * band where DEV silently collapsed to Mobile one-column (bare
 * `minmax(0, 1fr)` below) underneath a Tablet-looking Identity, a
 * regression STAGE never had. STAGE's live two-column ratio also isn't
 * uniform across that widened range: ~52/48 from 550-1023px, ~57.7/42.3
 * from 1024-1279px (measured via the QA `pdp-tablet-context-geometry`
 * tool, PDP-008R10R3) -- so the single 50/50 block is now two ratio-
 * matched sub-ranges instead of one. The right-rail structure itself
 * (Gallery col 1 / rail col 2, Configuration then Purchase stacked block-
 * level inside the rail) is unchanged and shared by both -- only the
 * two outer column tracks' fr-ratio and the low end of the range differ.
 * The pre-existing 1023/1024 Gallery thumbnail-orientation cutover
 * (`pdp-gallery-visual.js` / `single-product.css`, untouched by this fix)
 * still lands exactly on this same sub-range boundary.
 */
/* ---------------------------------------------------------------- */
@media (min-width: 550px) and (max-width: 1023.98px) {
	.pdp-decision-core {
		/* STAGE-measured ~52% Gallery / ~48% right rail (PDP-008R10R3). */
		grid-template-columns: minmax(0, 52fr) minmax(0, 48fr);
		column-gap: 24px;
		/* PDP-REG-002: the base rule's 24px `row-gap` (still correct/unchanged
		   for Desktop and Mobile) is the ONLY spacing between the Identity
		   row and the Gallery/right-rail row here (5b36963 already made it
		   the sole mechanism by zeroing `.pdp005e-identity`'s own
		   margin-bottom). But 24px was never the right target for this
		   sub-range: STAGE (the legacy-row reference page, which owns no
		   grid/row-gap at all -- its gap comes entirely from
		   `.pdp005e-identity`'s own original margin-bottom) measures a live
		   10px Identity-meta-row-bottom -> Gallery-frame-top gap at this
		   exact portrait sub-range (verified via the QA
		   `pdp-tablet-context-geometry` tool at 700/834/1023px on both
		   STAGE and DEV), not 24px -- confirmed by the fact that 10px is
		   exactly `.pdp005e-identity`'s own portrait-only margin-bottom
		   override (single-product.css, PDP-006I) that 5b36963 neutralized
		   grid-wide without reintroducing it as this grid's own row-gap.
		   Overriding row-gap here, scoped to this sub-range only, restores
		   that value without touching the base rule Desktop/Mobile share. */
		row-gap: 10px;
	}

	.pdp-decision-core > .pdp-gallery {
		grid-column: 1;
		grid-row: 2 / span 2;
		min-width: 0;
	}

	.pdp-decision-core > .add-to-cart-container > .pdp-config-purchase-track {
		grid-column: 2;
		grid-row: 2;
		min-width: 0;
	}

	/* One bounded right rail, single column: Configuration full width,
	   Purchase directly below -- no Desktop-style internal 2-column split
	   survives here. `form.variations_form` (or `.pdp-configuration-region`
	   + `form.cart:not(.variations_form)` for simple products) are plain
	   block children of the track, so they simply stack top to bottom;
	   `min-width: 0` on each keeps native table/form intrinsic width from
	   expanding the track past the rail's real available width. */
	.pdp-decision-core > .add-to-cart-container > .pdp-config-purchase-track > form.variations_form,
	.pdp-decision-core > .add-to-cart-container > .pdp-config-purchase-track > .pdp-configuration-region,
	.pdp-decision-core > .add-to-cart-container > .pdp-config-purchase-track > form.cart {
		display: block;
		min-width: 0;
	}

	.pdp-decision-core > .add-to-cart-container > .pdp-config-purchase-track table.variations {
		min-width: 0;
	}
}

@media (min-width: 1024px) and (max-width: 1279.98px) {
	.pdp-decision-core {
		/* STAGE-measured ~57.7% Gallery / ~42.3% right rail (PDP-008R10R3). */
		grid-template-columns: minmax(0, 57.7fr) minmax(0, 42.3fr);
		column-gap: 24px;
		/* PDP-REG-002: same root cause as the 550-1023.98px sub-range above,
		   for the landscape sub-range -- STAGE measures a live 22px gap
		   here (via the same QA tool at 1024/1180px on both STAGE and DEV),
		   exactly `.pdp005e-identity`'s own landscape margin-bottom
		   (single-product.css base 550-1279px rule) that 5b36963
		   neutralized grid-wide. Scoped to this sub-range only. */
		row-gap: 22px;
	}

	.pdp-decision-core > .pdp-gallery {
		grid-column: 1;
		grid-row: 2 / span 2;
		min-width: 0;
	}

	.pdp-decision-core > .add-to-cart-container > .pdp-config-purchase-track {
		grid-column: 2;
		grid-row: 2;
		min-width: 0;
	}

	.pdp-decision-core > .add-to-cart-container > .pdp-config-purchase-track > form.variations_form,
	.pdp-decision-core > .add-to-cart-container > .pdp-config-purchase-track > .pdp-configuration-region,
	.pdp-decision-core > .add-to-cart-container > .pdp-config-purchase-track > form.cart {
		display: block;
		min-width: 0;
	}

	.pdp-decision-core > .add-to-cart-container > .pdp-config-purchase-track table.variations {
		min-width: 0;
	}
}

/* ---------------------------------------------------------------- */
/* Mobile: linear -- Identity, Gallery, Price/Availability, Configuration, Purchase */
/*
 * PDP-REG-001A: narrowed from `max-width: 767.98px` to `max-width:
 * 549.98px` -- the true Mobile one-column band ends at 550px on STAGE
 * (see the Tablet comment above); this rule must not fire in the
 * 550px-767.98px band any more, or it would re-collapse the new
 * two-column Tablet rule back to one column there.
 */
@media (max-width: 549.98px) {
	.pdp-decision-core {
		/* PDP-008R8 (R8-04): a bare `1fr` track still carries an implicit
		   `min-width: auto` (min-content) floor, exactly like the Desktop
		   tracks before the R7 `minmax(0, Nfr)` fix (see above). Deeply
		   nested non-wrapping content (native gallery/table markup) pushed
		   this single mobile column's min-content to ~843px -- verified live
		   via `getComputedStyle(...).gridTemplateColumns` -- silently
		   overflowing `.pdp-decision-core`'s own 358px content box while an
		   ancestor's overflow clipping kept `document.documentElement.
		   scrollWidth` looking clean, which is exactly why the prior
		   `MOBILE_NO_OVERFLOW: PASS` (checked only via scrollWidth) was
		   invalid. `minmax(0, 1fr)` removes the floor so the column -- and
		   every child placed in it -- is capped at the real mobile
		   viewport's content width. */
		grid-template-columns: minmax(0, 1fr);
		/* PDP-REG-004 (Mobile Identity->Gallery gap parity): the base rule's
		   24px `row-gap` (still correct/unchanged for Desktop, and for
		   Tablet it is already overridden to 10px/22px by PDP-REG-002) was
		   never the right value below 550px. STAGE (the reference,
		   legacy-row page, which owns no grid/row-gap mechanism at all --
		   same as the Tablet/Desktop reference pages PDP-REG-002 and
		   PDP-008R10R2/R3 already relied on) measures a live 0px gap
		   between `.pdp005d-identity__title` (or the rating row, when a
		   product has one)'s own bottom edge and the Gallery frame's top
		   edge at 390/430/549px on the SAME product/SKU used for the
		   PDP-006H diagnostics, both with no rating data -- confirmed via
		   the frontend-qa Playwright harness, not assumed copied from
		   Tablet. DEV measured a 24px gap at the same widths, exactly this
		   grid's own base `row-gap`, confirming it (not `.pdp005d-identity`
		   itself, which already carries zero bottom padding/margin per
		   PDP-006D/PDP-006H, and not an empty rating wrapper -- this
		   product's rating markup is entirely absent, not present-but-
		   empty) as the double-counted spacing owner here too.
		   `row-gap` is a single grid-wide value, so zeroing it here also
		   removes the OTHER Mobile row boundary this grid has (Gallery ->
		   `.pdp-config-purchase-track`, the Configuration/Purchase track --
		   out of this task's scope and not reported as regressed); that
		   boundary's existing 24px is restored immediately below as the
		   track's own `margin-top` instead, so only the Identity->Gallery
		   boundary actually changes. */
		row-gap: 0;
	}

	.pdp-decision-core > .add-to-cart-container > .pdp-config-purchase-track {
		/* Restores the pre-existing 24px Gallery -> Configuration/Purchase
		   boundary that the `row-gap: 0` override above would otherwise
		   also remove (see comment above) -- out of scope for this task,
		   so left numerically unchanged, just re-owned as this element's
		   own margin instead of the grid's row-gap. */
		margin-top: 24px;
	}

	.pdp-decision-core > .add-to-cart-container > .pdp-config-purchase-track form.variations_form {
		display: block;
	}
}

/* PDP-REG-008 (Defect B -- Size-help spacing on Tablet/Mobile): the
   pre-existing [zsg] "size help" trigger row (`.zz-pdp-config-fithelp`,
   the styled `Не знаєте розмір? Допоможемо вибрати` link -- owner's task
   description "Допомога з вибором розміру" -- its own presentation is
   from `plugins/zigzag-custom/assets/css/pdp-configuration-fit.css`,
   untouched here) is the LAST child of `.pdp-configuration-region`. Below
   the 1280px Desktop cutover, Configuration and Purchase are not two
   side-by-side columns (see the Tablet/Mobile rules above) -- they stack
   in one column, so `.zz-pdp-config-fithelp`'s own bottom edge sits
   directly above the Purchase region's first content, the native qty/CTA
   row. Live-measured at 834/700/430/390 on DEV (STAGE has no equivalent
   component here to compare 1:1 against -- its own [zsg] trigger is the
   legacy pre-table position near price/availability, structurally
   unrelated to this Decision-Core-only stacking boundary, per this task's
   "use nearest equivalent, don't force an exact STAGE pixel value"
   guidance): `.zz-pdp-config-fithelp` carries no `margin-bottom` of its
   own, and the only space before the native qty/CTA row is WooCommerce's
   own empty `.woocommerce-variation.single_variation` box, a fixed
   16px-tall native element (confirmed via computed layout, not a margin
   that can collapse away) -- a bare 16px, reading as the size-help row
   sitting directly on top of qty/CTA. Adding 8px of margin-bottom here
   brings the total to 24px, the SAME rhythm value this exact region
   already uses one step earlier (`table.variations` -> Size-help itself
   is already a live-measured 20px at these widths, and Configuration's
   own `table.variations { margin-top: 24px }` below 1000px in
   `pdp-configuration-fit.css`) -- not a new/arbitrary number. Scoped to
   `.pdp-decision-core .pdp-configuration-region` (not a bare
   `.zz-pdp-config-fithelp` selector) so this never touches the same
   trigger's other, unrelated placement on `.custom-product-page`
   elsewhere on the same product page, and to `max-width: 1279.98px` --
   this file's own Desktop cutover -- so Desktop (where Configuration and
   Purchase are side-by-side columns and this trigger is nowhere near
   qty/CTA) is untouched. */
@media (max-width: 1279.98px) {
	.pdp-decision-core .pdp-configuration-region .zz-pdp-config-fithelp {
		margin-bottom: 8px;
	}
}

/* PDP-011B: Mobile-only correction. The 8px value above was sized for the
   PRE-Buy-Box-card architecture (PDP-REG-008 own comment: ".zz-pdp-config-
   fithelp's own bottom edge sits directly above ... the native qty/CTA
   row"), when the only thing between Size Help and native qty/CTA was a
   bare 16px-tall empty `.woocommerce-variation.single_variation` box.
   PDP-011A later wrapped that same seam in a full presentational
   `.zz-buybox` card (plugins/zigzag-custom/assets/css/pdp-buybox-v2.css),
   which opens immediately after Size Help with no margin/padding of its
   own -- confirmed live: the actual Size-Help -> Buy-Box gap was still
   exactly the 8px above, not the ~26px canonical PurchaseSurface2 target
   (canonical breaks that 26px down as `Purchase section padding-top: 16px`
   + `PurchaseSurface2 margin-top: 10px`, i.e. two separate boxes). A
   companion `.zz-buybox { margin-top: 10px }` rule was tried first to
   mirror that split literally, but `.zz-buybox` is the first in-flow child
   of `.single_variation_wrap` (no own top border/padding), so its
   margin-top collapsed with this same margin-bottom instead of adding to
   it (measured live: max(a,b), not a+b). `.zz-pdp-config-fithelp` is the
   sole confirmed owner of this seam, so the full 26px target is expressed
   here as one value rather than split across a margin pair that collapses.
   Scoped to <=549.98px only -- Tablet (550-1279.98px) keeps the existing
   8px above untouched; this task's scope is Mobile-only. */
@media (max-width: 549.98px) {
	.pdp-decision-core .pdp-configuration-region .zz-pdp-config-fithelp {
		margin-bottom: 26px;
	}
}

/* PDP-011B-R1: Tablet-scope seam correction. Canonical Tablet does NOT
   reuse the Mobile 26px Size-Help -> Buy-Box rule (per
   pdp-tab-app-v1.8.jsx / TabDecisionCore18: a 22px flex gap between the
   Configuration rail and Purchase58/PurchaseSurface2, not the Mobile
   single-column margin split) -- live-measured on the real fixture at
   834/1180, the general <=1279.98px 8px rule above (still correct/
   untouched for Desktop-adjacent legacy reasons) was 14px short of the
   canonical ~22px Tablet target. Scoped to exactly the Tablet range
   (550-1279.98px) so Mobile (already 26px via the more specific query
   above) and Desktop (>=1280px, side-by-side columns, this trigger is
   nowhere near qty/CTA) are both untouched.

   Also corrects `.zz-pdp-config-fithelp`'s own margin-top: plugins/
   zigzag-custom/assets/css/pdp-configuration-fit.css reduces it from the
   canonical 20px (last variation row -> Size Help, required by this same
   task for Tablet) to 14px inside its own `@media (min-width: 1000px)`
   block -- that threshold was written for true Desktop "scale c" density
   (see that file's own "6. Desktop only (>=1000px)" comment) but this
   component's real Desktop cutover is >=1280px (this file's own,
   pdp-configuration-fit.css's later Desktop rules, and pdp-buybox-v2.css
   all agree on 1280px), so it wrongly also caught Tablet Landscape
   (1024-1279.98px) -- live-measured 14px there instead of ~20px.
   Re-asserted at 20px here for the Tablet range: this selector
   (`.pdp-decision-core .pdp-configuration-region .zz-pdp-config-fithelp`,
   specificity 0,0,3,0) already wins over pdp-configuration-fit.css's bare
   `.zz-pdp-config-fithelp` (0,0,1,0) regardless of stylesheet load order,
   so this is a single-file correction and does not require also editing
   pdp-configuration-fit.css. */
@media (min-width: 550px) and (max-width: 1279.98px) {
	.pdp-decision-core .pdp-configuration-region .zz-pdp-config-fithelp {
		margin-top: 20px;
		margin-bottom: 22px;
	}
}