/* ============================================================================
   SECTION 01 · "1.0 Who and why " · Figma 2742:444
   ----------------------------------------------------------------------------
   Spec:   figma-truth/01-who-why.spec.md
   Pixels: figma-truth/sections-en/01-who-why.png (2560x1374, @2x)
   Lift:   salient-truth/saas/inline-styles.css  (extracted from the six inline
           <style> blocks of http://127.0.0.1:5010/salient/saas/index.html)

   Two parts, deliberately separated:
     PART 1  was Salient's own element CSS. HOISTED to
             css/salient-elements.css — it was duplicated verbatim here, in
             00-hero.css and in 09-recovery-42.css.
     PART 2  the Mykrobial retarget — Figma's type, colour and geometry.
   ========================================================================== */


/* The `.nectar-split-heading` block that used to sit here is HOISTED to
   css/salient-elements.css — it was duplicated verbatim in 00-hero.css,
   01-who-why.css and 09-recovery-42.css, and one of the three copies had
   dropped a media wrapper. That file loads before every section sheet, so
   the cascade is unchanged. Do not paste it back. */
/* ============================================================================
   PART 2 — MYKROBIAL RETARGET
   Every literal below cites the spec line it came from. Nothing is eyeballed.
   ========================================================================== */

/* ----------------------------------------------------------------------------
   2.1 · The band
   -------------------------------------------------------------------------- */

/* Section root 2742:444. Fill #f4f9fb, SOLID, opacity 1 — spec §3.1.
   strokeWeight is 1 in the payload but there is NO strokes array, so nothing
   is painted (spec §1.2). Do not add a border. */
.mk-who-why {
  background-color: var(--mk-surface-mist);
}

/* Inner wrapper 2742:445 "Text". Padding 120 on all four sides (spec §1.3).
   The horizontal 120 is .mk-container's --mk-page-x; only the vertical is
   declared here. Height is HUG and must stay auto — ES reflows the body to 8
   lines and the section becomes 723 (spec §1.3). Never pin 687. */
.mk-who-why__text {
  padding-block: 120px;                 /* §1.3 paddingTop / paddingBottom = 120 */
}

/* itemSpacing 48 (spec §1.3). Salient's own stack rhythm is
   `.wpb_wrapper>div{margin-bottom:24px}` (+ `>div:last-child{margin-bottom:0}`)
   in vendor/.../style.q-98889c766d.css — this retargets that mechanism to
   Figma's value rather than inventing a second one. */
.mk-who-why__text > .wpb_wrapper > .wpb_row            { margin-bottom: 48px; }
.mk-who-why__text > .wpb_wrapper > .wpb_row:last-child { margin-bottom: 0; }

/* The 120px inset is .mk-container's and nothing may add to it. MEASURED, not
   guessed: Salient's grid-system.q-dcb972ee3c.css carries
     `.vc_row-fluid > .span_12 .wpb_column{padding-left:1%;padding-right:1%}`
   which is 10.4px a side on a 1040 row. Left in place it narrows the measure to
   1019.2 and the body reflows from Figma's 7 lines to 8 (spec §2.1: box
   1040x252 = 7 x 36) — i.e. it silently changes the section height.
   The override needs three classes to out-specify that selector; CONVENTIONS §8.6
   says name the rule that forced it, so: that one. No !important needed. */
.mk-who-why .wpb_wrapper > .wpb_row.inner_row,
.mk-who-why .wpb_row.inner_row > .row_col_wrap_12_inner,
.mk-who-why .row_col_wrap_12_inner > .wpb_column,
.mk-who-why .wpb_column > .vc_column-inner {
  margin-left: 0;
  margin-right: 0;
  padding-left: 0;
  padding-right: 0;
}

/* ----------------------------------------------------------------------------
   2.2 · Overline — 2742:447
   Poppins Light 300 / 16 / lineHeight AUTO -> 24 / letterSpacing 3 PIXELS /
   textCase UPPER / fill #000000 / textAlign CENTER / box 1040x24 @ (120,120).
   The role base (.mk-eyebrow) already carries family, weight, size, 24px line
   box, +3px tracking and text-transform: uppercase — tokens.css.
   -------------------------------------------------------------------------- */

