/* Crux V6 — Wave 2 UX refinements
 *
 * Loaded LAST so every rule here wins on cascade order rather than on inflated
 * specificity. Nothing in this file changes copy, structure, navigation, product
 * behaviour, or the design language: it tunes measure, target size, rhythm and
 * motion using the existing token system only.
 *
 * Every rule below is traceable to a measurement taken against the Wave 1
 * baseline; the figure in each comment is the measured "before" value.
 *
 * Consumes semantic tokens only. No new colours, fonts, or components.
 */

/* ==========================================================================
   1. MEASURE — cap line length for sustained reading
   Target 45-78 characters. Values below were measured at 1440px and 768px.
   Capping uses `ch` so the cap tracks the font size rather than a fixed px.
   ========================================================================== */

/* Measured 102 characters per line at 1440. The row is `2.5rem 16rem 1fr`, so
   the description column inherits the whole remaining track on wide monitors.
   55ch resolves to ~70 rendered characters in DM Sans: the `ch` unit is the
   width of "0", which is wider than this face's average glyph, so the cap value
   sits below the character count it produces. */
.home .register__desc { max-width: 55ch; }

/* Measured 111 characters per line at 1440 — the longest measure on the page. */
.home .shift__row dd { max-width: 60ch; }

/* Section leads run to ~81 characters in the tablet band, just past the
   comfortable ceiling. Everything else measures inside 40-80 once the grid
   thresholds below are corrected. */
@media (min-width: 48rem) and (max-width: 63.99rem) {
  .home .sec__lead { max-width: 52ch; }
}

/* --------------------------------------------------------------------------
   Wave 4: capability pages. All five were measured at 768, 900 and 1440 across
   seven prose selectors; exactly two readings exceeded 80 characters per line,
   both on bill-tracker, and both because that page's copy is longer than its
   siblings' rather than because the layout differs:

     .hero__lede         84 chars/line @768   (707px wide)
     .rolepanel__outcome 85 chars/line @900   (712px wide)

   A max-width only binds when the container is wider than the cap, so the
   shorter copy on the other four pages and on the homepage and platform page is
   unaffected. Measured, not assumed: nothing else is capped.

   The hero cap is 38rem rather than the ~41rem the width arithmetic suggests.
   At 768 the `clamp()` type scale is at its smallest, so bill-tracker's 253
   characters still packed into three lines at 41rem and the average stayed at
   84. 38rem forces the fourth line break and brings it to 63.

   SCOPE: capability pages only. These caps were derived from bill-tracker and
   must not reach the homepage or the platform page, whose prose already measures
   inside 40-80 unaided. Every V6 page carries `body.home`, so that class cannot
   discriminate. `nav.breadcrumb` can: it is present on all five capability pages
   and on no other V6 route. It is a sibling of <main> rather than an ancestor,
   so the page is selected through :has() and the cap is applied from there. No
   markup change is required.

   Degradation: where :has() is unsupported the whole block is dropped and
   bill-tracker renders at its uncapped V5 measure. That is the inherited
   baseline, not a break.
   -------------------------------------------------------------------------- */
body:has(nav.breadcrumb) .hero__lede { max-width: 38rem; }
body:has(nav.breadcrumb) .rolepanel__outcome { max-width: 40rem; }

/* --------------------------------------------------------------------------
   Wave 5: pricing. Measured across all four new routes at 768/900/1440; the
   only reading over 80 was the pricing hero lede at 84 (@900 and @768).

   The pattern is now clear and is about copy length, not layout: hero ledes
   longer than roughly 250 characters break the 80-per-line ceiling in the
   tablet band, where the clamp() type scale is smallest.

       pricing      252 chars -> 84   capped here
       bill-tracker 253 chars -> 84   capped above
       platform     218 chars -> 73   fine, not capped
       homepage     203 chars -> 68   fine, not capped

   A width cap cannot discriminate by copy length, so it is applied per page
   where measurement showed it is needed, never globally. `.phero` is pricing's
   own hero class and appears on no other V6 route.

   The `.home` prefix is required, not decorative: pricing.css:9 already sets
   `.home .phero .hero__lede { max-width: 46rem }`. Loading later is not enough
   when the earlier rule is more specific, so this selector matches it exactly
   and wins on order.
   -------------------------------------------------------------------------- */
.home .phero .hero__lede { max-width: 38rem; }

/* Principle rows: measured, NOT capped, deliberately.

   One paragraph on quickbooks-sync reads 81 characters per line — a single
   character over the ceiling. It is 161 characters that fit in two lines, so the
   figure is an average and the longest rendered line is about 81.

   A 37rem cap was tried and reverted. At 592px that paragraph still fits two
   lines and still measures 81, so the cap narrowed four sibling paragraphs
   (157, 197 and 142 characters, already at 79, 66 and 71) to fix none of them.
   Reaching 80 would need roughly 34rem, which is a visible narrowing of the
   whole component to satisfy a rounding boundary.

   No cap ships. The 81 reading is recorded as an accepted margin in
   test_v6_remaining_e2e.py rather than chased. */

