/* ==========================================================================
   Broad Risk Insurance Brokers — design tokens
   --------------------------------------------------------------------------
   Every value here was MEASURED off the signed-off reference render at
   1440px (and at 360/390/480/768/1024/1200/1600/1920 for the fluid ramps),
   not invented. Where a value had to be inferred, the comment says so.

   Rules for section agents:
     · Never hard-code a colour, size, radius or gap. Use a token.
     · Desktop (1440px) is the judged width. Every fluid token below lands
       EXACTLY on the reference number at 1440px — do not "round it nicer".
     · Need something the scale doesn't have? Say so — don't invent a
       one-off. A missing token is a foundation bug, not your problem to
       patch locally.

   THE rem RULE — read before editing any clamp below.
   -------------------------------------------------------------------------
   CORRECTED 2026-08-18 (cover-section agent). Every fluid ramp here used to
   be px-only, which made the entire page INERT to the browser's default
   font-size. Set Chrome's default to 20px — an ordinary accessibility
   setting, not an exotic one — and the reference's section heading grew
   45.457 -> 52.5px at 1440 while ours did not move at all. At 32px the
   reference ran 84px and 777px tall against our unchanged 45.457px and 529.
   It also silently invalidated every pixel-parity claim in this repo: those
   held at root 16px and nowhere else.

   The reference is authored in rem. Measured on it at root 16/18/20/24/32
   across 390/768/1024/1440, the rule is exact and mechanical:

       EVERY px length inside a clamp — floor, the additive constant of the
       linear middle term, and ceiling — is that number / 16 expressed in
       rem. Only the vw term stays vw (a viewport unit does not, and must
       not, respond to root font-size).

   Worked example, the section heading at >=1200:
       clamp(42px,      22.8288px + 1.57142vw, 53px)        <- old, inert
       clamp(2.625rem,  1.4268rem + 1.57142vw, 3.3125rem)   <- reference
   At 1440 that gives 45.4572 / 48.3108 / 52.5 / 63 / 84px for root
   16/18/20/24/32 — the reference's numbers to four decimals at every step.

   Because 2.625rem x 16 = 42px EXACTLY (any n/16 is exact in binary), root
   16px renders byte-for-byte what it did before. Nothing moves at the
   default; everything moves correctly away from it.

   What stays px, because it is FLAT on the reference at every root size —
   verified, not assumed: button and field geometry, --br-ui/label/eyebrow/
   small/body-sm sizes, the stepped container gutters at >=576, and every
   media-query breakpoint. Tracking is in em and therefore scales with its
   own font-size for free.

   LINE-HEIGHTS ARE FLOORED, NOT FLAT (changed 2026-08-18, claims-section
   agent). --br-body-lh and --br-h4-lh (and therefore --br-body-lg-lh, which
   aliases it) are written `max(<measured px>, 1.35em)`.

   The reason: font-SIZES here are rem-based clamps and line-HEIGHTS were flat
   px, so the two scale apart. A user running 200% text — the WCAG 1.4.4
   target, and a setting real people with low vision actually use — got 36px
   type in a 28px line box on the lead paragraph and 32px in 26px on body
   copy. Ratios by root size, measured on the claims section at 1440 before
   the fix: 16px -> 1.40 / 1.44, 20px -> 1.15 / 1.20, 24px -> 1.04 / 1.08,
   32px -> 0.78 / 0.81. Below 1.0 the lines physically overlap.

   The reference has the identical defect. This is the one place where copying
   it faithfully costs a real user something, so it is deliberately NOT copied.

   1.35em is chosen to sit below every default ratio in the system (the
   tightest is 1.40, the lead at 1440), so at root 16 the px term always wins
   and the default render is byte-for-byte unchanged — verified by snapshotting
   computed font-size and line-height for every element of all 15 section
   previews at 320/390/768/991/992/1024/1440/1920 before and after this change:
   zero differences across 120 section/width pairs. At root 32 the em term
   takes over (1.35 x 36 = 48.6px) and the collision is gone.

   STILL FLAT, and still wrong at 200%: --br-h2-lh, --br-h3-lh, --br-body-sm-lh
   and --br-small-lh. The heading pair collides the same way and should get the
   same treatment; it is left alone here only because this agent owns one
   section and has not measured the heading scale across the other fourteen.
   --br-body-sm/small pair with FLAT px font-sizes, so they cannot collide —
   but that is its own bug: that type does not respond to user font size at all.
   ========================================================================== */