.mk-who-why__overline {
  margin: 0;
  color: var(--mk-ink-strong);          /* §3.1 — pure #000, NOT --mk-ink-body */
  text-align: center;                   /* §2.1 textAlignHorizontal CENTER */

  /* padding-bottom kills Salient's `p{padding-bottom:var(--nectar-paragraph-
     bottom-spacing,1.5em)}` (skin-material.q-2c163bc272.css), which was adding
     24px below the overline and breaking the 120/24/48 rhythm.

     padding-left: CSS emits letter-spacing after the LAST character too; Figma
     does not count it when centring. Measured, not assumed: in the @2x render
     the overline ink spans x 943..1616 of 2560 — centre 1280.0, i.e. dead
     centre of the frame. Plain text-align:center lands the ink 1.5px left (half
     of one 3px tracking unit). Padding the box by exactly one tracking unit
     cancels it. CONVENTIONS §8.3 flags the trap and forbids taking the drift
     silently. */
  padding: 0 0 0 var(--mk-track-eyebrow);
}

/* ----------------------------------------------------------------------------
   2.3 · Heading — 2742:449
   Merriweather Light 300 / 60 / lineHeight AUTO -> 75 (ratio 1.25) /
   letterSpacing absent -> 0 / fill #29101e / textAlign CENTER / box 1040x75.
   -------------------------------------------------------------------------- */

.mk-who-why__heading {
  /* 60 and 75 are section-01-only literals; §2.1. `--mk-size-display` is 48 and
     `--mk-lh-display` 60 — different role, do not borrow them. The size lives on
     the WRAPPER because Salient's data-custom-font-size="true" rule makes the
     h2 `font-size: inherit; line-height: inherit`
     (css/salient-elements.css, min-width:1000). */
  font-size: 60px;                      /* §2.1 fontSize 60 */
  font-family: var(--mk-font-serif);
  font-weight: var(--mk-w-light);       /* §2.1 fontStyle Light / weight 300 */
}

/* Salient generates one `font_line_height_1-<n>` utility per authored value and
   the vendored set has 1-3 and 1-8 but no 1-25. This is that same rule shape at
   Figma's ratio. It has to be !important and it has to reach `*`, because
   css/salient-elements.css puts line-height:1.2 on the generated word spans
   and 1.2 x 60 = 72,
   which would cost 3px of the 75px line box (spec §2.1, box height 75). */
.mk-who-why__heading,
.mk-who-why__heading * { line-height: 75px !important; }

/* Two classes deep on purpose. tokens.css carries
   `.mk-page :is(h1,h2,h3,.mk-serif){...}`; :is() takes the specificity of its
   most specific argument (.mk-serif), so that rule is (0,2,0) and a plain
   `.mk-who-why__heading h2` at (0,1,1) loses to it — measured, the opsz
   override below was silently discarded until this selector was widened. */
.mk-who-why .mk-who-why__heading h2 {
  margin: 0;                            /* §1.3 — the 48 gap is the wrapper's */
  color: var(--mk-ink-plum);            /* §3.1 #29101e — section 01 ONLY */
  font-weight: var(--mk-w-light);
  letter-spacing: 0;                    /* §2.1 letterSpacing absent -> 0 */
  text-align: center;                   /* §2.1 textAlignHorizontal CENTER */
  text-transform: none;                 /* §2.1 textCase ORIGINAL */

  /* OPTICAL SIZE — the local override that used to live here is GONE. It said
     Figma renders this 60px heading at opsz = font-size, and it was right:
     re-measured in the page-wide sweep, Figma ink 772.50 vs opsz 18's 823.00
     (+6.54 %) vs auto's 772.50 (+0.00 %). That is now the global rule, so
     restating it here would be duplication, not defence. See tokens.css
     "MERRIWEATHER OPTICAL SIZE" and NOTES.md §F3.

     The two-classes-deep selector above is still required for the OTHER
     declarations in this rule — tokens.css's `.mk-page :is(h1,h2,h3,.mk-serif)`
     is (0,2,0) because :is() takes its most specific argument, so a plain
     `.mk-who-why__heading h2` at (0,1,1) would lose. Do not narrow it. */
}