/* Breadcrumb links render as 15px-tall inline text (12px font). That is inherited
   from the V5 baseline, not introduced by the port, but it is well under a usable
   touch target. The hit area is expanded with padding and pulled back with an
   equal negative margin, so the pointer/touch target reaches 44px while the
   rendered breadcrumb bar keeps exactly its baseline height and position. No
   visual change; hit area only. */
.breadcrumb__list a {
  display: inline-block;
  padding-block: 0.9rem;
  margin-block: -0.9rem;
}

/* --------------------------------------------------------------------------
   Grid thresholds: multi-column blocks were switching on far too early.
   `.system` went to 4 columns and `.evalgrid` to 3 at 52rem (832px), which
   produced 163px and 260px columns. Measured at 900px that is 21 and 29
   characters per line respectively — below any readable minimum.

   `.team` in home.css already holds single-column until 62rem, so a later
   threshold is the page's own established behaviour rather than a new idea.
   Holding both to 64rem (1024px) keeps them full-width through the tablet band
   and leaves the desktop layout untouched.

   64rem is also where `.system`'s decorative cell connectors and the entry-cell
   inset rule are designed to read as one horizontal row, so the row forms only
   once there is width for all four cells.
   -------------------------------------------------------------------------- */
@media (min-width: 52rem) and (max-width: 63.99rem) {
  .home .system { grid-template-columns: 1fr; }
  .home .evalgrid { grid-template-columns: 1fr; }
  .home .system__cell:not(:last-child)::after { display: none; }
}

/* ==========================================================================
   2. TARGET SIZE — meet the >=44px bar the build spec already sets (17)
   Measured heights: hero peek button 37px, segmented buttons 41px,
   estimator range inputs 24px. --control-md is the existing 2.75rem (44px)
   token that exists precisely for this.
   Visual weight is unchanged: the extra size is hit area, not ink.
   ========================================================================== */

.home .hero-peek__btn {
  min-height: var(--control-md);
  padding-top: 0;
  padding-bottom: 0;
  align-items: center;
}

.home .segbtn {
  min-height: var(--control-md);
  display: inline-flex;
  align-items: center;
  justify-content: center;
}

/* Range inputs: grow the control box so the pointer/touch area reaches 44px.
   The rendered track and thumb are drawn by the UA at their own size and are
   centred in the taller box, so the slider looks the same and hits better. */
.home .roi__field input[type="range"] {
  height: var(--control-md);
}

/* ==========================================================================
   3. RHYTHM — deliberately NOT changed.
   The hero closes at 43.2px against 100.8px elsewhere, which looks like an
   inconsistency. It is not: home.css:215 pairs it with
   `.home .hero + .sec { padding-top: clamp(2.5rem, 5vw, 4rem); }`, compressing
   both sides of that one seam so the hero and the problem statement read as a
   single opening unit. Normalising the hero to the section scale was tried and
   reverted — it separated two blocks that are meant to be continuous.
   No rhythm changes ship in Wave 2.
   ========================================================================== */

/* ==========================================================================
   4. MOTION QUALITY
   The reveal transform was a uniform 14px lift on every element regardless of
   size. Large section blocks read better with a slightly shorter travel, which
   keeps the entrance calm instead of making big blocks appear to "drop".
   Distance only; duration, easing and reduced-motion behaviour are untouched.
   ========================================================================== */

html.js .demo[data-reveal],
html.js .roi[data-reveal],
html.js .shift[data-reveal] { transform: translateY(10px); }

/* Focus is already a 2px yellow ring at 2px offset. On the dark sections the
   ring can sit against a similar value, so add a thin dark halo for separation.
   Uses existing tokens; does not change the ring itself. */
.sec--dark :focus-visible,
.close :focus-visible {
  outline-color: var(--focus);
  box-shadow: 0 0 0 4px var(--bg-page);
}

/* ==========================================================================
   5. PERCEIVED PERFORMANCE
   Reserve the intrinsic aspect ratio of the masthead/footer logo. The asset is
   1549px wide and rendered at ~124px with no width/height attributes, so the
   box was unreserved until the PNG decoded.
   BUILD_white.png is a locked asset and is not modified.
   ========================================================================== */

.brand__logo { aspect-ratio: 1549 / 425; }

/* ==========================================================================
   Netlify honeypot field (contact form).
   Hidden from people, still submitted by bots. `display:none` is deliberate: the
   field must not be reachable, focusable, or announced, and it carries
   aria-hidden and tabindex="-1" in markup for the same reason. This is not a
   visually-hidden pattern; nobody should ever perceive it.
   ========================================================================== */
.hp-field { display: none; }

/* ==========================================================================
   6. PRINT — the page is a sales artefact and does get printed.
   Drop the reveal state and dark backgrounds so nothing prints blank.
   ========================================================================== */

@media print {
  html.js [data-reveal] { opacity: 1 !important; transform: none !important; }
  .masthead, .mobilenav, .nav-toggle { display: none !important; }
  .sec--dark, .close { background: #fff !important; color: #000 !important; }
}