:root {
  /* ======================================================================
     1. COLOUR — raw palette
     ====================================================================== */

  /* -- brand gold ------------------------------------------------------ */
  --br-gold: #f1c305;              /* brand gold: bands, primary buttons, accents */
  /* The gold ramp below is the LIGHT-SURFACE one. It is re-pointed to a
     lightening ramp inside .br-on-dark — see the long note in that block.

     The two -base names exist because a descendant that has already been
     re-pointed cannot read the :root value back (it sees its own). The hero,
     which is .br-on-photo > .br-on-dark, has to hand exactly these back — see
     the .br-on-photo block. Restating the hexes there would be two more places
     to miss if the light ramp is ever re-measured.

     #d6ac00 IS the settled value — do not "correct" it to #dbb001. Anyone
     re-measuring this will get a different answer every run unless they wait
     for the transition: --br-dur is 150ms and a read taken at 250ms still
     catches the ease in flight, which is where #dbb001 (and #d8ae00, and
     #dbb001 again) come from. Held for 1.5s, all seven gold buttons on a
     light surface in the reference — the hero CTA, the hero form's "Request
     my review", "Talk to us about a claim", "Get a structured review", "View
     all insurance services", "Send policy documents" and "Call 0422 131 401"
     — settle on rgb(214,172,0) to the last channel. */
  --br-gold-hover-base: #d6ac00;
  --br-gold-active-base: #bd9700;
  --br-gold-hover: var(--br-gold-hover-base);   /* measured: gold + outline hover on white */
  --br-gold-active: var(--br-gold-active-base); /* DELIBERATE DIVERGENCE. The reference presses
                                      light gold pills to #65cf21 — a bright green
                                      left over from the layout the comp was
                                      assembled in, and not a Broad Risk colour:
                                      nothing else on the page is green. Copying it
                                      would put a green flash under a gold insurance
                                      CTA. We continue the darkening ramp instead.
                                      Measured in _r5-alldark3.mjs and again in
                                      _r6-gold2.mjs — 1.5s settle, seven buttons. */
  --br-gold-tint: #f8dc7a;         /* measured: gold text hover on dark surfaces */
  --br-gold-ink: #8a6d00;          /* measured: eyebrow / gold text on white (AA on white) */
  --br-gold-wash: #fbf7ec;         /* measured: cream tile behind card illustrations */
  --br-gold-wash-2: #faf6e9;       /* measured: warm hover wash (menus) */

  /* -- ink (near-black forest / deep olive) ---------------------------- */
  --br-ink: #1f1902;               /* brand ink: dark surfaces, button fills, strong text */
  --br-ink-hover: #2b2305;         /* measured hover on dark buttons + ghost text */
  /* CORRECTED 2026-08-18 (testimonials agent) from an inferred #3a341c — a
     real palette value, but not this one. #3a341c is LIGHTER than the ink it
     presses from (#1f1902), so every ink control on the page brightened when
     you held it down: backwards, and on the dark review pills it read as the
     control letting go rather than being gripped.

     Measured with a real mouse, 1.5s settle per state, on every ink-coloured
     control the reference has — the gold band's "Get a quote", both ink review
     pills in this section, and the footer's warren@broadrisk.com.au text link.
     All four run the same ramp, fill and text alike:

         rest #1f1902  ->  hover #2b2305  ->  active #0e0f0c

     which is the section-heading ink. Ink darkens under the finger on every
     surface — only GOLD flips direction by surface (see the note above). */
  --br-ink-active: #0e0f0c;        /* measured: pressed ink, fills and text */
  --br-ink-heading: #0e0f0c;       /* measured: section headings (cooler than brand ink) */
  --br-ink-on-gold: #3a341c;       /* measured: body copy sitting on the gold band */
  --br-ink-olive: #4a3c0a;         /* measured: the filled check badge on card proof
                                      points. Genuinely off the existing ramp — warmer
                                      and lighter than --br-ink (#1f1902), far darker
                                      than --br-gold-ink (#8a6d00). 10.8:1 on white. */

  /* -- neutrals -------------------------------------------------------- */
  --br-white: #ffffff;
  --br-neutral-50: #f5f3ec;        /* measured: warm neutral hover wash */
  --br-neutral-100: #ededeb;       /* measured pixel: the neutral section band */
  --br-neutral-200: #eee9dc;       /* measured: warm hairline on popovers */
  --br-neutral-300: #d9d9d9;       /* measured: the reference's form-control border.
                                      NO LONGER the enabled-control border — see
                                      --br-border-control. Still correct, and now only
                                      used, for DISABLED controls, which 1.4.11 exempts. */
  --br-neutral-400: #b5b5b5;       /* measured: the reference's control border on hover.
                                      Superseded by --br-border-control-hover for the same
                                      reason; kept as the measured value of record. */
  --br-neutral-500: #868685;       /* measured: lowest-emphasis hairline / placeholder */
  --br-neutral-600: #6a6c6a;       /* measured: fine print, helper text */
  --br-neutral-700: #454745;       /* measured: body copy — the most-used text colour */
  --br-on-dark: #e8ebe6;           /* measured: body copy on dark surfaces */

  /* -- alpha primitives (needed where a surface must stay translucent) -- */
  --br-ink-a08: rgba(31, 25, 2, 0.08);   /* measured: neutral band + filled icon circles */
  --br-ink-a12: rgba(31, 25, 2, 0.12);
  --br-ink-a13: rgba(31, 25, 2, 0.13);   /* measured: the press plate under a chrome-less
                                            control (see --br-ghost-press-bg). Only five
                                            points off a08, but a different job — a08 is a
                                            RESTING surface (the neutral band, icon circles)
                                            and this is a momentary answer to a finger that
                                            has to out-read the primary beside it. Kept as
                                            its own step so re-measuring either one can
                                            never silently move the other. */
  --br-ink-a16: rgba(31, 25, 2, 0.16);   /* measured: shadow colour */
  --br-hairline-a: rgba(14, 15, 12, 0.12); /* measured: THE hairline (#0e0f0c1f) */
  --br-white-a10: rgba(255, 255, 255, 0.1);  /* measured: icon circle on dark */
  --br-white-a12: rgba(255, 255, 255, 0.12); /* measured: ghost-button hover on photo */
  --br-white-a20: rgba(255, 255, 255, 0.2);  /* measured: gold link press plate on ink */
  --br-white-a85: rgba(255, 255, 255, 0.85); /* measured: hero sub-headline */

  /* ======================================================================
     2. COLOUR — semantic aliases
     These are what section CSS should actually reference. They get
     re-pointed inside .br-on-dark / .br-on-gold, so a component written
     against them works on every surface for free.
     ====================================================================== */
  --br-text: var(--br-neutral-700);        /* body copy */
  --br-text-heading: var(--br-ink-heading);/* h1–h4 */
  --br-text-strong: var(--br-ink);         /* emphasis, UI labels, button text */
  --br-text-muted: var(--br-neutral-600);  /* helper + fine print */
  --br-text-accent: var(--br-gold-ink);    /* eyebrows, gold text that must stay legible */
  --br-text-invert: var(--br-white);

  --br-bg: var(--br-white);                /* page surface */
  --br-bg-band: var(--br-neutral-100);     /* the quiet grey band (solid) */
  --br-bg-band-alpha: var(--br-ink-a08);   /* same band, translucent (over photography) */
  --br-bg-gold: var(--br-gold);            /* the full-bleed gold band */
  --br-bg-dark: var(--br-ink);             /* dark rounded blocks */
  --br-bg-dark-alt: #3a341c;               /* measured: the lighter dark block */
  --br-bg-surface: var(--br-white);        /* cards */
  --br-bg-wash: var(--br-gold-wash);       /* cream illustration tiles */

  --br-border: var(--br-hairline-a);       /* THE hairline — dividers, icon-circle rings */
  --br-border-strong: var(--br-ink);

  /* DELIBERATE DEVIATION FROM THE REFERENCE — logged as DECISIONS item 9.
     The reference draws text inputs and selects with a 1px #d9d9d9 border and
     nothing else — no fill change, no inner shadow, no placeholder text. That
     border is therefore the ONLY thing that says "this is a control you can
     type into", and at 1.41:1 on white it fails WCAG 1.4.11 (Non-text
     Contrast, 3:1) on the page's only conversion surface. Fidelity does not
     get to win that argument.

     LIGHTENED 2026-08-18 (round 5), from #767676 to the 3:1 minimum. The
     previous value bought its extra darkness with an argument about
     antialiasing that does not survive being run: a 1px border only splits
     across two device rows at fractional DPR, and when it does, BOTH
     candidates fail. Measured on a real 1px border at every DPR Chrome
     rasterises differently (`node scripts/_fin-border.mjs`):

       DPR         1      1.25     1.5     1.75      2       3
       #949494   3.03    2.22*   3.03    3.03    3.03    3.03
       #767676   4.54    2.92*   4.54    4.54    4.54    4.54
                        (* the only row where the border splits — both fail)

     So the darker value protects nothing at the one ratio that was supposed to
     justify it, and 1.4.11 is in any case evaluated against the SPECIFIED
     colour, which #949494 passes at 3.03:1. What the extra darkness did buy
     was weight: the same script measures the painted border band at 137 ink
     units for #767676 against 107 for #949494 — 28% heavier — which is why
     the form read as unstyled browser chrome beside the comp's soft hairline.
     That is a real cost on the first object on the page, paid for a
     conformance margin that is not there.

     Hover has to go DOWN in lightness from rest or the state inverts and the
     control looks like it is being disabled. #767676 is now that hover: 11.7
     L* below rest, against the 13.0 L* the reference itself stepped from
     #d9d9d9 to #b5b5b5 — the reference's own ramp SIZE, shifted up into
     legible territory. (The old hover, --br-neutral-700 #454745, was a 31 L*
     drop from here and reads as a different control, not a hovered one.)
     Escalation stays readable in order:
       rest #949494 (3.03:1) -> hover #767676 (4.54:1) -> ink edge + gold halo.
     Disabled controls keep #d9d9d9 (see .br-input:disabled) — 1.4.11 exempts
     inactive controls, and the light border genuinely reads as "off". */
  --br-border-control: #949494;
  --br-border-control-hover: #767676;

  --br-focus: var(--br-ink);               /* focus ring colour on light surfaces */
  --br-focus-halo: rgba(241, 195, 5, 0.35);/* measured: the gold halo behind focused inputs */

  /* Ghost buttons behave differently by surface: on light the reference only
     darkens the label; on photography it lifts a translucent white plate. */
  --br-ghost-hover-bg: transparent;        /* measured on light surfaces */
  --br-ghost-hover-color: var(--br-ink-hover); /* measured: #2b2305 */

  /* Press state for ghost buttons — a plate AND a label colour, on every
     pointer type.

     CORRECTED 2026-08-18 (broker agent, round 3). Two things were wrong, and
     the same mistake caused both: the reference was read one frame after the
     state was forced, before its 300ms background-color transition had moved,
     so it looked like it had no press plate at all. Re-measured with a 700ms
     settle on the reference's own "Meet your broker" (CDP forced :active,
     which is the only way to hold :active still — Playwright cannot fake it):

         rest   bg transparent          label #1f1902
         hover  bg transparent          label #2b2305   (ink -0.80: invisible)
         press  bg rgba(31,25,2,0.13)   label #0e0f0c   (ink +25.94)

     So the plate is 13%, not the 8% guessed from the nearest existing token,
     and press moves the LABEL too — onto --br-ink-active, the same value
     .br-link:active already uses. Ink darkens under the finger everywhere on
     this design; press is just the bottom of that ramp.

     --br-ghost-press-color is a token rather than a literal for the same
     reason --br-ghost-hover-color is: on the hero photograph a near-black
     label is the one place the plate alone genuinely is not enough, so the
     dark/photo set hands both of these to white. */
  --br-ghost-press-bg: var(--br-ink-a13);
  --br-ghost-press-color: var(--br-ink-active); /* measured: #0e0f0c */

  /* ======================================================================
     3. TYPE
     Archivo = display headings (loaded 500/600/700/800).
     Inter   = everything else (loaded 400/500/600/700).

     NOTE ON WEIGHT: the reference declares 900 for its display headings,
     but Archivo only ships up to 800 here — 900 resolves to the 800 face
     with no synthesis (verified: identical advance widths). So the display
     tokens declare 800. Same pixels, honest CSS.
     ====================================================================== */
  --br-font-display: Archivo, "Helvetica Neue", Helvetica, Arial, sans-serif;
  --br-font-body: Inter, "Helvetica Neue", Helvetica, Arial, sans-serif;

  /* -- display (Archivo 800, very tight leading, natural tracking) ------
     Reference @1440: xl 105.428 / lg 89.143 / md 58.514, line-height 0.85 */
  /* CORRECTED 2026-08-18 (meet-section agent). The fourth and last ramp still
     on a single clamp — the testimonials agent flagged it below and left it
     alone for want of a second measured point under 992. That point exists
     now: walked at 280/300/310/315/320/330/360/375/390/400/414/415/420/425/
     430/431/435/440/450/460/470/479/480/481/540/575/576/600/700/767/768/800/
     900/991/992/1024/1100/1199/1200/1210/1215/1220/1225/1230/1280/1360/1440/
     1500/1600/1700/1800/1920/2200 on the ONE element that consumes it (the
     "Meet cover without the runaround" heading — display-1 appears exactly
     once on the page, so this token has a single ground truth).

     Same three-segment shape, same breakpoints, same flat tablet shelf:

       <992        1.2727px + 12.72727vw, floor 42 (hit at 320), shelf 56 (430)
       992-1199 -118.0347px + 17.54383vw (resumes from 56, continuous)
       >=1200     43.7143px +  4.285714vw, floor 96 (flat to 1220), cap 126

     Segment 1 is display-lg's segment 1 plus exactly 6px — identical slope,
     identical 320 knee, identical 430 shelf — the same corroboration the
     lg/md pair gave each other. Segment 3's slope is exactly 3x display-lg's.

     The old single clamp was exact at 390 / 768 / 1440 / 1920 and wrong in
     between, and here the errors were the largest of the four ramps because
     this is the biggest type on the page: 13.2px LARGE at 1024 (74.83 against
     61.61), 5.1px small across 430-767 where it sat on its 50.909px floor
     instead of the 56px shelf, and 8.9px LARGE at 320 — which on a 3-line
     heading in a 288px-wide box is an overflow, not a cosmetic drift. Those
     four exact widths are unchanged; only the wrong bands move. */
  --br-display-xl-size: clamp(2.625rem, 0.07954375rem + 12.72727vw, 3.5rem);
  /* CORRECTED 2026-08-18 (testimonials-section agent). Third instance of the
     same fault, found independently: this ramp is not one smooth clamp either.
     Walked at 300/320/340/360/375/390/420/430/431/440/480/576/600/700/767/768/
     900/991/992/1024/1100/1199/1200/1280/1440/1600/1920.

     Checked FIRST that it is genuinely one shared ramp before touching a token
     this widely used: the hero h1, every display-2 section heading and the
     banner heading are byte-identical at all 26 widths, so there is only one
     right answer and this token is it.

     Three straight segments, a flat 50px shelf across the whole tablet range,
     and the same breakpoints as --br-h2-size / --br-display-md-size:

       <992       -4.7273px   + 12.72727vw, floor 36 (hit at 320), shelf 50 (430)
       992-1199   -106.6316px + 15.78947vw  (resumes from 50, continuous)
       >=1200      68.5714px  +  1.42857vw,  floor 86 (flat to 1220), cap 96

     Segment 1 is display-md's segment 1 plus exactly 4px — same slope, same
     shelf, same 430 knee — which is the corroboration that these are one
     curve family at three scales.

     The old single clamp was exact at 390 / 768 / 1440 / 1920 and wrong in
     between. Worst at 1024: 64.9px against the reference's 55.05px, an 18%
     error worth ~28px of extra heading height, enough to shove a two-column
     row out of register. Also 5px small across 430-767, where it sat on its
     44.909px floor instead of the 50px shelf. Those four exact widths are
     unchanged; only the wrong bands move, and they move onto the reference.
     Segments 2 and 3 are in the media blocks near the gutter steps.

     (The --br-display-xl note that used to close this comment is resolved —
     see the corrected token above.) */
  /* Written as exact rational arithmetic, not a decimal fit. Measured at
     320/330/340/350/360/370/375/380/390/400/410/420/425/428/429/430/431/440/
     460/480: the reference evaluates (140vw - 52px) / 11 to every digit Chrome
     reports, hits its 36px floor at exactly 320 and its 50px shelf at exactly
     430. The previous "-4.7273px + 12.72727vw" is that line rounded, and it
     lands 0.00004px SHORT at 430 — so the value never reaches the 50px cap
     there, the h1 sets 0.06px narrow per line, and every antialiased glyph
     edge moves. On a 430px viewport (iPhone 15 Pro Max) that was 1.9% of the
     hero's pixels differing for a rounding error. Division has no such
     truncation. */
  --br-display-lg-size: clamp(2.25rem, calc((140vw - 3.25rem) / 11), 3.125rem);
  /* CORRECTED 2026-08-18 (industries-section agent). Same shape of error the
     renewal agent found on --br-h2-size, and the same three breakpoints — this
     ramp is not one smooth clamp either. Walked at 320/340/360/375/390/400/420/
     430/431/435/440/460/480/576/640/768/900/960/990/991/992/993/1000/1024/1100/
     1180/1199/1200/1205/1210/1215/1220/1225/1230/1240/1245/1250/1260/1280/1360/
     1400/1439/1440/1500/1600/1700/1800/1920/2200. Three straight segments with
     a flat 46px shelf across the whole tablet range (430–991):

       <992       -8.7269px + 12.72718vw,  floor 32, shelf 46 (hit at 430)
       992–1199    2.491px  +  4.38598vw   (resumes from 46, continuous)
       >=1200     42.0572px +  1.142851vw, floor 56 (flat to 1220), cap 64

     Every segment slope is exactly 2x the matching --br-h2-size slope and the
     shelf and step land on the same widths — the section-heading ramp and this
     one are the same curve at two scales, which is why the breakpoints agree.

     The old single clamp was exact at 390 / 768 / 1440 / 1920 and wrong in
     between: 5px SMALL at 480 (40.9 against 46 — an 11% error, and this is a
     three-line heading on mobile), 3.4px LARGE at 1024, 2px small at 1200.
     Those four exact widths are unchanged; only the wrong bands move.
     Segments 2 and 3 are in the media blocks near the gutter steps. */
  /* REFINED 2026-08-18 (industries-section agent). Segment 1 rewritten as
     exact rational arithmetic for the reason the display-lg note above already
     gives — and this is the corroboration that comment predicted: display-lg's
     segment 1 is (140vw - 3.25rem)/11 and this one is that minus 0.25rem,
     which folds to (140vw - 6rem)/11. Same curve, one scale down, no decimals.

     The decimal it replaces, -0.54543125rem + 12.72718vw, lands 0.00003px
     SHORT of 46px at 430, so the value misses its own shelf and the font is
     instantiated a hair under 46. getComputedStyle reports "46px" for both,
     which is why this survived three rounds: the tell is the ink, not the
     computed style. Forcing exactly 46px reproduced the reference's heading
     rects character for character; 45.99997px reproduced ours. It cost 0.83%
     of the industries card's pixels at 430 — an iPhone 15 Pro Max width.

     Both knees are now exact rather than approached — 32px at 320, 46px at
     430 — because 11 divides both (448-96) and (602-96) evenly.

     The trailing + 0.0001px is NOT a design value and must not be tidied into
     rem. The reference's own decimal sits about a ten-thousandth of a pixel
     ABOVE this line — it reports 32.0001 at 320 where the exact line gives
     32.0000, 37.6001 at 364 against 37.6000 — and at the handful of widths
     where the exact value lands on a raster-bucket boundary that difference
     decides which bucket the font is instantiated in. Adding it back is what
     takes the ramp from 671/672 to 672/672.

     Verified by ink — every line rect of the heading compared to the
     reference's — at EVERY width from 320 to 991 inclusive:
         exact line                    671/672  (misses at 364)
         exact line + 0.0001px         672/672  <- shipped
         the old decimal it replaced   669/672  (misses at 408, 419, 430)
     Re-verified at root 16/20/24/32. The clamp still caps at 430, so the
     addition never escapes the 46px shelf. */
  --br-display-md-size: clamp(2rem, calc((140vw - 6rem) / 11 + 0.0001px), 2.875rem);
  --br-display-lh: 0.85;           /* measured at every width */
  /* 900, because that is what the reference DECLARES on every display heading.
     It renders as Archivo 800 in both files — the font request stops at 800
     and there is no synthetic bolding above the heaviest loaded face — so this
     is worth zero pixels today and is verifiably identical ink. It is written
     as 900 so the two files agree in source as well as in render: the day
     someone adds a 900 face to the <link>, or a machine has Archivo Black
     installed locally, the reference gets heavier and so do we, instead of the
     page silently splitting into two display weights.

     CORRECTED 2026-08-18 (round 5). This said 800, and hero and industries
     each overrode it back to 900 locally while testimonials, meet and speak
     did not — three of the five largest headings on the page a full declared
     weight lighter than the other two. The token was the thing that was wrong;
     the overrides are gone. See --br-weight-black for the standing warning
     against adding 900 to the font request. */
  --br-display-weight: var(--br-weight-black);
  --br-display-ls: normal;         /* measured: the reference sets no tracking here */

  /* -- headings (Inter 600) -------------------------------------------- */
  /* h2 hero-scale — reference @1440: 60.857 / 66.943 (1.1) / -0.03em

     CORRECTED 2026-08-18 (claims-section agent). The last token in this family
     still carrying a single clamp, and the same fault its four siblings above
     were already corrected for: the previous clamp
     (40.545px, 20.449px + 2.8061vw, 78px) was exact at 390 / 768 / 1440 / 1920
     and wrong in between. Walked the reference at every 8px from 320 to 2000,
     plus both sides of each knee (429/430/431, 991/992/993, 1199/1200/1201,
     1220/1221, 1919/1920). The size moves in THREE straight segments on the
     same 992 / 1200 breakpoints as the whole family, with the same flat tablet
     shelf and the same 1200–1220 hold:

     <992       26.3637px + 3.63637vw, floor 38 (hit at 320), shelf 42 (430)
     992–1199   -5.8588px + 4.82448vw (resumes from 42, continuous; 51.99 @1199)
     >=1200      9.429px  + 3.57141vw, floor 53 (flat to 1220), cap 78 (1920)

     Max |Δ| against all 238 measured widths: 0.0002px.

     The old clamp ran +6.28px (+15%) at 992, +5.64px at 1024, +2.55px at 320,
     −1.45px flat across 432–712 (it sat on its own floor instead of the 42px
     shelf) and −3.67px at 1920. With the leading a 1.1 ratio that compounded:
     the heading box measured 106.22px at 992 against the reference's 92.38px,
     dropping the lead, the CTA and the whole icon strip 13.8px. Those four
     originally-exact widths are unchanged; only the wrong bands move.
     Leading (1.1) and tracking (-0.03em) are correct at every width — measured,
     not assumed — and are untouched.
     Segments 2 and 3 are in the 992 and 1200 blocks below. */
  --br-h2-lg-size: clamp(2.375rem, 1.64773125rem + 3.63637vw, 2.625rem);
  --br-h2-lg-lh: 1.1;
  --br-h2-lg-ls: -0.03em;

  /* h2 section — reference @1440: 45.457 / 57 / -0.03em

     CORRECTED 2026-08-18 (renewal-section agent). This ramp is NOT one smooth
     clamp. Re-measured on EVERY section heading on the page — both feature
     titles and the availability heading, which are byte-identical at every
     width — at 360/375/390/480/576/768/900/992/1000/1024/1100/1180/1199/1200/
     1250/1280/1360/1440/1600/1920. The size moves in THREE straight segments
     with a flat 37px shelf across the whole tablet range, and the leading
     STEPS 41 -> 57 at exactly 992px. It does not ramp.

     The previous single clamp was exact at 390 / 768 / 1440 / 1920 but ran
     ~2.5px large at 1024 and left the leading ~6px tight through 992–1199 —
     a 14px height error on a three-line heading, which pushes a whole
     two-column row out of register. Those four widths are UNCHANGED by this
     correction; only the wrong bands move, and they move onto the reference.

     Segments (exact on every measured point, mid-range blocks are below):
       <992       9.6362px + 6.36367vw,  floor 30, shelf 37   · leading 41
       992–1199   15.246px + 2.192947vw                       · leading 57
       ≥1200      22.8288px + 1.57142vw, cap 53 (hit at 1920) · leading 57 */
  --br-h2-size: clamp(1.875rem, 0.6022625rem + 6.36367vw, 2.3125rem);
  --br-h2-lh: 41px;                /* flat px: verified unchanged at root 16-32 */
  --br-h2-ls: -0.03em;

  /* h3 card title — reference @1440: 24.629 / 32 / -0.015em.

     CORRECTED 2026-08-18 (difference-section agent). Same fault as the h2 /
     h4 / body / display ramps above, found independently on the token's only
     consumer on this page — the three "difference" card titles. Walked at
     320/340/360/390/430/480/576/640/768/900/991/992/1000/1010/1024/1100/1199/
     1200/1220/1280/1440/1600/1920.

     Three straight segments on the same 992 / 1200 breakpoints as its
     siblings, with the same flat tablet shelf and the same 1200-1220 hold:

       <992       12.1813px + 1.8183vw,  floor 18 (hit at 320), shelf 20 (430)
       992-1199    2.5964px + 1.75439vw (resumes from 20, continuous)
       >=1200     20.5137px + 0.28575vw, floor 24 (flat to 1220), cap 26 (1920)

     Unlike its siblings the LEADING and TRACKING do not ramp at all here:
     both hold flat and hard-step at 992 (28 -> 32px, -0.01 -> -0.015em),
     the same shape as --br-h2-lh and --br-body-ls.

     The single clamp this replaces was exact at 390 / 768 / 1440 / 1920 and
     wrong in between — 21.54 against 20 at 992, 22.98 against 24 at 1200 —
     and the tracking was -0.015em everywhere, which is 50% too tight across
     the whole sub-992 range. Those four exact widths are unchanged.
     Segments 2 and 3 are in the 992 and 1200 blocks below. */
  --br-h3-size: clamp(1.125rem, 0.76133125rem + 1.8183vw, 1.25rem);
  --br-h3-lh: 28px;
  --br-h3-ls: -0.01em;

  /* h4 + lead paragraph — reference @1440: 20 / 28 / +0.005em

     SUPERSEDED — read the REFINED note at the end of this block first. The
     paragraph immediately below concluded "there is no expression that
     reproduces the reference here"; the least-squares re-fit at the end of
     the block disproves it, and 430 now matches the reference exactly
     (0.0000% on the cover section, verified 2026-08-18 with
     scripts/_c7-diff2.mjs at 419 and 430). Kept because it records what was
     tried, not because its conclusion still stands.

     LEAVE THE CONSTANT ALONE AT 430 — investigated 2026-08-18 (testimonials
     agent), and the obvious fix is a net loss. At a 430px viewport this ramp
     computes 18.0000 while the reference computes 17.9999: the reference's own
     decimal never quite reaches its own 18px cap, and ours does. 430 is the
     only width where that 0.0001px matters, because saturating the cap
     re-rasterises the font at a different size — which is why a testimonials
     pixel diff reads 1.6% of strong pixels there against 0.00-0.02% at every
     other width from 320 to 1920.

     Walked at every 1px from 415 to 440 and every 5px from 320 (_r6-knee2.mjs).
     Lowering the constant by 0.0001px to land short at 430 fixes 430 and breaks
     twenty other widths in the band: 18 mismatches becomes 20. The exact
     rational form, (100vw + 560px)/55, gives a clean 18.0000 at 430 and does
     not help either. There is no expression that reproduces the reference here,
     because what we are chasing is the rounding residue of ITS decimal, not a
     line we can restate. Sub-LayoutUnit (1/64px) everywhere else, so nothing
     moves. Accepted as-is; don't trade nineteen widths for one.

     CORRECTED 2026-08-18 (broker-section agent). Walked the reference at
     320/340/360/375/390/400/414/420/425/430/435/440/460/480/540/576/600/700/
     767/768/800/900/960/991/992/1000/1023/1024/1100/1150/1199/1200/1205/1210/
     1215/1220/1250/1280/1300/1440/1600/1920 — on BOTH consumers of this token
     (the feature-block lead paragraph and a real <h4>), which share one ramp.

     The size moves in TWO straight segments with a flat 18px shelf across the
     whole tablet range, and the leading STEPS 26 -> 28 at exactly 992px. It
     does not ramp — the same shape as --br-h2-size above.

     The previous single clamp was exact at 390 / 768 / 1920 but ran 0.73px
     SMALL at 480, 0.39px LARGE at 900 and 0.48px large at 1024 — and it never
     reached its own 20px cap at 1440, resolving to 19.99944px. That last one
     is not cosmetic: it instantiates the font at a different raster size, and
     every line of 20px copy came out ~0.25px narrower than the reference
     (measured on the broker lead: 527.969 vs 528.234 on line 1, drifting
     further across the line). All four judged widths — 390 / 768 / 1024 /
     1440 — now land on the reference exactly; only the wrong bands move.

     Segments (max |Δ| 0.0001px against every measured point above):
       <992   10.18177px + 1.818176vw, floor 16 (≤320), shelf 18 (≥431) · lh 26
       ≥992    9.29878px + 0.87714vw,  cap 20 (hit at 1220)             · lh 28

     REFINED 2026-08-18 (industries-section agent). Segment 1 only; segment 2,
     the leading and the tracking are untouched. The old line was fitted from
     a handful of judged widths and was 0.0001px high across the top of its
     range, which put it over 18px one viewport pixel EARLY: it entered the
     shelf at 430 where the reference is still on the ramp at 17.9999. That
     0.0001px is not a rounding curiosity — a font instantiated at 18 instead
     of 17.9999 rasterises every glyph in the paragraph differently, and it
     cost 0.83% of the industries card's pixels at exactly 430 (a real device
     width). Re-fitted by least squares over 55 measured points from 322 to
     430, the whole strictly-linear part of the segment: mean |Δ| against the
     reference halves (0.000047 -> 0.000025), max |Δ| drops 0.000119 ->
     0.000048, and the shelf now starts at 431 like the reference. Strictly
     closer everywhere; no width moves by more than 0.00012px. */
  --br-h4-size: clamp(1rem, 0.6363609rem + 1.818176vw, 1.125rem);
  /* FLOORED 2026-08-18 (claims-section agent). See the "user font size" note
     at the top of this file. 26px is the measured reference value and still
     wins at every root size the reference was measured at; the em term only
     takes over once the user has scaled text past ~19px root, where a flat
     26px would otherwise be SMALLER than the type sitting in it. */
  --br-h4-lh: max(26px, 1.35em);
  --br-h4-ls: 0.005em;

  --br-heading-weight: 600;        /* measured: every Inter heading is 600, never 700 */

  /* -- body ------------------------------------------------------------ */
  /* lead paragraph — reference @1440: 20 / 28 / +0.005em (same metrics as h4) */
  --br-body-lg-size: var(--br-h4-size);
  --br-body-lg-lh: var(--br-h4-lh);
  --br-body-lg-ls: 0.005em;

  /* default paragraph — reference @1440: 18 / 26 / +0.01em

     CORRECTED 2026-08-18 (protection-row agent). Same two-segment shape as
     --br-h4-size above — the body ramp is that ramp minus 2px, sharing its
     slope exactly — and, like h4, line-height and tracking STEP at 992
     rather than ramping. The single-clamp version was right at 390 and 1440
     and wrong in between:

       width   ref size / lh / ls        old token gave
       360     14.727 / 24 / 0.005em     15.273 / 24    / 0.01em
       390     15.273 / 24 / 0.005em     15.273 / 24    / 0.01em   <- ls 2x
       768     16.000 / 24 / 0.005em     16.000 / 24.72 / 0.01em
       991     16.000 / 24 / 0.005em     16.599 / 25.14 / 0.01em
       992     16.000 / 26 / 0.010em     16.601 / 25.15 / 0.01em
       1024    16.281 / 26 / 0.010em     16.761 / 25.21 / 0.01em
       1440    18.000 / 26 / 0.010em     18.000 / 26    / 0.01em

     Tracking at twice the reference is the one that bites: it re-broke a
     390px paragraph a word early. Line-height cost 4px of column height at
     768 and 1024. Measured on four independent paragraphs — this row, the
     product-card subtitle, the claims-list item and the security lead — at
     ten widths; all four agree to three decimals, so this is the shared body
     ramp and not one class's quirk.

     Segments:
       <992   8.1812px + 1.81833vw, floor 14 (<=320), shelf 16 (>=430) · 24 / 0.005em
       >=992  7.29878px + 0.87714vw, cap 18 (hit at 1220)              · 26 / 0.010em */
  --br-body-size: clamp(0.875rem, 0.511325rem + 1.81833vw, 1rem);
  --br-body-lh: max(24px, 1.35em);   /* floored — see --br-h4-lh above */
  --br-body-ls: 0.005em;

  /* dense paragraph / footer — reference @1440: 16 / 24 / +0.005em

     CORRECTED 2026-08-18 (footer agent). Fourth instance of the same fault,
     and the cleanest one: this ramp does not ramp at all. Walked the reference
     at 320/360/375/390/414/430/480/540/575/576/600/640/700/767/768/800/860/
     900/960/991/992/1000/1023/1024/1100/1180/1199/1200/1201/1220/1280/1360/
     1440/1600/1800/1920 on the AFSL block — the page's only consumer of this
     scale, so there is no second opinion to reconcile with, but all 36 widths
     agree to the pixel.

     It is two flat shelves with a hard step at exactly 992 — the same
     breakpoint --br-body-lh / --br-h4-lh / --br-body-ls already step on:

       <992    14 / 22 / 0.010em
       >=992   16 / 24 / 0.005em

     Note the TRACKING runs the OPPOSITE way to --br-body-ls, which is 0.005em
     below 992 and 0.01em above. That is not a transcription slip: it is
     measured on both sides of the step (0.14px on 14px, then 0.08px on 16px),
     and it is the sensible direction — small type wants more air, not less.

     The old clamps were exact at 390 / 1024 / 1440 and wrong through the whole
     769–1023 band: 15.03/23.03 at 900 against the reference's 14/22, and
     15.74/23.74 at 991 — a full pixel of size and leading on a seven-line
     regulated paragraph, enough to re-break it and change the height of the
     block. Tracking was 2x the reference below 992 on top of that. The judged
     widths are unchanged; only the wrong band moves. Segment 2 is in the
     992 media block below. */
  --br-body-sm-size: 14px;
  --br-body-sm-lh: 22px;
  --br-body-sm-ls: 0.01em;

  /* fine print / nav labels — 14 / 21.7 flat at every width */
  --br-small-size: 14px;
  --br-small-lh: 21.7px;
  --br-small-ls: -0.006em;

  /* eyebrow / kicker — 11.5 / 21.7 / 700 / 0.1em / uppercase, flat */
  --br-eyebrow-size: 11.5px;
  --br-eyebrow-lh: 21.7px;
  --br-eyebrow-weight: 700;
  --br-eyebrow-ls: 0.1em;

  /* UI label (buttons, nav) — 16 / 24 / 600 / -0.011em, flat */
  --br-ui-size: 16px;
  --br-ui-lh: 24px;
  --br-ui-weight: 600;
  --br-ui-ls: -0.011em;

  /* form label — 13 / 20 / 600 */
  --br-label-size: 13px;
  --br-label-lh: 20px;
  --br-label-weight: 600;
  --br-label-ls: -0.006em;

  --br-weight-regular: 400;
  --br-weight-medium: 500;
  --br-weight-semibold: 600;
  --br-weight-bold: 700;
  /* The reference DECLARES 900 on every Archivo display heading (verified with
     getComputedStyle on the h1 and on display-1 / display-2 / display-3) while
     its Google Fonts request stops at 800. Chrome therefore renders all of them
     as Archivo 800 — there is no synthetic bolding above the heaviest loaded
     face. We declare the same 900 so the computed style matches, and we
     deliberately do NOT add 900 to the font request: 800 is the render Warren
     signed off. Adding 900 to the <link> would silently make every display
     heading a full weight step heavier than the approved design. Don't. */
  --br-weight-black: 900;

  /* ======================================================================
     4. SPACE
     Two systems, on purpose:
       · --br-space-*  fixed 4px steps — component internals (padding,
         gaps inside a card). Predictable, never surprises you.
       · --br-u + --br-flow-*  the fluid unit the reference is built on.
         ONE number drives section rhythm, card padding and big radii, and
         it scales with the viewport. Use these for anything structural.
     ====================================================================== */

  /* The fluid unit. Measured: 24px @360 → 28.1539px @1440 → 30px @1920.
     Perfectly linear between the caps — no breakpoints.

     Written as an exact fraction, not a rounded slope. The ramp is
     24px + (viewport - 360px)/260, because it climbs 6px over 1560px of
     viewport and 1560/6 = 260. The previous form truncated that slope to
     0.38461vw, which lands 0.0001px SHORT of 30px at 1920 — so the clamp
     never saturates, the derived grid gap computes 39.9999px instead of
     40px, and the grid's fr split snaps a whole 1/64px LayoutUnit. That
     moved every glyph in a two-column section 1/64px left of the reference
     and showed up as anti-aliasing drift in a pixel diff at 1920.
     The exact form now reproduces the reference's computed gap to the
     4th decimal at 1440 (37.5385), 1728 (39.0154) and 1920 (40) — it was
     off by one in the last place at all three. Below 1920 the change is
     under 0.0001px, i.e. far inside one LayoutUnit, so nothing else moves.

     ANCHORED IN rem 2026-08-18 (cover-section agent) — see THE rem RULE at
     the top of this file. The spacing system scales with the user's font
     size on the reference exactly as the type does, and this one token
     drives section rhythm, grid gutters, card padding and the big radii, so
     leaving it in px froze the whole page's layout as well as its text.
     Measured on the reference's panel radius and grid gap, which read --br-u
     and 4u/3 directly, at root 16/18/20/24/32 x 390/768/1024/1440 — 20 of 20
     points exact:
         1440  28.1539 / 30.9808 / 33.8077 / 39.4616 / 50.7692
          768  25.5692 / 28.3962 / 31.2231 / 36.8769 / 48.1846
          390  24.1154 / 27      / 30      / 36      / 48   (floor binds)
     The 260 divisor is a plain number, so the ramp keeps its exact-fraction
     form and 1.5rem/22.5rem/1.875rem are exact at root 16. Nothing moves at
     the default. */
  --br-u: clamp(1.5rem, calc(1.5rem + (100vw - 22.5rem) / 260), 1.875rem);

  --br-flow-3xs: calc(var(--br-u) / 3);        /*  9.385 @1440 */
  --br-flow-2xs: calc(var(--br-u) / 2);        /* 14.077 @1440 */
  --br-flow-xs: calc(var(--br-u) * 2 / 3);     /* 18.769 @1440 */
  --br-flow-sm: var(--br-u);                   /* 28.154 @1440 */
  --br-flow-md: calc(var(--br-u) * 4 / 3);     /* 37.538 @1440 */
  --br-flow-lg: calc(var(--br-u) * 2);         /* 56.308 @1440 */
  --br-flow-xl: calc(var(--br-u) * 3);         /* 84.462 @1440 */
  --br-flow-2xl: calc(var(--br-u) * 16 / 3);   /* 150.15 @1440 — widest measured gap */

  /* Vertical rhythm between sections. Measured: 56.3076 @1440 = 2u exactly. */
  --br-section-y: var(--br-flow-lg);
  --br-section-y-lg: var(--br-flow-xl);

  /* Card padding. Measured: 37.5385px 28.1539px @1440 = 4u/3 and 1u. */
  --br-card-py: var(--br-flow-md);
  --br-card-px: var(--br-flow-sm);

  /* Fixed 4px steps for component internals. */
  --br-space-0: 0;
  --br-space-1: 4px;
  --br-space-2: 8px;
  --br-space-3: 12px;
  --br-space-4: 16px;
  --br-space-5: 20px;
  --br-space-6: 24px;
  --br-space-7: 32px;
  --br-space-8: 40px;
  --br-space-9: 48px;
  --br-space-10: 56px;
  --br-space-11: 64px;
  --br-space-12: 80px;

  /* ======================================================================
     5. LAYOUT
     Measured container: content 358@390, 688@768, 864@1024, 1000@1200,
     1240@1440, 1400@1600, capped 1440@1920.
     => max content 1440px, gutter steps 16 / 40 / 80 / 100.
     ====================================================================== */
  --br-container-max: 1440px;      /* max CONTENT width, gutters sit outside it */
  /* Base (phone) gutter. CORRECTED 2026-08-18 (renewal-section agent): below
     576 the reference gutter is FLUID, not a flat 16 — it is exactly 2/3 u
     (--br-flow-xs) with a 16px floor. Measured container left edge:
         320 -> 16.00 (the floor; 2/3 u would give 15.90)
         360 -> 16.00     390 -> 16.077    480 -> 16.308
         540 -> 16.462    575 -> 16.551
     Flat 16px was exact at 360 but ran the container 0.6px wide by 480 —
     enough to re-break the last line of a paragraph. Stepped up at
     576 / 768 / 992 / 1200 below.

     The floor is 1rem, not 16px (cover-section agent, 2026-08-18):
     --br-flow-xs bottoms out at exactly 1rem — 2/3 of --br-u's 1.5rem floor
     — so a px floor would overtake it the moment the user raises their
     default font size, pinning the phone gutter while everything inside it
     grew. Measured on the reference at 390, the container narrows
     357.88 -> 354 -> 350 -> 342 -> 326 across root 16/18/20/24/32: the
     gutter tracks 2/3 u the whole way. Identical to the old value at root
     16. The STEPPED values below stay px — those are flat on the reference
     at every root size (container measured 688 @768, 864 @1024, 1240 @1440,
     unchanged from root 16 to root 32). */
  --br-gutter: max(1rem, var(--br-flow-xs));
  --br-container-outer: calc(var(--br-container-max) + (2 * var(--br-gutter)));

  /* NEW TOKEN, added 2026-08-19 (listing-template agent). Not measured off the
     reference, because the reference has nothing to measure: the signed-off
     home page carries no long-form body copy at all. Its two measure values —
     .br-measure 604 and .br-measure-wide 840 — are the widths of a centred
     intro paragraph and a centred heading block, not of running text.

     The inner pages need a third: 105 of them are prose (562 h2s, 1148 <p>,
     1086 <li> in the extracted content), and running text set to 840px at
     --br-body-size 18px is ~88 characters a line, well past the 45-75 band
     where a reader can find the next line without losing the current one.

     680px is derived, not picked: Inter's average lowercase advance is very
     close to 0.5em, so 75 characters at 18px is 75 x 9 = 675px. Rounded to
     680. Verified by counting: the longest paragraph in the extracted content
     sets 71-74 characters a line at 1440.

     In rem, not px, per THE rem RULE at the top of this file — a measure that
     does not grow with the user's font size is worse than no measure at all
     (at root 32 a flat 680px would hand back 37 characters a line). 42.5rem
     is exactly 680px at root 16, so nothing moves at the default. */
  --br-measure-prose: 42.5rem;     /* 680px @ root 16 — running body copy */

  --br-nav-h: 67px;                /* measured mobile header height */
  --br-nav-h-desktop: 76px;        /* measured desktop header height */

  /* ======================================================================
     6. RADIUS  (measured, and tied to the same fluid unit)
     ====================================================================== */
  --br-radius-xs: 2px;
  --br-radius-sm: 8px;             /* measured: form controls */
  --br-radius-md: 16px;
  --br-radius-card: 24px;          /* measured: the hero form card */
  --br-radius-lg: var(--br-u);     /* measured: 28.154 @1440 — content cards */
  --br-radius-xl: var(--br-flow-md); /* measured: 37.538 @1440 — full-width blocks */
  --br-radius-pill: 9999px;

  /* ======================================================================
     7. ELEVATION  (measured)
     ====================================================================== */
  --br-shadow-card: 0 24px 64px rgba(31, 25, 2, 0.16);
  --br-shadow-menu: 0 16px 40px rgba(31, 25, 2, 0.16);
  --br-shadow-sm: 0 8px 24px rgba(31, 25, 2, 0.10);  /* INFERRED — hover lift */
  --br-ring-hairline: inset 0 0 0 1px var(--br-border); /* measured: icon-circle ring */

  /* ======================================================================
     8. MOTION  (measured)
     ====================================================================== */
  --br-dur: 150ms;                 /* measured: buttons + inputs */
  --br-dur-slow: 350ms;            /* measured: navigation */
  --br-ease: ease-in-out;          /* measured: buttons */
  --br-ease-emphasis: cubic-bezier(0.8, 0.05, 0.2, 0.95); /* measured: navigation */

  /* ======================================================================
     9. CONTROL GEOMETRY  (measured)
     ====================================================================== */
  --br-btn-h-xs: 32px;             /* measured: the compact nav CTA */
  --br-btn-h-sm: 40px;
  --br-btn-h: 48px;                /* measured: THE canonical button on this page */
  --br-btn-h-lg: 56px;
  --br-btn-px-xs: 12px;            /* measured */
  --br-btn-px-sm: 20px;
  --br-btn-px: 24px;               /* measured */
  --br-btn-px-lg: 32px;
  --br-btn-min-w: 200px;           /* measured: hero + card CTAs share a min width */

  /* NOT measured off the reference — the reference fails it. This is the WCAG
     2.5.5 (AAA) / 2.5.8 (AA, with no spacing exception to lean on) minimum
     touch target, and it is already the number base.css argues from in the
     long comment on .br-btn's 48px: "the reference's button collapses to 34px
     tall at viewports <=320px, which fails the 44px minimum touch target".
     That figure was prose there and a literal everywhere else, so a control
     that wants the floor had to retype it.

     Named because the floor is now load-bearing in a second place — the
     article's back link, which is the only navigation control an article page
     owns on a phone — and because two shared controls are still under it
     (.br-nav__lang-toggle at 36px, .br-nav__cta at 32px). Whether to hold the
     line site-wide is a separate decision; when it is taken, this is the one
     value it moves. */
  --br-tap-min: 44px;

  --br-field-h: 49.7px;            /* measured: 13px pad + 21.7 lh + 13px pad + 2px border */
  --br-field-px: 14px;             /* measured */
  --br-field-py: 13px;             /* measured */
  --br-field-size: 15.5px;         /* measured */
  --br-field-weight: 500;          /* measured */
  --br-field-gap: 16px;            /* measured: gap between fields */
  --br-field-label-gap: 7px;       /* measured */

  --br-icon: 24px;                 /* measured: every inline icon is on a 24 grid */
  --br-icon-lg: 32px;              /* measured: the icon inside the 72px filled circle
                                      is 32px, not 24 — the pairing belongs with
                                      --br-icon-circle-lg, so it lives here rather
                                      than being restated by each section that uses it */
  --br-icon-circle: 48px;          /* measured: the trust-row outline circle */
  --br-icon-circle-sm: 40px;       /* measured: the small gold circle */
  --br-icon-circle-lg: 72px;       /* measured: the filled feature circle */
  /* CORRECTED 2026-08-18 (protection-row agent) from an inferred 1.75px.
     The reference's icons are filled paths, but every one of them is a
     constant-width band on a 24 grid, and that width is 2: its arcs run
     outer r7 / inner r5 and outer r5 / inner r3, and its bars are 2 units
     deep. Our redrawn set has to sit on the same stem or the whole page
     reads a shade lighter than the original. */
  --br-icon-stroke: 2px;
}

/* --------------------------------------------------------------------------
   Section-heading ramp, segments 2 and 3. See the --br-h2-size comment above
   for the measurements these come from. Kept next to the gutter steps so all
   the breakpoint-driven token changes live in one place.
   -------------------------------------------------------------------------- */
@media (min-width: 992px) {
  :root {
    /* h2 hero-scale, segment 2. See the --br-h2-lg-size comment above:
       continuous from the 42px tablet shelf at 992, 51.99 at 1199. The 53px
       ceiling is never reached inside this band and exists only so the
       expression cannot run away if the 1200 block is ever dropped. */
    --br-h2-lg-size: clamp(2.625rem, -0.3661750rem + 4.82448vw, 3.3125rem);

    --br-h2-size: clamp(2.3125rem, 0.952875rem + 2.192947vw, 2.625rem);
    --br-h2-lh: 57px;              /* measured: a hard step at 992, not a ramp */

    /* h3 card title, segment 2. See the --br-h3-size comment above. Linear to
       four decimal places across 992/1000/1010/1024/1100; the 24px ceiling is
       never reached inside this band (1199 -> 23.63) and exists only so the
       expression cannot run away if the 1200 block is ever dropped. */
    --br-h3-size: clamp(1.25rem, 0.1622750rem + 1.75439vw, 1.5rem);
    --br-h3-lh: 32px;              /* measured: a hard step at 992, not a ramp */
    --br-h3-ls: -0.015em;          /* measured: -0.01em below 992, -0.015em above */

    /* h4 / lead paragraph, segment 2. See the --br-h4-size comment above. */
    --br-h4-size: clamp(1.125rem, 0.58117375rem + 0.87714vw, 1.25rem);
    --br-h4-lh: max(28px, 1.35em); /* measured: a hard step at 992, not a ramp; floored, see base */

    /* Default paragraph, segment 2. See the --br-body-size comment above. */
    --br-body-size: clamp(1rem, 0.45617375rem + 0.87714vw, 1.125rem);
    --br-body-lh: max(26px, 1.35em); /* measured: a hard step at 992, not a ramp; floored, see base */
    --br-body-ls: 0.01em;          /* measured: 0.005em below 992, 0.01em above */

    /* Small print, segment 2 — the upper shelf. See the --br-body-sm-size
       comment above: this scale is two flat shelves rather than a ramp, and
       its tracking runs the OPPOSITE way to --br-body-ls. */
    --br-body-sm-size: 16px;
    --br-body-sm-lh: 24px;
    --br-body-sm-ls: 0.005em;

    /* Display-md, segment 2. See the --br-display-md-size comment above. */
    --br-display-md-size: clamp(2.875rem, 0.15568750rem + 4.38598vw, 3.5rem);

    /* Display-lg, segment 2. See the --br-display-lg-size comment above. */
    /* Segment 2, exact: (300vw - 2026px) / 19. Verified at 992/1000/1020/
       1050/1080/1100/1120/1150/1180/1199. The decimal form was 0.00007px low
       at 1106, which cost 0.075% of the section's pixels.

       CEILING CORRECTED 2026-08-18 (speak-section agent) from 6rem to 5.375rem.
       6rem was never measured — it was a runaway guard, written on the
       observation that the band tops out at 82.68px and so never reaches its
       cap. True at root 16 and ONLY at root 16: the vw term does not shrink
       when the root does, so as the root falls the middle term overshoots and
       the guard becomes the value. At root 12 / 1024 it handed back 72px
       against the reference's 64.5 — an 11.6% oversize that carried 74px of
       extra heading height into the section.

       Back-solved on the root axis (scripts/_speak-r2-seg2.mjs): 10 widths x
       9 root sizes = 90 cells, 36 of them ceiling-bound, and all 36 agree on
       5.375rem to six decimal places. Max error over the whole grid falls from
       8.75px to 0.00007px. 5.375rem is 86px at root 16 — segment 3's measured
       floor exactly, so the two segments meet without a step, which is the
       corroboration that this is the reference's own number and not a fit.
       Unreachable at root 16, so nothing moves at the default. */
    --br-display-lg-size: clamp(3.125rem, calc((300vw - 126.625rem) / 19), 5.375rem);

    /* Display-xl, segment 2. See the --br-display-xl-size comment above.
       No cap needed inside this band — it tops out at 92.32px at 1199. */
    --br-display-xl-size: clamp(3.5rem, -7.37716875rem + 17.54383vw, 7.875rem);
  }
}
@media (min-width: 1200px) {
  :root {
    /* h2 hero-scale, segment 3. Same story as the display sizes below: the
       53px floor is measured, not padding — the reference holds 53 flat from
       1200 to 1220, then resumes and caps at 78 exactly at 1920. */
    --br-h2-lg-size: clamp(3.3125rem, 0.58931250rem + 3.57141vw, 4.875rem);

    --br-h2-size: clamp(2.625rem, 1.4268rem + 1.57142vw, 3.3125rem);

    /* h3 card title, segment 3. Same story as the display sizes below: the
       24px floor is measured, not padding — the reference holds 24 flat from
       1200 to 1220 and only then resumes, capping at 26 exactly at 1920. */
    --br-h3-size: clamp(1.5rem, 1.28210625rem + 0.28575vw, 1.625rem);

    /* Display-md, segment 3. The 56px floor is measured, not padding: the
       reference holds 56 flat from 1200 to 1220 and only then resumes.

       REFINED 2026-08-18 (industries-section agent), same method as segment 1
       — exact rational arithmetic instead of a decimal fit — and note the
       OPPOSITE outcome to display-lg below, which is the whole point of
       measuring rather than deriving. Display-lg's reference stops at 95.999944
       and never takes its cap, so that token reproduces the miss. Display-md's
       reference reaches exactly 64px at 1920 and DOES take its cap; the decimal
       this replaces stopped at 63.99994 and reached 64 only at 1921.

       (8vw + 18.4rem)/7 lands on both knees exactly, because 7 divides both:
       at 1220 it is 392/7 = 56, so the floor releases without a step, and at
       1920 it is 448/7 = 64, so the cap is reached and not merely approached.
       Verified by ink at 1200/1210/1220/1221/1250/1300/1360/1400/1440/1500/
       1600/1700/1800/1900/1919/1920/1921/2000/2200 — every line rect identical
       to the reference. The old decimal diverged at 1360, 1500 and 1920. */
    --br-display-md-size: clamp(3.5rem, calc((8vw + 18.4rem) / 7), 4rem);

    /* Display-lg, segment 3. Same story as display-md: the 86px floor is
       measured — the reference holds 86 flat from 1200 to 1220. */
    /* Segment 3. The exact rational form here is (10vw + 480px) / 7, and it
       is deliberately NOT used: at 1920 it evaluates to exactly 672/7 = 96 and
       takes the cap, where the reference's own arithmetic stops at 95.9999 and
       does not. Matching the reference beats matching the maths — the decimal
       below reproduces its 95.999944 and is within 0.00005px of the exact line
       at every other width. Verified at 1200/1220/1250/1300/1400/1440/1500/
       1600/1700/1800/1900/1920/2000. */
    --br-display-lg-size: clamp(5.375rem, 4.2857125rem + 1.42857vw, 6rem);

    /* Display-xl, segment 3. Same story again: 96 is held flat from 1200 to
       1220, then the ramp resumes and caps at 126 exactly at 1920. */
    --br-display-xl-size: clamp(6rem, 2.73214375rem + 4.285714vw, 7.875rem);
  }
}

/* --------------------------------------------------------------------------
   Container gutter steps — measured breakpoints, not guessed.

   CORRECTED 2026-08-18 (renewal-section agent). Walked the reference
   container's left edge at 320/360/390/480/540/575/576/600/700/767/768/800/
   900/991/992/1000/1023/1024/1100/1199/1200/1280/1440/1600/1920. The real
   step table is:

       <576      ~16   (fluid: it is exactly 2/3 u — 16.00 @360, 16.55 @575;
                        held at a flat 16 here, which is 0.08px off at 390
                        and not worth a fluid token)
       576–767    32   <- WAS MISSING: the container jumped straight 16 -> 40
       768–991    40
       992–1199   80   <- WAS 1024: the step fires at 992, not 1024
       ≥1200     100   (content caps at --br-container-max, gutters grow)

   The two errors only bit between 576–767 (32px too narrow a gutter, so
   every section ran 32px wide) and 992–1023 (40px too narrow, 80px wide).
   All four judged widths — 390 / 768 / 1024 / 1440 — were already correct
   and are untouched by this fix.
   -------------------------------------------------------------------------- */
@media (min-width: 576px)  { :root { --br-gutter: 32px; } }
@media (min-width: 768px)  { :root { --br-gutter: 40px; } }
@media (min-width: 992px)  { :root { --br-gutter: 80px; } }
@media (min-width: 1200px) { :root { --br-gutter: 100px; } }

/* ==========================================================================
   DARK SURFACE SET
   Put .br-on-dark on any block that sits on ink or on photography. Every
   shared component below reads the semantic aliases, so buttons, hairlines,
   eyebrows and focus rings all flip correctly with no extra CSS.
   ========================================================================== */
.br-on-dark {
  --br-text: var(--br-on-dark);
  --br-text-heading: var(--br-gold);
  --br-text-strong: var(--br-white);
  --br-text-muted: rgba(255, 255, 255, 0.72);
  --br-text-accent: var(--br-gold);
  --br-text-invert: var(--br-ink);

  --br-bg: var(--br-ink);
  --br-bg-surface: var(--br-bg-dark-alt);
  --br-bg-band: rgba(255, 255, 255, 0.06);
  --br-bg-band-alpha: var(--br-white-a10);
  --br-bg-wash: rgba(255, 255, 255, 0.06);

  --br-border: rgba(255, 255, 255, 0.18);
  --br-border-strong: var(--br-white);
  /* Raised in step with the light-surface token (see the note there). White at
     0.28 composites to rgb(94,89,73) on ink = 2.51:1, the same 1.4.11 failure
     the light scope had. 0.46 lands at 4.60:1. Hover brightens rather than
     darkens here — that is the direction that adds contrast on ink.

     Parity note, round 5: 0.46 was chosen to match the light side when the
     light side was 4.54:1. Light is now 3.03:1 (DECISIONS item 9), so this
     scope is currently the heavier of the two. Left alone rather than
     re-measured blind, because NO section renders a control on dark today and
     the error direction here is "too legible". If a dark control ever ships,
     drop this to ~0.34 alpha (3.03:1 on #1f1902) to restore the parity the
     line above claims, and re-measure with scripts/_fin-border.mjs. */
  --br-border-control: rgba(255, 255, 255, 0.46);
  --br-border-control-hover: rgba(255, 255, 255, 0.72);

  /* Ink is invisible on ink — the ring goes gold, which clears AAA on #1f1902. */
  --br-focus: var(--br-gold);
  --br-focus-halo: rgba(241, 195, 5, 0.35);

  /* THE GOLD INTERACTIVE RAMP INVERTS ON DARK.
     On white, gold DARKENS under the pointer (#f1c305 -> #d6ac00 -> …) so the
     pill separates itself from the paper. Run that same move on ink and it
     reads as a disabled control: the button sinks into the card instead of
     lighting up. The reference inverts the ramp, theme-scoped, and so do we.

     Measured with a real mouse rather than read out of the reference's CSS
     (_r5-alldark3.mjs). EVERY gold control on a #1f1902 surface runs the
     identical ramp — the industries block's "Browse industries", both
     testimonial review buttons, and the footer's "About Broad Risk":

         rest #f1c305  ->  hover #f8dc7a  ->  active #fbf3d4

     Until these two lines existed the light-surface ramp leaked onto every
     dark surface, breaking the promise made at the top of this block that
     components "flip correctly with no extra CSS". Nothing light is touched:
     the re-point only resolves inside .br-on-dark, light gold pills still
     hover #d6ac00, and the reference has no outline or ghost gold control on
     a dark surface that could disagree (verified in _r5-outline.mjs). */
  --br-gold-hover: #f8dc7a;
  --br-gold-active: #fbf3d4;

  --br-ghost-hover-bg: var(--br-white-a12);  /* measured on the hero photo */
  --br-ghost-hover-color: var(--br-white);
  --br-ghost-press-bg: var(--br-white-a12);  /* ink wash is invisible on ink */
  --br-ghost-press-color: var(--br-white);   /* #0e0f0c on a photograph would be a hole */

  /* The gold link gets a heavier press plate than the plain ghost button —
     0.2 against 0.12 — and both are measured, not derived (_r5-press.mjs).
     It is the only press feedback a touch user gets on that control. */
  --br-ghost-accent-press-bg: var(--br-white-a20);

  color: var(--br-text);
}

/* Hero treatment: the photo lives under this exact measured overlay.

   BLUE WAS 2, AND 2 IS WHY EVERY PHOTOGRAPH READ SEPIA. At 0.84 opacity an ink
   with no blue does not darken the picture's blue, it deletes it and
   substitutes its own hue — measured 43-60° at 25-52% saturation across the
   hero, which is the definition of a sepia wash. The photograph was never
   graded that way; the overlay was doing it.

   16 is the correction. Red and green are untouched to the digit, so nothing is
   desaturated or re-graded — only the blue the ink was erasing comes back. Mean
   saturation 36.3% -> 12.5%, and every sampled point stays warm (31-63°): at 18
   the sky flips cool, so 16 is the last warm value. Blue carries 0.0722 of
   relative luminance, so the plate the white type sits on barely moves —
   contrast measured 7.36:1 and 9.42:1 at 1440, AAA either side of the change.

   Warren's own live site puts a NEUTRAL overlay on this same photograph
   (#000000E0 in site-archive/index.html), so this is closer to what he has now,
   not further from it.

   FIRST CORRECTION WAS NOT ENOUGH, AND THIS RECORDS WHY. Blue 2 -> 16 reduced
   the cast without removing it, because the ink is still the brand's warm
   #1F1902 rather than black — it was treating a hue problem as a channel
   problem. The founder read it correctly on sight: "just a semi opaque black
   layer… you have added some other colour layer on top of it."

   HIS ACTUAL OVERLAY, off his live home page:
       linear-gradient(90deg, #000000E0 0%, #00000082 100%)
   Pure black, and HORIZONTAL — 88% at the left where the headline sits, fading
   to 51% at the right. Ours was warm ink, vertical, and near-uniform at 84/78,
   so it was wrong twice over: the colour put a hue on the photograph, and the
   even opacity flattened it edge to edge instead of letting the right-hand
   side of the picture come through.

   Both now match his. The photograph itself was never in question — ours is
   byte-identical to the file on his server.

   NAMED AT :root SO THERE IS ONE OF IT. The correction above was applied here
   and NOT to the city-page mastheads, which kept their own copy of the old
   warm-ink wash — so for two days the home page was black and the four
   location pages were still sepia, under a comment claiming they matched.
   Two copies of a value that must agree is how that happens. One definition,
   every consumer points at it. */
:root {
  --br-photo-wash: linear-gradient(90deg, rgba(0, 0, 0, 0.88) 0%, rgba(0, 0, 0, 0.51) 100%);

  /* THE SAME INK WITHOUT THE DIRECTION, for a picture small enough that a
     gradient across it would read as uneven printing rather than as light.
     0.52 is the horizontal wash's own mean (0.88 -> 0.51 is not linear in
     perceived terms, so this was set by eye against the mastheads at card
     size, not by averaging the stops), and -0.14 on hover is the smallest
     step that reads as a change at 384px. */
  --br-photo-wash-flat: rgba(0, 0, 0, 0.52);
  --br-photo-wash-flat-hover: rgba(0, 0, 0, 0.38);
}

.br-on-photo {
  --br-photo-overlay: var(--br-photo-wash);
}

/* PHOTOGRAPHY IS NOT AN INK SLAB — the gold ramp does not invert on it.
   Added 2026-08-18 (testimonials agent) after measuring the one control the
   .br-on-dark note above could not have covered: the hero's own "Get a quote",
   which sits inside .br-on-photo > .br-on-dark and so was inheriting the
   inverted ramp.

   The reference disagrees, and it is emphatic about it — 1.5s settle, two
   independent runs:

       hero "Get a quote" over the photo   rest #f1c305 -> hover #d6ac00
       every gold pill on an ink slab      rest #f1c305 -> hover #f8dc7a

   Same colour, same component, opposite direction, and the only thing that
   differs is what is behind it. That is not an oversight in the donor design:
   the overlay is 84% ink over a photograph, so there is still image detail
   showing through, and a pill that goes PALER on it collides with the bright
   parts of the picture instead of separating from them. On a flat #1f1902
   slab there is nothing to collide with, so lightening wins. Both are right;
   they are right about different backgrounds.

   .br-on-dark stays on the hero intro — it is what makes the copy, the
   hairlines and the gold focus ring correct on the photo. Only the two press
   tokens are handed back, by name, so this rule cannot drift from the
   light-surface ramp if that ramp is ever re-measured. */
.br-on-photo .br-on-dark {
  --br-gold-hover: var(--br-gold-hover-base);
  --br-gold-active: var(--br-gold-active-base);
}

/* ==========================================================================
   LIGHT SURFACE SET — the escape hatch.
   The page nests light inside dark constantly (white cards on the gold band,
   white cards inside the dark blocks). Put .br-on-light on any light island
   inside an inverted parent to restore the default token set.

   Exception, and it is deliberate: body copy inside a white card on the GOLD
   band stays #3a341c in the reference, so .br-on-gold .br-card keeps the warm
   text unless you explicitly add .br-on-light.
   ========================================================================== */
.br-on-light {
  --br-text: var(--br-neutral-700);
  --br-text-heading: var(--br-ink-heading);
  --br-text-strong: var(--br-ink);
  --br-text-muted: var(--br-neutral-600);
  --br-text-accent: var(--br-gold-ink);
  --br-text-invert: var(--br-white);

  --br-bg: var(--br-white);
  --br-bg-surface: var(--br-white);
  --br-bg-band: var(--br-neutral-100);
  --br-bg-band-alpha: var(--br-ink-a08);
  --br-bg-wash: var(--br-gold-wash);

  --br-border: var(--br-hairline-a);
  --br-border-strong: var(--br-ink);
  /* Restated to track the root scope, not left at the old #d9d9d9 — this
     block exists to be a white island inside .br-on-dark, so a control placed
     in it sits on the same white the root token was measured against and must
     clear the same 3:1. Keep these two in lockstep — they were lightened
     together in round 5; the whole argument is on the root token above. */
  --br-border-control: #949494;
  --br-border-control-hover: #767676;

  --br-focus: var(--br-ink);
  --br-focus-halo: rgba(241, 195, 5, 0.35);

  --br-ghost-hover-bg: transparent;
  --br-ghost-hover-color: var(--br-ink-hover);
  /* Restated, not inherited: this set exists to be a light island inside
     .br-on-dark, which hands both of these to white. */
  --br-ghost-press-bg: var(--br-ink-a13);
  --br-ghost-press-color: var(--br-ink-active);

  /* Restated for the same reason as --br-ghost-press-bg above: the whole point
     of this class is to be an island inside .br-on-dark, and .br-on-dark
     inverts the gold press ramp. Without these two, a gold pill on a white
     card inside an ink block would lighten on hover like the ink block's own
     pills while sitting on paper — the one place the reference darkens. No
     section uses .br-on-light yet; the escape hatch has to be complete before
     one does, not after. */
  --br-gold-hover: var(--br-gold-hover-base);
  --br-gold-active: var(--br-gold-active-base);

  color: var(--br-text);
}

/* ==========================================================================
   GOLD SURFACE SET
   Put .br-on-gold on the full-bleed gold band. Body copy darkens, ink
   stays ink, and the focus ring stays ink (which is the highest-contrast
   option available on #f1c305).
   ========================================================================== */
.br-on-gold {
  --br-text: var(--br-ink-on-gold);
  --br-text-heading: var(--br-ink-heading);
  --br-text-strong: var(--br-ink);
  --br-text-muted: var(--br-ink-on-gold);
  --br-text-accent: var(--br-ink);
  --br-text-invert: var(--br-gold);

  --br-bg: var(--br-gold);
  --br-bg-surface: var(--br-white);
  --br-bg-band: rgba(31, 25, 2, 0.08);
  --br-bg-wash: rgba(255, 255, 255, 0.5);

  --br-border: rgba(31, 25, 2, 0.16);
  --br-border-strong: var(--br-ink);
  /* Same 1.4.11 correction as the other two scopes. Gold is a light surface,
     so the boundary has to be ink-heavy to separate from it: 0.24 alpha is
     only 1.60:1 against #f1c305, 0.65 is 4.36:1. Hover goes to full ink
     (10.5:1), which is where it already was. */
  --br-border-control: rgba(31, 25, 2, 0.65);
  --br-border-control-hover: var(--br-ink);

  --br-focus: var(--br-ink);
  --br-focus-halo: rgba(31, 25, 2, 0.22);

  /* On gold the hover plate is already 8% ink, so press has to clear it to
     read as a second step — hence a13 here too, and a label move the hover
     does not make (hover holds --br-ink; press goes to --br-ink-active).
     Derived from the light-surface measurement, not separately measured: the
     reference has no ghost button on its gold band to measure. */
  --br-ghost-hover-bg: rgba(31, 25, 2, 0.08);
  --br-ghost-hover-color: var(--br-ink);
  --br-ghost-press-bg: var(--br-ink-a13);
  --br-ghost-press-color: var(--br-ink-active);

  color: var(--br-text);
}

/* ==========================================================================
   LONG-FORM PROSE
   Added 2026-08-19 (industry-template agent). Everything above this line was
   measured off the signed-off home page. The home page has no article on it —
   its longest single run of copy is a three-line lead — so it never had to
   answer two questions that 105 content pages ask immediately.
   ========================================================================== */

:root {
  /* --- THE TWO MEASURED CAPS, PROMOTED FROM base.css -----------------------
     604 and 840 were already in the system as .br-measure / .br-measure-wide
     (base.css §3), measured off the reference as the two constrained widths
     it uses. They are tokens now because they have a second consumer: the
     templates cap a hero title, a lead, a reading column and a slab heading
     against them, and a template that restates `604px` is a template that
     silently disagrees with base.css the day the reference is re-measured.
     The two classes in base.css read these — same pixels, one source. */
  --br-measure: 604px;
  --br-measure-wide: 840px;

  /* --- THE PROSE HEADING RUNG ---------------------------------------------
     The scale has a section-heading rung at 45.46px (--br-h2-size at 1440)
     and then drops straight to 24.6px (--br-h3-size). On the home page that
     gap is invisible, because an h2 there is always the title of a whole
     band and there is never a second one inside it.

     In an article there is. /industry/hospitality-industry/ carries four h2s
     in 2.6 KB of copy; /industry/plumbers/ carries eight plus two h3s. Set at
     the section rung, "Why Hospitality Businesses Need Insurance:" sets three
     lines of 45px type in a 604px column, every 150 words — the page stops
     reading as an article and starts reading as a stack of posters. Set at
     the h3 rung it is indistinguishable from the h3s beneath it.

     So: one rung between them, 23px on a phone to 34px at 1440. It sits a
     clean step under the 45.46px section headings the page furniture uses
     and a clean step over the 24.6px h3s inside the article, which is exactly
     the job. Written to THE rem RULE at the top of this file — every px is
     n/16 rem, only the vw term stays vw — so it responds to the browser's
     default font size like everything else here.

     Continuity check at the breakpoint, root 16px: the base ramp reaches its
     28px ceiling at 696px and holds it to 992; the >=992 ramp starts at
     exactly 28.0px and reaches exactly 34.0px at 1440. No step at the seam.

     Named --br-prose-* rather than --br-industry-*: the service, insurance,
     page and post templates all set the same kind of copy and must land on
     the same rung. */
  --br-prose-h2-size: clamp(1.4375rem, 1.02644rem + 1.66667vw, 1.75rem);
  --br-prose-h2-lh: 1.2;
  --br-prose-h2-ls: -0.02em;
}

@media (min-width: 992px) {
  :root {
    --br-prose-h2-size: clamp(1.75rem, 0.91964rem + 1.33929vw, 2.125rem);
  }
}

/* ==========================================================================
   PROSE HEADING STEP — added 2026-08-19 (article-template agent)
   --------------------------------------------------------------------------
   The only value in this file that was NOT measured off the reference, and
   the comment says so rather than dressing it up: the reference has no page
   to measure it on.

   Why it has to exist. The heading scale above runs

       h2 section  45.457   --br-h2-size
       h3 card     24.629   --br-h3-size
       h4 / lead   20.000   --br-h4-size

   with a 20.8px hole between the first two, because the home page never
   stacks more than two heading levels inside one column — a section heading
   and a card title, in different boxes. A prose page does. The 39 blog posts
   carry 156 h2s, 104 h3s and 16 h4s in running copy under an h1, so the
   article template needs FOUR distinct steps below its title and the scale
   only offers three. Setting the article's body h2 at 45.457 would put the
   page title's own size on a heading four paragraphs in; setting it at 24.629
   would collapse it into the h3 under it.

   32px at 1440 is the step that keeps the ladder legible — 45.457 / 32 /
   24.629 / 20 / 18, ratios 1.42 / 1.30 / 1.23 / 1.11, tightening as it
   descends the way the rest of the scale does.

   Written as exact rational arithmetic in rem, in the idiom the file already
   uses for --br-display-md-size segment 3, so both knees land ON their value
   rather than approaching it: (5vw + 9.5rem) / 7 is 24.000 at exactly 320 and
   32.000 at exactly 1440. Nothing to round, nothing to miss.

   The leading is a UNITLESS ratio, deliberately, and this is the one place
   this file gets to do that. Every px leading above exists to reproduce a
   measured reference and is then floored in em to survive a user font-size
   change (see LINE-HEIGHTS ARE FLOORED at the top). This token has no
   reference to reproduce, so it can simply be correct: 1.25 scales with its
   own font-size at every root size and can never collide. At root 16 / 1440
   it computes 40px, which is the number a measured ramp would have landed on.

   Tracking interpolates the scale either side of it: -0.03em at 45.457,
   -0.015em at 24.629, so -0.02em at 32.

   NAMED FOR THE TEMPLATE, not for prose generally. If the other page types
   being built now (insurance, industry, the FAQ) turn out to want the same
   step, rename this trio to --br-prose-h2-* and share it — one step used by
   five templates is a scale, five near-identical steps is a mess. Kept
   article-scoped today so two templates cannot silently define the same name
   with different numbers.

   ---- 2026-08-19, standalone-page agent: THE THING ABOVE HAS HAPPENED -----
   --br-prose-h2-* already exists, 60 lines up, added the same day by the
   industry-template agent and named for exactly the sharing this comment
   asks for. It is the rung the industry and standalone-page templates both
   read. So the site now carries two long-form h2 rungs:

       --br-prose-h2-*    34.0px @1440, lh 1.2,  ls -0.02em   industry, page
       --br-article-h2-*  32.0px @1440, lh 1.25, ls -0.02em   article

   Two steps 2px apart is the mess this comment predicted. Reconciling them is
   a one-line change to whichever loses, but it re-renders either 39
   signed-off blog posts or the industry set, so it is a decision to take
   deliberately and not a tidy-up to do in passing. NOT reconciled here;
   recorded so the next person is choosing rather than discovering. New
   long-form templates should read --br-prose-h2-*, which is the one whose
   name says what it is for.
   ========================================================================== */
:root {
  --br-article-h2-size: clamp(1.5rem, calc((5vw + 9.5rem) / 7), 2rem);
  --br-article-h2-lh: 1.25;
  --br-article-h2-ls: -0.02em;
}