/* ----------------------------------------------------------------------------
   2.4 · Body — 2742:450
   Poppins Regular 400 / 20 / lineHeight 179.99999523162842 PERCENT -> 180% /
   letterSpacing absent -> 0 / fill #1a2328 / textAlign CENTER /
   box 1040x252 = 7 lines x 36 (spec §2.1; 252/36 = 7 exactly).
   -------------------------------------------------------------------------- */

.mk-who-why__body {
  margin: 0;
  padding: 0;                           /* kills Salient's p{padding-bottom:1.5em}
                                           = 30px at 20px — skin-material.css */
  font-family: var(--mk-font-sans);
  font-weight: var(--mk-w-regular);
  font-size: var(--mk-size-body);       /* 20 */
  line-height: var(--mk-lh-body);       /* 180% -> 36. Figma's float is binary
                                           noise for 180 — spec §2.1. */
  letter-spacing: 0;
  color: var(--mk-ink-body);            /* §3.1 #1a2328 */
  text-align: center;                   /* §2.1 textAlignHorizontal CENTER */
}


/* ============================================================================
   3 · RESPONSIVE
   ----------------------------------------------------------------------------
   READ TRUTH is two frames only: EN@1280 and ES@1440. Between them nothing
   scales — padding 120, itemSpacing 48, 60px heading, 20/1.8 body are all
   byte-identical; only the measure narrows and the body reflows (spec §5.2).
   So there is nothing to declare above 1280.

   EVERYTHING BELOW IS INFERRED. Spec §5.1 is explicit: there is no tablet or
   mobile frame for this section in the Figma file, and §5.3's table is a
   reasoned recommendation that "needs founder sign-off before shipping".
   Values below are §5.3's, unchanged.

   ONE KNOWN DIVERGENCE, stated rather than smoothed over: §5.3 also recommends
   a side padding of 80 / 64 / 24 at its breakpoints. --mk-page-x is owned
   page-wide by grid.css (64 at <=1049, 48 at <=1024, 24 at <=640) and a section
   must not fork it, so the horizontal inset here follows grid.css, not §5.3.
   Raised in NOTES.md.
   ========================================================================== */

@media (max-width: 1279px) {          /* INFERRED — spec §5.3 row "1024-1279" */
  .mk-who-why__text { padding-block: 96px; }
  .mk-who-why__text > .wpb_wrapper > .wpb_row { margin-bottom: 40px; }
  .mk-who-why__heading { font-size: 52px; }
  .mk-who-why__heading,
  .mk-who-why__heading * { line-height: 65px !important; }   /* 52 x 1.25 */
}

@media (max-width: 1023px) {          /* INFERRED — spec §5.3 row "768-1023" */
  .mk-who-why__text { padding-block: 72px; }
  .mk-who-why__text > .wpb_wrapper > .wpb_row { margin-bottom: 32px; }
  .mk-who-why__heading { font-size: 44px; }
  .mk-who-why__heading,
  .mk-who-why__heading * { line-height: 1.3 !important; }
  .mk-who-why__overline { font-size: 14px; letter-spacing: 2.5px; padding-left: 2.5px; }
  .mk-who-why__body { font-size: 18px; line-height: 1.75; }
}

@media (max-width: 767px) {           /* INFERRED — spec §5.3 row "< 768" */
  .mk-who-why__text { padding-block: 56px; }
  .mk-who-why__text > .wpb_wrapper > .wpb_row { margin-bottom: 24px; }
  .mk-who-why__heading { font-size: 34px; }
  .mk-who-why__heading,
  .mk-who-why__heading * { line-height: 1.3 !important; }
  .mk-who-why__overline { font-size: 13px; letter-spacing: 2px; padding-left: 2px; }
  .mk-who-why__body { font-size: 17px; line-height: 1.7; }
}


