/* =====================================================================
   PREQUATE — AUTHORISED DESKTOP FIX (17 Aug 2026)

   This file is SEPARATE from the band layer on purpose. The band layer's
   guarantee is "every rule inside max-width:991px, checked at build time, so
   desktop cannot be reached by it". That guarantee is worth keeping literally
   true, so the one change Ashik authorised above 991 lives here instead, where
   it is a single obvious file that can be reverted by deleting one link tag.

   SCOPE: 992-1469 only. 1470 and above is untouched and verified identical.

   ---------------------------------------------------------------------
   THE DEFECT. On /product-alpha-metrics and /product-orbit-report the whole
   "Why Us?" block - the heading and all four pillar cards - paints NOWHERE
   between 992 and 1469. Hit-tested on the live pages: 0 of 5 elements painted
   at 992/1024/1200/1469, 5 of 5 at 1470.

   WHY. Webflow authored the section with no in-flow children:
     .why-us              { height:100%; overflow:hidden }
     .main-text-for-why-us{ position:absolute }   top -42px (ABOVE the box)
     .main-4-boxs         { position:absolute }   top +46px, 321px tall
   Both children are out of flow, so the section has no content height and
   resolves to 0px. The content is MEANT to spill out of it - at 1470 that is
   exactly what happens, and the next section reserves the room for it
   (`.circle-section{margin-top:728px}`).

   Our own W3.1 rule `.why-us{position:relative !important}` (scoped 480-1469,
   added 13 Aug under "orbit stage clipping") made the section the containing
   block for those two absolute children. They then became subject to its own
   `overflow:hidden` on a zero-height box - so they were clipped away entirely.
   Every desktop check this project ever ran was at 1470, where the rule stops
   applying, which is why it survived.

   ---------------------------------------------------------------------
   WHY THIS FIX AND NOT THE OBVIOUS ONES. Both alternatives were built and
   measured on the live pages before this one was chosen:

   1. `position:static` (i.e. just undo the W3.1 line). Restores all 5 elements
      - and turns HORIZONTAL SCROLL ON at 992/1024/1200. The containment was
      load-bearing after all; its comment was telling the truth.
   2. `height:367px` with containment kept. No scroll, but only 4 of 5 paint -
      the heading sits at top -42px so a fixed height clips it - and the page
      grows 367px at every width in the band.

   3. THIS ONE: keep `position:relative` so the horizontal overhang is still
      contained, and split the axes - clip X, leave Y free. That reproduces
      1470's behaviour exactly.

      NOTE `overflow-y:visible` next to `overflow-x:hidden` silently computes to
      `auto` - the classic trap. `overflow-x:clip` + `overflow-y:visible` is the
      pair that actually works.

   MEASURED, live, both pages, before -> after:
     elements painted   0/5 -> 5/5   at 992, 1024, 1200, 1469
                        5/5 -> 5/5   at 1470 (control, untouched)
     horizontal scroll  off -> off   at every width
     page height        unchanged to the pixel (6376/6386/6292/6287)
     section box        0px -> 0px   (no geometry change)
     ink collisions     0 -> 0       (nothing overlaps anything)
   ===================================================================== */
@media (min-width: 992px) and (max-width: 1469px) {
  .why-us {
    overflow-x: clip !important;
    overflow-y: visible !important;
  }
}


/* ==========================================================
   WHY US CARDS — EQUAL WIDTH AT 992-1469 (17 Aug, Ashik's report)

   Ashik: "not all the cards are same size". Measured on the LIVE published
   pages, first card against the other three:
     992   228 vs 248,248,248
     1024  236 vs 256,256,256
     1194  279 vs 299,299,299   <- iPad Pro 11 LANDSCAPE
     1280  300 vs 320,320,320
     1440+ 321 all equal
   Heights were already equal; it is card 1's WIDTH. It is authored with a
   different class (.mqin-background-frame) and its Webflow column comes out
   20px narrower. Equalising the column padding did NOT fix it - the column
   itself is narrower, so the frame's width:100% just inherits the problem.

   FIX: stop using Webflow's float/.w-col maths for this row and give it four
   equal grid tracks - the same approach that made <=991 exact. Then the card
   widths are defined by the track, not by per-column quirks.

   MEASURED after, both pages: 992 -> 230 x4, 1194 -> 281 x4, 1280 -> 302 x4,
   1469 -> 349 x4. Width spread 0, top spread 0, gaps 24/24/24, no horizontal
   scroll. 1470 CONTROL untouched: 321 x4, original 33/47/47 gaps intact.

   NOTE FOR THE MORNING: at 1470 (signed-off desktop) the gaps between these
   four cards are 33/47/47 - unequal in the original design. Left exactly as
   delivered; flagged, not changed.
   ========================================================== */
@media (min-width: 992px) {
  .why-us .columns-4 {
    display: grid !important;
    grid-template-columns: repeat(4, 1fr) !important;
    gap: 24px !important;
    align-items: stretch !important;
    grid-auto-rows: 1fr !important;
  }
  .why-us .columns-4::before,
  .why-us .columns-4::after { display: none !important; }
  .why-us .columns-4 > * {
    float: none !important;
    width: 100% !important;
    max-width: none !important;
    padding-left: 0 !important;
    padding-right: 0 !important;
    margin: 0 !important;
    box-sizing: border-box !important;
  }
  .why-us .mqin-background-frame,
  .why-us .bck-frmae,
  .why-us .background-frame,
  .why-us .background-framee {
    width: 100% !important;
    max-width: none !important;
    height: 100% !important;
    /* KEEP the authored 321px floor. Without it, equal rows size to content and
       the cards flatten - 321px tall at 1470 became 196px, which is a change to
       the card's proportions, not to its alignment. Rule 14 authorises fixing
       alignment, not reshaping the design. */
    min-height: 321px !important;
    margin: 0 !important;
    box-sizing: border-box !important;
  }
  .why-us .columns-4 > * { height: 100% !important; align-self: stretch !important; }
}

/* RULE 14 (Ashik, 17 Aug): an inconsistency at 1470+ is still an inconsistency.
   The card grid above now has NO upper bound, so the four cards are equal width,
   equal height and equally spaced at every width from 992 up - the original
   design's uneven 33/47/47 gaps at 1470 included. */


/* ==========================================================
   WHY US CARDS — INTERNAL ALIGNMENT AT >=992 (17 Aug, same round as the
   <=991 fix in gone.css section A-3; read that comment first, it carries the
   diagnosis).

   The card BOXES are already equal at >=992 - the 4-track grid above did that.
   What is NOT equal is where the content starts inside them, and it is visible
   at 1194, which is Ashik's iPad Pro 11 in LANDSCAPE:

     title top, relative to the card, icons LOADED
       992    194 / 199 / 186 / 202     spread 16
       1194   194 / 199 / 199 / 209     spread 15   <- iPad Pro 11 landscape
       1470   195 / 187 / 187 / 197     spread 10
       1920   195 / 195 / 195 / 197     spread  2

   TWO causes, the same two as <=991:
     1. The frames are `justify-content:center`, so the content block is
        vertically CENTRED and its start y therefore depends on the length of
        its own copy. Longer copy starts higher. Top-aligning against the card's
        own padding makes the icon, title and body start at the same y in every
        card, on both pages, whatever the copy length.
     2. The icon <img> had no height and the four PNGs differ (139x141 x3,
        162x146), so card 4 sat lower - and at 992, where the card is only 230px
        wide, max-width:100% squashed it to 132px tall against the others' 141.

   Rule 14 is the authority for touching >=992 at all: an inconsistency at 1194
   or at 1470 is still an inconsistency, and "in any form needed".

   MEASURED after, both pages, icons loaded:
     title-baseline spread   16/15/10/2  ->  0 at 992/1024/1100/1194/1280/1366/
                                             1440/1469/1470/1600/1920
     card height             426/410/394/378/353/337/337/337/337/337/321
                             UNCHANGED to the pixel at every one of those widths
     card width              unchanged, spread 0
     horizontal scroll       off -> off
   ========================================================== */
@media (min-width: 992px) {
  .why-us .columns-4 img {
    width: 100% !important;
    height: 141px !important;
    max-width: 100% !important;
    object-fit: contain !important;
    flex: 0 0 auto !important;
    align-self: center !important;
  }
  .why-us .mqin-background-frame,
  .why-us .bck-frmae,
  .why-us .background-frame,
  .why-us .background-framee {
    justify-content: flex-start !important;
  }
}


/* ============ APPENDED 2026-08-18 01:11: desk-careers.css ============ */
/* desk-careers.css — DESKTOP ONLY (>=992). /careers.
   DEFECT (Ashik, 18 Aug): the "?" in "unusual?" is cut.
   CAUSE: .are-you-unsual-1 paints its gradient with -webkit-background-clip:text +
   transparent text-fill. Chrome clips that background to the element's border box,
   and the italic "?" glyph ink overhangs the box on the right, so the tip of the
   bowl is never painted -> a flat vertical slice.
   The existing page-head fix (padding-right:13.5px / margin-right:-13.5px, !important)
   is ~2px short. It is !important and lands AFTER this asset in the cascade, so this
   rule is rooted `html body` to win. Layout is unchanged: the extra padding is
   cancelled by an equal negative margin, and the gradient ramp is re-expressed so the
   64% stop still falls at 64% of the ORIGINAL padding box (24 - 13.5 = 10.5px added) -> colours pixel-identical. */

@media (min-width: 992px) {
  html body .are-you-unsual-1 {
    padding-right: 24px !important;
    margin-right: -24px !important;
    background-image: linear-gradient(90deg,
      rgb(112, 112, 112) 0px,
      rgb(255, 150, 51) calc((100% - 10.5px) * 0.64)) !important;
  }
}


/* ============ APPENDED 2026-08-18 01:11: desk-contact.css ============ */
/* =====================================================================
   PREQUATE — /contact-us DESKTOP, "too much white space" (18 Aug 2026)
   Ashik named this defect and opened desktop for THIS page only.
   Every rule is inside @media (min-width:992px); nothing at <=991 moves.

   THE DEFECT (his screenshot): the empty run between the bottom of the
   enquiry form / map block and the contact-details row (email | address |
   phone) that sits above the social icons.

   ATTRIBUTION at 1470 (identical at 1194 and 992):
     .div-block-46 (grid)      height:900px   top 220  bottom 1120
       .frame-1000007057       height:900px   real content ends at 838
       .div-block-47           height:900px   real content ends at 837
     .div-block-48             margin-top:40px            top 1160
   The two columns need 618px. The authored 900px leaves 282px of unused
   box below the ink; the row's own 40px margin sits under that. Empty run
   838 -> 1160 = 322px, of which 282px is slack and 40px is the authored gap.

   FIX: let the boxes hug their content and keep the authored 40px gap.
   section.section-40 also carries an explicit height (1125.55px = the sum of
   the old children); left alone it would just move the same 282px below the
   social icons, so it collapses too.

   ABSOLUTE-CHILD TRAP CHECKED: the only position:absolute descendants in this
   section are the Google Maps iframe and a.directions-btn, and BOTH resolve
   against .map-circle-wrapper (position:relative, height:600px), which is not
   touched here. Nothing in the chain from section-40 down to the ink is
   out of flow, so height:auto cannot collapse this section (the /about-us
   failure mode).

   CLIPPING TRAP CHECKED: none of the four boxes was clipping — scrollHeight
   == height == 900 with 618px of content, overflow visible. height:auto is
   also strictly safer than a fixed smaller height here, because the HubSpot
   iframe is resized by HubSpot's own script as the multi-step form advances;
   an auto box grows with it, a fixed box would be overrun.

   ROOTING: `html[data-wf-page=...] body` is used deliberately — it scopes the
   rule to /contact-us via Webflow's own page attribute and gives the desktop
   asset (which loads at the END of the site head, BEFORE every page-head
   <style>) enough weight to survive the page head. No !important is needed;
   verified in that exact cascade slot.
   ===================================================================== */

@media (min-width: 992px) {
  html[data-wf-page="6a410ffa9ea227a7c2c9900d"] body section.section-40,
  html[data-wf-page="6a410ffa9ea227a7c2c9900d"] body .div-block-46,
  html[data-wf-page="6a410ffa9ea227a7c2c9900d"] body .div-block-46 .frame-1000007057,
  html[data-wf-page="6a410ffa9ea227a7c2c9900d"] body .div-block-46 .div-block-47 {
    height: auto;
    min-height: 0;
  }
}


/* ============ APPENDED 2026-08-18 21:31: r6-blog-desktop.css ============ */
/* r6-blog-desktop.css — /blog, DESKTOP >=992 ONLY
   Named defect (Ashik, 18 Aug): "arrows dont look right, alignement is not
   correct and the button" -> clarified: "The arrow buttons themselves."

   Cause 1 (look): the visible button is the 56x56 orange disc
   .frame-10000019235, but the chevron .section_slider-arrow-icon is a separate
   absolutely-positioned box sized by a hand-typed one-sided padding
   (padding-right:292px on the left arrow, padding-left:224px on the right), so
   each glyph paints off-centre inside its disc, and by DIFFERENT amounts
   (measured ink: left -6.5px, right +1.5px from the disc centre).
   Cause 2 (horizontal alignment): the arrow box is 30% of the viewport
   (left:0/right:70% and the mirror), so the disc's distance from the card
   is a function of viewport width - it is CUT at 992 (content box only 47.6px
   wide inside overflow:hidden), sits ON the card at 992-1224, and floats 169px
   away from it at 1920. The two paddings also differ (250 vs 255), so the pair
   is never symmetric.
   Cause 3 (vertical alignment): margin-top:240px / margin-bottom:128px inside
   the 468px-tall .section_slider pins the discs 40px BELOW the card's centre
   at every width (measured 40.0 at 992/1100/1280/1470/1600/1920).

   Fix: the arrow box IS the button - 56x56, identical both sides; one mirrored
   expression for the horizontal offset and one shared value for the vertical
   axis, so size, gap and axis are equal BY CONSTRUCTION (standing rule 12). */

@media (min-width: 992px) {

  /* the arrow box becomes the button: same size, same axis, both sides */
  html[data-wf-page="69a1896f399d61033d19cd10"] .section_slider > .w-slider-arrow-left,
  html[data-wf-page="69a1896f399d61033d19cd10"] .section_slider > .w-slider-arrow-right {
    width: 56px !important;
    height: 56px !important;
    min-width: 0 !important;
    padding: 0 !important;
    margin: 0 !important;
    top: calc(50% + 16px) !important;   /* mask is centred on the slider; the card sits 16px below that centre */
    bottom: auto !important;
    transform: translateY(-50%) !important;
    display: flex !important;
    align-items: center !important;
    justify-content: center !important;
    overflow: visible !important;
  }

  /* one mirrored expression: 12px clear of the 1200px card, clamped to 12px
     from the viewport edge once the margin runs out (<=1224) */
  html[data-wf-page="69a1896f399d61033d19cd10"] .section_slider > .w-slider-arrow-left {
    left: max(12px, calc((100% - 1200px) / 2 - 68px)) !important;
    right: auto !important;
  }
  html[data-wf-page="69a1896f399d61033d19cd10"] .section_slider > .w-slider-arrow-right {
    right: max(12px, calc((100% - 1200px) / 2 - 68px)) !important;
    left: auto !important;
  }

  /* the disc must not shrink inside the 56px box */
  html[data-wf-page="69a1896f399d61033d19cd10"] .section_slider > .w-slider-arrow-left > .frame-10000019235,
  html[data-wf-page="69a1896f399d61033d19cd10"] .section_slider > .w-slider-arrow-right > .frame-10000019235 {
    flex: 0 0 auto !important;
  }

  /* the chevron sits centred in its own disc */
  html[data-wf-page="69a1896f399d61033d19cd10"] .section_slider > .w-slider-arrow-left > .section_slider-arrow-icon,
  html[data-wf-page="69a1896f399d61033d19cd10"] .section_slider > .w-slider-arrow-right > .section_slider-arrow-icon {
    position: absolute !important;
    top: 0 !important; right: 0 !important; bottom: 0 !important; left: 0 !important;
    width: auto !important;
    height: auto !important;
    margin: 0 !important;
    padding: 0 !important;
    display: flex !important;
    align-items: center !important;
    justify-content: center !important;
    line-height: 1 !important;
  }
}


/* ============ APPENDED 2026-08-18 21:31: r6-casestudies-desktop.css ============ */
/* r6-casestudies-desktop.css — DESKTOP ONLY (>=992). /case-studies  (page id 69a800cea6999a158841d491)
   Ashik, 18 Aug ~20:31: "The container does not fit the entire content, and the arrows are not right."

   R1  THE CONTAINER (testimonial video sliced at the bottom).
   .section-3.csdsdsd is height:100vh + overflow:hidden. Its only in-flow child is
   .testimonials_conatiner (368px); everything else hangs off .section-style-2, which is
   position:absolute (inset 0 0 -669px 0) and therefore contributes NOTHING to the section's
   height. The testimonial stack needs 905px measured from the section's top (video bottom 820,
   mask bottom 827, nav dots bottom 905) at EVERY width 992-1920 — a constant. So on any window
   shorter than 905 CSS px the section clips its own content: dots gone below vh 905, video
   sliced below vh 820 (20px at vh 800, 60px at 760, 120px at 700). Ashik's 1470-wide window is
   ~800 tall, which is why he sees the subject's body cut.
   FIX: a floor on the section, min-height:905px. Used height = max(100vh, 905px), so at vh >= 905
   the page is byte-identical to today and below it the content simply fits.
   C5 CHECKED AND WHY height:auto IS FORBIDDEN HERE: .section-3's descendant .section-style-2 is
   position:absolute, so height:auto would collapse the section to 368px and print the heading over
   the slider. min-height leaves every position value untouched: .section-3 static,
   .testimonials_conatiner relative, .section-style-2 absolute, .testimonials-6 static,
   .section_content-wrapper static, .section_slider relative — all unchanged.
   C4: nothing here is a scroll-drawn SVG; no geometry, dash or timing is touched.

   R2  THE ARROWS (left disc empty, its chevron floating outside to the right).
   The disc (.frame-10000019235, 56x56, radius 70px) is an in-flow flex item centred by the arrow
   block's own justify-content:center inside its content box (the block is 441x100 with
   padding-right:250px on the left arrow / padding-left:150px on the right). The glyph
   (.section_slider-arrow-icon, the w-icon-slider-* ::before) is a SEPARATE absolutely-positioned
   box with inset 0, auto margins and a padding equal to its own width (left: width 156 /
   padding-right 156; right: width 121 / padding-left 121). Under box-sizing:border-box that padding
   collapses the content box to ZERO width, so text-align:center parks the glyph on one edge of the
   box instead of on the disc: 47.0px to the RIGHT of the left disc's centre (visibly outside a
   56px disc -> bare disc + a stray white chevron on the grey background) and 14.5px left of the
   right disc's centre (still inside it, which is why the right arrow looks fine).
   FIX: give the glyph box the ARROW BLOCK'S OWN padding (padding:inherit) with inset:0 and no
   margins, so its content box is exactly the arrow's content box, then centre the glyph in it with
   flex. The glyph now lands on the disc centre by the same rule that centres the disc, at any
   width and for either arrow. No size, colour, copy or hit area changes. */

@media (min-width: 992px) {

  /* R1 */
  html[data-wf-page="69a800cea6999a158841d491"] section.section-3.csdsdsd {
    min-height: 905px;
  }

  /* R2 */
  html[data-wf-page="69a800cea6999a158841d491"] .section-3 .w-slider-arrow-left > .section_slider-arrow-icon,
  html[data-wf-page="69a800cea6999a158841d491"] .section-3 .w-slider-arrow-right > .section_slider-arrow-icon {
    top: 0;
    right: 0;
    bottom: 0;
    left: 0;
    width: auto;
    height: auto;
    margin: 0;
    padding: inherit;
    display: flex;
    align-items: center;
    justify-content: center;
    line-height: 1;
  }
}


