/**
 * Harvest — Buttons (C8).
 *
 * One button system, two surfaces: the theme's own `.hrv-btn*` classes (used by
 * Harvest templates) AND Magento core button classes (`.action.primary`,
 * `.action.tocart`, `.action.secondary`, and the generic `button`/`.action`)
 * so real catalog / cart / checkout pages get the Harvest look without touching
 * core templates. All colour comes from --hrv-* tokens (palette + dark safe).
 *
 * Comp reference: solid accent fill / white text / 8px radius (primary),
 * transparent + accent border (secondary), 13–14px, weight 600.
 */

/* SPECIFICITY REPAIR — Blank was winning the corner radius.
   Magento Blank's `styles-m.css` carries `a.action.primary { border-radius: 3px }` at
   (0,2,1). The theme's own `.action.primary` below is (0,2,0), so on any button that
   happens to be an <a> Blank won and the theme's radius never applied. S7 caught it on
   T2: the hero CTA "Shop the season" rendered at 3px beside three "Add to Cart"
   buttons at 14px — same colour, same height, two different corner shapes on one page.
   This is the same (0,2,1)-beats-(0,2,0) class that beat the theme on `width` on Home,
   where `float` in the SAME declaration block won and the block read as fully applied.
   A DECLARATION BLOCK IS NOT AN ALL-OR-NOTHING UNIT.
   Adding the element qualifier makes the theme's own selector (0,2,1) and puts it
   after Blank in source order, so it wins on both counts rather than relying on either.

   NOT CHANGED HERE, deliberately: the comp specifies a 999px pill for these CTAs
   (12 pill declarations against 9 at 14px, so the artboard genuinely mixes the two).
   Choosing WHICH buttons become pills is a theme-wide design decision affecting every
   one of the 434 pages, and I am not making it inside a T2 fix. This change restores
   the radius the theme already declares; the pill question is filed separately. */
.hrv-btn,
a.hrv-btn,
.action.primary,
a.action.primary,
.action.tocart,
a.action.tocart,
.action.submit,
.action.submit.primary,
.action.select,
.action.secondary,
a.action.secondary,
button.action-primary,
.actions-toolbar .action.primary,
.actions-toolbar a.action.primary,
  /* N-16: enumerated from the SERVED Blank sheets rather than patched one at a time as each
     page review surfaced one. These are the Blank/Luma button rules that set border-radius
     and outrank the theme block above:
       styles-l.css  .block.newsletter .action.subscribe            (0,3,0)  <- N-16, global footer
       styles-m.css  .cart.table-wrapper .actions-toolbar > .action (0,4,0)
       styles-m.css  a.pagebuilder-button-primary / -secondary      (0,1,1)
       styles-m.css  .minicart-wrapper .action.showcart .counter.qty(0,4,0)  (a badge, not a button)
     Two instances had already been found by two reviews of ONE page, which is the signal to
     enumerate rather than keep repairing. The theme block now names them. */
.block.newsletter .action.subscribe,
.cart.table-wrapper .actions-toolbar > .action,
a.pagebuilder-button-primary,
a.pagebuilder-button-secondary {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  gap: 8px;
  font-family: var(--hrv-font-body);
  font-size: 14px;
  font-weight: 600;
  line-height: 1.2;
  padding: 13px 28px;
  border-radius: var(--hrv-radius-md);
  border: 1px solid transparent;
  cursor: pointer;
  text-align: center;
  text-decoration: none;
  transition: background-color 0.15s ease, border-color 0.15s ease, color 0.15s ease;
}

/* Primary — solid accent. */
.hrv-btn,
.hrv-btn--primary,
.action.primary,
.action.tocart,
.action.submit,
.action.submit.primary,
.action.select,
button.action-primary,
.actions-toolbar .action.primary {
  background: var(--hrv-accent);
  border-color: var(--hrv-accent);
  color: var(--hrv-accent-text);
}
.hrv-btn:hover,
.hrv-btn--primary:hover,
.action.primary:hover,
.action.tocart:hover,
.action.submit:hover,
.action.submit.primary:hover,
.action.select:hover,
button.action-primary:hover,
.actions-toolbar .action.primary:hover {
  background: var(--hrv-accent-hover);
  border-color: var(--hrv-accent-hover);
  color: var(--hrv-accent-text);
}