/* ============================================================================
   4 · REDUCED MOTION
   ----------------------------------------------------------------------------
   Required by spec §6.3: "the Salient source has no reduced-motion guard of its
   own, only the data-m-rm-animation mobile switch." Both entrances resolve to
   the fully-revealed end state. The column rule matters because Salient's
   `.wpb_column.has-animation{opacity:0}` is a CSS start state that JS then
   transitions — without this the copy would simply never appear.
   ========================================================================== */

/* R7-04 NOTE, 2026-08-21: after R6-06 (overline) and R7-04 (body) NO column in
   this section carries `has-animation` any more, so every
   `.wpb_column.has-animation` selector below and in §5.1 currently matches
   NOTHING. They are kept, not deleted, because unlike §5.2's duration handle
   they are GUARDS: if a future change re-adds a Salient column animation here
   the guard must already be in place, and an absent guard fails by hiding
   copy. Their inertness is stated so the next reader does not read them as a
   description of what runs. MEASURED under reduced motion after the change:
   overline / heading / body / column all opacity 1, translate none. */
@media (prefers-reduced-motion: reduce) {
  .mk-who-why .wpb_column.has-animation { opacity: 1 !important; }
  .mk-who-why .nectar-split-heading[data-animation-type="line-reveal-by-space"] { opacity: 1 !important; }
  .mk-who-why .nectar-split-heading[data-animation-type="line-reveal-by-space"] span .inner {
    transform: none !important;
    opacity: 1 !important;
    filter: none !important;
    transition: none !important;
  }
}


/* ============================================================================
   5 · FOUNDER DEFECT D07 — the entrance the founders could not see
   ----------------------------------------------------------------------------
   Founder trace FT-20260817-vista-pacifico-review.md:
     "D07 Overline does not animate in (skipped). Paragraph fade is too fast to
      perceive — slow it."

   The trigger position and the animation family are fixed in the markup (see
   the two D07 blocks in 01-who-why.html). Two things can only be fixed here.
   ========================================================================== */

/* ----------------------------------------------------------------------------
   5.1 · COMPLETE SALIENT'S ASYMMETRIC no-js GUARD.
   NOT cosmetic, and not speculative — it is the exact visual signature the
   founders reported on the sister section (D13: "moves up but does not fade").

   The shell serves `<html lang="en" class="no-js">`. Nothing in the head ever
   swaps it (a real Salient page runs
   `document.documentElement.classList.remove("no-js")` inline at the top of
   <body> — salient-truth/resort/index.html @108383). On THIS page the class
   arrives late and by accident: js_composer_front.min.js adds
   `js js_active vc_desktop vc_transform` to <html>, and that file is a
   `type="salientlazyscript"` tag promoted by nectar-delay-javascript.js on the
   visitor's first gesture. Measured, both states, in headless Chrome:

       before promotion   html.no-js    -> column opacity 1, transform 75px
       after  promotion   html.js       -> column opacity 0, transform 75px

   The first row is the defect. Salient's guard is asymmetric:

       .wpb_column.has-animation                      { opacity: 0 }
       .wpb_column.has-animation[data-animation=...]   { transform: translateY(..) }
       html:not(.js) .wpb_column.has-animation         { opacity: 1 }   <- opacity ONLY

   so under `no-js` the copy is shown at FULL OPACITY and STILL DISPLACED. Any
   visitor whose first gesture is a scroll rather than a mousemove sees exactly
   that: type sitting low, fully opaque, sliding up with no fade when the
   Waypoint finally fires. Completing the guard removes the displaced-and-opaque
   frame entirely, so the entrance either plays in full or is not visible at all.

   Precedent, not a new idea: 13-recovery-45 already ships
   `html:not(.js) #s13-recovery-45 .wpb_column.has-animation{transform:none}`
   and NOTES.md §13-A records that the shell owner was asked to pick one of two
   forks page-wide and never did. Raised again, with the founder evidence
   attached, in founder-trace/SHARED-REQUESTS.md (SR-01).

   SELF-RETIRING: the moment the shell adds the `no-js` -> `js` swap this
   selector stops matching and Salient's own start state takes over unchanged.
   -------------------------------------------------------------------------- */