/* ============ APPENDED 2026-08-19 01:12: r9-deskinv-line.css ============ */
/* ==========================================================================
   ROUND 9, item 1 — /the-investment-desk, DESKTOP >=992 ONLY
   Ashik (1470, DPR 2): "The orange line is overlapping the text, should be
   little lower."   logs/r9/desk-investment/image1.png

   WHAT THE LINE IS.  Not a scroll-drawn SVG.  It is a plain, solid-filled
   DIV:  div.timeline_progressbar.new-line.deck.nnn.sdsdsd.dvsdvsdv.wewe
   position:absolute, top:159px, margin-top:50px, width:5px, height:6500px,
   background rgb(255,150,51).  Proven static: no data-w-id, no inline style,
   computed height/top/transform byte-identical at scroll fractions
   0 / 0.25 / 0.50 / 0.90 after a full IX2 prime.  There is nothing to
   desync — no dasharray, no path, no scaleY.  (The scroll-drawn artwork on
   this page is code-embed-59, the curved SVG that BEGINS at page y 7066,
   exactly where this bar ends.  It is not touched.)

   CAUSE.  The bar's top is pinned to the section, the text is pinned to the
   hero, and the two track the viewport HEIGHT at different rates:

     .growth-main-section._122121  margin-top:-376px after a 100vh hero
         => section top      =  vh - 376
     bar top = section top + top(159) + margin-top(50)
         =>   bar top        =  vh - 167
     .text-268 is centred in the 100vh hero
         =>   para box bottom = 0.5*vh + 214.3

     clearance(vh) = bar top - para bottom = 0.5*vh - 381.3

   So the clearance shrinks by 0.5px for every 1px of lost viewport height and
   goes NEGATIVE below vh 762.6.  Measured, 1470 wide:
     vh 1000  +118.7   vh 900  +68.7   vh 763  +0.2
     vh 746    -8.3    vh 733  -14.8  (Ashik's framing)  vh 700  -31.3
   At Ashik's vh the bar's tip lands on the baseline of the word "than" in
   "...need more than passive oversight." — ink touching ink.  Nothing is
   clipping anything: every ancestor is overflow:visible / clip-path:none /
   contain:none (control run below), so the painted extents ARE the boxes.
   Width plays no part: bar top 566 / para bottom 580.8 at 992,1100,1280,
   1440,1470,1600,1920 alike.

   THE SHIFT — candidates measured on the page, not guessed:
     15px  minimum that gives 0 overlap with the paragraph's line box at his
           exact framing (580.8 - 566 = 14.8).  Zero headroom: re-breaks at
           vh 732 and leaves a bare 5px stub floating under the sentence.
     30px  the paragraph's own line-height.  Clears text for vh >= 703, but
           at his vh the tip stops 6px ABOVE the CTA's arrow disc — a nub.
     50px  the bar's OWN existing margin-top, the nearest gap value the
           element already carries.  <== CHOSEN.
   50px clears the paragraph for every vh >= 662.6 (vs 762.6 today) and at
   Ashik's vh puts the tip inside the arrow disc (602-639), so the line reads
   as descending out of the CTA — which is exactly how it already reads at
   vh 900+.  It creates no composition the page does not already produce; it
   only moves the vh at which each one appears.  Bonus: it uncovers 20 device
   px of the white chevron the bar currently paints over.

   HOW.  margin-top 50 -> 100 moves the TOP down 50.  height 6500 -> 6450
   holds the BOTTOM at page y 7066, where the curved scroll-drawn SVG
   (code-embed-59) takes over — that joint must not move.  Both source values
   are constant across 992-1920, verified.
   Long class chain is load-bearing: the live rule
   `.timeline_progressbar.new-line.deck.nnn.sdsdsd.dvsdvsdv.wewe{margin-top:50px}`
   is 7 classes; a short page-scoped selector silently loses the cascade.
   ========================================================================== */
@media (min-width: 992px) {
  html[data-wf-page="69bfc522d51b3633b0925da1"] body
  .timeline_progressbar.new-line.deck.nnn.sdsdsd.dvsdvsdv.wewe {
    margin-top: 100px;   /* was 50px  — top 566 -> 616 at vh 733 */
    height: 6450px;      /* was 6500px — bottom stays at page y 7066 */
  }
}


/* ============ APPENDED 2026-08-19 01:12: r9-deskma-card.css ============ */
/* ==========================================================================
   R9 item 2 — /m-a-advisory  DESKTOP >=992
   Ashik: "The right card is spilling out of the image container"

   WHAT THE ELEMENTS ARE (measured at 1470, identical at 992/1194/1920):
     image container : .frame-10000018701 (left card)  301 x 300px
                       .frame-10000018705 (right card) 301 x 300.634px
                       both are background-image divs, FIXED height (Figma
                       export), padding 19.6875px 12.8726px, position:static.
     white text box  : .frame-10000018702  — ONE SHARED CLASS used by both
                       cards, in normal flow, margin-top:142px, padding
                       15.1442px, height driven by its own copy.

   CAUSE — the box is simply wrong; nothing is clipping.
     margin-top:142px is a fixed offset authored against a THREE-line card.
     Left card copy is 3 lines  -> box 126.281px tall
        19.6875 (pad-top) + 142 + 126.281 = 287.97 of 300      -> 12.03px spare
     Right card copy is 4 lines -> box 147.281px tall
        19.6875 + 142 + 147.281 = 308.97 of 300.634            -> -8.34px
     i.e. the right card's white box hangs 8.34px BELOW the bottom edge of its
     own image, at every desktop width (the section is fixed-px, it does not
     reflow). Every ancestor is overflow:visible / clip-path:none / contain:none,
     so this is painted spill, not a clip artefact.

   FIX — bottom-anchor the shared box instead of top-anchoring it, so it grows
   upward into the photo and can never leave the image again. ONE declaration
   for both cards (standing rule 12): the insets are the container's own
   authored numbers — left/right = its padding 12.8726px, bottom = 12px, which
   is the gap the CORRECT (left) card already has: 300 - 19.6875 - 142 - 126.281
   = 12.03. The left card therefore does not move (0.03px); only the right card
   changes, and the two boxes end up bottom-aligned by construction.
   The containers have an explicit height, so taking the child out of flow
   cannot collapse them.

   NOT TOUCHED: <=991 (both cards spill there too, by ~40px, but the band is
   signed off and this file is >=992 only).
   ========================================================================== */
@media (min-width: 992px) {
  html[data-wf-page="69ad5decf269310df111d3f5"] body .growth-main-section .left-conatainer .frame-10000018701,
  html[data-wf-page="69ad5decf269310df111d3f5"] body .growth-main-section .left-conatainer .frame-10000018705 {
    position: relative;
  }
  html[data-wf-page="69ad5decf269310df111d3f5"] body .growth-main-section .left-conatainer .frame-10000018701 > .frame-10000018702,
  html[data-wf-page="69ad5decf269310df111d3f5"] body .growth-main-section .left-conatainer .frame-10000018705 > .frame-10000018702 {
    position: absolute;
    left: 12.8726px;
    right: 12.8726px;
    bottom: 12px;
    top: auto;
    margin-top: 0;
  }
}


/* ============ APPENDED 2026-08-19 09:27: r10-D.css ============ */
/* ==========================================================================
   ROUND 10, item D — /the-investment-desk, DESKTOP >=992 ONLY
   Ashik (1470 x 733, DPR 2): "The range line is overlapping the circle,
   marked in red, check and fix."

   WE CAUSED IT.  PUBLISH 9 (19 Aug ~02:00) moved this bar's margin-top
   50 -> 100px specifically so its tip would tuck INSIDE the CTA's round
   arrow disc, on the reasoning that the page already reads that way at
   vh 900+.  He is rejecting that composition.  This rule replaces it.

   THE ELEMENT is unchanged from PUBLISH 9: a plain, solid-filled DIV
   div.timeline_progressbar.new-line.deck.nnn.sdsdsd.dvsdvsdv.wewe —
   position:absolute, top:159px, width:5px, background rgb(255,150,51).
   NOT scroll-drawn.  The scroll-drawn artwork (code-embed-59) begins where
   this bar ends and is not touched.

   THE GEOMETRY, measured at 992/1194/1470/1920 x vh 620/700/733/800/900/1000
   (width-invariant to 0.00px, exactly linear in vh):

     section top      = vh - 376          (.growth-main-section._122121)
     bar top          = vh - 217 + MT     (section top + top:159 + margin-top)
     paragraph bottom = 0.5*vh + 214.3    (.text-268, centred in a 100vh hero)
     arrow-disc box   = 0.5*vh + 234.3 .. 0.5*vh + 274.3  (img.group-1000006809)
     CTA block bottom = 0.5*vh + 294.3    (.dropdown-7, 20px padding round the disc)
     first timeline dot = vh + 33         (.image-384)

     clearance(disc) = bar top - disc bottom = 0.5*vh - 491.3 + MT

   With the live MT=100 that is 0.5*vh - 391.3: NEGATIVE below vh 782.6.
   At his 733 the bar top is 616 and the disc ink ends at 639-640, so 24px
   of bar is painted through the disc — over the white chevron itself
   (ink scan, x 829-833: disc-only run 627-640 becomes solid 616-732).

   THE FIX IS NOT A CONSTANT.  The bar is anchored to the section (moves 1px
   per 1px of vh) and the disc to the hero centre (0.5px per 1px), so ANY
   constant only relocates the threshold — PUBLISH 9 moved it from 762.6 to
   662.6 for the paragraph and left the disc broken below 782.6.  Solving
   clearance(disc) = +20 for every vh gives

     margin-top = 511.3125px - 50vh  =>  bar top = 0.5*vh + 294.31

   i.e. the bar starts EXACTLY at the bottom of the CTA block, at every
   viewport height.  The 20px gap is not invented: it is the CTA wrapper's
   own padding — the same 20px that already separates the paragraph from the
   top of the disc.  Ink gap measured 21px at vh 733.  Both constants are
   exact multiples of 1/64px (Chrome's LayoutUnit) and 50vh is always .0 or
   .5, so margin+height cancels to 6550.0000px with no rounding residue on
   either branch of the max()/min() pair.

   THE HANDOVER (Ashik: "go with the max version").  A flat formula would pin
   the clearance to 20px at EVERY vh, which also CLOSES a gap that is not
   broken: live clearance is +58.7 at vh 900 and +108.7 at vh 1000.  Nobody
   reported the tall case, so the rule hands back to the exact live values
   (margin-top 100px / height 6450px, PUBLISH 9) as soon as the window is tall
   enough, via max()/min():

     handover where 511.3125 - 50vh == 100px   ->   vh = 822.625
     at that vh both branches give clearance 20.0125 — the join is continuous,
     no step (measured at vh 822 -> 20.01 and vh 823 -> 20.20).

   So below vh 822.625 the formula branch holds the 20px gap; above it the rule
   is a NO-OP by construction and the page keeps exactly today's composition.

   THE BOTTOM DOES NOT MOVE.  margin-top + height is held at 6550px, exactly
   as the shipped rule does (100 + 6450 = 50 + 6500 = 6550), so the bar's
   bottom stays at section top + 6709 — page y 7066 at vh 733 — which is
   where the scroll-drawn code-embed-59 takes over.  Verified unmoved to
   0.00px at all 24 width x vh combinations.

   SELECTOR: the live 7-class chain, verbatim.  A short page-scoped selector
   loses the cascade to it (moves height but not margin-top) — proven in R9.
   ========================================================================== */
@media (min-width: 992px) {
  html[data-wf-page="69bfc522d51b3633b0925da1"] body
  .timeline_progressbar.new-line.deck.nnn.sdsdsd.dvsdvsdv.wewe {
    margin-top: max(100px, calc(511.3125px - 50vh));
    height:     min(6450px, calc(6038.6875px + 50vh));
    /* was 100px / 6450px.  Below vh 822.625 the calc branch wins and holds a
       20px gap under the CTA disc; at or above it these ARE the live values,
       so the rule is a no-op.  max()+min() are mirrored, so margin+height is
       6550.0000px on BOTH branches and the bar's bottom never moves. */
  }
}


/* ============ APPENDED 2026-08-19 09:27: r10-E.css ============ */
/* ==========================================================================
   ROUND 10, item E — /the-investment-desk, DESKTOP >=992 ONLY
   Ashik (1470 x 733, DPR 2): "the watermark should be behind the line, fix it."

   WHAT THE TWO THINGS ARE
     watermark  div.text-304.tansaction.fggffg.bmbm
                position:sticky, z-index:-1, font-size 174px,
                color rgb(235,235,235), text "The Investment Deck",
                child of  SECTION.growth-main-section._122121  (relative, z 20)
     the line   TWO elements end to end, joined at page y 7066:
                (a) page y 616-7066  div.timeline_progressbar.new-line...
                    plain solid DIV, x 829-834, inside growth-main-section
                (b) page y 7066+     the scroll-drawn SVG path inside
                    div.code-embed-59 (z 5) > div.side-bar-left-side (z 3)
                    inside  SECTION.section-72.investment  (relative, z 2)

   WHY THE LINE LOSES TODAY
     Segment (a) already wins: it is a positioned z-auto descendant of
     growth-main-section (paint step 6) and the watermark is a negative-z
     child stacking context of the SAME section (paint step 2).  That half of
     the line is never interrupted.
     Segment (b) loses, and it loses OUTSIDE its own section: section-72
     carries z-index:2 and growth-main-section carries z-index:20, both
     position:relative children of body.  The whole of growth-main-section —
     watermark included — therefore paints above the whole of section-72.
     No z-index anywhere inside section-72 can reach past that: z 5 on
     code-embed-59 is compared against its siblings inside section-72, never
     against the watermark.  The break in the orange line starts at exactly
     page y 7066, the joint, which is what the picture shows.
     Lowering the watermark is not available: it is trapped inside
     growth-main-section's stacking context, so its own z-index cannot move it
     relative to anything in section-72.  The fix has to be at section level.

   THE CHANGE
     section-72's z-index 2 -> 21, one step above growth-main-section's 20.
     This reorders exactly ONE pair: everything in section-72 against
     everything in growth-main-section, and only where they overlap
     (page y 7065-7357).  section-72 has NO background and NO opaque box in
     that band — its only ink there is the two orange scroll-drawn lines —
     so nothing of the page's content can be covered by it.
     Ordering against every other body child is unchanged: section-9 is
     position:relative z-index:auto (paint step 6, already below both),
     .navbar is z 12000, .st_wrapper is z 400, and sections 31/53/blog/footer
     are static and start at page y 7865, past section-72's bottom (7565).

   C4: no SVG geometry is touched.  Only the ancestor SECTION's z-index
   changes; viewBox / d / stroke-width / stroke-dasharray / stroke-dashoffset /
   getTotalLength / box size are all byte-identical before and after at every
   scroll fraction measured.
   C5: no height and no position is changed anywhere.
   ========================================================================== */
@media (min-width: 992px) {
  html[data-wf-page="69bfc522d51b3633b0925da1"] body section.section-72.investment {
    z-index: 21;   /* was 2 — must clear .growth-main-section._122121's 20 */
  }
}


/* ============ APPENDED 2026-08-21 02:10: r22-h.css ============ */
/* r22-h  /diy  DESKTOP >=992 only  (page id 69a8012ac883179ccd5c029e)
   Hand-scoped per C2. Nothing outside the min-width:992px block. */

@media (min-width: 992px) {

  /* --- DEFECT 1: the hero strands itself ---------------------------------
     .section-20 is height:1300px but its content (sticky nav 70 + .div-block-16)
     only fills ~810 -> 490px of dead section under the paragraph.
     .div-block-16 is height:700px + padding 175/65 with justify-content:center,
     so its 168px of type floats with 146px of slack above and below.
     Both become auto; the padding now sets the rhythm. All children of both are
     position:static / sticky (the only position:absolute descendants are the
     w-dropdown lists, contained by their own position:relative .w-dropdown, and
     .w-nav-overlay which is display:none) -> C5 does not apply. */
  html[data-wf-page="69a8012ac883179ccd5c029e"] body .section-20 { height: auto; }
  html[data-wf-page="69a8012ac883179ccd5c029e"] body .div-block-16 {
    height: auto;
    padding-top: 210px;
    padding-bottom: 130px;
  }

  /* --- .project-holder is height:625px around an 801px list ---------------
     The 5th project overflows its container by 176px. Today that spill is
     swallowed by the 324px margin below; once that margin goes it would print
     over the newsletter. Children are all position:static/relative -> safe. */
  html[data-wf-page="69a8012ac883179ccd5c029e"] body .project-holder { height: auto; }

  /* section break trimmed to match the hero->list gap (~287px both sides). */
  html[data-wf-page="69a8012ac883179ccd5c029e"] body .section-4 { margin-bottom: 140px; }

  /* --- DEFECT 2: the empty orange gradient panel -------------------------
     .calinder is the CONNECT / Calendly block. Its two children (.frame-39,
     .calender) are display:none in the Webflow DESIGNER stylesheet, site-wide,
     unconditionally - they are hidden on / and /consumer too. Nothing is
     clipped: .calinder is position:static, display:flex, overflow:visible,
     opacity 1, clip-path none, full width. What is left is the legacy base
     style - a 900px orange gradient shell plus a 324px top margin.
     Everywhere else the block is used the markup carries the combo class
     .calinder-class, whose rule is exactly
       { background-image:none; height:auto; margin-top:0 }
     /diy is the one place the combo class is missing. This replicates it. */
  html[data-wf-page="69a8012ac883179ccd5c029e"] body .calinder {
    background-image: none;
    height: auto;
    margin-top: 0;
  }

}


/* ============ APPENDED 2026-08-22 17:32: r29-a-desk.css ============ */
/* ============================================================================
   r29 agent A — HERO UNDERLINE, DESKTOP ONLY (min-width:992px, no upper bound).
   Continuation of r28-B (tablet 768-991, live in prq-band-2026-08-21h.css).
   Pages covered: /consumer (6a26980bff679ec1b699021f) and
                  /family-managed-business (69c397e91a19a2ce973d48a7).
   Hand-scoped per page id (C2). NOTHING outside the two media blocks, and
   nothing below 992.

   MECHANISM (proven in r28-B, not re-derived): the rule is a sliver SVG in an
   <img> with NO preserveAspectRatio, i.e. xMidYMid MEET. WebKit gives these a
   bogus intrinsic size, meet scales the artwork to the HEIGHT and CENTRES it,
   so the painted ink is ~50-80px short at EACH end inside a box Blink computes
   and paints correctly. Remedy: stop drawing the SVG, paint the stroke as a CSS
   gradient (no intrinsic size, nothing to letterbox).
   ========================================================================== */

/* ---------------------------------------------------------------------------
   /consumer  — the box IS wrong here, and it is already word-flush at tablet.
   img.image-471 is a FIXED 580 x 5 px box at every desktop width; the accent
   span "new architecture" is a fixed 507.11 px at font-size 78px. Measured at
   992/1200/1440/1470/1920, all five identical:
       img.left  - span.left  = -78.55   (78.55px of LEFT OVERHANG)
       span.right - img.right =  +5.66   (the rule stops SHORT of the word)
   The <=767 script's own artwork ratios (LEAD 0.63 / TAIL 0.05 of the width of
   "architecture" = 367.77px) predict left 408.19 / right 1026.03 / height 5.33
   against an actual 421.98 / 1001.98 / 5.00 - off by 13.8px, 24.1px and 0.33px,
   and on the WRONG SIDE at the tail (the artwork overshoots the word by 5%, the
   desktop box undershoots it by 5.66px). So unlike /FMB below, the desktop box
   is NOT the approved artwork geometry, and r28-B already made this word flush
   at 768-991 and shipped it. Same three rules here => the 991/992 seam reads
   the same. Every value re-derived at desktop:
       height 5.00px / 78px      = 0.0641em   (identical em to the tablet band)
       bottom (453.70 - 447.70)  = 6.00px / 78px = 0.0769em
       right  italic "e" ink overhang, -0.085em (same em as tablet, pixel-checked)
   --------------------------------------------------------------------------- */