/* Secondary — outline.
   ------------------------------------------------------------------------------
   `a.action.secondary` IS LOAD-BEARING HERE. Do not "tidy" it away as a duplicate of
   the line above it.

   THE BUG IT FIXES. The base rule at the top of this file lists BOTH `.action.secondary`
   and `a.action.secondary` and sets the SHORTHAND `border: 1px solid transparent`. This
   rule used to list only `.action.secondary`. On an <a> that is:
       base    a.action.secondary  (0,2,1)  border-color: transparent   <- won
       colour  .action.secondary   (0,2,0)  border-color: accent
   so every anchor-based secondary button in the theme had a fully transparent border.
   `background` and `color` still landed, because the base rule never sets those — which
   is exactly why the control looked ALMOST right (accent label, correct padding, correct
   box) and survived every review: the outline is the only thing missing, and no
   measurement of the properties this rule was thought to own would show it.
   This is the same (0,2,1)-beats-(0,2,0) trap the docblock at the top of this file
   describes for `border-radius`, recurring on a different property, and it is the third
   time on this theme. A DECLARATION BLOCK IS NOT AN ALL-OR-NOTHING UNIT.

   MEASURED, not reasoned (render-rig `__hrvSecondarySelfTest`, live at 1440): injecting
   an <a> and a <button> carrying identical classes returned borderColor
   `rgba(0, 0, 0, 0)` for the anchor and `rgb(192, 138, 45)` for the button on the same
   page. The <button> was never affected — nothing in the base rule is element-qualified
   for it — which is why the repair is the `a.` qualifier and not a specificity bump.

   THE HOVER RULE BELOW IS DELIBERATELY NOT QUALIFIED. It sets only `background` and
   `color`, and the base rule sets neither, so it is uncontested on anchors already.
   Verified on the live cascade with forced :hover (render-rig `--hover`), reading AFTER
   the 150ms transition above has settled — read during it, computed style returns the
   interpolation's first frame and the tint looks like `oklab(0 0 0 / 0)`, i.e. a
   convincing false report of a transparent hover background. Adding `a.` there would be
   a no-op today, and a no-op selector is a claim that something was needed.
   Border-colour on hover is inherited from THIS rule, so fixing it here fixes both states.

   WIDTH STAYS 1px, AGAINST A COMP THAT SAYS 1.5px. The Wheat artboards draw the outlined
   secondary as `border: 1.5px solid var(--ac)`. Rendered, that is the SAME LINE: Chrome
   floors a fractional border-width to whole device pixels, so at DPR 1 the comp's own
   declared 1.5px computes to 1px — measured on the artboard itself, with a declared 2px
   control alongside it that computed to 2px, so the probe demonstrably distinguishes
   widths. The only place 1.5px would differ is HiDPI, where nothing here is reviewed, and
   taking it would split the shared button base into a 1px primary and a fractional
   secondary. The pill radius (999px vs 14px) and the 15px/700 type are the same class of
   theme-wide artboard question this file's top docblock already files for separate design
   resolution; the width joins them rather than being settled inside a bug fix. */
.hrv-btn--secondary,
.action.secondary,
a.action.secondary {
  background: transparent;
  border-color: var(--hrv-accent);
  color: var(--hrv-accent);
}
.hrv-btn--secondary:hover,
.action.secondary:hover {
  background: var(--hrv-accent-tint);
  color: var(--hrv-accent-hover);
}

/* Ghost / neutral outline (e.g. "All deals" on a dark hero, quiet actions). */
.hrv-btn--ghost {
  background: transparent;
  border-color: var(--hrv-border-strong);
  color: var(--hrv-text);
}
.hrv-btn--ghost:hover {
  border-color: var(--hrv-text);
  color: var(--hrv-text);
}

/* Icon-only square button (wishlist ♡ / compare in the product card, nav arrows). */
.hrv-btn--icon {
  padding: 10px 13px;
  min-width: 40px;
}

/* Sizes. */
.hrv-btn--sm { padding: 10px 16px; font-size: 13px; }
.hrv-btn--lg { padding: 15px 34px; font-size: 15px; }
.hrv-btn--block { display: flex; width: 100%; }

/* Disabled / loading. */
.hrv-btn:disabled,
.hrv-btn.disabled,
.action.primary:disabled,
.action.tocart:disabled {
  opacity: 0.5;
  cursor: not-allowed;
}

/* Text/link button. */
.hrv-btn-link {
  background: none;
  border: none;
  padding: 0;
  font: inherit;
  font-weight: 600;
  color: var(--hrv-accent);
  cursor: pointer;
}
.hrv-btn-link:hover { color: var(--hrv-accent-hover); text-decoration: underline; }

@media (max-width: 767px) {
  .hrv-btn,
  .action.primary,
  .action.tocart { padding: 12px 22px; }
}

/* ---------------------------------------------------------------- N-16
   Blank/Luma rules that outrank the theme's button rules.

   N-16 asked for the SYSTEMIC answer rather than a third one-off, because two separate
   reviews of the same page had each surfaced one instance. So the cascade was enumerated
   instead of guessed: for every button-like control on Home, every rule in every loaded
   stylesheet was matched against the element, ranked by specificity the way the cascade
   ranks it, and the winner named. At 1440 and at 375, on live 0.1.28.

   THE ENUMERATION RETURNED EXACTLY ONE REMAINING CONFLICT — the pair below. Everything else
   the theme styles, it wins.

   AND N-16's OWN EXAMPLE NO LONGER REPRODUCES. The ticket records the footer Subscribe
   button at 3px radius >=768 and 0px 14px 14px 0px at 375. Measured now, at both widths:
   radius 14px, padding 13px 28px, font-size 14px — all the theme's values. Later work on
   this file fixed it and the ticket was never closed. A ticket is a record of a past
   measurement, not a live one.

   What DOES still lose: the authentication popup's Sign In button. Blank's
   `.block-authentication .action.action-login` is (0,3,0) and beat `.action.secondary` at
   (0,2,0), so the button rendered 96x52 at padding 14px 17px / font-size 18px instead of the
   theme's 13px 28px / 14px. Confirmed on the REVEALED popup, not inferred from the closed
   one — while it is shut the element measures 0x0, and a 0x0 box says nothing about how it
   renders when opened.

   Matching (0,3,0) would already win on source order, since the theme's CSS loads after
   styles-m.css. That leaves it to chance rather than stating it, so the selector below is
   deliberately (0,4,0): specificity decides, and source order gets no vote. */
.block-authentication .action.action-login.secondary,
.block-authentication button.action.action-login {
  padding: 13px 28px;
  font-size: 14px;
}