html:not(.js) .mk-who-why .wpb_column.has-animation {
  transform: none;
}

/* ----------------------------------------------------------------------------
   5.2 · SLOW THE PARAGRAPH FADE — "slow it", D07.

   Salient's `fade-in` branch in init.js `Je()` is
       it[i] = setTimeout(function () { n.transition({opacity: 1}, s, r) }, a)
   where `s` is `H` = `body[data-cad]` = 1500 and `r` is `body[data-cae]` =
   easeOutQuart. jQuery.transit implements `.transition()` by writing an INLINE
   `transition` shorthand and then setting the property, so the duration is an
   inline style — and `data-cad` is on <body>, which this lane does not own and
   which twenty other sections read.

   An `!important` author declaration outranks a non-important inline
   declaration (CSS Cascade §6.4.4), so this is the one legitimate section-local
   handle on that duration. It is scoped to the ONE column that needs it.

   IT MUST NOT BE WIDENED to the overline column. That column now runs
   `slight-fade-in-from-bottom`, which is the anime.js branch: anime writes
   `opacity` and `transform` as inline styles EVERY FRAME, and a CSS transition
   on an every-frame inline write turns each frame into a chase — the same
   footgun js/mk-expanding-card.js documents for clip-path. Transit-driven
   properties may be retimed from CSS; anime-driven ones may not.

   VERIFIED, not assumed: sampled through the entrance in headless Chrome at
   80ms intervals; see the return notes for the opacity ramp.
   -------------------------------------------------------------------------- */
/* ---- RETIRED BY R7-04, 2026-08-21 -----------------------------------------
   The rule that stood here was

       .mk-who-why #mk_01_row_body .wpb_column.has-animation[data-animation="fade-in"]
       { transition-duration: 2400ms !important; }

   It is now UNMATCHABLE: R7-04 removed `has-animation` and the
   `data-animation` value from that column (see the R7-04 block in
   01-who-why.html), so the paragraph is driven by ONE system instead of two.
   Deleting the selector rather than leaving it inert is the point — an
   unmatchable rule with a paragraph of rationale above it is the next reader's
   trap. The D07 requirement it served ("slow it") is carried instead by
   §5.4's `--myk-mv-dur-body: 700ms`, which is 3.5x the page default.
   -------------------------------------------------------------------------- */

/* ----------------------------------------------------------------------------
   5.4 · R7-04 — THE BODY IS ONE BEAT BEHIND THE LEAD, NOT ONE SECOND
   FT-20260821-jehnean-round7:
     "`.mk-who-why__body.mv-in` fade is TOO DELAYED vs data-mv='lead' and the
      overline. Tighten the stagger."

   MEASURED BEFORE (review/r7/r7-whowhy/before-stagger-all.json — opacity
   sampled every rAF from the scroll that brings the section into view, five
   viewports, ms to opacity 0.02 / 0.50 / 0.95):

       band          overline + heading        body
       1280 x 900    201 / 384 / 643           701 / 1326 / 2234
       1440 x 900    205 / 388 / 647           688 / 1313 / 2222
       1750 x 980    204 / 387 / 645           686 / 1312 / 2220
        834 x 1112   242 / 425 / 692           692 / 1317 / 2225
        390 x  844   196 / 379 / 646           687 / 1312 / 2221

   The body STARTED ~490ms after the lead started and was not 95% in until
   ~2.22s — 1.58s after the lead had finished. As three beats that is not a
   stagger, it is a pause.

   ROOT CAUSE, and it is the SAME defect R6-06 removed from the overline one
   element away: the paragraph was DOUBLE-DRIVEN. js/myk-motion.js had already
   adopted the <p> as `data-mv="body"` (hence the `.mv-in` class she named),
   while its Salient column ALSO ran `fade-in` at data-delay 450 with the
   2400ms handle above. Two entrance systems multiplying their opacities on one
   paragraph, and the slower one wins everything.

   THE FIX IS A DELETION, NOT AN ADDITION. The Salient column animation is gone
   from the markup; what remains is the one grammar the overline and heading
   already run. These two custom properties are read by css/myk-motion.css's
   own `html.mv [data-mv="body"]` rule — they are its declared knobs — so this
   retimes the paragraph WITHOUT touching that shared file and without a
   section-local transition of its own.

       delay 220ms = the lead's own 100ms + one 120ms stagger step (the hero's
                     step, named in the round-7 brief), so the paragraph starts
                     exactly one beat behind the overline and heading.
       dur   700ms = the lead's duration. D07's "slow it" is still honoured —
                     the page default for `body` is 200ms and this is 3.5x it —
                     while the paragraph now settles WITH the block instead of
                     a second and a half after it.

   MEASURED AFTER: see the after table in founder-trace/helix/R7-04.md.
   -------------------------------------------------------------------------- */