@media (min-width: 992px) {

  html[data-wf-page="6a26980bff679ec1b699021f"] body .herroo img.image-471 {
    visibility: hidden !important;
  }
  html[data-wf-page="6a26980bff679ec1b699021f"] body .herroo span.we-build-new-architecture-that-scale-demands.ff {
    position: relative !important;
  }
  html[data-wf-page="6a26980bff679ec1b699021f"] body .herroo span.we-build-new-architecture-that-scale-demands.ff::after {
    content: "" !important;
    position: absolute !important;
    left: 0 !important;
    right: -0.085em !important;
    bottom: 0.0769em !important;
    height: 0.0641em !important;
    border-radius: 999px !important;
    background-image: linear-gradient(to right, rgba(255,150,51,0), #FF9633) !important;
    pointer-events: none !important;
    z-index: 1 !important;
  }

}

/* ---------------------------------------------------------------------------
   /family-managed-business — 🔴 THE BOX IS THE ARTWORK. ONLY THE PAINT CHANGES.
   The <=767 script's LEAD 2.68 / TAIL 0.02 against the phrase "the next"
   (759.61 -> 994.63, width 235.02 at font-size 64px) predict
       left  = 759.61 - 2.68*235.02 = 129.76   actual img left  = 130.39
       right = 994.63 + 0.02*235.02 = 999.33   actual img right = 998.61
       height = (999.33-129.76)/226.8 = 3.833  actual img height = 3.83
   i.e. the DESKTOP box matches the signed-off phone artwork to <1px, exactly as
   the tablet box did. The 629px left lead is the drawing's fade-in ramp, not the
   defect. So the left edge is NOT touched here: geometry byte-identical, paint
   replaced. The accent is a bare text run inside one div (.text-567, only <br>
   children) and is NOT italic (font-style:normal), so there is no wrapper span
   to anchor on and no italic overhang to nudge - the nudge derives to zero. The
   hero is authored in fixed px and every offset below is CONSTANT at 992, 1200,
   1440, 1470 and 1920 - and identical to the tablet block's, so the seam is
   continuous by construction:
       img.left - block.left  = -74.99    block.right - img.right = -3.98
       img.top  - block.top   = 126.00    img.height = 3.83
   .text-567 is position:static with no positioned descendants and no existing
   ::before/::after, so position:relative is inert.
   --------------------------------------------------------------------------- */
@media (min-width: 992px) {

  html[data-wf-page="69c397e91a19a2ce973d48a7"] body .herroo img.image-470 {
    visibility: hidden !important;
  }
  html[data-wf-page="69c397e91a19a2ce973d48a7"] body .herroo .text-567 {
    position: relative !important;
  }
  html[data-wf-page="69c397e91a19a2ce973d48a7"] body .herroo .text-567::after {
    content: "" !important;
    position: absolute !important;
    left: -75px !important;
    right: -3.98px !important;
    top: 126px !important;
    height: 3.83px !important;
    border-radius: 999px !important;
    background-image: linear-gradient(to right, rgba(255,150,51,0), #FF9633) !important;
    pointer-events: none !important;
    z-index: 1 !important;
  }

}


/* ============ APPENDED 2026-08-22 18:58: navactive-r30a-desk.css ============ */
/* ============================================================================
   r30-a — NAV ACTIVE-STATE HIGHLIGHTING.  DESK HALF (>=992).
   The BAND half (<=991) is build/css/proposed/r30-a-band.css and carries the
   IDENTICAL rule bodies, so 991 and 992 render the same treatment.
   GLOBAL: the nav is ONE shared component on all 20 pages.  Every selector is
   rooted at `.navbar` — never `html`, never page-scoped (C2).
   NO markup, NO copy, NO href changes.  Webflow already stamps `w--current`
   and `aria-current="page"` on the current page's links; this is pure CSS.

   WHAT GETS MARKED (census, logs/r30/a/census.json, 5 pages x both nav modes)
     .menu-item-13   leaf links inside "What We Do"        (/growth, /manufacturing)
     .menu-item-17   leaf links inside "Who We Are"        (/about-us)
     .menu-item-18   leaf links inside "How We Think"      (/careers)
     .link-block-2 / .w-inline-block (the LOGO, href="/")  -> deliberately EXCLUDED
     .link-style / .link-block-12 / .link-block-13 (FOOTER) -> see FOOTER below
   Both nav compositions (hamburger .container-237 480-920, desktop row 921+)
   carry their own copy of every menu item, so ONE selector set covers both.

   THE TREATMENT, AND WHERE IT COMES FROM
   colour + underline.  NOT background, NOT weight, NOT geometry.
   - Background is already OWNED by the site's own hover state
     (`.menu-item-13:hover{background:#ececec}`, `.menu-item-14/15/16/17/18:hover
     {background:var(--color)}`).  Re-using it for "active" would make the two
     states indistinguishable, and on touch the hover state sticks.
   - Weight and any box property would reflow the nav row as you move between
     pages.  Rect proof: every nav item identical ON vs OFF (REPORT.md).
   - #a84900 is the SITE'S brand orange `--color-2` (#f96900, hsl 25 100% 49%)
     at the same hue and saturation, darkened to hsl 26 100% 33% purely for
     legibility: #f96900 measures 2.73:1 on whitesmoke and FAILS WCAG AA;
     #a84900 measures 5.35:1 on whitesmoke, 4.94:1 on the #ececec hover pill,
     5.84:1 on white.  Numbers in REPORT.md; overrule with one line if wanted.
   - The underline is the non-colour cue (colour-alone would fail 1.4.1).  It
     is ink inside the line box and changes no rect.
   `aria-current="page"` is ALREADY in the markup and is the correct semantic;
   nothing is added or changed for assistive tech.

   THE ` *` STEP IS LOAD-BEARING.  The anchors themselves compute
   `color: rgb(0,0,238)` (unset) — the visible label is a CHILD element with its
   own colour, so colouring only the anchor paints nothing.  `text-decoration`
   propagates to descendants on its own and does not need the step.

   OWNERSHIP — nothing here fights any of the six live nav files.
   navtab-r24 (max-width), navenq-r24b (position/left/width), navvert-r24c
   (height), navcol-r24d (background-color), navwhat-r27g (display/flex-flow/
   width/height/min-*), navsub-r28c (width/margin-inline/align-items) declare
   no `color` and no `text-decoration-*` on any selector in this file.  Verified
   ON vs OFF, one key metric each, in REPORT.md.
   ========================================================================= */
@media screen and (min-width: 992px) {

  /* 1. the current page's own nav link */
  .navbar a[class*="menu-item-"].w--current,
  .navbar a[class*="menu-item-"].w--current * {
    color: #a84900;
  }
  .navbar a[class*="menu-item-"].w--current {
    text-decoration-line: underline;
    text-decoration-color: currentColor;
    text-decoration-thickness: 2px;
    text-underline-offset: 4px;
  }

  /* 2. THE PARENT GROUP.  Webflow only marks the LEAF, so "What We Do" gives
        no clue that /growth lives under it.  `:has()` marks the ancestor group
        with pure CSS - Baseline widely available (Chrome 105, Safari 15.4,
        Firefox 121), and where it is unsupported the selector is simply
        dropped: the leaf still highlights and nothing breaks.  It nests
        correctly by construction - on /growth both "Sectors" (level 2) and
        "What We Do" (level 1) light up, which reads as a breadcrumb.
        Colour + underline only: the toggle rows are `fit-content` boxes
        (navsub-r28c) and must not change width. */
  .navbar .w-dropdown:has(a[class*="menu-item-"].w--current) > .w-dropdown-toggle,
  .navbar .w-dropdown:has(a[class*="menu-item-"].w--current) > .w-dropdown-toggle * {
    color: #a84900;
  }
  .navbar .w-dropdown:has(a[class*="menu-item-"].w--current) > .w-dropdown-toggle {
    text-decoration-line: underline;
    text-decoration-color: currentColor;
    text-decoration-thickness: 2px;
    text-underline-offset: 4px;
  }

  /* 3. FOOTER — DELIBERATELY OFF.  Recommendation: DO NOT ship this.
        `w--current` lands on footer links too, but on /growth it lands on
        THREE of them: the "Growth" link AND the two column HEADINGS "Services"
        and "Sectors", both of which carry href="/growth" in the footer markup
        (logs/r30/a/probe2.txt, FOOTER row).  Highlighting the footer would
        therefore light up two headings that are not the current page - a
        content bug surfaced, not a styling win.  Screenshot of this variant is
        in logs/r30/a/ so it can be overruled with one line; uncomment to ship.
  .footer-links a.link-style.w--current,
  .footer-links a.link-style.w--current *,
  .navbar ~ * a.link-block-12.w--current,
  .navbar ~ * a.link-block-13.w--current { color: #a84900; }
  */
}


/* ============ APPENDED 2026-08-23 00:25: r33-a-wpgrid-desk.css ============ */
/* R33-A desktop twin (>=992), /whitepaper only — see the band
   file's header. 3 cards already tile at 1194/1470; a 4th
   overhangs. Wrap fixes it; no-op at n<=3. */
@media (min-width: 992px) {
  html[data-wf-page="69a7fe2a9be55e8bb7bff0cd"] body .collection-list-7.w-dyn-items {
    flex-flow: row wrap !important;
    justify-content: center !important;
  }
  html[data-wf-page="69a7fe2a9be55e8bb7bff0cd"] body .collection-list-7.w-dyn-items > .collection-item-6:not(:only-child) {
    flex: 0 1 477px !important;
    min-width: 0 !important;
    max-width: 100% !important;
  }
}


/* ============ APPENDED 2026-08-23 23:31: r36-j-desk.css ============ */
/* ============================================================================
   r36 agent J — DESKTOP ONLY (min-width:992px, no upper bound). Two parts.
   Desktop opened BY NAME for item 13 (23 Aug). Everything inside one
   @media (min-width:992px) block per part; nothing below 992.
   ========================================================================= */

/* ---------------------------------------------------------------------------
   PART A — nav ENQUIRE panel, GLOBAL (nav is site-wide, no page scope; same
   exception r24-B used). The >=992 twin of build/css/fixes/navenq-r24b.css.

   CAUSE (measured, logs/r36/j/before-A.json): Webflow base `.dropdown-list-5`
   keeps `width:1000px; margin-left:-722px` at >=992. Measured panel right edge
   vs viewport: 992 -> 1028.2 (maxScrollLeft 36), 1000 -> 1036.2, 1024 -> 1060.2,
   1194 -> 1230.2, 1280 -> 1316.2 — a real 36px horizontal scroll up to ~1443.
   And the 991->992 seam JUMPS: band r24-B gives 48..943 at 991, live desktop
   gives 28.2..1028.2 at 992.

   FIX = the r24-B mechanism, extended: `.dropdown-3` static hands the panel
   `.navbar` (sticky, full width) as containing block; then the panel is pinned
   to the nav pill. The pill row (.frame-10000018610) is full-bleed until its
   max-width:1337.41px cap engages (~1433+), centred above it. So:
     left  = max(48px, calc(50% - 668.705px))      (668.705 = 1337.41/2)
     width = min(calc(100% - 96px), 1337.41px)
   At 992 this is 48..944 — identical (±1px) to the band's 991 rect, so the
   seam is continuous. At 1470/1920 the panel sits exactly on the centred pill
   (66.3..1403.7 / 291.3..1628.7). No width can overflow: width <= 100%-96px.
   min-width:0 kills the base `.w-dropdown-list{min-width:100%}` (same trap
   r24-B hit). The desktop form embed is a hard width:1000px; let it reflow
   exactly as r24-B did. Selectors are (0,2,0) vs the base (0,1,0) — no
   !important needed, and no page-head or deskfix rule touches these classes
   (grepped live heads + prq-deskfix-2026-08-22c.css: zero hits).
   --------------------------------------------------------------------------- */
@media (min-width: 992px) {

  .navbar .dropdown-3 {
    position: static;
  }

  .navbar .dropdown-list-5 {
    left: max(48px, calc(50% - 668.705px));
    right: auto;
    margin-left: 0;
    width: min(calc(100% - 96px), 1337.41px);
    max-width: min(calc(100% - 96px), 1337.41px);
    min-width: 0;
  }

  .navbar .dropdown-list-5 > .w-embed {
    width: 100%;
    max-width: 100%;
  }

}

/* ---------------------------------------------------------------------------
   PART B — /manufacturing hero underline, desktop. Page-scoped
   (6a2697efcafdfab233a12e80). Same mechanism as r29-a-desk (consumer branch):
   the sliver SVG (img.image-469, SAME 1134x5 file as FMB) letterboxes its ink
   in WebKit (no preserveAspectRatio -> xMidYMid meet); stop drawing it, paint
   the rule as a CSS gradient on the accent phrase.

   BOX-UNTOUCHED vs WORD-FLUSH — the r29 test, run at 992/1200/1440/1470/1920
   (logs/r36/j/wordsB output): FMB's approved artwork ratios (LEAD 2.68 /
   TAIL 0.02 of the anchor width) predict img.left = 566.05 - 2.68*475.25 =
   -707.6 for anchor "manufacturers." vs actual -35.8 (672px off), and -2116 for
   the full phrase — nowhere near <1px. The box is NOT the approved artwork
   geometry (it overhangs the anchor by a constant -219.05px left at every
   width and leaves the viewport entirely at 992: img.left -104.4). So:
   WORD-FLUSH, like /consumer in r29-a. Anchor = the whole italic accent span
   "mid-market manufacturers." (class ends in -1) — the SAME span the shipped
   768-991 band rule underlines in full (band 21m line 11615), so the 991/992
   seam reads as the same full-phrase underline. Single line (1 client rect) at
   every width 992-1920; fs 78px constant.
   Values re-derived from the authored img box at 1200 (constant 1200-1920):
     height  4.67px / 78px                    = 0.0599em -> 0.06em
     bottom  span.bottom - img.bottom = 2.87px / 78 = 0.0368em
     right   0 — painter-checked (logs/r36/j/px.py): bar right col 1040 ==
             the italic period's own ink right col 1040 at 1200 (delta 0)
   The span is position:static, no authored ::before/::after (asserted in the
   prove run), so position:relative is inert.
   --------------------------------------------------------------------------- */
@media (min-width: 992px) {

  html[data-wf-page="6a2697efcafdfab233a12e80"] body .herroo img.image-469 {
    visibility: hidden !important;
  }
  html[data-wf-page="6a2697efcafdfab233a12e80"] body .herroo .text-549 span.we-engineer-value-breakouts-for-mid-market-manufacturers-1 {
    position: relative !important;
  }
  html[data-wf-page="6a2697efcafdfab233a12e80"] body .herroo .text-549 span.we-engineer-value-breakouts-for-mid-market-manufacturers-1::after {
    content: "" !important;
    position: absolute !important;
    left: 0 !important;
    right: 0 !important;
    bottom: 0.0368em !important;
    height: 0.06em !important;
    border-radius: 999px !important;
    background-image: linear-gradient(to right, rgba(255,150,51,0), #FF9633) !important;
    pointer-events: none !important;
    z-index: 1 !important;
  }

}


/* ============ APPENDED 2026-08-23 23:31: r36-k2-desk.css ============ */
/* r36-k2 (B): HubSpot newsletter iframe intercepts footer links at 992-1469.
   Cause: Webflow base `.footer { height:100vh; overflow:hidden }` + display:flex
   center — at 992/1194 the footer content (scrollHeight 1008-1056px) is taller
   than 100vh, the centred overflow pushes the first link row ~54-78px ABOVE the
   footer top edge, under the newsletter section's HubSpot form wrapper
   (.div-block-98, position:relative z-index:40, iframe 210px tall) which itself
   overhangs its section by ~22px. elementFromPoint on logo/About Us/Services/
   Sectors (992) and About Us/Services/Sectors/Thought Leadership (1194) returns
   the HS IFRAME. Fix = the desktop twin of the band's existing
   `.footer{height:auto!important}`: let the footer grow, keep 100vh minimum.
   The form is untouched. C5 note: the footer's only absolute child is
   .st_wrapper (Back-to-Top pill), bottom-anchored — it stays at footer bottom. */
@media (min-width: 992px) {
  html[data-wf-page="695f47e15a2d0396f4b09ea6"] body .footer,
  html[data-wf-page="6a26980bff679ec1b699021f"] body .footer,
  html[data-wf-page="6a410ffa9ea227a7c2c9900d"] body .footer {
    height: auto;
    min-height: 100vh;
  }
}


/* ============ APPENDED 2026-08-23 23:31: r36-i1-desk.css ============ */
/* r36-i1-desk — /product-orbit-report >=992: NO RULES NEEDED, measured.
   Desktop was opened for this item, and every heading role was censused OFF vs ON at
   992 and 1470 (logs/r36/i1/FINAL-SWEEP.txt): orbit already equals alpha role for role
   there — hero 106/400+600, .text-201 60/500, .text-202 50/700, .text-208 60/400,
   .text-211 60/500, when-... 75/400+600 — and the >=992 rows are rect-identical OFF vs
   ON (docH 6265/6265 at 992, 6287/6287 at 1470). The flattening was <=991 only (the
   :where() clamp rules in the band asset); the deskfix asset carries zero rules for
   page 69ae7305afc289537c5cbba1. Shipping an empty file rather than inventing rules. */


/* ============ APPENDED 2026-08-25 12:16: r38-A.css ============ */
/* ==========================================================
   ROUND 38 — A : /about-us  TEAM CARDS  (item 1)
   PAGE 69654c46fc526095771e37cc   DESKTOP >=992 ONLY.
   Single @media (min-width:992px); max 991 is not in any selector.

   REPORTED (Vyshak, 13" laptop):
     "Alignment and double padding on the team and other photos"
     — one card in a row carries an empty band the others do not,
       and the name / role / qualification block sits at a different
       height across the row (he circled "Kartik Khurdia").

   REPRODUCED, live, 1280 and 1440 — logs/r38/agentA/ourteam-1280-before.png
   name top (dy from card top), every card, every tab:
     OUR TEAM  Harsha 303.1  Karan 281.1  Vyshak 281.1        (row 1)
               Anirudha 303.1  Kanishka 303.1  Kartik 281.1   (row 2, his circle)
               Pradyumna 281.1  Sahaja 281.1
     BOARD     Anand 313.1  Rajesh 313.1  Arnab 313.1
               Uday 288.1   Rajnish 313.1                     (same row, 25px apart)
     PARTNERS  all three 303.1                                 (agree today, same mechanism)
   The LinkedIn icon is already at dy 413.1 on every card of every tab.

   CAUSE — COPY LENGTH, NOT AN AUTHOR-TIME OVERRIDE.
   Every card is structurally identical: same classes, same child
   count (3), no per-card inline style except the shared opacity:0
   on .hover_overlay. The white panel is a FIXED box:
     .default_info        absolute, height 192, margin-top 281
       .frame-1000006856  flex column, justify-content:FLEX-END, pb 24
         .content-style-14 / -24 / -9   flex column, FLEX-GROW:0, mt 10
           .info-11 / -14 / -6          name + role + qualification
           linkedin icon                a.w-inline-block / .social-icons-8
   The content block is shrink-to-fit inside a flex-END parent, so it
   is BOTTOM-anchored: its bottom is nailed at dy 449 and its TOP
   floats with its own height. The qualification line is the variable:
   .text-506 is 22px for "BCom, Christ University | CA, ICAI" and 44px
   for "BCom, Delhi University | CA, ICAI | CFA (L1)" — one line vs two
   in the same 241px column (.text-704 on Board: 25 vs 50). So the whole
   name block starts 22px (Board 25px) lower on every short-qualification
   card. That offset IS the empty band, and it IS the row misalignment:
   one cause, both symptoms. COPY IS NOT CHANGED.
   The long-qualification cards additionally overflow the panel padding
   (10 + 167.9 into a 168px content box), which is why Kartik's name sits
   flush against the photo with no top padding at all.

   THE FIX — flow only. No new pixel, no new breakpoint, no pinned height.
   Let the content block FILL the panel instead of shrink-to-fit
   (flex-grow:1) and distribute its two children to the two ends
   (justify-content:space-between). The name block is then TOP-anchored
   at the author's own margin-top:10px -> dy 291 on every card of every
   tab, and the icon row is BOTTOM-anchored -> dy 413.1, exactly where
   it already is. row-gap:0 because with space-between the gap IS the
   free space; keeping the authored 24px would re-create the overflow
   (168 - 10 - 108 - 35.9 = 14.1px of room). Worst case after the fix is
   Board's two-line card at 110 + 35.9 = 145.9 in 158 — 12.1px of slack,
   so nothing overflows and nothing collides.
   No dead space is added to make one box match another (rule 5): the
   slack a short qualification leaves simply lands between the
   qualification and the icon instead of above the name.
   C4/C5 clear: no scroll-drawn SVG and no absolute/sticky/fixed
   descendant inside the content block; no ancestor is touched, so
   .default_info, .team_card and the section keep their exact heights.

   BLAST RADIUS: .content-style-14/-24/-9 exist only inside .team_card
   on this page. Board and Our Team both carry the defect. Partners is
   correct today but is the same shrink-to-fit mechanism and one class
   away from the same bug — and if it were left out, the three panes
   would rest at three different heights (291 / 291 / 303) as you click
   between them, which is the complaint again. The three selectors are
   written as separate blocks so any one can be dropped.
   ========================================================== */

@media (min-width: 992px) {

  /* OUR TEAM pane */
  html[data-wf-page="69654c46fc526095771e37cc"] body .team_card .content-style-14 {
    flex-grow: 1;
    justify-content: space-between;
    row-gap: 0px;
  }

  /* BOARD pane */
  html[data-wf-page="69654c46fc526095771e37cc"] body .team_card .content-style-24 {
    flex-grow: 1;
    justify-content: space-between;
    row-gap: 0px;
  }

  /* PARTNERS pane */
  html[data-wf-page="69654c46fc526095771e37cc"] body .team_card .content-style-9 {
    flex-grow: 1;
    justify-content: space-between;
    row-gap: 0px;
  }

}


/* ============ APPENDED 2026-08-25 12:16: r38-B.css ============ */
/* ==========================================================================
   ROUND 38 — ITEM 2 — /about-us (69654c46fc526095771e37cc) — DESKTOP >=992
   Vyshak, 25 Aug: "These were supposed to come one by one and not static to the line."

   MEASURED DEFECT (logs/r38/agentB/before-1280.json, ancestor-aware opacity, per frame):
   the four statement lines all rise inside 116ms — .text-131 + .text-691 at t=801ms and
   .text-130 + .text-364 at t=917ms — so the block reads as ONE simultaneous paint.
   Cause: Webflow IX2 fades the two COLUMN wrappers (.left-text / .right-text), not the lines,
   and the two column animations start 83-116ms apart. IX2 writes the wrapper's opacity as an
   INLINE style every frame from its own rAF engine, so no CSS transition-delay can stagger it.

   THE SEAM: parent opacity MULTIPLIES child opacity, so a child held at opacity 0 stays
   invisible however the IX2 parent behaves. We therefore stagger the CHILDREN and never touch
   the parent's opacity, its transform, or the interaction itself.

   🔴 FAIL-SAFE BY CONSTRUCTION: the opacity:0 start state is keyed off `.r38-stagger`, a class
   that ONLY build/js/proposed/r38-B.js adds. If that script does not load, does not run, or
   errors, this file matches nothing and the lines paint exactly as they do today. There is no
   unconditional opacity:0 on any line.
   ========================================================================== */
@media (min-width: 992px) {

  /* start state — applied only while the script has armed the block */
  html[data-wf-page="69654c46fc526095771e37cc"] body .middle-area-content .w-layout-grid.grid-2.r38-stagger > .left-text > .text-130,
  html[data-wf-page="69654c46fc526095771e37cc"] body .middle-area-content .w-layout-grid.grid-2.r38-stagger > .right-text > .text-131,
  html[data-wf-page="69654c46fc526095771e37cc"] body .middle-area-content .w-layout-grid.grid-2.r38-stagger > .right-text > .text-691,
  html[data-wf-page="69654c46fc526095771e37cc"] body .middle-area-content .w-layout-grid.grid-2.r38-stagger > .left-text > .text-364 {
    opacity: 0;
    transform: translateY(12px);
    transition: opacity .45s ease-out, transform .45s ease-out;
  }

  /* revealed state — the script adds .r38-in one line at a time, in reading order */
  html[data-wf-page="69654c46fc526095771e37cc"] body .middle-area-content .w-layout-grid.grid-2.r38-stagger > .left-text > .text-130.r38-in,
  html[data-wf-page="69654c46fc526095771e37cc"] body .middle-area-content .w-layout-grid.grid-2.r38-stagger > .right-text > .text-131.r38-in,
  html[data-wf-page="69654c46fc526095771e37cc"] body .middle-area-content .w-layout-grid.grid-2.r38-stagger > .right-text > .text-691.r38-in,
  html[data-wf-page="69654c46fc526095771e37cc"] body .middle-area-content .w-layout-grid.grid-2.r38-stagger > .left-text > .text-364.r38-in {
    opacity: 1;
    transform: none;
  }
}

/* reduced motion: nothing is ever held back. (The script also refuses to arm under it —
   this block is the second belt, for a preference changed after the script ran.) */
@media (min-width: 992px) and (prefers-reduced-motion: reduce) {
  html[data-wf-page="69654c46fc526095771e37cc"] body .middle-area-content .w-layout-grid.grid-2.r38-stagger > .left-text > .text-130,
  html[data-wf-page="69654c46fc526095771e37cc"] body .middle-area-content .w-layout-grid.grid-2.r38-stagger > .right-text > .text-131,
  html[data-wf-page="69654c46fc526095771e37cc"] body .middle-area-content .w-layout-grid.grid-2.r38-stagger > .right-text > .text-691,
  html[data-wf-page="69654c46fc526095771e37cc"] body .middle-area-content .w-layout-grid.grid-2.r38-stagger > .left-text > .text-364 {
    opacity: 1;
    transform: none;
    transition: none;
  }
}


/* ============ APPENDED 2026-08-25 12:16: r38-C.css ============ */
/* ROUND 38 — item 3 — /about-us — DESKTOP >=992
   "The line is off from Saudi."  (Vyshak, 13" laptop)

   The map hub (the pulsing dot, the 4 short arcs in .code-embed-24 and the tall
   vertical connector in .curve-tall-wrap) is pinned at a FIXED offset inside
   .svg-layer-2.hshs, so it sits at the same page-y at every desktop width.
   The 5th line — the long single arc in .code-embed-25 — is a STATIC flex item
   that follows .image-523 (the world map) in flow, and .image-523's height
   scales with the viewport (h = 38.8194% of the container width). Its authored
   margin-top:-520px was tuned at 1440, where the map is exactly 559px tall, so
   the arc only meets the hub at 1440 and rides up/down by (imgH - 559px)
   everywhere else — 63px high at 1280, 175px high at 992, 186px low at 1920.

   Fix: fold the map's own height into the margin as a PERCENTAGE OF THE SAME
   CONTAINING-BLOCK WIDTH the map is sized from, so the arc's start point stops
   depending on the map's height and lands on the hub at every width.
   -520px (authored) + 559px (the map's height at the authored 1440) - 38.8194%.
   Percentage margins resolve against the containing block's inline size, which
   is the identical box .image-523 fills, so the two are now in ONE coordinate
   system and there is no per-width nudging.

   C4: .code-embed-25 > svg is `draw-on-scroll reverse lines-single`. Nothing
   here resizes, re-dashes, re-times or transforms it — only the WRAPPER DIV's
   margin moves. Reverse-group progress is (scrollY - svg._reverseStart)/(0.35*
   innerHeight), i.e. scroll-distance based, NOT rect based, so draw timing is
   bit-identical. No ancestor is transformed. */

@media (min-width: 992px) {
  html[data-wf-page="69654c46fc526095771e37cc"] body .svg-layer-2.hshs .code-embed-25 {
    margin-top: calc(-520px + 559px - 38.8194%);
  }
}


/* ============ APPENDED 2026-08-25 12:16: r38-D.css ============ */
/* ==========================================================================
   ROUND 38 — item 4 — /growth — DESKTOP >=992      (v2, rebuilt after QA block)
   Vyshak: "This shouldn't come in this frame"

   THE DEFECT (unchanged diagnosis, re-proved): there is no bleed-through and no
   artwork overlap anywhere in 992..1920 — ink-vs-ink overlap is 0. The hero's
   two flow-line blocks are GUILLOTINED by the bottom of the window: on a fresh
   load at scrollY 0 they have already run their Webflow reveal (opacity 0 -> 1)
   while the fold passes straight through them, so you land on the hero and see a
   sliced, half-faded line of type welded to the bottom edge.
       LIVE guillotine band: page y 775.5 .. 950.5  ->  77 of 203 (width,height)
       cells cut across 992..1920 x vh 600..1100.

   WHY v1 WAS BLOCKED, and it was right to block it: v1 moved the pair up with a
   PERCENTAGE OF THE GRID ROW. `.growth-main-section` is height:1190px in fixed
   px, so a % of that row is viewport-height-INDEPENDENT — the band did not go
   away, it slid to y 640..772 and started slicing 1366x768 instead.

   THE CEILING, measured in rendered pixels (harness/r38D_ceiling.mjs, the two
   text blocks hidden so their own ink cannot be mistaken for artwork). First
   orange row of the flow-line curve / band, identical at 992/1280/1440/1920:
       left column  (x under "It's just not our DNA.")  page y = 1027
       right column (x under "Considering half...")     page y = 1145
   The binding one is 1027. With the pair's combined ink extent E and 27px of
   clearance, the lowest reachable ink top is 1000 - E. So "ink top greater than
   the largest viewport height" (>1100) is ARITHMETICALLY OUT OF REACH inside
   this section: it would put the words on top of the orange artwork. Stated
   plainly, per the brief, rather than papered over.

   WHY ONE VIEWPORT-HEIGHT BREAKPOINT IS UNAVOIDABLE (not a preference):
   let f(vh) be the ink top. "Never sliced" requires, for every vh, either
   f(vh) > vh (block below the fold) or f(vh) + E < vh (block above it). The
   pill floors f at 626 and the artwork caps it at 1000-E, so the first is only
   reachable for vh <= 1000-E and the second only for vh >= 626+E. Any CONTINUOUS
   f must cross from one regime to the other, and to do that it has to pass
   through the interval [vh-E, vh] — which is exactly the sliced state. So no
   single continuous expression (%, vh, clamp, calc) can clear the whole range,
   and the fix rule's last resort — one breakpoint — is genuinely required. It is
   spent on HEIGHT, and the range either side is covered by a vh expression with
   min/max caps, so nothing is pinned to a new fixed width.

   THE SHAPE OF THE FIX
     <= 812px tall  (every 13-14" laptop: 656 / 688 / 768 / 789 / 800 / 812)
        the pair sits BELOW the fold, ink top 840. You land on the hero, see the
        heading, the pill and the flow line, and meet the words WHOLE when you
        scroll. That is the literal reading of "shouldn't come in this frame".
     >= 813px tall
        below-the-fold is no longer reachable (840 + 151 would cross 1027), so
        the pair sits ABOVE the fold instead, tracking the viewport with
        clamp(626px, 100vh - 175px, 840px) so it stays as low in the composition
        as the fold allows and never drifts: at vh 813 it is at 638, at vh 900 at
        725, and from vh 1015 up it parks at 840, i.e. back where the design put
        it. Clearance to the fold is >= 24px at every height.
   The stagger between the two halves goes 94px -> 70px. Anything above 82px makes
   the block so tall that the two regimes stop overlapping and NO breakpoint can
   join them; 70px keeps the question clearly above the answer with margin.
   NOT TOUCHED: section height, .svg-line-container, the inline flow-line SVG,
   .grid-3 itself, every copy string. Nothing is hidden, clipped or deleted.

   Geometry: the grid row starts at page y 315.5; each column centres its own
   text, so ink top = 315.5 + height/2 - (half the text's own ink height).
       right column  height = 2*(Qtop - 260)      Qtop 626 -> 732px, 840 -> 1160px
       left  column  height = 2*(Qtop + 70 - 275) Qtop 626 -> 842px, 840 -> 1270px
   ========================================================================== */

/* ---- viewport 992+ and SHORTER than 813px: park the pair below the fold ---- */
@media (min-width: 992px) and (max-height: 812px) {

  /* "Considering half measures?"  ink 775.5..886.5  ->  840..951 */
  html[data-wf-page="697a492dac0e6730581f2a69"] body .growth-main-section .w-layout-grid.grid-3.nbmnbbmb > .right-side-of-the-grid.hellooooo {
    height: 97.479%;            /* 1160px of the 1190px row */
    align-self: start;
    margin-top: 0;
  }

  /* "It's just not our DNA."      ink 869.5..950.5  ->  910..991 */
  html[data-wf-page="697a492dac0e6730581f2a69"] body .growth-main-section .w-layout-grid.grid-3.nbmnbbmb > .left-side-of-the-grid {
    height: 106.723%;           /* 1270px of the 1190px row */
    align-self: start;
  }

}

/* ---- viewport 992+ and 813px or TALLER: the pair rides above the fold ------ */
@media (min-width: 992px) and (min-height: 813px) {

  /* ink top = clamp(626px, 100vh - 175px, 840px) */
  html[data-wf-page="697a492dac0e6730581f2a69"] body .growth-main-section .w-layout-grid.grid-3.nbmnbbmb > .right-side-of-the-grid.hellooooo {
    height: clamp(732px, 200vh - 870px, 1160px);
    align-self: start;
    margin-top: 0;
  }

  html[data-wf-page="697a492dac0e6730581f2a69"] body .growth-main-section .w-layout-grid.grid-3.nbmnbbmb > .left-side-of-the-grid {
    height: clamp(842px, 200vh - 760px, 1270px);
    align-self: start;
  }

}


/* ============ APPENDED 2026-08-25 12:16: r38-E.css ============ */
/* ============================================================================
   ROUND 38 — item 5 — /family-managed-business — DESKTOP >= 992 ONLY
   PAGEID 69c397e91a19a2ce973d48a7
   Vyshak: "The Purpose build for Family owned needs to be in the center of
   the orbit."

   MEASURED CAUSE — the orbit has TWO different centres, and the heading sits
   at neither. Inside .circle-section there are two absolutely-positioned
   siblings, both `top:1400px; height:1400px`:
       .decorative-element   margin-top:-150px  -> holds .code-embed-28..31,
                                                   i.e. every grey ring; each
                                                   embed is static-centred in
                                                   it, so ring centre = its
                                                   box centre.
       .content-container    margin-top: 0      -> holds the orbiting cards
                                                   (.success-stories-grid,
                                                   arm pivot = its box centre)
                                                   AND the heading.
   The 8 Aug "FMB orbit clearance" embed zeroed .content-container's -150px
   but left the sibling .decorative-element on -150px, so the rings paint
   150px above the card orbit they are supposed to describe. The heading is
   then centred in .center-circle-group, which is only 1200px tall and
   TOP-aligned inside the 1400px .main-coniatiner (itself static-positioned
   at +46px by its own margin-top:92px), so it lands 96px below the rings and
   54px above the card pivot.
   Measured, identical at 992/1194/1280/1440/1470/1920:
       ring painted cy 1946.54   card pivot cy 2100   heading ink cy 2042.78
       heading ink cy - ring cy = +96.24 px at every width (constant)
       heading ink cx - ring cx = +0.45 px  (horizontal was already right)

   THE FIX — no new number is invented. .decorative-element is given the SAME
   margin-top:0 its sibling .content-container was already given on 8 Aug, so
   the rings become concentric with the card orbit; then .main-coniatiner is
   made to fill .content-container and .center-circle-group to fill that, so
   the group's EXISTING `justify-content:center` puts the heading on that one
   shared centre by construction at every width. .main-coniatiner's only
   child is .center-circle-group, so no card moves.
   Result: ring cy 2096.54 / heading ink cy 2096.78 / pivot 2100 -> dy 0.24px.
   .decorative-element._333333333.hebrhvuu already carries overflow:hidden,
   so the ring artwork is translated, never re-clipped or re-scaled, and no
   pixel below page y2800 changes (proved by image diff).
   Nothing here touches a scroll-drawn SVG, a stroke, a dash or a transform.
   ========================================================================== */
@media (min-width: 992px) {

  /* 1. the ring box: finish the 8 Aug move its sibling already made */
  html[data-wf-page="69c397e91a19a2ce973d48a7"] body .circle-section .decorative-element._333333333 {
    margin-top: 0;
  }

  /* 2. the heading's box == .content-container's box == the ring box */
  html[data-wf-page="69c397e91a19a2ce973d48a7"] body .circle-section .main-coniatiner._33333._65gryrg {
    top: 0;
    margin-top: 0;
    height: 100%;
  }

  /* 3. fill it, so the group's own justify-content:center IS the orbit centre */
  html[data-wf-page="69c397e91a19a2ce973d48a7"] body .circle-section .center-circle-group._9999._89hryr {
    height: 100%;
  }

}


/* ============ APPENDED 2026-08-25 12:16: r38-F.css ============ */
/* ============================================================================
   r38 agent F — item 6, /family-managed-business, DESKTOP ONLY (>=992).
   Vyshak: "Spacing in this line in family business page is too much"
   -> the heading "We understand the value of family."

   WHICH OF THE FOUR IT IS: (a) LINE-HEIGHT.
   NOT letter/word-spacing: letter-spacing:normal, word-spacing:0px, and the
     "of" -> "family." gap measures 15.0px on a 64px face = one normal space.
   NOT margin/padding: both spans and both .text-709 wrappers are 0 on all
     four sides; .content_container padding 0.
   NOT a dead vertical run: the 940px margin-top on section-26 is clearing the
     absolutely-positioned orbit block above it (.content-container._6567,
     position:absolute, y1400-2800) and is load-bearing — do not touch it.

   CAUSE, measured live at 992/1194/1280/1440/1470/1920 (all six identical):
     .we-understand-the-value-of-family-2 / -3   font-size   64px
                                                 line-height 77.44px = 1.21
   Every other big section heading on this page and on both sibling sector
   pages runs ratio 1.00 at >=992:
     /manufacturing (the agreed reference page)
        "This is where we operate."             75px / 75px = 1.00
        "Manufacturers like you sit in the.."    75px / 75px = 1.00
        "Over 75% of mid-market companies.."     75px / 75px = 1.00
        "We engineer value breakouts.."          78px / 78px = 1.00
     /consumer
        "We build new architecture"              78px / 78px = 1.00
        "Have Changed."                          75px / 75px = 1.00
     /family-managed-business (its OWN other H2)
        "Unlocking your next Rs500 - 1,000 Cr"   75px / 75px = 1.00
   This heading is the outlier: at 1.21 the two wrapped lines sit 77.44px
   apart where the house value would put them 64px apart — 13.44px of extra
   air per line gap, on a heading that always wraps to two lines at >=992.

   FIX: land on the value the siblings already use (standing rule 12).
   Unitless 1 — no px, no vw, no width-pinned magic number, no new breakpoint.

   CASCADE (C1): the deskfix asset is the LAST <link rel=stylesheet> in <head>
   (6a8b3607ecd76b1215dc0d75_prq-deskfix-2026-08-22d.css) with 15 page-head
   <style> blocks after it. All 15 read live: ZERO mention of
   `we-understand-the-value-of-family`. Proven by injecting this file at
   exactly that node position on the live page — computed line-height went
   77.44px -> 64px at all six widths. Selector is (0,3,2) against the Webflow
   base (0,1,0); no !important needed.

   HEIGHT (C5): .text-709 shrinks 159.9 -> 134.0px (painted ink 159.4 ->
   147.0). section-26 is a fixed height:600px, so the section box and every
   element after it are byte-identical and document height is UNCHANGED at all
   six widths. Only .text-351 / .main_para_content inside the section ride up
   25.9px, keeping their own heights. Census of every descendant of section-26:
   ZERO position:absolute / sticky / fixed (posDesc == []). Scroll swept at
   0/20/40/60/80/100% at all six widths: scrollWidth == viewport, document
   height constant. Pixel clearance between line 1's ink and the "family."
   ascender measured on the PNGs: 33px -> 21px, no overlap.

   768 SEAM: this page carries 6 `max-width: 768px` embeds. This rule starts at
   992 and never enters that seam; 767 / 768 / 769 measured rect-identical
   (full-page census, 0 diffs).
   ========================================================================== */

@media (min-width: 992px) {

  html[data-wf-page="69c397e91a19a2ce973d48a7"] body .text-709 .we-understand-the-value-of-family-2,
  html[data-wf-page="69c397e91a19a2ce973d48a7"] body .text-709 .we-understand-the-value-of-family-3 {
    line-height: 1;
  }

}


/* ============ APPENDED 2026-08-25 12:16: r38-G.css ============ */
/* ROUND 38 — item 7 — /family-managed-business — DESKTOP >=992 only.
   Vyshak: "Animation of line isn't center aligned to the words below."

   WHAT IT IS: the scroll-drawn flow line
   .verticall_line_containerr > .code-embed-12 > svg.draw-on-scroll.speedmax
   (viewBox 0 0 637 1298, drawn by animating a clipPath <rect height>).
   Its last ~220px is a straight vertical stem that hangs just above
   "SOMETHING TO THINK ABOUT / Will you become part of the 5% ...".

   MEASURED: the stem's painted centre sits at (viewport centre + 33.0px) at
   992 / 1194 / 1280 / 1440 / 1470 / 1920 — a CONSTANT offset — while the ring
   and the words below it are centred at exactly the viewport centre (0.0px).
   The artwork is a fixed 637px block positioned by fixed px, so the correction
   is a constant -33px in the same coordinate system, not a new magic number at
   a new width. It holds unchanged across the whole >=992 range.

   C4: the svg is SCROLL-DRAWN. This is a plain positional offset on the
   WRAPPER (position:relative/left). No transform, no scale, no size change:
   the svg's rendered box, viewBox, path d, getTotalLength() and the clip-rect
   draw geometry are all byte-identical before and after. position:relative
   with z-index:auto does not create a stacking context and does not move
   siblings, so nothing else in the section shifts. */

@media (min-width: 992px) {
  html[data-wf-page="69c397e91a19a2ce973d48a7"] body .verticall_line_containerr .code-embed-12 {
    position: relative;
    left: -33px;
  }
}


/* ============ APPENDED 2026-08-25 12:16: r38-H.css ============ */
/* ==========================================================================
   ROUND 38 — item 6 EXTENSION — /family-managed-business — DESKTOP >=992
   PAGE 69c397e91a19a2ce973d48a7

   NOT one of Vyshak's seven. Raised by the DESIGN REVIEWER as the round's top
   finding, and applied because WITHOUT IT THIS ROUND MAKES THE PAGE WORSE.

   Item 6 sets "We understand the value of family." from line-height 1.21 to
   1.00, which is the value every equivalent section-statement H2 already uses
   on /manufacturing (78/78, 75/75 x4), /consumer (78/78, 75/75), /growth
   (75/75) and on THIS page's own other H2s ("Unlocking your next" 75/75,
   "We help family managed businesses..." 64/64).

   But "Purpose built for Family Owned Businesses" — the orbit heading item 5
   is centring, ON THE SAME PAGE, the SAME 64px face, the SAME 77.44px
   line-height (1.21) — is not in item 6's selector. /manufacturing's
   equivalent orbit heading is 75/75 = 1.00 and /consumer's is 75/75 = 1.00,
   so it is the same outlier one section away.
   TODAY the two FMB headings MATCH each other (both wrong against the house
   value). After item 6 alone they would MISMATCH. Fixing one of a matched
   pair leaves the page LESS internally consistent than it is now — standing
   rule 12, "equal gaps and sizes site-wide".

   MEASURED BY THE DESIGN REVIEWER, live, merged set injected at the real
   cascade slot, identical at 1280 and 1440:
       merged as-is          heading ink cy 1996.78  ring cy 1997  dy -0.22
       merged + this file    heading ink cy 1997.00  ring cy 1997  dy  0.00
       ink height 165.4 -> 152.0, word count 6 -> 6 (nothing erased)
   The group's own justify-content:center re-centres the shorter block, so
   ITEM 5 GETS BETTER, not worse: dy -0.22 -> 0.00.

   Attribute-prefix selector because the heading's words are split across
   per-word spans (...-1, ...-2, ...) generated by the page's own markup.
   ========================================================================== */

@media (min-width: 992px) {
  html[data-wf-page="69c397e91a19a2ce973d48a7"] body .center-circle-group [class^="purpose-built-for-family-owned-businesses-"] {
    line-height: 1;
  }
}


/* ============ APPENDED 2026-08-25 15:37: fmbjoin-r39.css ============ */
/* r39-A  —  /family-managed-business  —  DESKTOP >=992 only.
   Ashik, 25 Aug: "In the desktop, family managed business page the lines breaking, fix this."

   THE DEFECT: the vertical rail that runs down through Data / Speed / Professional Management /
   Governance is one SVG artwork (.code-embed-11, viewBox 0 0 1364 1318) and the orange flow line
   that continues below it is a SECOND artwork (.code-embed-12, viewBox 0 0 637 1298). They have to
   abut at the Governance node. Measured live, fully drawn:
       992  gap 218.78px   1194  gap 117.78px   1280  gap 74.78px   1364-1920  gap 32.78px

   CAUSE 1 (below 1364) - THE CLAMP. .veryical_line_container is position:absolute, display:flex,
   justify-content:center, overflow:hidden, MAX-WIDTH:100%. Its width shrink-wraps to the 1364px
   artwork, so as soon as the viewport is narrower than 1364 the max-width clamps it to 100% and
   the artwork stops being centred - it pins to the container's left edge and its bottom endpoint
   sticks at an ABSOLUTE x of 690.79 while the icons, the flow line and the words below all keep
   tracking the page centre. At 992 the rail ends up 190px right of its own Governance icon.

   CAUSE 2 (every width) - r38 ITEM 7. That item put left:-33px on .code-embed-12 to centre the
   flow line's BOTTOM stem on "Will you become part of the 5%...". The path's start (610.517) and
   end (634.5) are 23.983 user-units apart, so translating the artwork centred the bottom and
   un-joined the top by exactly that much. Before r38 the join was 0.23px at >=1364.

   THIS FILE FIXES CAUSE 1 AND HALF OF CAUSE 2. It retires the clamp's effect by giving the rail
   an anchor that survives it: 690.793 is the path's OWN bottom-endpoint x, so
   `left: calc(50% - 690.793px)` lands that endpoint exactly on the page centre at EVERY width.
   No new fixed pixel at a new fixed width - the only constant is read off the artwork's own path
   data, and .code-embed-11's width always equals its container's, which is always centred in the
   viewport, so 50% is always the page centre.
   position:relative + left is a PURE VISUAL shift: the layout box does not move, so scrollable
   overflow is unchanged and the container's own overflow:hidden still clips exactly as today.

   C4: .draw-on-scroll is drawn by animating a <clipPath><rect height> in USER units (stroke-
   dasharray is `none`, getTotalLength is never read - see the page's own draw script). Nothing
   here resizes, re-dashes, re-times or transforms the svg. */
@media (min-width: 992px) {
  html[data-wf-page="69c397e91a19a2ce973d48a7"] body .veryical_line_container .code-embed-11 svg.draw-on-scroll:first-of-type {
    position: relative;
    left: calc(50% - 690.793px);
  }
}


/* ============ APPENDED 2026-08-25 22:59: r40-A.css ============ */
/* ==========================================================================
   ROUND 39 — item R39-1 — /growth hero — DESKTOP >=992
   Vyshak 4:49PM: "This isn't how it needs to be placed. I think something is
   wrong here."   HIS SCREENSHOT IS THE PRE-r38 PAGE.

   WHAT IS ALREADY CURED: the fold guillotine (r38 item 4) is live in
   prq-deskfix-2026-08-22f.css and works — verified on fresh loads at
   1280x800 / 1366x768 / 1440x789 / 1440x900 / 1470x876 / 1920x1080 /
   992x800 / 1194x834. Nothing here touches the vertical geometry, so that
   guarantee is untouched by construction (only text-align and one gutter).

   WHAT IS STILL WRONG, and it is a placement bug with a provable cause:
   the answer block is authored to sit FLUSH RIGHT against the orange rail.
   Webflow put that instruction on the wrong boxes:
       .its-just-not-our-dna-0 { text-align:right; width:100% }
       .its-just-not-our-dna-2 { text-align:right; width:100% }
   Both are INLINE <span>s. `text-align` and `width` are inert on an inline
   box, so on desktop the block computes text-align:start and renders
   left-aligned and ragged-right. The designer had to re-declare it on the
   BLOCK to make it work at <=479:
       @media (max-width:479px) .text-146.jkj { text-align:right; width:70% }
       @media (max-width:479px) .text-147     { text-align:right; width:75% }
   and at 375 both blocks do render flush right against the rail. Desktop
   never got that re-declaration.

   MEASURED (identical at 992/1100/1194/1280/1366/1440/1470/1600/1920 — the
   whole composition is width-invariant, gaps constant to 0.1px):
       rail (the inline svg's vertical stroke, x=820 in a 823-wide viewBox)
       answer line 1 "It's just not"  ends  7.0px short of the rail
       answer line 2 "our DNA."       ends 46.4px short of the rail   <-- ragged
       question ink starts           33.0px right of the rail
   So the left half is ragged AND jammed at 7px while the right half breathes
   at 33px. That is the "isn't how it needs to be placed".

   BLOCK 1 is the bug fix: give the block the alignment its own spans ask for.
   BLOCK 2 equalises the two gutters at 33px so the rail sits centred in a
   40px channel instead of 7px/33px. It is deliberately a SEPARATE block:
   delete it and block 1 still stands on its own.
   ========================================================================== */

@media (min-width: 992px) {

  /* --- 1. the authored right-alignment, moved onto a block box ------------ */
  html[data-wf-page="697a492dac0e6730581f2a69"] body .growth-main-section
    .w-layout-grid.grid-3.nbmnbbmb > .left-side-of-the-grid .text-146 {
    text-align: right;
  }

  /* --- 2. equal 33px channel either side of the rail ---------------------- */
  /*    live: 24px margin-right leaves the ink 7.0px from the rail.
        The rail is 26px inboard of the column's own right edge, so the same
        33px the question already has needs 24 + 26 = 50px here.            */
  html[data-wf-page="697a492dac0e6730581f2a69"] body .growth-main-section
    .w-layout-grid.grid-3.nbmnbbmb > .left-side-of-the-grid {
    margin-right: 50px;
  }

}


/* ============ APPENDED 2026-08-25 22:59: r40-B.css ============ */
/* ============================================================================
   ROUND 39 — AGENT B — items R39-2 + R39-4
   The orange sticky SIDE MENUS. Desktop only (>=992). Vyshak 25 Aug 4:51-4:53 PM:
   "This is different from Font sizes to the other ones" / "Both the side menus need
   to have this spacing fixed."

   INVENTORY (measured live, not assumed) — the component is on THREE pages:
     /transaction          .frame-10000019236   4 items  .text-683                17px/121%/300
     /m-a-advisory         .frame-10000019245   4 items  .text-689                17px/121%/300
                                                         .synergy-adjacency-...   17px/100%/400  <- deviant
     /the-investment-desk  .frame-10000019240   6 items  .text-685 / .text-687    15px/100%/300  <- deviant
   (/growth /efficiency /portfoliovalue /manufacturing /consumer /family-managed-business
    /diy /product-alpha-metrics /product-orbit-report /case-studies /whitepaper /blog
    /about-us /careers /contact-us /privacy-policy /style-guide and the /project/* pages
    were swept with harness/r39B_disc.mjs: no such component on any of them.)
   All three panels are display:none at EVERY width <=991 (harness/r39B_sub992.mjs), so
   this component is desktop-only by construction as well as by media query.

   DERIVATION of 1.3 — not invented. Census of every SMALL-TYPE RUN THAT ACTUALLY WRAPS
   on these same three pages (harness/r39B_census.mjs -> logs/r39/agentB/census.json):
       /transaction         1.3 x4   1.4 x1   1.5 x2
       /m-a-advisory        1.3 x6   1.4 x4   1.5 x1   (+ the 3 defective menu items at 1.0)
       /the-investment-desk 1.3 x16  1.5 x5            (+ 3 display headings at 1.0)
   1.3 is the modal ratio on all three pages and the site applies it at 13px, 15px, 18px
   and 20px alike, i.e. it is a size-independent site ratio, not a one-off. The only 1.0
   survivors are display headings. 121% (today's menu value) leaves 0.6px between the ink
   of two wrapped lines; 100% makes the ink OVERFLOW its own line box by 1.5px top and
   bottom — that is the cramping, and the uneven ink rhythm, that Vyshak photographed.
   font-weight:300 is what 5 of the 11 items and 2 of the 3 panels already use.
   ============================================================================ */
@media (min-width:992px){

  /* --- /transaction — .text-683 x4 : 121%/300 -> 1.3/300 ------------------- */
  html[data-wf-page="69beaa159de154a927745525"] body .frame-10000019236 .text-683{
    font-weight:300;
    line-height:1.3;
  }

  /* --- /m-a-advisory — .text-689 x1 + .synergy-adjacency-analysis x3 ------- */
  /* the whole point of the item: one list, two treatments. Both end at 17/1.3/300,
     which is exactly the treatment /transaction's list now carries. */
  html[data-wf-page="69ad5decf269310df111d3f5"] body .frame-10000019245 .text-689,
  html[data-wf-page="69ad5decf269310df111d3f5"] body .frame-10000019245 .synergy-adjacency-analysis{
    font-size:17px;
    font-weight:300;
    line-height:1.3;
  }

  /* --- /the-investment-desk — .frame-10000019240, 6 items, 15px/100%/300 -----
     DELIBERATELY NOT CHANGED. It was built, measured, and then rejected:
       * its 6 labels are single-line at EVERY width >=992 (that panel is a fixed
         221.3px at every viewport), so line-height cannot change its ink rhythm at
         all — its ink gaps are already 29.58px x5, exactly equal.
       * the ONLY thing line-height:1.3 does there is make the panel 27px taller
         (325.86 -> 352.86), and at 992 that drops the opaque orange panel over the
         top ~23px of the "Why The Investment Desk exists" heading.
         Proof: logs/r39/agentB/_the-investment-desk-992-before.png vs
                logs/r39/agentB/_the-investment-desk-992-REJECTED-variant.png,
         and harness/r38_gate.mjs flagged it: "overlap 8->9 (noise 0)".
     A change with no visual benefit that plants a real clipping regression is not a
     fix. Its genuine disagreement with the other two panels is FONT SIZE (15 vs 17)
     and item count (6 vs 4) — a design question for the reviewer, written up in
     REPORT.md, not something to answer by guessing here.
     ------------------------------------------------------------------------ */
}


/* ============ APPENDED 2026-08-25 22:59: r40-C.css ============ */
/* ============================================================================
   ROUND 39 — AGENT C — item R39-3
   "...and even the Prequate's logo covers the other one"   (Vyshak, 4:51 PM)

   WHAT IS ACTUALLY WRONG
   The orange side-menu tab is position:sticky and it PARKS INSIDE the sticky
   nav's own band, so the collision never scrolls away. Measured live, the nav
   band is identical at every width >=992 and at every scroll position:
        nav box .navbar.w-nav   y 50..120   z-index 12000
        painted pill            y 46.5..123.5
   The three tabs park at:
        /transaction          .frame-10000019236   top:100px  -> 23px inside the band
        /m-a-advisory         .frame-10000019245   top: 50px  -> 73px inside the band
        /the-investment-desk  .frame-10000019240   top: 50px  -> 73px inside the band
   Swept 41 scroll positions per page: the pill painted over the tab at 33/41
   (/transaction), 32/41 (/m-a-advisory), 34/41 (/the-investment-desk). On
   /m-a-advisory the pill hides the FIRST menu item ("Partner search") outright.
   The nav is sealed site-wide (r30, 20 pages), so the TAB moves, not the nav.

   140px is the nav band's own bottom (sticky top 50 + nav height 70 = 120) plus
   a 20px gap. It is width-independent because the nav band is width-independent
   (measured identical at 992/1194/1280/1366/1440/1470/1920 and at scrollY
   0/1500/4000). It also makes the three tabs park at the SAME height, which they
   do not today (100 / 50 / 50).
   ========================================================================== */
@media (min-width: 992px) {

  html[data-wf-page="69beaa159de154a927745525"] body .frame-10000019236,
  html[data-wf-page="69ad5decf269310df111d3f5"] body .frame-10000019245,
  html[data-wf-page="69bfc522d51b3633b0925da1"] body .frame-10000019240 {
    top: 140px;
  }
}

/* ----------------------------------------------------------------------------
   SAME COMPONENT, HORIZONTAL PLACEMENT — /m-a-advisory only, >=1470 only.

   The tab has border-radius on its LEFT corners only: it is a tab attached to
   the right edge of the page. /transaction and /the-investment-desk get that
   with margin-left:auto and are flush at every width. /m-a-advisory instead
   carries margin-left:1200px, which the site head already patches to 81.633%
   for @media (min-width:480px) and (max-width:1469px) — 81.633% of 1470 IS
   1200px, i.e. the author meant "270px in from the right edge at 1470".
   Above 1469 nothing patches it, so the hard 1200px stays and the tab detaches
   from the edge: measured 201.4px of empty page to its right at 1920, with a
   square, unrounded right edge left hanging in mid-air.

   calc(100% - 270px) is the same authored offset expressed from the right edge
   instead of the left, so it is continuous across the 1469/1470 seam
   (1469: 269.8px wide, flush -> 1470: 270px wide, flush) and stays flush at
   1512/1600/1728/1920. Nothing below 1470 changes.
   !important + the page-scoped selector are needed to beat the site head rule.

   NOT DONE, on purpose: margin-left:auto here would let the tab take its
   max-content width (317.2px) at every width. That reads better in isolation,
   but it widens the tab by 82px at 1280 and it then lands on the orange 50px
   heading "...transactions" (2052px^2 of ink-on-ink, measured at scrollY 4221).
   Reported, not shipped.
   -------------------------------------------------------------------------- */
@media (min-width: 1470px) {

  html[data-wf-page="69ad5decf269310df111d3f5"] body .frame-10000019245 {
    margin-left: calc(100% - 270px) !important;
  }
}


/* ============ APPENDED 2026-08-26 13:37: r42-T.css ============ */
/* ============================================================================
   ROUND 42 — AGENT T — /transaction, DESKTOP (>=992) ONLY.
   Ashik, 26 Aug 2026: "'search advisory' should be the same size as the other
   fonts. need not be bigger, change it."

   WHAT IT IS
   The orange sticky side tab on /transaction (.frame-10000019236) is the only one
   of the three side tabs on this site that carries an IN-PANEL heading. That
   heading is `.text-682` ("Search Advisory"), styled by Webflow's own
   `.text-682{font-size:50px;font-weight:500;line-height:100%}` (specificity 0,1,0,
   no !important, in the SHARED webflow stylesheet — nothing in the page head or in
   prq-band / prq-deskfix touches it).
   At 50px it wraps to TWO lines inside a 230px box, is 199.2px wide against a
   180.7px content box (it overflows its own padding by ~9px each side), and makes
   the heading pill 124.7px tall against the 46.8px of each of the four items below
   it (`.text-683`, 17px / 22.10px / 300 since round 40).

   THE CHANGE
   font-size 50px -> 17px, matching `.text-683` exactly, and line-height 100% ->
   1.3 — the same ratio round 40 derived from the modal wrapping ratio of these
   three pages and shipped onto `.text-683`, giving 22.10px, identical to the items.
   Nothing else. The heading pill then measures 46.8px, the same as an item pill.

   font-weight is LEFT AT 500 (items are 300) on purpose: he asked for size, and
   500 is what still reads it as the panel's title. If he wants it flattened to
   300 as well that is a one-word change, but it is not what he asked for.

   The panel is `display:none` at every width <=991 (measured 320/375/393/480/600/
   768/900/991: rect 0x0, ancestor display:none), so this rule cannot leak below
   992 even before the media query — the media query is belt and braces.

   FORM: this must live in build/css/fixes/ and is page-scoped BY HAND per trap C2.
   ============================================================================ */
@media (min-width: 992px) {

  html[data-wf-page="69beaa159de154a927745525"] body .frame-10000019236 .text-682 {
    font-size: 17px;
    line-height: 1.3;
  }
}


/* ============ APPENDED 2026-08-26 13:37: r43-G.css ============ */
/* ==========================================================================
   ROUND 43 — item G — /growth, the flow-line pair
   "Considering half measures?" / "It's just not our DNA."   DESKTOP >=992 only.

   Pairs with build/js/proposed/r43-G.js, WHICH MUST SHIP INLINE IN THE SITE HEAD,
   not as a `defer` asset — the reason is measured and written up in that file.

   THIS FILE HIDES NOTHING ON ITS OWN. Every rule is keyed on `html.r43g-gate`, a
   class only that script ever sets, and the script takes it back off again after
   the reveal. With the script absent, blocked, late or broken, this file is a
   no-op and /growth renders exactly as it does today.

   ASHIK, 26 Aug: "the text in the bottom of the line should not be seen in the
   initial page it should only appear after scrolling" ... "lower it more, not too
   much just so that its in the second screen" ... "in my mac when i open it it is
   fine, but if i switch to full screen it shows".

   REPRODUCED, live, 26 Aug (logs/r43/agentG/recon.mjs, LIVE-*.png):
       1440x800  ink 839.5..990.5  fold 800   entirely BELOW the fold   correct today
       1440x900  ink 724.5..875.5  fold 900   fully painted on screen 1  DEFECT
       1512x982  ink 806.5..957.5  fold 982   fully painted on screen 1  DEFECT   <- his full screen
       1920x1080 ink 839.5..990.5  fold 1080  fully painted on screen 1  DEFECT
   r38 item 4 parks the pair below the fold only while the viewport is <=812px
   tall. Full screen on his MacBook is 982. Across the 210-cell grid, 119 cells
   show the pair on the first screen today.

   WHY THE POSITION CANNOT BE THE ANSWER — re-measured, not inherited.
   Rendered-pixel scan of the orange artwork with both text blocks hidden
   (logs/r43/agentG/ceiling.mjs, ceil-*.png, ceiling-annotated.png). Identical at
   992 / 1280 / 1440 / 1512 / 1920:
       first orange row under the LEFT column  ("...our DNA.")      page y 1080
       first orange row under the RIGHT column ("Considering...")   page y 1145
   (r38 recorded 1027 for the left column; the artwork is a solid orange mass, not
   the thin stroke in the svg path, and 1080 is where it actually starts.)
   The left column binds. The pair's combined ink extent is 151px, so even with a
   mean 50px clearance the ink TOP can never pass ~880 before the words print on
   the flow line. A viewport 982px tall therefore CANNOT have this pair below its
   fold: 880 + 151 = 1031 is still inside the first screen, and it would be sliced
   by the fold as well — the exact defect r38 exists to prevent.
   GROWING THE SECTION DOES NOT HELP EITHER: .image-368 is position:absolute,
   top:509px against the section, and .svg-line-container is the first in-flow
   child of a top-aligned flex section, so extra section height is added BELOW the
   artwork and the ceiling does not move with it.
   Of the three honest options — move it, grow the section, gate the reveal — only
   the third works at every height, and it is what his first sentence asks for.
   SO THE GEOMETRY IS NOT TOUCHED. r38 item 4's rules stay exactly as they are
   (they still guarantee the pair is never sliced by the fold at rest at any
   height, which is why the reveal can never open onto a sliced block either), and
   the paint is simply withheld until the reader scrolls.

   WHAT THE RULES DO
     html.r43g-gate               set by the script while <head> is still parsing,
                                  before the pair's markup exists. Holds both blocks
                                  at opacity 0. `!important` is required and is
                                  aimed at exactly one thing: Webflow IX2 writes an
                                  INLINE opacity on these two elements every frame
                                  from its own rAF engine, and an important author
                                  declaration is the only thing that outranks a
                                  normal inline one.
     html.r43g-gate.r43g-in       set once the reader has scrolled AND the pair is
                                  fully clear of the fold; the hold stops applying
                                  and the blocks fade up to IX2's own value.
   Both classes come off again ~900ms after the reveal, so the page ends up with
   none of this CSS applied at all.

   🔴 FOR INTEGRATION (C2): these selectors are rooted at `html` ON PURPOSE and are
   hand-scoped, exactly like r38-D.css. This file belongs in build/css/fixes/ and
   the deskfix asset, which are copied verbatim. It must NEVER go through
   bandbuild's pages/*.css path, which would prefix :where(html[...]) and produce
   html-inside-html that matches nothing.

   NOT TOUCHED: every copy string; the section; .grid-3; the two grid columns and
   their r38 heights; .svg-line-container; the inline flow-line svg (C4);
   .image-368; and everything at <=991 — /growth is sealed on phone and tablet and
   the script does not even arm below 992.
   ========================================================================== */

@media (min-width: 992px) {

  /* the fade the reveal rides in on */
  html.r43g-gate[data-wf-page="697a492dac0e6730581f2a69"] body .growth-main-section .w-layout-grid.grid-3.nbmnbbmb .text-147,
  html.r43g-gate[data-wf-page="697a492dac0e6730581f2a69"] body .growth-main-section .w-layout-grid.grid-3.nbmnbbmb .text-146.jkj {
    transition: opacity 520ms ease;   /* must match FADE in r43-G.js */
  }

  /* THE GATE — closed only while the script says so, open the moment it adds .r43g-in */
  html.r43g-gate:not(.r43g-in)[data-wf-page="697a492dac0e6730581f2a69"] body .growth-main-section .w-layout-grid.grid-3.nbmnbbmb .text-147,
  html.r43g-gate:not(.r43g-in)[data-wf-page="697a492dac0e6730581f2a69"] body .growth-main-section .w-layout-grid.grid-3.nbmnbbmb .text-146.jkj {
    opacity: 0 !important;
  }

}

/* Reduced motion: still gated, but it appears rather than fades. */
@media (min-width: 992px) and (prefers-reduced-motion: reduce) {
  html.r43g-gate[data-wf-page="697a492dac0e6730581f2a69"] body .growth-main-section .w-layout-grid.grid-3.nbmnbbmb .text-147,
  html.r43g-gate[data-wf-page="697a492dac0e6730581f2a69"] body .growth-main-section .w-layout-grid.grid-3.nbmnbbmb .text-146.jkj {
    transition: none;
  }
}

/* 🔴 NO `@media print` BLOCK HERE, ON PURPOSE.
   The print protection used to live here as `@media print { ...opacity:1 }`. Two
   reasons it moved into the script instead:
     1. harness/deskbuild.py refuses any @media header without `min-width:>=992px`,
        which is the guarantee that nothing in the desktop asset can reach the
        sealed bands. `@media print` has no min-width, so this file could not be
        built. Writing `@media print and (min-width:992px)` would NOT fix it
        honestly either: print media resolves against the PAPER width, about 794px
        at A4/96dpi, so that rule would simply never apply and would look like
        protection while providing none.
     2. A `beforeprint` handler is strictly better anyway — it DISARMS the gate,
        so the copy is restored in the live DOM before the print snapshot is taken,
        instead of being overridden in one more cascade layer.
   See the `beforeprint` listener in r43-G.js. */


/* ============ APPENDED 2026-08-29 12:35: r50-K-desk.css ============ */
/* r50-K-desk — the footer "BOOK A CALL" pill, 992-1469.  >=992 ONLY.
   Ashik named this one explicitly and told me to close it, which is why desktop is being
   touched at all this round.  Nothing else at >=992 changes.

   WHAT IS WRONG (measured by me, live, WebKit, page `/`):
     992 / 1024 / 1200 / 1366 / 1469 : label = 3 INK LINES in a 97x48 pill,
                                       escaping top +23.4 and bottom +24.4
     1470 / 1920                     : 1 line, pill 190.5x48, clean
     <=991                           : 1 line, clean (the columns stack, nothing is squeezed)
   So the defect is EXACTLY 992-1469, and the correct target is what the page already does at
   1470: a 190.5px single-line pill.

   THE CAUSE, and it is one of our own rules.  A site-head block from 13 Aug sets
   `.small-columns { width:auto !important; max-width:100% !important; }` for a 576px logo strip.
   In the footer that strips the authored `.f2wf-small-columns { max-width:700px }`, so the link
   block takes its 950px max-content and its two siblings are squeezed:
   `.footer-text` (authored 455px) bottoms out at its automatic minimum, **103px** at 992-1200 and
   129px at 1366-1469.  The pill inside it is `width:100%; max-width:283px; height:48px;
   padding:17px 25px 16px 11px`, so a 103px column leaves a 61px content box for a 153.5px label
   -> 3 lines of 34.57px line-height inside a FIXED 48px box -> ink escapes top and bottom.

   WHY THE FIRST ATTEMPT WAS NOT ENOUGH — recorded because it is the interesting part.
   Restoring the 700px cap alone, plus `width:max-content` on the pill, took 992 from 3 lines to
   2 and the escape from +23.4/+24.4 down to +6.1/+7.1 — better, but STILL CUT.  At 992 the row is
   only 952.4px wide, so 700 + 61 (logo) + gaps leaves `.footer-text` 177.7px, and the pill still
   could not reach 190.5.  A strict improvement is not a fix, and this is a frozen band on every
   page of the site, so it does not ship half-done.

   THE FIX.  Guarantee the text column enough room for the pill FIRST, and let the link block give
   up the difference — it is the element that was over-taking space in the first place.
     1. `.footer-text` gets `min-width` = the pill's own single-line width plus its column padding,
        so the pill can always reach 190.5px and stay on ONE line.
     2. `.small-columns` gets its authored 700px cap back AND `min-width:0` so it is allowed to
        shrink below its max-content when the row is narrow.  Without min-width:0 a flex item will
        not shrink past its automatic minimum size and step 1 cannot be satisfied.
     3. the pill takes `width:max-content`.  `fit-content` CANNOT work here — it resolves against
        the available width, so at 992 it would keep the pill at the column width and still wrap.
        `max-content` lands it at 190.5px, byte-identical to what the page already renders at
        >=1470, so 992-1920 becomes ONE consistent button.
   Height is never touched: on one line the authored 48px box holds the ink with 11.2px above and
   10.2px below, exactly as it does at 1470 today. */

/* 🔴 RE-BOUND TO 1050 AFTER PUBLISH — I SHIPPED A REGRESSION AND THIS IS THE CORRECTION.
   The first cut ran from 992.  `min-width:0` on `.small-columns` let it collapse to 276.4px at
   992, which squeezed the link columns INSIDE it until their text collided.  Measured on the LIVE
   published site, footer text runs, ink vs ink:
       992  -> 3 overlaps: "Who We Are" over "What We Do" 13.1 x 19.4px,
                           "Manufacturing" over "Alpha Metrics" 24.8 x 3.7 and 24.8 x 9.3
       1030 -> 3 overlaps (4.7 x 19.4, 3.6 x 3.7, 3.6 x 9.3)
       1050 -> 0        1200 -> 0
   A new legible-text collision on all 45 pages with a footer is a worse defect than the
   pre-existing 3-line pill, and it is one this round PLANTED.  So the fix now starts at 1050,
   where `.small-columns` is 334.4px and the link columns fit.
   992-1049 therefore keeps today's behaviour: the pill still wraps to 3 lines there.  That is
   named to Ashik, not silently accepted.  The alternative — flooring `.small-columns` around
   335px — cannot work at 992, where the row is only 952.4px and 335 + 455 + 61 + gaps does not
   fit; it would just move the squeeze somewhere else. */
@media (min-width: 1050px) and (max-width: 1469px) {
  .footer .columns.f2wf-columns > .small-columns.f2wf-small-columns {
    max-width: 700px !important;
    min-width: 0 !important;
    flex-shrink: 1 !important;
  }
  .footer .columns.f2wf-columns > .footer-text {
    min-width: 227px !important;
    flex-shrink: 0 !important;
  }
  .footer .columns.f2wf-columns > .footer-text .link-block-6 > .frame-1000006879 {
    width: -webkit-max-content !important;
    width: max-content !important;
    max-width: none !important;
  }
}


/* ============ APPENDED 2026-08-30 09:32: pills-a1-r55-desk.css ============ */
/* pills-a1-r55-desk.css — r55 slice A1, SITE-WIDE pill components.  DESKTOP ONLY (>=992).
   Desktop is sealed by standing rule; Ashik opened it on 29 Aug for THIS DEFECT CLASS ONLY
   ("I want this to be done for all the layouts"). Nothing here touches anything but a pill.
   ===========================================================================
   SCOPE IS BY COMPONENT CLASS, NOT BY PAGE ID — same reasoning as the band file.
   `.frame-1000006879` is the footer CTA component: exactly 1 instance per page, verified live
   on 10 pages, and it is on all 46. It must not diverge between pages.
   ===========================================================================
   Author: agent A1, round r55.  NOT PROMOTED to EXTRA until its gate is green.
*/

@media (min-width: 992px) {

  /* A1-1  criterion A — footer "BOOK A CALL", the same 14.00px label offset as the band.
     Derivation, the symH-blindness proof and the reason the vertical 17/16 is preserved are all
     in build/css/fixes/pills-a1-r55.css. Width-neutral: 11+25 == 18+18 == 36.
     MEASURED bsymH 14.00 -> 0.00 on all 10 pages at 1440; pill 170.56 -> 170.56. */
  .frame-1000006879 { padding: 17px 18px 16px 18px; }

}

@media (min-width: 992px) and (max-width: 1049px) {

  /* A1-3  criteria C + D — footer "BOOK A CALL" collapses to three lines, 992-1048.
     Measured on /, /blog, /careers at 992/1000/1024/1048 (and 991 + 1056 as the clean controls):
     the pill drops from 189.53x48 to 96.98x48 while the label stays 22px/34.57px, so it wraps to
     THREE lines = 103.69px of ink inside a FIXED 48px pill and escapes the painted pill by
     24.34px. It is on all 46 pages. Pre-existing; nothing this round caused it.

     🔴 WHY THIS IS PILL-SCOPED AND NOT COLUMN-SCOPED.
     build/css/proposed/r50-K-desk.css already fixes this from 1050 up, and it was DELIBERATELY
     bounded away from 992: its first cut floored the footer columns (min-width:0 on
     .small-columns, min-width:227px on .footer-text) and planted three legible-text collisions
     in the footer link columns on all 45 pages. I reproduced that regression exactly, from an
     independent implementation, using a new named check `footerOvl` added to
     harness/pillaudit.mjs — 992: "Who We Are"/"What We Do" 11.98 x 19.00,
     "Manufacturing"/"Alpha Metrics" 24.75 x 3.69 and 24.75 x 9.31; 1030: 3.53 x 19.00,
     3.64 x 3.69, 3.64 x 9.31. r50-K's own notes record 13.1 x 19.4 / 24.8 x 3.7 / 24.8 x 9.3
     and 4.7 x 19.4 / 3.6 x 3.7 / 3.6 x 9.3. Same pairs, same widths, same magnitudes.
     The rules below touch NEITHER .small-columns NOR .footer-text — only the pill inside the
     column — so that mechanism cannot fire. Proved, not assumed: footerOvl = 0 before AND 0
     after at 992 / 1000 / 1024 / 1048 / 1056 on /, /blog and /careers.
     The pill ends at 170.56x48, i.e. the same single-line pill the component already renders at
     >=1050, so 992-1920 becomes one consistent button (standing rule 12).
     MEASURED, 3 pages x 4 widths: escape 24.34 -> -9.72 (ink 9.72px inside the pill),
     nLines 3 -> 1, box 96.98x48 -> 170.56x48, bsymH 14.00 -> 0.00.
     h-scroll 0 before and 0 after at every width. */
  .footer-text .link-block-6 > .frame-1000006879 {
    width: -webkit-max-content;
    width: max-content;
    max-width: none;
  }
  .footer-text .link-block-6 > .frame-1000006879 .text-344 { white-space: nowrap; }

}


/* ============ APPENDED 2026-08-30 09:32: pills-a2-r55-desk.css ============ */
/* ==========================================================================
   ROUND 55 — A2, desktop (>=992). Restored by the MAIN AGENT at merge.

   A2's original file was a single rule whose selector list mixed the SITE-WIDE
   footer pill in with three page-specific CTAs. The footer half is a duplicate of
   A1's component-scoped rule and was removed; the three page CTAs below are NOT
   duplicates and are A2's own work, so they are restored here verbatim.

   🔴 The C3 integration gate is what caught this: dropping the whole block left
   TALK TO THE INVESTMENT DESK, TALK TO OUR TEAM and START A CONVERSATION
   un-centred at >=992 (measured symH 14.00-14.02 on the ON arm at 992/1194/1440),
   even though A2 had reported them fixed. A per-agent green gate is not a green
   publish — and neither is a merge that reads selector lists as if each one
   covered a single component.

   Cause, as A2 found it: the house orange CTA pill is authored
   `padding: 17px 25px 16px 11px` and the round arrow that might have justified the
   11px is a SIBLING box, not a child, so the label sits 7px left of optical centre.
   18/18 is sum-preserving (11+25 = 36) so no pill changes width.
   ========================================================================== */
@media (min-width: 992px) {
  html[data-wf-page="69beaa159de154a927745525"] body .frame-10000019292,
  html[data-wf-page="697a79dd08d69f93b1438c34"] body .frame-10000019211,
  html[data-wf-page="69bfc522d51b3633b0925da1"] body .frame-10000019262 {
    padding-left: 18px !important;
    padding-right: 18px !important;
  }
}

/* ROUND 55 — MAIN AGENT. The >=992 half of the same defect: at 992-1440 the CTA's label
   takes two lines in a pill pinned to 48px and the first line paints 7.06px above the pill.
   Same remedy as the page already applies to itself at 320 and 768-991: let it grow. */
@media (min-width: 992px) {
  html[data-wf-page="69bfc522d51b3633b0925da1"] body .frame-10000019262.frame-10000019262 {
    height: auto !important;
    min-height: 48px !important;
  }
}


/* ============ APPENDED 2026-08-30 09:32: pills-a3-r55-desk.css ============ */
/* pills-a3-r55-desk.css — r55 pill round, agent A3, DESKTOP >=992 ONLY.
   Desktop is normally frozen; Ashik unfroze it for THIS defect class only ("all the layouts").
   Nothing here touches anything that is not a pill/button.
   Same probe, same two added named checks (bsymH/bsymV, rows2), same derived noise floor:
     bsymH 0.01  symH 0.02  symV 0  bsymV 0  escape 0  ovl 0  gapSpread 0  docH 0
   ------------------------------------------------------------------------------------------- */


/* ============================================================================================
   SITE-WIDE BLOCK — DEDUPE AT MERGE. Desktop twin of ITEM 1 in
   build/css/fixes/pills-a3-r55.css, with a byte-identical rule body. All 20 page ids on purpose:
   the footer is the same element on every page and must not diverge (standing rule 12).

   ITEM 1 — footer BOOK A CALL label 14.00px left of centre.                        CRITERION A
   .frame-1000006879 { padding:17px 25px 16px 11px } from the Webflow shared sheet. 11+25 = 36 =
   18+18 and box-sizing is border-box, so the pill's box does not move by a single pixel; only
   the label centres. Measured identical at 992 / 1194 / 1280 / 1440 / 1920.
   This does NOT interact with r50-K-desk, which sets width/min-width on the same pill and its
   two flex ancestors from 1050 to 1469 and never touches padding.
   ============================================================================================ */

/* [r55 MERGE] BLOCK REMOVED BY THE MAIN AGENT — duplicate of A1's site-wide footer rule
   was: @media (min-width: 992px) { ... }
   The surviving copy is the one named above. Provenance: logs/r55/pills-a3-r55-desk.css */



/* ============================================================================================
   ITEM 2 — /family-managed-business hero CTA "Book a 30-minute Diagnostic".        CRITERION A
   Desktop twin of ITEM 2 in build/css/fixes/pills-a3-r55.css; see that file for the full
   diagnosis. Short form: r37-U ITEM 7 fixed this inside a max-width:479px block and it was
   never re-scoped, so 480-1920 still runs the authored
       .frame-10000019107 { width:352px; padding:20px 0 20px 10px }
   against /consumer's and /manufacturing's
       .frame-10000019076 { width:362px; padding:20px 10px }.
   Measured on FMB at 992/1194/1280/1440/1920: ink 12.91px from the left edge, 2.92px from the
   right, bsymH 9.99, escape -2.92 (about to spill). The reference pages read bsymH 0.01.
   ============================================================================================ */
@media (min-width: 992px) {
  html[data-wf-page="69c397e91a19a2ce973d48a7"] body .frame-10000019107 {
    width: 362px !important;
    padding-right: 10px !important;
  }
}


/* ============ APPENDED 2026-08-30 09:32: pills-a5-r55-desk.css ============ */
/* ==========================================================================
   R55-A5 — CMS CONTENT TEMPLATES, PILLS/BUTTONS, >=992 (DESKTOP)
   Desktop is unfrozen for THIS DEFECT CLASS ONLY (pills/buttons) by Ashik's
   "I want this to be done for all the layouts", r55.

   NO LAYOUT IS RESTRUCTURED BY THIS FILE.  An earlier draft converted
   /case-studies' >=992 float row to a grid; that was withdrawn on the
   coordinator's instruction and is NOT in this file.  Card rects at >=992 are
   byte-identical before and after on /case-studies, and byte-identical at 5 of
   7 widths on /project (see each block).
   ========================================================================== */


/* --------------------------------------------------------------------------
   A5-2 (desktop half) — /case-studies card category pill
   (.frame-10000019188), >=992.  CRITERION A.

   🔴 THE DEFECT IS NOT WHAT THE FIRST PASS SAID IT WAS.  Re-measured with a
   per-LINE metric instead of the ink-union metric:

     ovl 8.26px^2 is NOT ink over ink.  The two Range rects are 17.000px tall
     at a 16.8px line-height, i.e. inflated by 0.200px; their pitch is 16.797px
     — the line-height exactly.  Overlap depth is 0.203px over 40.64px of
     width.  That is line-box rounding.  Screenshot-confirmed at 1440
     (logs/r55/a5shots/cs-1440-pill-zoom.png): clear space between
     "PORTFOLIO" and "VALUE".  Nothing overlaps.  escape is -6.61 (ink 6.6px
     INSIDE the painted pill), so nothing spills either.  C and D are CLEAN.

     What IS broken is CRITERION A, and the union metric was hiding it.  The
     label is a display:block with text-align:start, so the short second line
     is flush left inside a box sized to the long first line:
         per-line symH  line1 0.00–4.58px   line2 34.09–38.67px
     symHunion reads 0–4.58 and passes the 1.5px gate; the second line is
     34–39px off-centre.  This is the same class of error as "a union of child
     boxes is not ink", one level down.

   AND A ONE-LINE LABEL IS GEOMETRICALLY IMPOSSIBLE HERE at >=992:
     one-line ink "PORTFOLIO VALUE" = 119.28px; the pill's content box is
     76.05px.  Short by 43.22px, and 2.49px short even of the whole 121.77px
     pill at zero padding.  The pill can only widen by taking width from the
     title in a zero-slack space-between row, the title then gains a line, and
     .tabs-6 .w-dyn-items.w-row is still a legacy FLOAT row at >=992, so one
     taller card detonates it — measured: card 4 to x=1138, cards 5–6 to a
     third row, docH +960 at 992 / +614 at 1194 / +558 at 1440.

   FIX: centre the label.  Nothing else.  Zero box change, zero height change.
   PROVEN at 992/1024/1194/1280/1440/1600/1920, ON vs OFF on the same page:
     all six .collection-item-4 rects BYTE-IDENTICAL at every width;
     every pill box byte-identical at every width;
     docH identical (6902/6904/6671/6629/6529/6481/6457 both ways);
     scrollWidth-clientWidth 0 -> 0 and forced max scrollLeft 0 -> 0;
     card 4 stays at x=130, cards 5–6 stay in row 2 at every width;
     per-line symH 34.09/38.67 -> 0.00 (0.016 at 1600/1920);
     escape -6.61 unchanged, ovlDepth 0.203px unchanged, nLines 2 unchanged.

   🔴 LOGGED, NOT FIXED — FOR ASHIK, NOT FOR THIS ROUND:
   the pill is still 48.81px tall where its siblings are 32.02px, and the label
   still breaks mid-phrase.  That is standing rule 12 (consistency), not one of
   the four criteria he named, and clearing it at >=992 requires the float-row
   decision above.  It wants an explicit call, not a pill round.
   -------------------------------------------------------------------------- */
@media (min-width: 992px) {
  html[data-wf-page="69a800cea6999a158841d491"] body .collection-item-4 .frame-10000019188 .intro-desc-12 {
    text-align: center !important;
  }
}


/* --------------------------------------------------------------------------
   A5-3 (desktop half) — /project/* card category pill (.frame-10000019093),
   the 6 case-study DETAIL pages, one CMS template
   (data-wf-page 69bed61a86443de1912694e3).  CRITERION A + C-adjacent.

   Structurally identical to /case-studies (.frame-10000019092 is a zero-slack
   nowrap space-between row holding .intro-desc-6 + the pill) but WITHOUT the
   float row: the cards are .link-block-36 in a row that equalises, so the pill
   CAN take its 183px back and the title CAN absorb it.  Proven by card rects,
   not assumed.  Here the union metric goes red too —
       per-line symH  16.27 / 50.36 at 1440, 27.41 / 61.50 at 1920,
       2 lines, 48.81px against its siblings' 32.02px
   — so this one gets the real fix, and comes out consistent with the same
   template's <=991 half.

   PROVEN, ON vs OFF, on /project/project-auber AND /project/project-pepper at
   992/1024/1194/1280/1440/1600/1920:
     pills 2 lines -> 1 line, 48.813 -> 32.016, per-line symH -> 0.00 at all 7;
     card rects BYTE-IDENTICAL at 992, 1024, 1280, 1440;
     at 1194 all three cards grow 498 -> 522 UNIFORMLY (docH +24) — the title
       takes a line, no card is left ragged and no card changes column;
     at 1600/1920 all three cards SHRINK 474.813 -> 474.000 (docH -1), because
       the 48.81px pill was the tallest thing in that row;
     scrollWidth-clientWidth and forced max scrollLeft UNCHANGED at every width
       (170/154/105/27/0/0/0 — a large PRE-EXISTING h-scroll from the
       fixed-width rich-text body, identical before and after, not touched).
   -------------------------------------------------------------------------- */
@media (min-width: 992px) {
  html[data-wf-page="69bed61a86443de1912694e3"] body .frame-10000019092 {
    min-width: 0 !important;
  }
  html[data-wf-page="69bed61a86443de1912694e3"] body .frame-10000019092 .intro-desc-6 {
    min-width: 0 !important;
    flex: 1 1 auto !important;
  }
  html[data-wf-page="69bed61a86443de1912694e3"] body .frame-10000019092 .frame-10000019093 {
    flex: 0 0 auto !important;
    white-space: nowrap !important;
    max-width: 100% !important;
  }
}

/* ROUND 55 — main agent at merge: the same seventh page at >=992. See the band
   file's header for why /portfoliovalue was missing from every agent's slice. */
@media (min-width: 992px) {
  html[data-wf-page="697a79dd08d69f93b1438c34"] body .frame-10000019092 {
    min-width: 0 !important;
  }
  html[data-wf-page="697a79dd08d69f93b1438c34"] body .frame-10000019092 .intro-desc-6 {
    min-width: 0 !important;
    flex: 1 1 auto !important;
  }
  html[data-wf-page="697a79dd08d69f93b1438c34"] body .frame-10000019092 .frame-10000019093 {
    flex: 0 0 auto !important;
    white-space: nowrap !important;
    max-width: 100% !important;
  }
}


/* ============ APPENDED 2026-08-31 01:10: clickfix-r57-desk.css ============ */
/* ============================================================================
   r57 — CLICK-BLOCKED CONTROLS, DESKTOP LAYER (>= 992)
   31 Aug 2026.  Companion to r57-clickfix-band.css; same two mechanisms, same
   zero-pixel rule.  Desktop is opened for this round only, and only for the
   controls named below.
   ========================================================================= */

@media (min-width: 992px) {

  /* --- A.  /the-investment-desk — hero CTA "TALK TO THE INVESTMENT DESK".
     Dead at 992 / 1194 / 1440 / 1600 / 1920.  Same cause and same +1 bump as
     the band file: .dropdown-7 (relative, z 20) loses the root stacking
     context to the LATER SECTION.growth-main-section._122121 (relative, z 20).
     At 1920 the blocker resolves to the section itself; at 992-1600 to its
     6,951px DIV.div-block-102.  Both are beaten by 21.                      */
  html[data-wf-page="69bfc522d51b3633b0925da1"] body .section-9.sdsfdv .dropdown-7.w-dropdown {
    z-index: 21;
  }

  /* --- B.  /product-alpha-metrics — footer logo, About Us, Careers, Services,
     Sectors, Thought Leadership: six controls dead at 1920.
     DIV.background-black (position:absolute, transparent, nInteractive = 0,
     two decorative IMG.image-382 children only) is 1920x3686 and reaches down
     over the whole footer.  Decorative cover -> pointer-events:none, set on
     the wrapper so it is not simply the next hit-test winner.               */
  html[data-wf-page="69a80211b2573514f5e3bc2d"] body .the-black-background-section .background-black {
    pointer-events: none;
  }

  /* --- C.  /blog — the two post cards A.link-block-33, 1202x452.
     IMG.image-454 is the hero photograph: position:absolute, z-index:1,
     overflow:hidden, no text, nInteractive = 0.  It is sized off the viewport
     width, so from 1440 up it hangs below its own SECTION.hero-blog-section
     and across the post grid — 1/5 probe points at 1440, 2/5 at 1600,
     3/5 at 1700, 5/5 at 1920.  Decorative cover -> pointer-events:none.
     Scoped to >= 992 as measured; 768-991 is clean and untouched.           */
  html[data-wf-page="69a1896f399d61033d19cd10"] body .hero-blog-section .image-454 {
    pointer-events: none;
  }

}


/* ============ APPENDED 2026-08-31 20:29: r58-growth-timeline-desk.css ============ */
/* r58 — /growth "How we help" service timeline, DESKTOP ONLY (>=992px).
   1. uniform 64px ink gap between all 8 service blocks (was 101/190/101/171/101/194/101)
   2. .text-153 justified so every left-column right edge is flush at the same x
   3. the rail, the dot's travel container and the section re-lengthed by the same -510px
      so the removed space does not reappear as dead run at the bottom. */
@media (min-width:992px){
  /* --- 1a. separation INSIDE a grid --------------------------------------- */
  .service-timeline-section.dfdf .timeline-left > .left-conatainer{ padding-top:0; }
  .service-timeline-section.dfdf .timeline-left > .left-conatainer + .left-conatainer{ padding-top:66px; }
  .service-timeline-section.dfdf .left-conatainer.hi2323{ margin-top:297px; }

  /* --- 1b. separation ACROSS a grid boundary ------------------------------ */
  .service-timeline-section.dfdf .grid-4.neww.sd.grid3{ margin-top:40px; }
  .service-timeline-section.dfdf .grid-4.newww{ margin-top:-197px; }
  .service-timeline-section.dfdf .grid-4.neww.dsf{ margin-top:-167px; }

  /* --- 2. justify the paragraph ------------------------------------------ */
  .service-timeline-section.dfdf .text-153{ text-align:justify; }
  .service-timeline-section.dfdf .text-153 br{ display:none; }

  /* --- 3. take the reclaimed 510px out of the rail and the section -------- */
  .service-timeline-section.dfdf{ height:3290px; }
  .service-timeline-section.dfdf .timeline_progressbar.hii{ height:3340px; }
  .service-timeline-section.dfdf .middle-line.new-dot{ height:3240px; }
}


/* ============ APPENDED 2026-08-31 20:29: r58-transaction-bold-desk.css ============ */
/* ============================================================================
   ROUND 58 — /transaction, DESKTOP (>=992) ONLY.
   Ashik, 31 Aug 2026: "the search advisory alone is in bold, make it like every
   other text in that container".

   WHAT IT IS
   The orange sticky side tab on /transaction (.frame-10000019236) holds five
   links. Four of them are `.text-683` (17px / 22.1px / weight 300 since r40).
   The first, "Search Advisory", is a DIFFERENT Webflow class, `.text-682`,
   whose only weight declaration is `.text-682{font-weight:500}` in
   prequates-amazing-site.webflow.shared.ec4d3dfec.css (specificity 0,1,0, no
   !important). Nothing in prq-band, prq-deskfix or prq-r42video sets a weight on
   it. It is not <strong>/<b>, not a synthetic bold (same family Productsans,
   same 17px, no -webkit-text-stroke, no text-shadow) — it is a real 500 face
   against four 300s.

   WHY IT WAS 500
   Round 42 (r42-T, appended to prq-deskfix-2026-08-22l.css 26 Aug) took this same
   element from 50px to 17px and wrote, verbatim: "font-weight is LEFT AT 500
   (items are 300) on purpose: he asked for size, and 500 is what still reads it
   as the panel's title. If he wants it flattened to 300 as well that is a
   one-word change, but it is not what he asked for." This is that one word.

   NOT A STATE. The dark/orange bar Ashik sees beside one item is the
   scroll-driven ACTIVE marker: it is the 3px border-left on the item's wrapper,
   repainted by IX2 as the timeline scrolls (the four `.frame-10000019239`
   wrappers carry data-w-id; `.frame-10000019238` does not). It moves with scroll
   and is unrelated to the weight. "Search Advisory" is bold in EVERY scroll
   state, so the 500 is not an active/current state — .link-block-16 never gets
   .w--current, measured false on all five.

   CASCADE
   winner  html[data-wf-page="69beaa159de154a927745525"] body .frame-10000019236 .text-682   (0,3,2)
   loser   .text-682                                                                        (0,1,0)
   and prq-deskfix loads AFTER the shared sheet. No !important required.

   SCOPE: this side-tab component exists on exactly three pages. /m-a-advisory
   (.frame-10000019245, 4 items) and /the-investment-desk (.frame-10000019240,
   6 items) measure weight 300 on EVERY item — no odd one out, nothing to
   re-scope. /portfoliovalue /growth /efficiency /manufacturing /consumer
   /family-managed-business /diy have no such component.

   The panel is display:none at every width <=991, and the rule is inside
   @media (min-width:992px) as well. Belt and braces.
   ============================================================================ */
@media (min-width: 992px) {
  html[data-wf-page="69beaa159de154a927745525"] body .frame-10000019236 .text-682 {
    font-weight: 300;
  }
}


/* ============ APPENDED 2026-08-31 20:29: r58-OVERLAP-desk.css ============ */
/* ==========================================================================
   ROUND 58 — /transaction, DESKTOP >=992 — "Fix the overlapping containers"

   WHAT ASHIK CIRCLED
   The orange service tab (.frame-10000019236 — Search Advisory / Target
   Profiling / Due Diligence / Business Valuation / Deal Oversight) collides
   with the tilted "Case Study" card (.right-sticky-box) in the pull-quote
   section below it.

   CAUSE (measured, not assumed)
   .frame-10000019236 is position:sticky, top:140px (140 set by
   prq-deskfix-2026-08-22l), inside .service-timeline-section.transactions,
   which has a HARD height:5100px. A sticky box's travel is clamped by its
   containing block, so the tab's bottom parks exactly on that section's
   bottom edge.
   But the three boxes that follow are pulled UP into that same 5100px by
   authored negative margin:
        .section-72.efsdfsdf   margin-top:-602px   height:500px
        .table-section         margin-top: 20px
   so .table-section starts 602-500-20 = 82px ABOVE the timeline section's
   bottom edge, and the Case Study card starts 40px inside that, i.e. exactly
   42px above where the tab is allowed to park. The tab therefore parks ON the
   card. Measured identical (42.0px) at 992/1200/1440/1680/1920 x 700/800/900/
   1080 — it is a chain of fixed px, so it never varies.
   Horizontally the tab is flush right (margin-left:auto) while the card is
   grid-centred, so the collision widens as the viewport narrows:
        992 -> 223.5px   1200 -> 171.5px   1440 -> 111.5px
       1680 ->  51.5px   1920 -> 0 (they just clear)

   THE FIX
   Give the sticky box a bottom margin. A sticky box is constrained inside its
   containing block MINUS its own margins, so margin-bottom raises the parking
   line by exactly that much. It changes NO layout: the section's height is a
   hard 5100px and the tab is the last item of a flex-start column, so the
   margin is consumed by free space that already existed.

   102px, not a nudge: 602 - 500 = 102 is the exact distance by which the
   flow-line section is pulled up past its own height, so the tab now parks on
   the BOTTOM EDGE OF .section-72.efsdfsdf — the last box that belongs to the
   timeline. That leaves a constant 60px of clear air above the Case Study
   card at every width and every viewport height, and the tab is still fully
   present 334px past the last pixel of timeline content (timeline ink ends at
   doc 5574, tab now parks at 5908 @1440x900).

   SCOPE: >=992 only. The tab is display:none at every width <=991 (shared
   .frame-10000019236 rule at <=479 plus the page-head 480-991 block), so this
   cannot reach mobile or tablet; proven anyway at 375/480/768/991.

   FORM: hand-scoped per trap C2 (never bare `html`/`html body` in pages/*.css).
   ========================================================================== */
@media (min-width: 992px) {

  html[data-wf-page="69beaa159de154a927745525"] body .frame-10000019236 {
    margin-bottom: 102px;
  }
}


/* ============ APPENDED 2026-08-31 20:29: r58-a-desk.css ============ */
/* ============================================================================
   r58-a — /m-a-advisory, DESKTOP (>=992) body-copy consistency
   Ashik, 31 Aug 2026: "The texts in the page should be consistent. fix it"
   (circled the two "Managed transactions" / "Post transaction integration"
   timeline paragraphs)

   CAUSE — this is the "existing fix never re-scoped" pattern, 7th occurrence.
   prq-band-2026-08-29g.css already carries, inside @media (max-width:991px):

       html[data-wf-page="69ad5decf269310df111d3f5"] .good-deals-...-deta,
       html[..] .we-run-an-active-...-int,
       html[..] .most-deals-look-better-...-o,
       html[..] .we-act-as-a-focused-...-thi,
       html[..] .growth-main-section .left-conatainer .text-153.sdd {
         font-family:Productsans,Arial,sans-serif; font-weight:300;
         line-height:130%; color:#767676; letter-spacing:normal; }

   ...i.e. these five paragraphs were harmonised for phone + tablet and the
   >=992 band was never done. Measured live (logs/r58/seam-before.json):

     width  .we-act-...(A)     .we-run-...   .most-deals-...  .text-153.sdd(B)
      768   22/28.6/300        22/28.6/300   22/28.6/300      22/28.6/300
      991   22/28.6/300        22/28.6/300   22/28.6/300      22/28.6/300
      992   22/28.6/100  <--   22/28.6/300   22/28.6/300      22/30/300  <--
     1440   22/28.6/100  <--   22/28.6/300   22/28.6/300      22/30/300  <--

   So at >=992 exactly two of the four timeline paragraphs deviate:
     A  font-weight:100  (from .we-act-...-thi in the Webflow shared sheet)
     B  line-height:30px (136%) (from .text-153 in the shared sheet)
   That is the whole of what Ashik circled: A is thinner AND tighter than B.

   TARGET VALUE — not guessed:
     font-weight 300 : 3 of the 4 timeline paragraphs already use it at >=992,
                       5 of 5 use it at <=991, and prq-deskfix-2026-08-22l.css
                       already normalised this page's side-menu list to
                       17px/1.3/300 for exactly this reason (r39 agent B).
     line-height 130%: 3 of the 4 already use it at >=992, 5 of 5 at <=991, and
                       the r39 census found 1.3 is the modal body ratio on this
                       page (1.3 x6 vs 1.4 x4 vs 1.5 x1) and on its two siblings.
   Font SIZE is untouched: all four timeline paragraphs are already 22px at
   >=992 and the defect is not a size defect.

   Cascade: all three selectors carry the html[data-wf-page] prefix, so they are
   (0,2,1) / (0,5,1) against the shared sheet's (0,1,0) single-class rules and
   win on specificity alone, from the band asset's position (before the page
   head). No !important, and none is needed — proven by injecting at the real
   cascade slot (immediately after the last <link rel=stylesheet>).
   ========================================================================== */
@media (min-width:992px){

  /* A — "Transactions consume leadership attention…" : 100 -> 300 */
  html[data-wf-page="69ad5decf269310df111d3f5"] .we-act-as-a-focused-external-team-that-is-outcomes-forward-and-act-as-the-clearing-house-for-all-thi{
    font-weight:300;
  }

  /* B — "The deal closing is not the finish line…" : 30px -> 130% */
  html[data-wf-page="69ad5decf269310df111d3f5"] .growth-main-section .left-conatainer .text-153.sdd{
    line-height:130%;
  }

  /* C — hero body paragraph "Most M&A outcomes are decided long before…".
     Fifth member of the same <=991 list; the only other body paragraph on the
     page still at font-weight:100 at >=992, and the first one the reader meets.
     SEPARABLE: drop this one rule if the desktop hero is to stay untouched. */
  html[data-wf-page="69ad5decf269310df111d3f5"] .good-deals-that-drive-true-value-are-seldom-made-in-board-rooms-alone-they-only-happen-when-the-deta{
    font-weight:300;
  }
}


/* ============ APPENDED 2026-08-31 20:29: r58-twt-desk.css ============ */
/* ============================================================================
   ROUND 58 — TEXT-WEIGHT CONSISTENCY, /transaction + /the-investment-desk
   DESKTOP (>= 992) ONLY.   Extends the /m-a-advisory item Ashik approved
   ("do all three").  Companion to build/css/proposed/r58-a.css.

   ---------------------------------------------------------------------------
   THE DIRECTION: THE SINGLE 300 IS CORRECT.  THE SIBLINGS AT 100 ARE THE BUG.
   ---------------------------------------------------------------------------
   The sibling agent reported `.text-385` (/transaction) and `.text-418`
   (/the-investment-desk) as "the odd one out at 300 while its siblings are
   100".  They are the odd ones out and they are RIGHT.  Six independent lines
   of evidence, none of them a majority-within-the-broken-cluster argument:

   1. THE SITE'S BODY WEIGHT IS 300, AND 100 IS A 30-RULE RARITY.
      prequates-amazing-site.webflow.shared.ec4d3dfec.css declares
      font-weight:300 242 times and font-weight:100 exactly 30 times
      (excluding the two @font-face blocks).  Nine of those 30 are the two
      clusters this file fixes; two more are the /m-a-advisory paragraphs
      r58-a already raises to 300.

   2. EVERY OTHER BODY PARAGRAPH ON BOTH PAGES IS ALREADY 300.
      /transaction, Productsans grey body copy at >=992 (harness/TWT_census):
        30px .text-80 300 | 20px .text-268 300 | 20px .text-664 300 |
        15px x5 300 | 17px x4 300 (side tab) | 35px 300
        ... and 18px x4 at 100  <- the only 100 on the page.
      /the-investment-desk:
        25px 300 | 20px 300 | 18px x4 stat labels 300 | 18px .text-678 300 |
        16px x3 300 | 15px x7 300 | 13px x10 300
        ... and 18px x5 + 12px x2 at 100  <- the only 100s on the page.

   3. THE SAME COMPONENT ON THE SIBLING PAGES IS 300, WITH ZERO DEVIATION.
      The timeline body paragraph `.timeline-left .left-conatainer` exists on
      exactly four pages (swept live, harness/TWT_sibling.mjs):
        /growth              8 of 8 at 300   (22px / 30px)
        /m-a-advisory        3 of 4 at 300   (22px / 28.6px) -> 4 of 4 after r58-a
        /transaction         1 of 5 at 300   (18px / 23.4px)  <- this file
        /the-investment-desk 1 of 6 at 300   (18px / 23.4px)  <- this file, block 2

   4. THE DIRECTION IS ALREADY SET BY THE APPROVED /m-a-advisory ITEM.
      r58-a raises `.we-act-as-a-focused-...-thi` 100 -> 300 and
      `.good-deals-...-deta` 100 -> 300.  It RAISES.  Lowering the 300s here
      would make three pages consistently contradict each other.

   5. THE BAND ALREADY WROTE THE SPEC OUT IN FULL, FOR THIS EXACT ROLE.
      prq-band-2026-08-29g.css, @media (max-width:991px), page 69ad5dec...:
        font-family:Productsans; font-weight:300; line-height:130%;
        color:#767676; letter-spacing:normal
      /transaction's four 18px paragraphs are already Productsans / 130% /
      #767676 / letter-spacing normal.  They miss that spec on ONE property:
      weight.  `.text-385` is the only one of the five that meets all five.

   6. WHEN A NORMALISATION LAST RAN ON THESE PAGES, IT TARGETED 300.
      prq-deskfix-2026-08-22l.css (r39 agent B, appended 25 Aug) set
      `html[data-wf-page="69beaa159de154a927745525"] body .frame-10000019236
       .text-683 { font-weight:300; line-height:1.3 }` on /transaction, with
      the derivation "font-weight:300 is what 5 of the 11 items and 2 of the
      3 panels already use", and its census recorded 1.3 as the modal body
      ratio on /transaction, /m-a-advisory AND /the-investment-desk.
      r58-transaction-bold.css (this round) likewise lowers 500 -> 300.

   The 100 face is real, not synthesised: ProductSans-Thin.ttf is declared at
   font-weight:100.  So this is a genuine hairline face used for running body
   copy, which is exactly the "one paragraph is thinner than the others"
   defect Ashik circled on /m-a-advisory.

   NOTHING ELSE CHANGES.  No font-size, no line-height, no colour, no
   letter-spacing, no margin.  `.text-385` and `.text-418` are NOT touched —
   they are already correct.

   ---------------------------------------------------------------------------
   CASCADE
   ---------------------------------------------------------------------------
   Every loser is a single-class rule in the Webflow shared sheet with no
   !important:
     .the-problem-is-...-se                (0,1,0)   font-weight:100
     .we-build-a-rigorous-...-operation    (0,1,0)   font-weight:100
     .text-383                             (0,1,0)   font-weight:100
     .we-provide-an-independent-...-keeping(0,1,0)   font-weight:100
     .building-a-world-class-...-most      (0,1,0)   font-weight:100
     .text-396.asas                        (0,2,0)   font-weight:100
     .felt-prequate-...-goals              (0,1,0)   font-weight:100
   My selectors are html[data-wf-page=...] + class = (0,2,1) / (0,3,1), and
   this file loads after the shared sheet either way.  No !important needed,
   none used.
   prq-band, prq-deskfix and prq-r42video mention NONE of these seven classes
   (grepped, 0 hits each).  Neither page's head <style> blocks mention any of
   them except one 480-991 font-size rule on /the-investment-desk, which is
   outside this file's media range.  Hand-scoped html[data-wf-page="..."],
   never bare `html body` (trap C2).

   COMPOSES WITH THE ROUND'S OTHER /transaction ITEMS — no element in common:
     r58-transaction-bold.css  -> .frame-10000019236 .text-682  (side tab)
     r58-OVERLAP.css           -> .frame-10000019236            (side tab)
   Both live in the sticky orange side tab; every element below is in the
   timeline column or the stat grid.  Disjoint sets, verified in the gate.
   ============================================================================ */

@media (min-width: 992px) {

  /* ---------------------------------------------------------------------
     BLOCK 1 — /transaction.  The four timeline body paragraphs that sit
     under the 40px section headings, 18px / 23.4px / #767676 / 625px wide.
     100 -> 300, matching their fifth sibling `.text-385`.
     --------------------------------------------------------------------- */
  html[data-wf-page="69beaa159de154a927745525"] .the-problem-is-the-market-doesnt-organize-itself-around-your-thesis-we-run-a-structured-proactive-se,
  html[data-wf-page="69beaa159de154a927745525"] .we-build-a-rigorous-profile-of-each-potential-target-across-strategic-fit-financial-health-operation,
  html[data-wf-page="69beaa159de154a927745525"] .text-383,
  html[data-wf-page="69beaa159de154a927745525"] .we-provide-an-independent-dedicated-oversight-function-across-the-full-transaction-lifecycle-keeping {
    font-weight: 300;
  }

  /* ---------------------------------------------------------------------
     BLOCK 2 — /the-investment-desk.  The 12px client-outcome captions under
     93% / 100% / >50%, 12px / 15.6px / #707070, centred.
     100 -> 300, matching their third sibling `.text-418`.
     The identical caption role in the FIRST stat grid on the same page
     (500+ / 100+ / 25+ / $10B+ -> .text-396 .text-398 .text-400 .text-402)
     is 4 of 4 at 300, which is the same answer from a second direction.
     --------------------------------------------------------------------- */
  html[data-wf-page="69bfc522d51b3633b0925da1"] .text-396.asas,
  html[data-wf-page="69bfc522d51b3633b0925da1"] .felt-prequate-was-accountable-to-their-organisational-goals {
    font-weight: 300;
  }

  /* ---------------------------------------------------------------------
     BLOCK 3 — /the-investment-desk, SEPARABLE.  Drop these three lines alone
     if the round is to stay strictly to the two elements the sibling agent
     named.

     The same class on five timeline paragraphs, 18px / 23.4px / #767676 /
     700px.  It is the exact structural twin of Block 1: same component
     (`.timeline-left .left-conatainer` body paragraph), same size, same
     line-height, same colour, and the same page carries one instance of that
     role at 300 (`.the-metric-we-are-most-proud-of-...`, 18px / 23.4px /
     #767676, with a 700 lead-in span).  So this role is 5-at-100 vs 1-at-300
     on /the-investment-desk, exactly as it is 4-at-100 vs 1-at-300 on
     /transaction.

     RECOMMENDATION: SHIP IT.  Leaving it out fixes the 12px trio and leaves
     the largest run of hairline body copy on the site — five paragraphs, one
     per section — reading thinner than every other paragraph on its own page.
     That is the same complaint, unfixed, on the page we just touched.
     --------------------------------------------------------------------- */
  html[data-wf-page="69bfc522d51b3633b0925da1"] .building-a-world-class-internal-investment-function-is-expensive-slow-and-operationally-complex-most {
    font-weight: 300;
  }
}


/* ============ APPENDED 2026-08-31 20:29: r58-ringdot-desk.css ============ */
/* ============================================================================
   r58 — /family-managed-business, "SOMETHING TO THINK ABOUT" ring
   Ashik: "The green button should fit in the gap in the circle"

   SCOPE: DESKTOP ONLY, @media (min-width:992px).
   768–991 the band asset already sets `.frame-1000007066 { display:none }`;
   ≤767 is sealed. Nothing below 992 is touched — proven by a 0-diff rect census
   of every node in .section-28 at 375 / 480 / 767 / 768 / 991.

   THE CAUSE
   The ring is one filled path in `.hero-blob-svg`, sized `height:100vh`, so it
   grows and shrinks with the VIEWPORT HEIGHT. The green dot stack is placed by
   `.frame-1000007066.dsd { margin-left:789px; margin-top:250px }` off a
   flex-centred static position — fixed pixels. The dot therefore sits at a
   CONSTANT 397.2px / 11.79deg from the ring centre at every viewport, while the
   gap's own midpoint moves between 335px (vh 650) and 474px (vh >= 931).
   Measured error against the gap midpoint, live, before this fix:
        vh 650 -> 103.2px   vh 740 -> 62.4px   vh 780 -> 44.3px
        vh 900 ->   9.9px   vh >=931 -> 24.0px
   At short viewports (a laptop with a bookmarks bar) the dot lands ~100px
   OUTSIDE the ring — "it floats to the right of the stroke".

   THE RING'S OWN GEOMETRY (viewBox 0 0 1048 1048)
     centre    (524, 524)
     outer R   523.98      inner R 424.17      band 99.81
     gap       a radial slot, 0.000deg to 23.639deg  (3 o'clock -> ~3:47)
     cap faces mid (998.089, 524.001) and (958.303, 714.111), both at R 474.09
     GAP MID   (988.038, 621.098) = centre + (464.038, 97.098)
   Rendered ring size  S = min(100vh, 931px)
     100vh from `.hero-blob-svg{height:100vh}`; 931px because the svg is a flex
     item of `.code-embed-13{width:931px}` and flex-shrink caps its (square) size.
   Ring centre inside `.svg_circle`, exactly and for every S:
     x = 50%              y = 50% + 27px      (27px = half of code-embed-13's
                                               54px margin-top)

   THE FIX
   `.frame-1000007066.dsd` becomes a 0x0 anchor ON the ring centre. Each embed is
   then translated by the gap vector (464.038, 97.098)/1048 x S and pulled back by
   its own painted-circle centre (a percentage of its own box, so it survives any
   later size change). The three green circles also become exactly concentric —
   today they are 1.7px and 3.2px apart.
   ============================================================================ */

@media (min-width: 992px) {

  /* --- 0x0 anchor pinned to the ring's centre ---------------------------- */
  html[data-wf-page="69c397e91a19a2ce973d48a7"] body .section-28 .svg_circle .frame-1000007066.dsd {
    position: absolute !important;
    left: 50% !important;
    top: calc(50% + 27px) !important;
    right: auto !important;
    bottom: auto !important;
    width: 0 !important;
    height: 0 !important;
    margin: 0 !important;
    display: block !important;
    overflow: visible !important;
  }

  /* --- neutralise the three embeds' own offsets, keep their sizes -------- */
  html[data-wf-page="69c397e91a19a2ce973d48a7"] body .section-28 .svg_circle .frame-1000007066.dsd > .code-embed-33,
  html[data-wf-page="69c397e91a19a2ce973d48a7"] body .section-28 .svg_circle .frame-1000007066.dsd > .code-embed-34,
  html[data-wf-page="69c397e91a19a2ce973d48a7"] body .section-28 .svg_circle .frame-1000007066.dsd > .code-embed-35 {
    position: absolute !important;
    left: 0 !important;
    top: 0 !important;
    right: auto !important;
    bottom: auto !important;
    margin: 0 !important;
    padding: 0 !important;
    width: auto !important;
    height: auto !important;
  }

  /* --- seat each painted circle on the gap midpoint ---------------------- */
  /* gap vector = (464.038, 97.098)/1048 x S,  S = min(100vh, 931px)
       x : min(44.27843vh, 412.232px)
       y : min( 9.26508vh,  86.258px)
     second translate() = minus the svg's own painted centre, as a % of its box */

  /* .thinkabout-dot — 101 box, circle cx 44.8082 cy 39.1734 r 27.9 (NOT centred) */
  html[data-wf-page="69c397e91a19a2ce973d48a7"] body .section-28 .svg_circle .frame-1000007066.dsd > .code-embed-33 {
    transform: translate(min(44.27843vh, 412.232px), min(9.26508vh, 86.258px))
               translate(-44.36455%, -38.78554%) !important;
  }
  /* .thinkabout-glow — 93 box, circle cx/cy 46.5 r 46.5 (centred) */
  html[data-wf-page="69c397e91a19a2ce973d48a7"] body .section-28 .svg_circle .frame-1000007066.dsd > .code-embed-34 {
    transform: translate(min(44.27843vh, 412.232px), min(9.26508vh, 86.258px))
               translate(-50%, -50%) !important;
  }
  /* .thinkabout-glow-outer — 124 box, circle cx/cy 62 r 62 (centred) */
  html[data-wf-page="69c397e91a19a2ce973d48a7"] body .section-28 .svg_circle .frame-1000007066.dsd > .code-embed-35 {
    transform: translate(min(44.27843vh, 412.232px), min(9.26508vh, 86.258px))
               translate(-50%, -50%) !important;
  }
}

/* ============================================================================
   OPTIONAL — NOT part of the fix above, do not ship unless Ashik asks.
   "Option B": scale the whole green stack with the ring so the dot keeps the
   proportion it has at 1440x900 (dot diameter = 65.1% of the ring's band) at
   every viewport height instead of 90% at vh 650 and 63% at vh >= 931.
   Sizes are the authored 101/93/124 x S/900.
   The transforms above need no change — they are percentage-based.

@media (min-width: 992px) {
  html[data-wf-page="69c397e91a19a2ce973d48a7"] body .section-28 .svg_circle .frame-1000007066.dsd .thinkabout-dot {
    width:  min(11.22222vh, 104.478px) !important;
    height: min(11.22222vh, 104.478px) !important;
  }
  html[data-wf-page="69c397e91a19a2ce973d48a7"] body .section-28 .svg_circle .frame-1000007066.dsd .thinkabout-glow {
    width:  min(10.33333vh,  96.204px) !important;
    height: min(10.33333vh,  96.204px) !important;
  }
  html[data-wf-page="69c397e91a19a2ce973d48a7"] body .section-28 .svg_circle .frame-1000007066.dsd .thinkabout-glow-outer {
    width:  min(13.77778vh, 128.272px) !important;
    height: min(13.77778vh, 128.272px) !important;
  }
}
   ============================================================================ */


/* ============ APPENDED 2026-08-31 20:29: r58-orbit-rings-desk.css ============ */
/* ============================================================================
   r58 — ORBIT ARMS: seat every client-story card on the SAME ring (ring 2).
   Ashik, 31 Aug: "All the texts revolving should be in the second line but
   some are in the second and some are in the first, fix it in both the pages."

   MECHANISM (page-head block "BASE ORBIT MECHANICS — do not edit"):
     .box { transform: translate(var(--radius),0) translate(-50%,-50%) }
   so --radius IS the seating radius of the card's CENTRE.
   Authored desktop values: .box-1/.box-3 = 417px (ring 1), .box-2/.box-4 = 568px (ring 2).
   Ring artwork radii measured live at 1440: 418.5 / 568 / 718.5 / 720.
   568 is "the second ring" counting from the inside AND from the outside.

   We change ONLY the custom property, so both @keyframes (spin-arm on .arm and
   spin-box on .box) keep running untouched — no transform is overridden, the
   counter-rotation that keeps the cards upright is preserved, and no SVG
   geometry is touched (790-unit arc / vector-effect:none untouched).

   Scoped >=992 only. Below 992 the live page-head block already replaces the
   orbit with a static grid (.circle-section .arm{position:static;animation:none}
   and .box{transform:none}), so --radius is dead there — but the media query
   makes that structural, not incidental. Mobile/tablet stay sealed.
   ========================================================================= */
@media (min-width: 992px) {

  /* /family-managed-business */
  html[data-wf-page="69c397e91a19a2ce973d48a7"] .box-1,
  html[data-wf-page="69c397e91a19a2ce973d48a7"] .box-3,
  /* /manufacturing */
  html[data-wf-page="6a2697efcafdfab233a12e80"] .box-1,
  html[data-wf-page="6a2697efcafdfab233a12e80"] .box-3,
  /* /consumer */
  html[data-wf-page="6a26980bff679ec1b699021f"] .box-1,
  html[data-wf-page="6a26980bff679ec1b699021f"] .box-3 {
    --radius: 568px;
  }

}


/* ============ APPENDED 2026-08-31 20:29: r58-fmb-headline-desk.css ============ */
/* ============================================================================
   r58 — /family-managed-business hero headline: break after "Purpose built for"
   and keep both lines centred.

   Ashik, 31 Aug: 'Also make, "Family owned business" in a single line.'
   Then, on seeing the result: 'align the "family owned business" to the centre'.

   The headline is one text flow in a centred container:
     span -0  "Purpose built for "        (Awesome Serif Var Vf, 64px, italic, orange)
     span -1  "Family Owned Businesses"   (Productsans, 64px/500, grey)
   It wraps naturally, so it broke as "Purpose built for Family" / "Owned Businesses".

   MEASURED at 1440: "Family Owned Businesses" is 739.1px of ink on one line.
   The container was 637px. It must be >= 739 or the line cannot centre.

   🔴 MY FIRST ATTEMPT WAS WRONG, TWICE, AND THE MEASUREMENT HID IT.
   I first shipped `display:block; white-space:nowrap` with NO width change,
   believing the text would overflow the 637px box symmetrically. It does not:
   a centred line that is wider than its box cannot centre, so it starts at the
   box's left edge and overflows RIGHT. Ink ran 401.5 -> 1140.6, centre 771 —
   **51px right of the page centre**. That is exactly what Ashik saw.

   Worse, my collision sweep called that version SAFE. It measured the spans with
   `getClientRects()`, which on a `display:block` span returns the BOX (637), not
   the letters (739). The box understated the ink by 102px and hid the overflow.
   Re-measured with a Range over the trimmed text nodes — and card ink, not card
   boxes — the numbers invert:

     variant                         collisions   min clearance
     orbit fix only (2-line headline)      0          109.8px
     nowrap only, container 637           11            0.0px   <-- my first fix
     container 745 + nowrap                0           31.8px   <-- SHIPPED

   So the off-centre look and the collision were the same bug. Fixing the centring
   fixes both. 360 animation phases, ink vs ink, at 1440.

   Lesson, for whoever edits this next: `getClientRects()` on a block-level span is
   the box. Overflowing text is invisible to it. Measure text nodes.

   Ships WITH r58-orbit-rings.css and depends on it — without that fix the live page
   already has 382 card/headline collisions per rotation.
   745 = 739.1 of ink + ~6px slack for font-metric variation between machines;
   `white-space:nowrap` is belt-and-braces so a wider render cannot re-wrap.
   Verified 0 collisions at 992 / 1200 / 1440 / 1680 / 1920.
   ========================================================================= */
@media (min-width: 992px) {
  html[data-wf-page="69c397e91a19a2ce973d48a7"] .purpose-built-for-family-owned-businesses {
    width: 745px;
  }
  html[data-wf-page="69c397e91a19a2ce973d48a7"] .purpose-built-for-family-owned-businesses-1 {
    display: block;
    white-space: nowrap;
  }
}


/* ============ APPENDED 2026-08-31 20:29: wphero-r58-desk.css ============ */
/* r58 — whitepaper hero gradient scrim, DESKTOP HALF.
   Source: build/css/proposed/r58-wphero-A-scrim.css, approved by Ashik 31 Aug.
   The source file is deliberately un-gated: the legibility failure exists at 375 too
   (emerging-funding-avenues title measured 2.04:1 there). deskbuild only accepts >=992
   and bandbuild only accepts <=991, so the same declarations ship as two halves.
   The <=991 twin is build/css/fixes/wphero-r58-band.css — EDIT BOTH OR NEITHER. */
@media (min-width: 992px) {
  /* r58 OPTION A (RECOMMENDED) - gradient scrim behind the whitepaper hero text.
     Page-scoped BY HAND (C2): 69c10ad5cd39146277315a22 is the ONE CMS template behind all four
     /whitepaper/* detail pages. Destined for build/css/fixes/ (copied verbatim), not pages/.
     Layout-neutral: adds a ::after backdrop + z-index only. No box, margin, padding or size changes.
     Alpha is derived from the WORST POSSIBLE image (pure #FFF), not from the current four:
       white text on alpha a black scrim over #FFF  ->  contrast = 1.05 / (lin(1-a)+0.05)
       a = .56  ->  4.93:1   (clears 4.5:1 small text AND 3:1 large text on ANY image) */
  
  html[data-wf-page="69c10ad5cd39146277315a22"] .rectangle-1327{
    isolation:isolate;                 /* contains the scrim; changes no geometry */
  }
  html[data-wf-page="69c10ad5cd39146277315a22"] .rectangle-1327::after{
    content:"";
    position:absolute;
    inset:0;
    z-index:1;                          /* above .image-482 (z auto), below the text frame */
    pointer-events:none;                /* never intercepts a click */
    border-radius:inherit;              /* matches the photo's 20px corners */
    background:linear-gradient(to top,
      rgba(0,0,0,.66)   0%,
      rgba(0,0,0,.62)  20%,
      rgba(0,0,0,.59)  35%,
      rgba(0,0,0,.56)  50%,             /* content band tops out at 45.9% - full strength to 50% */
      rgba(0,0,0,.46)  58%,
      rgba(0,0,0,.34)  66%,
      rgba(0,0,0,.22)  74%,
      rgba(0,0,0,.12)  82%,
      rgba(0,0,0,.05)  90%,
      rgba(0,0,0,0)   100%);
  }
  html[data-wf-page="69c10ad5cd39146277315a22"] .frame-10000019167{
    z-index:2;                          /* text, pills and the orange button ride ABOVE the scrim */
  }
  /* Outlined pills: white 1px stroke + 20px white text is the weakest ink in the hero.
     A translucent chip lifts them clear of the 4.5:1 line with margin, and echoes the
     solid black pills on the row below. Background only - no size, no position change. */
  html[data-wf-page="69c10ad5cd39146277315a22"] .frame-10000019168{
    background-color:rgba(0,0,0,.28);
  }
}


/* ============ APPENDED 2026-08-31 20:29: icons-r58-desk.css ============ */
/* r58 — /contact-us baked contact rows: box must match the corrected artwork.
   The three SVGs were re-exported with the viewBox widened so the 2px icon stroke
   is no longer clipped (email 329->331, address 433->435, phone 191x29->193x31).
   At >=992 these <img>s use `object-fit: cover` with the box sized in px, so if the
   box is left at the OLD intrinsic size cover crops the new margin straight back off
   and the fix is undone. Below 992 the same images use `object-fit: contain`, which
   never crops — so this needs no <=991 twin. Verified by measurement at 375/480/768/991.
   Ships WITH the three re-uploaded assets; neither half works alone. */
@media (min-width: 992px) {
  html[data-wf-page="6a410ffa9ea227a7c2c9900d"] img.email   { width: 331px; height: 29px; }
  html[data-wf-page="6a410ffa9ea227a7c2c9900d"] img.address { width: 435px; height: 61px; }
  html[data-wf-page="6a410ffa9ea227a7c2c9900d"] img.phone   { width: 193px; height: 31px; }
}


/* ============ APPENDED 2026-08-31 20:50: icons-r58b-desk.css ============ */
/* r58-b — /contact-us contact rows: the width bump from icons-r58-desk.css was CLAMPED.
   Shipped in 22m, verified LIVE, and only 1 of 3 took:
       email   wanted 331px  ->  computed 329px
       address wanted 435px  ->  computed 433px
       phone   wanted 193px  ->  computed 193px  ✅
   Cause: Webflow's base `img { max-width: 100% }` resolves against each image's own
   `.w-inline-block` parent, whose width is pinned to the OLD artwork size (329 / 433).
   So max-width won and clipped the widened viewBox straight back off — exactly the defect
   the re-export was meant to cure. Phone's parent shrink-wraps, which is why it alone worked.
   Not a specificity problem: my rule already won on `width`. `max-width` was simply never set.
   Nothing in ANY stylesheet declares these values — grepped all four live sheets and the page's
   13 inline <style> blocks. It is a used-value clamp, so it has to be released, not out-ranked.
   Releasing the clamp on the image AND its parent; both are shrink-to-fit around the artwork. */
@media (min-width: 992px) {
  html[data-wf-page="6a410ffa9ea227a7c2c9900d"] img.email,
  html[data-wf-page="6a410ffa9ea227a7c2c9900d"] img.address,
  html[data-wf-page="6a410ffa9ea227a7c2c9900d"] img.phone {
    max-width: none;
  }
  html[data-wf-page="6a410ffa9ea227a7c2c9900d"] a.w-inline-block:has(> img.email),
  html[data-wf-page="6a410ffa9ea227a7c2c9900d"] a.w-inline-block:has(> img.address),
  html[data-wf-page="6a410ffa9ea227a7c2c9900d"] a.w-inline-block:has(> img.phone) {
    width: max-content;
    max-width: none;
  }
}