.mk-who-why {
  --myk-mv-delay-body: 220ms;
  --myk-mv-dur-body:   700ms;
}

/* ----------------------------------------------------------------------------
   5.3 · REDUCED MOTION — §4 above pins `.wpb_column.has-animation` to opacity 1
   but was written when both columns were `fade-in`, which has no transform. The
   overline is now `slight-fade-in-from-bottom`, whose CSS start state IS a
   50px transform, so the guard has to neutralise that too or a reduced-motion
   visitor gets the copy parked 50px low forever.
   -------------------------------------------------------------------------- */
@media (prefers-reduced-motion: reduce) {
  .mk-who-why .wpb_column.has-animation {
    transform: none !important;
    transition-duration: 1ms !important;
  }
}


/* ============================================================================
   6 · R6-06 — THE TOP GAP, CALIBRATED FROM OMAI (FT-20260820-jehnean-round6)
   ----------------------------------------------------------------------------
   Jehnean: "there's too much space at the top above the [Overline TBD if
   needed at all]... go look at Omai for 'OMAI redefines destination living'
   ... and about how much spacing and white space exists above it."

   MEASURED, not eyeballed — review/r6/r6-whowhy-omai/omai-measure.json,
   omaivillas.com live, fresh headless Chrome, 2026-08-21:

     white space, their hero's bottom edge -> that heading's ink top
       1280 x 900 viewport:   280px
       1280 x 800 viewport:   280px      <- px-FIXED on their side

     ours before this rule (before.json, 1280x900):
       hero bottom -> overline rest top   316.5px      (and GROWING with the
       viewport: the B02 band `max(1080px,120svh)` + `align-content:center`
       centres a fixed 687px content block, so at her 1728x1117 screen the gap
       computes ~447px — 1.6x Omai. That growth is the complaint.)

   THE TRANSLATION. Omai's own gap is a fixed 280px, but B07 forbids us a fixed
   px (the founder rule: viewport-relative, re-picked at no breakpoint). So we
   take their PROPORTION AT THE 1280x900 MEASUREMENT VIEWPORT — 280/900 of a
   screen — and hold it as svh, which the brief asks for in as many words
   ("reduce our top gap to their proportion (viewport-relative per B07, never
   fixed px)"). At 900svh that is exactly Omai's 280px; at 1117 it is 347px
   where the old centring gave ~447.

   MECHANISM: releasing rhythm.css's `min-height: var(--mk-band-12)` (B02) and
   letting the section hug `padding + content`. B02 asked for "more vertical
   space above and below before the video section appears"; R6-06 is the same
   founder re-picking the TOP amount against a reference, and R6-07 ("bring
   the video section up a bit") spends the height this releases. The BOTTOM
   keeps its B02 generosity: measured 276.5px before at 900vh; the symmetric
   31.11svh below is 280px — within 4px of what she approved, and now
   proportional instead of centring-derived.

   (0,3,0) beats rhythm.css's `.mk-page .mk-who-why` at (0,2,0) without
   touching that shared file. Same 1000px gate as the rhythm tokens. With
   min-height released, `align-content:center` has nothing to distribute, so
   the grid declarations up there go inert rather than fought.
   ========================================================================== */

@media (min-width: 1000px) {
  .mk-page .mk-section.mk-who-why {
    min-height: 0;
  }
  .mk-page .mk-who-why .mk-who-why__text {
    /* R7-03 — see §7. Omai's REAL measured gap is 240 and it does not grow
       with the viewport. `min()` keeps the value viewport-relative below the
       reference viewport (B07) and caps it at the reference above it, which is
       the half that was missing: at her effective 980-tall viewport the old
       form computed 304.9. */
    padding-block: min(240px, calc(100svh * 240 / 900));
  }
}


/* ============================================================================
   7 · R7-03 — THE R6 NUMBER WAS A MIS-READ, AND THIS IS THE RE-MEASUREMENT
   ----------------------------------------------------------------------------
   FT-20260821-jehnean-round7:
     "`.mk-container.mk-who-why__text` STILL too much space above and below."

   §6 above took the top gap 316.5 -> 280 and cited "Omai's measured
   proportion, 280/900". THAT NUMBER WAS NEVER MEASURED. The r6 evidence file
   it points at, review/r6/r6-whowhy-omai/omai-measure.json, records

       "gap_heroBottom_to_headingTop": null,
       "hero": null,
       "prevSibling": null,
       "heading": { "rect": { "top": 1180, "bottom": 1460, "h": 280 } }

   — the gap probe returned null and 280 is the HEADING'S OWN BOX HEIGHT. A
   box height was read as a white-space gap and then held as a proportion.

   RE-MEASURED LIVE, omaivillas.com, fresh headless Chrome, 2026-08-21,
   five viewports (review/r7/r7-whowhy/omai-gap.json). The element is the
   `.module-my` section that holds "Omai redefines destination living":

       viewport      margin-block   hero-bottom -> heading ink top
       1280 x 900    240 / 240      240
       1440 x 900    240 / 240      240
       1750 x 980    240 / 240      240      <- HER effective viewport
        834 x 1112   180 / 180      180
        390 x  844   120 / 120      120

   TWO facts, and the second is the one that reached her as a defect:
     1. the value is 240, not 280;
     2. it does NOT grow with the viewport. Ours did — `100svh * 280/900`
        computes 304.89 at 980 — so the band she actually reviews in was
        carrying 65px MORE than the reference while the 1280 verification
        reported "within 4px". That is R7-10 in one section.

   THE FORM. B07 forbids a flat px that is re-picked at a breakpoint, and
   Omai's own value IS flat px. `min(240px, 100svh*240/900)` satisfies both
   readings honestly: below a 900-tall viewport it is viewport-relative and
   shrinks continuously; at and above it, it is the measured reference and
   stops growing. One expression, no breakpoint re-pick.

   MEASURED AFTER (review/r7/r7-whowhy/after-all.json): 240/240 at 1280,
   1440 and 1750.

   NOT CHANGED, and recorded rather than smoothed: tablet (72) and phone (56)
   are already FAR BELOW Omai's 180 / 120. R7-03 is a "too much space" defect
   and those two are the opposite; raising them is a zebra-consistency
   decision that spans sections, so it is filed for R7-09's owner in
   founder-trace/SHARED-REQUESTS.md (OBS-ZEBRA-01) instead of being taken
   unilaterally from inside one section lane.
   ========================================================================== */


/* ============================================================================
   8 · R7-09 — THE BREATH. ONE RULE FOR THE WHOLE PAGE'S VERTICAL RHYTHM.
   ----------------------------------------------------------------------------
   FT-20260821-jehnean-round7 R7-09:
     "who-is-safe-stay-for has too much space, unique has too little — spacing
      must be consistent ACROSS sections and breakpoints."

   §7 above answered the first half from inside this section and R7-08 answered
   the second half from inside 03-unique, independently. That is exactly how a
   page ends up locally correct and globally uneven, so R7-09 is owned by the
   single-writer `r7:zebra` pass and this block is its half.

   WHAT THE PAGE ACTUALLY DID, MEASURED BEFORE ANY CHANGE. Every boundary was
   parked at mid-screen and the empty band around it measured in viewport
   coordinates (review/r7/r7-zebra/seam.py; raw
   review/r7/r7-zebra/seam-before-*.json; the whole table with screenshots is
   review/r7/zebra-spacing-table.md):

     seam                1280   1440   1750(HERS)   834    390
     hero -> 01           240    240      240        72     56
     01 -> 02             240    240      240        72     56
     02 -> 03             126    126      137.2       4      4
     03 -> 04             223    223      234.2      63.5   41
     04 -> 07              96     96       96       103.2   68.6
     08 -> 09              98     98      146         4      4
     14 -> 16             252    270      270       157.3   40
     16 -> 17             356    374      442       116.7   22

   Desktop spread 96..442 = 4.6x. Tablet 4..157 = 39x. Phone 4..68.6 = 17x.
   And the second finding is the one that answers "across breakpoints":
   NOTHING on this page was viewport-proportional except 02->03, which R7-08
   had made 14vh a few hours earlier. 240 is 240 at both 900 and 980. So is 96.
   So is 39.4, at every width down to 390.

   THE RULE, in the words a designer can hold:

     ONE BREATH. The empty space between any two neighbouring things on this
     page is one breath, and a breath is always the same fraction of the screen
     you are looking at: one fifth of its SHORTER side, never under 96px and
     never over 208px. A section whose photograph runs to its own edge spends
     no breath there and its neighbour supplies the whole one. Where two
     sections both stand back from the boundary, they take half each.

       --mk-breath: clamp(96px, 20vmin, 208px)
         1280x900 -> 180   1440x900 -> 180   1750x980 -> 196
          834x1112 -> 166.8   390x844 -> 96 (floor)

   WHY vmin AND NOT vh. Two measured reasons, not a preference. (1) On a phone
   vmin IS the width (390 < 844), so the breath is completely immune to the
   URL-bar viewport jitter that makes vh unstable there. (2) On tablet portrait
   vh would make the gap LARGER than on desktop (1112 > 980), which is backwards
   — the reference ladder shrinks on small screens and so does this.

   WHY THIS NUMBER. It is bounded on both sides by the founder's own two
   sentences, and it is the only band that satisfies both: it must be BELOW
   this section's 240 ("too much space") and ABOVE 03-unique's 137.2 ("too
   little"). 196 at her band moves this section -18% and 03-unique +43%. Both
   R7-03 and R7-08 are deepened, neither is reversed.

   WHAT THIS REPLACES HERE. All four of the padding-block values in this file —
   §7's `min(240px, 100svh*240/900)` at >=1000 and §3's 96 / 72 / 56 at the
   three max-width breakpoints. One proportional expression, no breakpoint
   re-pick, which is what B07 asked for in the first place. It also closes
   OBS-ZEBRA-01: tablet went 72 -> 166.8 and phone 56 -> 96, both of which were
   far under any reference.

   SPECIFICITY, STATED RATHER THAN TUNED. (0,3,0) — the same weight as §7's
   `.mk-page .mk-who-why .mk-who-why__text`, won on source order because this
   block is last in the file. The three max-width blocks are (0,1,0) and lose on
   weight, so no media query is needed to unwind them and none is used.

   THE TOKEN IS A FALLBACK ON PURPOSE. `--mk-breath` belongs in css/tokens.css,
   which this lane does not own; the promotion is filed as REQ-ZEBRA-1 in
   founder-trace/SHARED-REQUESTS.md. Until it lands the literal below is the
   value; after it lands every consumer picks it up with no edit here.
   ========================================================================== */

.mk-page .mk-who-why .mk-who-why__text {
  padding-block: var(--mk-breath, clamp(96px, 20vmin, 208px));
}

/* 2026-09-02 — MOBILE: the gap between this paragraph and the video card
   below (02-who-why-b) read as "a lot of spacing" on the founder's Pixel 7
   ("drop your bottom padding between those sections to match your side
   padding ... twenty-four pixels ish"). The breath token above stays for the
   TOP; only the bottom collapses to the page gutter under 1000px. (0,3,0),
   later in the file than the breath rule, so it wins on source order. */
@media (max-width: 999px) {
  .mk-page .mk-who-why .mk-who-why__text { padding-bottom: var(--mk-page-x, 24px); }
}