/* ===========================================================================
   Time Aesthetics - post-export CSS repairs.

   WHY THIS FILE EXISTS (measured 2026-09-18, hydrated, 390px):
   A Framer static export is a client-side-routed React app. Tapping an internal
   link does NOT fetch a new document - the page is swapped in. So a <style>
   block written into ONE page's HTML is only ever parsed when that page is
   HARD-loaded, and every repair delivered that way is absent on the path most
   visitors take. Proven on this site: home -> tap "Contact" left the map at
   640px/max-width:none (54.7% visible, the exact pre-fix value), the submit
   button back at rgb(64,196,170) (2.19:1) and the hero h1 back at #fff.
   A <link> in <head> survives, because the document is never replaced - once
   any page is hard-loaded the sheet stays live for the whole visit. This file
   is therefore linked from ALL SIX pages, including 404.html.

   WHY THE HERO RULES ARE PAGE-SCOPED, AND MUST STAY THAT WAY:
   The two hero repairs are mutually exclusive by page type. #0c4e6e over the
   PHOTO heroes measured 1.00:1 worst pixel - invisible, strictly worse than no
   fix - and the preset class h1.framer-styles-preset-sei7ti exists on all five
   pages. Unscoped, soft navigation cross-applies one page's hero fix onto
   another's hero. Scoping is by each page's own hero container class, MEASURED
   2026-09-18 as stable and unique across hydration AND soft navigation (one
   hero, one h1, one preset match per page on both arrival paths):
     /            .framer-11z6qql   photo hero
     /about-us/   .framer-aoboo4    photo hero
     /treatments/ .framer-8sxdx0    photo hero
     /contact-us/ .framer-174d7s9   pale-wash hero
     /faq/        .framer-51iw3u    pale-wash hero
   Never merge the two groups. Never drop the scoping.

   Lives in /assets/ deliberately: .assetsignore is an ALLOW-list whose `/*`
   withholds every root-level entry, so a root-level copy of this file would
   work locally and 404 on the deployed preview, silently taking all five
   repairs with it. `!/assets/` re-includes this subtree at every depth.
   =========================================================================== */

/* MEASURED 2026-09-17, hydrated, pixel-sampled under the glyphs at 390 and 1440. White hero text over photographs measured 1.86-2.32:1 worst-pixel against a 3:1 large-text bar; the home paragraph measured 2.01:1 against a 4.5:1 normal-text bar. Values chosen BY MEASUREMENT: the house 3px 3px 3px #00000040 left the worst pixel unchanged at 1.86, because a soft offset shadow lands beside the glyph rather than behind it. A dense multi-layer halo is required, and small text needs a tighter/denser one than large text. Result: headings 3.27-4.42.

   PARAGRAPH FIGURE CORRECTED 2026-09-22. This comment previously claimed the
   paragraph measured "4.98-5.88". That does not reproduce at ANY mask threshold
   and should not be cited. Re-measured on the hydrated page at four widths:
     threshold 90 -> 3.10-3.31 : 1     threshold 40 -> 1.55-1.59 : 1
     threshold  8 -> 1.09-1.10 : 1     (bar is 4.5, text is 18px/400)
   The mask threshold is a FREE PARAMETER and is worth ~2 ratio points here, so a
   ratio quoted without it is not a citation. INDEPENDENTLY RE-DERIVED 2026-09-22
   (3.10-3.46 / 1.56-1.59 / 1.09-1.10 at the same three thresholds), and that pass
   also found HOW the retracted "4.98-5.88" was reachable: only at threshold ~120-140,
   which discards about a third of the masked glyph pixels. That is the whole failure
   mode in one line - a stricter threshold silently drops the antialiased edges and
   flatters the result, which is why the threshold must always be stated. On the honest (low) thresholds that
   admit antialiased glyph edges, the worst pixel is well under the bar.
   WHAT THIS MEANS IN PRACTICE: rendered-checked at 1280px/3x
   (verification/compare/home-hero-para-1280-3x.png) the paragraph IS readable
   across both the pale-blue and dark-glove regions - the halo is doing real work -
   but it is genuinely marginal over the darkest part of the photo, which is what a
   ~3.2:1 reading describes and what "5.88" concealed. Worst-pixel sampling over a
   photographic backdrop always reads pessimistically at low thresholds; judge this
   one by the rendered crop, not by the ratio alone.

   Rob's call 2026-09-17 to use a shadow rather than darken the photo. CEILING:
   WCAG gives no formal credit for text-shadow, so an automated contrast audit will
   still flag these pages. This is a legibility fix, not an audit pass. */
.framer-11z6qql h1.framer-styles-preset-sei7ti,
.framer-aoboo4 h1.framer-styles-preset-sei7ti,
.framer-8sxdx0 h1.framer-styles-preset-sei7ti {
  text-shadow: 0 0 3px rgba(0, 0, 0, .85), 0 2px 6px rgba(0, 0, 0, .7), 0 4px 16px rgba(0, 0, 0, .5) !important;
}
.framer-11z6qql p.framer-styles-preset-ekf7z4,
.framer-aoboo4 p.framer-styles-preset-ekf7z4,
.framer-8sxdx0 p.framer-styles-preset-ekf7z4 {
  text-shadow: 0 0 2px rgba(0, 0, 0, 1), 0 1px 2px rgba(0, 0, 0, 1), 0 0 6px rgba(0, 0, 0, .95), 0 0 12px rgba(0, 0, 0, .8) !important;
}

/* MEASURED 2026-09-15: hero h1 rendered #fff on the gradient's white end = 1.00:1 contrast on /contact-us/ (WCAG fail, text invisible), and 1.49:1 @1440 / 1.46:1 @810 / 1.44:1 @375 on /faq/ - the same mechanism, linear-gradient(#fff0 64.7%, #fff 100%) plus the light-cyan #33cfff40 overlay. Framer re-renders these h1s from JS, so the inline style cannot win - !important on the token is the only durable fix. #0c4e6e is the site's own --token-60b0a9e9-5070-4ec0-8dc5-d16605334856 (used 73x); on white = 9.01:1 (WCAG AAA), measured 6.05:1 on the /faq/ hero. */
.framer-174d7s9 h1.framer-styles-preset-sei7ti,
.framer-51iw3u h1.framer-styles-preset-sei7ti {
  --framer-text-color: #0c4e6e !important;
  color: #0c4e6e !important;
}

/* MEASURED 2026-09-17: the submit button rendered white on rgb(64,196,170) at 16px/600 = 2.19:1 against the 4.5:1 normal-text requirement - the site's primary conversion control, failing at every width. Solid on solid, so that ratio is exact rather than sampled. rgb(40,131,113) is the LOWEST-contrast shade that clears 4.5:1 with hue (168.2deg) and saturation (0.53) held constant, so it reads as the same teal, just deeper - measured 4.59:1. Verified site-wide that this teal is a background on this ONE element only; the 72 other occurrences are FAQ icon strokes, which are unaffected. Rob's call 2026-09-17. Unscoped deliberately: the only submit input on the site is the /contact-us/ enquiry form. */
input[type="submit"] {
  background-color: rgb(40, 131, 113) !important;
}

/* MEASURED 2026-09-18 on the hydrated live preview at 390px: .framer-cag3xf-container computes width:640px with max-width:none, inside a 350px overflow:hidden ancestor (scrollWidth 640) - so 45% of the map is clipped off-screen. max-width:100% clamps it to the 350px parent. Deliberately max-width, not width: measured no-op at 810 and 1440 (container stays 640px with and without the rule), so tablet and desktop render identically and this is a repair, not a design change. RANGE CORRECTED 2026-09-22: this comment previously said "between roughly 430 and 726px", which was never measured. MEASURED again 2026-09-22 at 1px steps from 280 to 820 on the hydrated page, two-armed (rule active vs. rule defeated by a later override), reading the container's own computed width: the rule narrows the map at every width from 280 (and below) through 679 - rendered width tracks viewport minus 40 - and is a clean no-op from 680 up, where both arms agree at the natural 640px. So the active band is 280-679, crossover at 679/680, not 430-726. (A first pass at 4px steps reported 676 only because its grid ran 676 then 680 and never sampled 677-679.) Single match site-wide - the only iframe on the site after hydration. */
.framer-cag3xf-container {
  max-width: 100% !important;
}

/* MEASURED 2026-09-22, ink mask, dsf3, hydrated, and INDEPENDENTLY RE-DERIVED 2026-09-23
   by a clean-room rig that reproduced every figure below and corrected two of them (both
   marked CORRECTED). SCOPE OF THE EVIDENCE, so nobody over-reads it: the "live == local
   exactly" check belongs to the 2026-09-22 adjudication of the UNREPAIRED page. The
   repaired state below is measured on the local server only - it is not deployed, and no
   figure here has been confirmed against the live preview. Everything is headless Chrome
   at DPR 3; a real phone's subpixel antialiasing will differ at the glyph rim, though the
   296-348 failures are interior pixels and survive that. The /contact-us/ hero h1 renders at 48px
   weight 500 at every width up to 809 - Framer has no native breakpoint below 360 - so
   WCAG 1.4.3 applies its large-text 3:1 bar. Across a 296-352px band the final "Us"
   crosses the dark hair region of the photo and fails it. At 296px 6.226% of ink pixels
   sit under the bar with a worst pixel of 1.00:1 - the whole final "s", contiguous glyph
   INTERIOR rather than an antialiased rim: 669 of the 1422 failing pixels survive a 1 CSS
   px erosion, which is what proves it is not antialiasing.
   BAND CORRECTED 2026-09-23. The first pass sampled 296/320/344 and wrote the band as
   296-344. A denser sweep finds 346 (0.758%), 348 (0.451%), 350 (0.175%), 351 (0.039%) and
   352 (0.004%) also under bar, first clean width 353. Those tail widths are rim-only -
   zero pixels survive erosion - so they are detectable but not on their own adjudicable.
   The repair was never under-scoped by the error: under bar reads 0.000% from 353 up and
   this rule already covers everything to 359. Below the band, 280 and 288 are clean
   (0.000%, worst 4.15) because the 48px line wraps to two there and "Us" lands on pale
   wash. Rendering that heading at 40px below 360 was proven in-browser BEFORE
   recommending: 0 pixels under bar at 296, 320, 344 and 359, worst 7.28-7.32 against the
   true backdrop.
   WORST-PIXEL FIGURE CORRECTED 2026-09-23. Against the glyph's own dark shadow the
   after-state worst at 296 is 4.29, not the 4.34 first recorded - 4.34 is the 310-359
   figure. Both clear the bar so the repair is unaffected, but 4.34 was not the worst case
   it was quoted as.
   The photograph is untouched - no darkening, no scrim, no overlay, no colour change - per
   Rob's standing call never to darken a client's imagery to fix a text problem. An ink
   mask (pixel == the text colour +/-2 AND differing from the hidden-text plate) is used
   deliberately, and an independent alpha-coverage mask agreed with it to within 0.1
   percentage points at every width, so the verdict is not an artefact of one mask. A
   diff@threshold mask understates this defect: at 296 it reads 6.806% at threshold 8,
   2.989% at 40 and 2.556% at 90, discarding more of the antialiased edge as the threshold
   rises, and the "2.74% / 1.28" figure quoted in this project's history is that mask at
   threshold 90 with the shadow kept. Do not quote a threshold-140 figure - the two
   independent runs that produced this note disagreed there (0.335% / worst 2.40 against
   0.082% / worst 2.48), so only the direction is safe to cite, not the value.
   CLAIM NARROWED 2026-09-23. Earlier wording here said a diff mask excludes the worst
   pixels "by construction", which overstates it - at no tested threshold does it clear the
   page; even at 140, where it discards most of the glyph, the worst pixel still sits under
   the 3:1 bar on both runs. It halves the apparent extent; it cannot on its own produce a
   "not a defect" ruling. The two earlier and wrong rulings came from judging a crop at 3x
   magnification, which flatters a low-contrast edge while leaving the ratio unchanged.
   Both the Framer token and the plain declaration are set because this export writes that
   token inline on text nodes - the same reason the colour repair above sets both; the
   winning rule and the 359/360 boundary were confirmed by reading the computed value, not
   assumed. Rejected alternative, do not revisit:
   object-position 40% 50% also clears the bar but crops the model's face off at 296px.
   Rob's call 2026-09-23 to ship this. Scoped to the contact hero container for the reason
   given at the top of this file - the preset class exists on all five pages, and the two
   hero repairs are mutually exclusive by page type. */
@media (max-width: 359px) {
  .framer-174d7s9 h1.framer-styles-preset-sei7ti {
    --framer-font-size: 40px !important;
    font-size: 40px !important;
  }
}

/* MEASURED 2026-09-23 on the hydrated page, then INDEPENDENTLY RE-DERIVED the same day by
   a clean-room sweep (270-400 at 1px, 400-1920 at 2px, two arms, the baseline arm taken by
   BLOCKING this stylesheet at the network layer rather than overriding it). That pass
   confirmed the boundary and the scoping and REFUTED two claims first written here; both
   are corrected below and neither changes the shipped rule.
   The header wordmark "Time Aesthetics" sits in .framer-tdlnl4, a flex child with a zero
   basis, so it receives only the width left over - measured as viewport minus 172.14 at
   every width. DOM DESCRIPTION CORRECTED: an earlier wording here called the wordmark an
   "h2 sibling of the round logo image". It is not. .framer-tdlnl4 has exactly ONE child,
   the h2; the logo is a SEPARATE sibling anchor a.framer-1qd08xl (70.1 wide), and the two
   are siblings under .framer-741qjp. The flex mechanics are unaffected - only the sentence
   was wrong.
   The longest word renders 136.17 wide at the 28px mobile variant and 102.17 at 21px, and
   the crossover is exactly 308/309: at 308 the box is 135.86, short by 0.31 (an earlier
   note said one tenth - it is three tenths), so Framer breaks that word MID-WORD into
   "Aesthetic" and "s" for three lines; at 309 the box is 136.86 and it stays whole at two.
   The header pill is a fixed 67 tall with a clipping ancestor, so the three-line case
   escapes it by 18.3: SEEN at 296px, where the first line is sliced off at the top, the
   middle line runs under the menu button and the trailing "s" hangs below the pink pill.
   309 and above are deliberately left alone - two lines, contained, legible, the export's
   own behaviour. They read as escaping by 1.5, which is empty line-box below the text, not
   ink: "Aesthetics" carries no descender. Confirmed on 1x captures at 309, 320 and 375,
   and the two arms are identical from 309 to 1920 with no second broken band anywhere.
   Rendering the wordmark at 21px keeps the longest word whole inside the box.
   COVERAGE CORRECTED - READ THIS BEFORE TRUSTING THE BAND: this rule fixes 275-308, NOT
   "308 and below". At 274 and narrower the word STILL breaks mid-word and still escapes
   the pill, by 6.11. The earlier wording cited "the narrowest measured box of 107.9 at
   280", which was itself the tell - nothing below 280 had been measured, and the claim ran
   past its own evidence. Left unfixed deliberately: 280 is the narrowest real device and
   WCAG 1.4.10 reflow is specified at 320, so 274 is below anything that ships. If that
   ever changes, the same rule needs a smaller step below 275, not a wider media query.
   Scoped to .framer-tdlnl4 so the footer wordmark, which shares the preset class and is
   never short of room, is untouched - verified at 28px on all six pages at 280/296/308,
   and the selectors match exactly two elements per page, both the header wordmark. The
   repair also survives SOFT NAVIGATION, proven with a window sentinel that persisted
   across clicked nav links (navigation entries stayed at 1, so no document replacement),
   not merely assumed from the stylesheet living in head. Vertical centring is unchanged:
   wordmark centre 113.5 at 21px and at 309's 28px, pill centre also 113.5.
   Repair of pre-existing export behaviour, not a design change - Rob's call 2026-09-23 to
   investigate and fix. Chromium only: line breaking may differ on WebKit or Gecko, and
   nothing here is confirmed against the deployed preview. */
@media (max-width: 308px) {
  .framer-tdlnl4 a.framer-styles-preset-etwqqf,
  .framer-tdlnl4 h2.framer-text {
    --framer-font-size: 21px !important;
    font-size: 21px !important;
  }
}

/* MEASURED 2026-09-24 on the hydrated page, on all six pages, by a 1px sweep of 250-340 with a
   fresh document load at every width. Resize-without-reload was not trusted on its own: this
   export renders one responsive variant per load, so the sweep was corroborated against fresh
   loads at 270, 322, 323, 375, 420, 800 and 1440. Those agreed exactly and also located where
   the variant really changes - the short "11 Jamieson Way" form holds from 250 to at least 800,
   and only by 1440 does the longer "11-13" form appear.
   The top contact bar .framer-q6lja0 is a max-content row that can neither give way nor reflow:
   every box in the chain is a flex item with zero shrink, and the text nodes carry the export's
   preformatted setting, so no line ever wraps. Its content needs 341 across while the bar is
   only as wide as the viewport, so the tail is cut. Accounted exactly at 296: 20 of bar inset,
   then the address line as a 16 pin glyph, a 5 gutter and 261.61 of text, then an 18 social
   glyph and 20 of trailing bar inset - 340.6 against a measured scroll extent of 341.
   CUT EDGE CORRECTED, AND THE FIRST RIG RUN HERE WAS WRONG: a scroll container cuts at its
   padding box, not its content box, so ink lying inside the bar's own 20 inset is still visible.
   Measuring to the content box reported a band of 270-322; the true band is 250-302. The address
   overruns the cut edge by 6.61 at 296, by 22.61 at 280 and by 0.61 at 302, and from 303 up no
   TEXT is cut.
   SCOPE OF THAT SENTENCE CORRECTED 2026-09-24, and the reason it was wrong is worth keeping:
   it first read "from 303 up nothing is cut at all". Every figure in this comment measures TEXT
   ink only, so the social glyph never entered the accounting. The 18 quoted just above is that
   link's ANCHOR box; its artwork is 25 across and its own ink overruns that anchor rightward by
   about 7. So the glyph IS cut where this comment used to say nothing was: from 303 to 325, by
   22.27 at 303, clean from 326 - and again below 298, by 1.23 at 296 widening to 47.23 at 250.
   The text is clear at those widths; the artwork is not.
   That is PRE-EXISTING, NOT caused by this rule - proven against the blocked arm - and this rule
   measurably improves it: the bar's scroll extent falls from 341 to 313, and the container overrun
   at 296 falls from 31.61 blocked to 3.58 with the rule served. Left for its own ruling rather
   than folded in here: different element, different cause.
   Because the cut edge IS the padding box, trimming the bar's trailing
   inset buys nothing whatsoever - only type size or leading space moves the ink. The content is
   not unreachable while cut: the bar scrolls sideways, so a swipe reveals the tail.
   REJECTED, MEASURED, DO NOT RETRY: letting the chain give way and the text wrap is strictly
   worse than the defect it fixes. It collapses the address to six lines, takes the bar from
   44.81 to 156.84 tall, and .framer-oxqBx - a fixed 120 box that hides vertical overflow - then
   swallows 46 of that, unreachable and with no scroll to recover it. ANY height growth here is
   clipped by that box, which is the same fixed-height-ancestor trap as the header pill above.
   Also rejected: a step to 13 still leaves 280 cut by 3.92.
   Both lines of the bar are stepped together, not the address alone, so the phone line does not
   sit larger than the line directly beneath it. The step takes the bar from 44.81 down to 40
   tall, so it grows nothing and .framer-oxqBx stays at 120 of content inside its 120 of box.
   COVERAGE: this fixes 275-302. The crossover is exactly 274/275 - at 274 the address still
   overruns by 0.58, at 275 it clears by 0.42. Below 275 is left cut deliberately, the same call
   and the same floor as the wordmark rule above: 280 is the narrowest real device, and WCAG
   1.4.10 reflow is specified at 320, where the bar's TEXT is untouched and uncut.
   THAT WCAG SENTENCE CORRECTED 2026-09-24 - it first claimed the bar "already clears untouched"
   at 320, full stop, which overstates it. The text does. The social glyph does not: at 320 its
   ink is cut by 5.27 and the anchor box itself by 0.61, identically in both arms. Never record
   this bar as reflow-clean without saying which element is meant.
   Scoped to the bar's own container, never to the shared preset - that preset class also dresses
   the header wordmark, which carries its own rule above, so targeting it would collide. Verified
   to match exactly four elements per page: the phone and address paragraphs and the anchor
   inside each, all of them in the header, none in the footer, identical on all six pages. Above
   302 the rendered result is unchanged by this rule, confirmed arm-against-arm at 303, 320, 360,
   390, 414, 480, 600, 768, 1024, 1200, 1280, 1440 and 1920 - every metric identical with the rule
   served and with it blocked.
   COVERAGE FIGURES CORRECTED 2026-09-24 by an independent clean-room re-derivation: an earlier
   wording here gave "ink 302.61, bar 44.81, type 14" as the unchanged result "through to 1440".
   The IDENTITY between arms does hold at every width tested; those NUMBERS do not. They hold
   from 303 to 768 only. By 1024 the export has switched variant - ink 572.48, bar 22.41 tall,
   and the text itself becomes the longer "11-13 Jamieson Way" form - and from 1440 ink is 598.50.
   Type stays at its shipped 14 throughout. The claim ran past the widths that had been measured,
   which is the same fault the wordmark comment above was corrected for; the rule is unaffected.
   ALSO RECORDED, because the obvious tests mislead here: a scroll extent wider than the visible
   width is NOT a cut detector on this bar - with this rule applied and no TEXT cut it still
   reports 313 against 296, because Chromium folds the trailing inset into the scrollable area.
   (Written "nothing cut" when first added earlier the same day; corrected for the glyph, above.)
   Ink against the padding box is the only honest test. And blocking this WHOLE stylesheet to get
   a baseline reports six changed text elements, not four; blocking only this final block reports
   exactly four, all in the bar. The extra two are other rules in this file, not a leak from this
   one.
   TIGHTEST CLEARANCE ON THE SITE IS 303, NOT 302: there the untouched 14 text clears the cut
   edge by 0.39, and this rule does not apply. Not caused by this repair and not fixed by it, but
   a 0.4 shift in text metrics would cut it. Webfont failure is NOT that risk - with all five font
   requests blocked the fallback measures narrower, so it is safer, not worse. A wider substitute
   face, or mobile text auto-adjust, is the real exposure.
   Both the export's own size token and the plain declaration are set, for the reason given on
   the two rules above: this export writes that token inline on its text nodes.
   Repair of pre-existing export behaviour, not a design change. Rob's call 2026-09-24 to fix it
   before go-live, and to take this single lever having been told the size sits under the project
   floor of 18 for reading text - this is utility text in a bar the export itself already ships
   at 14, and the step applies only below 303 across. Chromium only: line breaking and text
   metrics may differ on WebKit or Gecko, and nothing here is confirmed against the deployed
   preview. */
@media (max-width: 302px) {
  .framer-wi7tjs p.framer-text,
  .framer-wi7tjs a.framer-text {
    --framer-font-size: 12.5px !important;
    font-size: 12.5px !important;
  }
}

/* ---------------------------------------------------------------------------
   Round 2, 2026-09-24. Six pre-existing narrow-viewport defects found by an
   independent cross-repair audit AFTER the three repairs above, every one of
   them proven pre-existing by a two-arm run with this stylesheet blocked at the
   network layer. Rob ruled each one individually on 2026-09-24; the rulings and
   the measurements behind each value are recorded per rule below.
   Rigs: verification/round2/ (sweep, candidates, fine, cols, inkcut, preflight,
   thresh). Untracked, withheld from deploy by the .assetsignore root cascade.
   --------------------------------------------------------------------------- */

/* MEASURED 2026-09-24, fresh page load per width, per-CHARACTER line clustering
   (not getClientRects().length, which counts fragments not lines): the opening-hours
   day names break MID-WORD from 250px to 360px on all three pages that carry the
   table (/, /about-us/, /contact-us/) - "Wednes|day", "Thursda|y", "Saturda|y" at
   320, and "Wednesday" still splitting at 360. Clean from 370. Cause: each day box
   is a flex item with `flex:1 0 0; width:1px` so its width is a share of the row
   (64.5px at 320) and the text carries the export's `word-break:break-word`, which
   splits the word as soon as the share is narrower than it. Restoring the default
   break-at-spaces behaviour fixes it with NO type-size change, which is why no
   font-size is set here.
   BOUND CORRECTED 2026-09-24, before commit, from 296px to 339px - and the reason
   matters more than the number. The first bound was set by measuring the day name's
   ink against the TIME TEXT and taking the width where they stop colliding (296).
   That was the WRONG REFERENCE. Between the two columns sits a ruled divider line,
   and the day name reaches it ~15px before it reaches the time text, so at 296-338
   the unbroken "Wednesday" runs THROUGH the divider - measured +21.34px past the
   divider's left edge at 296, +9.34 at 320, +0.34 at 338, clear from 339. The
   numbers said "7.47px of clearance" at 320 while the rendered page showed the word
   crossing a ruled line; a screenshot of the hours table is what caught it, not the
   rig. Proven caused by this rule, not pre-existing: in the blocked arm the day
   names never reach the divider at any width (-15.22 at 296, -15.58 at 320).
   So the bound is 339px, the measured crossover, and below it the export's own
   mid-word break is left exactly as it is. That leaves 320px still breaking
   mid-word - stated plainly rather than buried, because it is a real device width.
   The alternatives were measured and are worse: letting the day column take its
   natural width (`min-width:max-content`) stops both the break and the crossing but
   forces the times to 4 lines and nearly doubles the table, row height 46 -> 89.63
   at 320 and -> 246.47 at 250, which is a design change rather than a repair; and
   fitting "Wednesday" into the 64.5px column at 320 would need roughly 11.6px type,
   below even the contact bar's 12.5px, on real reading content. Rob's call 2026-09-24
   was to fix the hours; 339 is the widest fix that repairs without introducing a new
   visible defect, and it covers 360 - the width that reaches the most real devices
   and the one the defect report called out.
   No upper bound because the rule is a measured no-op above the band: at 390 the
   served and unset arms are identical (1 line, ink 10.66px inside the box), and at
   370-390 the day names do not break in either arm.
   Scope: `[data-framer-name="Monday"]` is the export's layer name on ALL SEVEN day
   boxes (Framer reused one layer name), verified matching exactly 7 boxes / 7
   paragraphs whose texts are Monday..Sunday on each of the three pages, and ZERO
   elements on /treatments/, /faq/ and 404. The preset class is not used as the
   selector because it also styles the time box beside it. Rob's call 2026-09-24. */
@media (min-width: 339px) {   /* MEASURED 2026-09-24: exact width at which the unbroken day name stops crossing the column divider, 1px sweep */
  [data-framer-name="Monday"] p.framer-text {
    word-break: normal !important;
    overflow-wrap: normal !important;
  }
}

/* MEASURED 2026-09-24, same method: the "Design by The ARCHiTECH" footer credit -
   Rob's own credit link - breaks MID-WORD from 250px to 320px on ALL SIX pages,
   rendering "Design by / The / ARCHiTEC|H" as three lines in a 80px box at 320
   (the box is `flex:1 0 0; width:1px`, so 80px is just the leftover share after the
   100px copyright box and the divider). Clean from 330. Four lines of paragraph at
   320 become three with this rule, two at 390 either way.
   Bounded at 281px because below it the unbroken name is CUT instead: measured
   +0.78px past the clipping ancestor's padding box at 280, +4.78 at 276, +30.78 at
   250, versus -0.22 (clear) at 281 and -39.22 at 320. 281 is the exact crossover,
   swept at 1px, and sits alongside the 274/275 floor of the two rules above.
   The rule is on the ANCHOR, not the paragraph: at 250 the paragraph-level variant
   produced the same cut but with a worse line count, and `white-space:nowrap` was
   measurably worse again (cut from 300px down, +50.2 at 300). A `min-width:max-content`
   wrapper variant was the worst of all - it forces the box to 180.16px and cuts it
   by 60.16 at 320 - and is NOT to be retried.
   Scope: exactly ONE `a[href*="thearchitech.com.au"]` per page, verified on all six.
   Wrapping only - the credit link is never removed and never gets rel="nofollow".
   Rob's call 2026-09-24. */
@media (min-width: 281px) {   /* MEASURED 2026-09-24: exact cut crossover for the unbroken name, 1px sweep */
  a[href*="thearchitech.com.au"] {
    word-break: normal !important;
    overflow-wrap: normal !important;
  }
}

/* MEASURED 2026-09-24: the hero h1 breaks MID-WORD on / ("Treatment|s",
   "Injectable|s") and on /treatments/ ("Treatment|s") from 250px to 301px, clean
   from 302 - the same defect class the /contact-us/ hero rule above fixes, but that
   rule is scoped to /contact-us/ only so these two pages were never covered.
   40px is chosen to MATCH the value already shipped for the /contact-us/ hero above
   rather than as a fresh guess; measured, it clears the whole band from 258px up
   (breaks remain at 250-257, below the 275 floor the two rules above already accept).
   Rejected: leaving 48px and only setting word-break:normal - measured, the longest
   token then extends to a fixed x=291.13 at every width, so it pokes past a 250-290
   viewport and is cut. 36px and 32px also clear the band but are a larger change to
   an approved design than the precedent value, so 40px wins.
   The halo text-shadow on these two photo heroes is unchanged and still computes
   (verified in the hydrated DOM at every swept width). Per the global rule, small
   text needs a denser halo than display text - 40px is display text and is the same
   size the /contact-us/ hero already ships, so the existing halo applies unchanged.
   Scope: hero container + the shared preset, exactly as the rules above. The two
   photo-hero pages only. NEVER merge with the pale-wash hero group; #0c4e6e on a
   photo hero measures 1.00:1. Rob's call 2026-09-24. */
@media (max-width: 301px) {   /* MEASURED 2026-09-24: last width that breaks mid-word at 48px; 302 is clean */
  .framer-11z6qql h1.framer-styles-preset-sei7ti,
  .framer-8sxdx0 h1.framer-styles-preset-sei7ti {
    --framer-font-size: 40px !important;   /* source: the /contact-us/ hero rule above, same value, measured to clear 258px up */
    font-size: 40px !important;            /* source: as above */
  }
}

/* MEASURED 2026-09-24: the Instagram glyph's ARTWORK is clipped, which the
   contact-bar comment above originally missed because that accounting measured TEXT
   ink only. The anchor is 18x18 but its artwork wrapper is
   `position:absolute; inset:-7px -7px -7px 0`, so the artwork renders 25px wide and
   bleeds 7px to the RIGHT only. Measured ink past the bar's padding box: +49.58 at
   250, +19.58 at 280, +3.58 at 296, clear at 302, then +24.61 at 303, +17.61 at 310,
   +7.61 at 320, +1.61 at 326, clear from 327. Present on all six pages.
   THE REFERENCE THIS PARAGRAPH USES, NAMED AT LAST, AND ONE FIGURE CORRECTED
   (re-measured 2026-09-25, whole stylesheet blocked, `verification/round2/insta-ink.mjs`).
   Every number on the two lines above is the **svg/container BOX** right edge against the
   bar's padding box: 24.61 at 303, 17.61 at 310, 7.61 at 320, 1.61 at 326 — all four
   reproduced exactly. The contact-bar comment above quotes DIFFERENT numbers for the same
   element (22.27 at 303, "clean from 326") and it is NOT in conflict: it measures the
   **PAINTED PATH INK**, which sits 2.34px inside the svg box. Both are correct; neither
   said which reference it used, and that 2.34 was carried as an unexplained disagreement.
   Take the box figures for anything about clipping the ELEMENT, the ink figures for
   anything about what a reader can SEE. Note `getClientRects()` on an svg child just
   echoes the svg's own box — path ink needs `getBBox()` through `getScreenCTM()`.
   CORRECTED: "clear from 327" is wrong on this reference. By the box the glyph is still
   cut by 0.61 at 327 and clears at **328** (-0.39); by path ink it clears from **326**
   (-0.73, against +0.27 at 325). 327 matches neither. Left in place above rather than
   overwritten, because the 327 in the media query below is a DIFFERENT and correct
   measurement and the two must not be conflated.
   THE SHIPPED 327 BOUND IS CONFIRMED, independently re-derived 2026-09-25 in the SERVED
   arm: at 327 the 24px anchor clears by exactly 0.39, and at 326 a 24px anchor would be
   cut by 0.61 — so 327 is the exact crossover, not an approximation.
   NOT RE-RULED, deliberately: the contact-bar comment's "identically in both arms" for
   the 320px figures could not be checked here, because that sentence's "arms" may mean
   blocking only its own final block (which leaves `inset:0` active) whereas this run
   blocks the whole stylesheet. Stated rather than silently corrected on a guess.
   `inset:0` removes the bleed so the artwork can never exceed its own anchor, and it
   costs nothing in layout - the anchor's box is untouched. Verified by computed value
   at every swept width: header artwork ink width equals the anchor width exactly.
   CORRECTED 2026-09-24, before commit: an earlier draft applied `inset:0` to BOTH
   Instagram instances on the premise that it contains the artwork generally. It does
   not, and the acceptance check caught it. The two icons are different components.
   MEASURED 2026-09-24: the HEADER svg scales to its container, so with inset:0 its
   artwork ink width equals the anchor width at every swept width and is fully
   contained. The FOOTER svg has a fixed intrinsic size that overflows its container
   regardless, so inset:0 there only moved its right ink edge OUTWARD, from 273.75 to
   278.25 - it made the overhang worse. The rule is therefore scoped to the header
   instance. Never apply it site-wide on the assumption that a container inset governs
   the artwork inside it; on this export it governs one of the two icons, not both.
   Tap target, WCAG 2.5.8 (24x24 minimum): the anchor is 18x18 site-wide.
   HONEST LIMIT, stated rather than papered over - the header icon CANNOT reach 24x24
   below 327px. Measured, it sits FLUSH against the Google-Maps address link (gap
   exactly 0.00 at every width up to 346) and the bar's clip edge is the viewport
   edge, so there is no space on either side; growing it below 327 would put artwork
   past the clip edge again (headroom -0.61 at 326). So the size criterion is met from
   327 up, and the spacing exception is NOT met below that - the two targets abut.
   327 is measured: at 327 a 24px anchor leaves 0.39px of clip headroom, ink cut
   -0.39, bar text cut -24.39. Growth is RIGHTWARD (the gap to the address link stays
   0.00 at every width, so this does not reduce the separation that already exists).
   Rob's call 2026-09-24, choosing this over dropping the bar address/phone to 12.5px
   up to 330px - that would have bought a 24x24 target and a fully uncut glyph from
   292px up, at the cost of 12.5px address text on 320px phones, which is real
   reading text on a real device width. Not taken.
   The FOOTER Instagram link has room on every real device width (48.75px of clip
   headroom at 320, no neighbour on its row) so it gets the full 24x24 target, which
   means a narrow-phone visitor still has a compliant-sized target for the same
   destination.
   CORRECTED 2026-09-24, before commit: an earlier draft of this comment said the
   footer target applied "unconditionally". That was wrong and the acceptance check
   caught it. The footer icon's right ink edge is fixed at 277.25px once its box is 24px, set by its centred
   column, so a 24px box is CUT below 278px - measured +0.25 at 277, +6.25 at 271,
   +9.25 at 268 - where an 18px box was not (its ink edge sits at 273.75). The rule is
   therefore bounded at 278px, the exact crossover (278 clears by 0.75), so below it
   the export's own 18px box is left alone rather than being made worse. 278 also
   sits alongside the 274/275/281 floors of the rules above.
   TWICE-CORRECTED 2026-09-24, by an independent adversarial review AFTER commit. Two
   numbers in the paragraph above were wrong and both are fixed in place: it said the
   rule is "bounded at 279px, the exact crossover (279 clears by 0.75)" while the code
   ships `@media (min-width: 278px)` and the gate's FOOTER_BIG_MIN is 278 - the prose
   contradicted the shipped bound and itself three words later; and it gave "+7.25 at
   271", which its own stated constant refutes (277.25 - 271 = 6.25; 7.25 is the figure
   at 270). Kept visible rather than silently overwritten because a later session
   repairing a regression from the prose would have moved a shipped media query by 1px
   and re-cut the icon. The mechanism of the error is the point: the first correction
   was applied with a scripted string-replace that matched some occurrences and not
   this sentence, and the script reported success anyway. Assert a patch landed before
   trusting it.
   RESIDUAL, recorded honestly: the header glyph is still cut from 303 to about 318
   (+17.61 at 303 falling to +0.61 at 320) and below about 290, because there the bar
   row itself is wider than the viewport - the pre-existing bar-width defect the rule
   above already accepts a floor on, not something this rule causes. No standard
   device width falls in that residue: 296, 320, 360 and 390 all measure clear.
   NOT a WCAG pass claim: the size criterion is met at 327+ and in the footer only. */
.framer-q6lja0 a[aria-label*="instagram" i] > div[class*="-container"] {
  inset: 0 !important;   /* MEASURED 2026-09-24: cancels the header icon's right bleed; its artwork ink then equals its anchor box at every swept width */
}
@media (min-width: 278px) {   /* MEASURED 2026-09-24: exact crossover - a 24px footer box puts ink at 277.25, cut by 0.25px at 277 and clear by 0.75px at 278 */
  footer a[aria-label*="instagram" i] {
    width: 24px !important;    /* WCAG 2.5.8 - 24x24 minimum target size; 48.75px clip headroom measured at 320 */
    height: 24px !important;   /* WCAG 2.5.8 - as above */
  }
}
@media (min-width: 327px) {   /* MEASURED 2026-09-24: lowest width where a 24px header anchor still leaves clip headroom (0.39px) */
  .framer-q6lja0 a[aria-label*="instagram" i] {
    width: 24px !important;    /* WCAG 2.5.8 - 24x24 minimum target size */
    height: 24px !important;   /* WCAG 2.5.8 - as above */
  }
}

/* MEASURED 2026-09-24: four shared footer columns carry a hard-coded
   `width:340px; flex:0 0 auto`, so inside a narrower viewport they are centred and
   overhang both sides, giving `main` a hidden horizontal extent on ALL FIVE pages -
   45px at 250, 30 at 280, 22 at 296, 10 at 320, 1 at 338, zero from 344. `main` is
   `overflow:hidden` with no scrollbar, so that extent is unreachable.
   HONEST SCOPE, because the first measurement of this was wrong: NO VISIBLE INK is
   cut. With carousel content correctly excluded (an element inside its own
   horizontal scroller is reachable by swiping and is NOT cut by main - omitting that
   filter reported a false 3,496px of "cut" content on /treatments/ and /about-us/,
   which is the testimonial carousel), the worst visible overhang on every page and
   width sampled is NEGATIVE: text -15.94 to -275.39, artwork -20 to 0, painted boxes
   0. So this rule is layout hygiene, NOT a repair of anything a visitor can see, and
   must never be recorded as one.
   `max-width:100%` clamps them with no side effects, measured: hidden extent 45/30/
   22/10/1 -> 0 at every width on / and /contact-us/, column content still fits
   (spill 0.00 at 250, -20.00 from 296), footer height unchanged at 570px narrow and
   278px at 1440, no new overhanging element, document scroll still 0, and above 344
   the columns are 340px again so the clamp is inactive.
   /about-us/ keeps a 20px residue from a DIFFERENT element - an absolutely
   positioned `Page Title` box at `left:20px` with a viewport-width `width`, present
   250-768. Rob ruled it CLOSED on 2026-09-24 and it is deliberately NOT fixed here:
   its overhang contains no ink (worst visible -2.63 at 250) and both clamps tested
   made something visible worse - `max-width:calc(100% - 40px)` wraps the "About Us"
   heading onto two lines at 250 (h1 48px -> 96px tall), and `right:20px;width:auto`
   resizes the desktop title box from 600px to 1260px at 1440. Do not retry either.
   404.html keeps a residue too, and it is also deliberately not fixed: below 279px a
   269.656px content-width text block (div.framer-1n32k2g, the error message) overhangs
   by 9.83 at 250 and 4.83 at 260, clearing at 279. It is content-driven width on an
   error page at a width below any phone, it is not one of the four columns, and
   clamping it would re-wrap the error copy. Recorded, not repaired.
   Rob's call 2026-09-24. */
.framer-wli25x,
.framer-oyihfb,
.framer-1nz4jg6,
.framer-1qiwgez {
  max-width: 100% !important;   /* MEASURED 2026-09-24: clamps the export's hard-coded 340px column to the viewport; inactive from 344px up */
}

/* MEASURED 2026-09-24: both email addresses render with the ".au" OUTSIDE the link -
   the anchor text stops at "info@timeaesthetics.com" and ".au" follows as a bare
   text node in the paragraph, taking the paragraph's grey `#666d80` while the linked
   part is `#0c4e6e`. Two different colours mid-address makes it read as truncated.
   The hrefs are CORRECT (`mailto:info@timeaesthetics.com.au`) and are not touched -
   this is appearance only. CSS cannot select a bare text node, and the markup is
   React-owned so it cannot be restructured, so recolouring the paragraph is the only
   available mechanism; it is safe because the paragraph contains nothing but the
   anchor and that tail (verified: exactly one element child, and the paragraph's full
   text matches an address on its own).
   The `:not(:has(> :nth-child(2)))` guard is NOT decoration. Without it the selector
   also matches a /contact-us/ paragraph that holds BOTH addresses plus the labels
   "General" and "Doctor" (three element children, and its own link colour is
   rgb(0,153,255), not #0c4e6e) - recolouring that would have turned those two labels
   link-coloured. Verified with the guard: 2 of 2 matched on /, /treatments/,
   /about-us/, /faq/ and 404, and 2 of 3 on /contact-us/ with exactly that paragraph
   excluded, at both 390 and 1440.
   The links carry no underline (`text-decoration-line: none` measured), so matching
   the colour is sufficient - there is no remaining visual seam. Rob's call 2026-09-24. */
p.framer-text:has(> a[href^="mailto:"]):not(:has(> :nth-child(2))) {
  --framer-text-color: #0c4e6e !important;   /* source: the export's own link token, measured rgb(12,78,110) on these anchors */
  color: #0c4e6e !important;                 /* source: as above */
}

/* MEASURED 2026-09-24: the "see the testimonials" arrow link on the home page is a
   20x20 icon-only target, under the WCAG 2.5.8 minimum of 24x24. It was NOT one of
   the seven defects in the round-2 list - it turned up in the tap-target census run
   for the Instagram fix - so it was measured, reported, and left alone until Rob
   ruled on it. Rob's call 2026-09-24: fix it too.
   Growing it to 24x24 is measurably free, unlike the header Instagram icon: the
   anchor's left edge is unmoved by the rule at every width (it grows rightward), the
   5px gap to the neighbouring link is unchanged, the clip ancestor
   keeps 98.88px of headroom at its tightest sampled width, the document still does
   not scroll horizontally, and the only layout consequence is its row growing
   22.41px -> 24px. The svg follows its anchor, so the arrow itself renders 4px
   larger; that is the visible cost of the repair and is the same trade already
   accepted for the Instagram icons.
   FIGURE CORRECTED 2026-09-24: this said the left edge "stays at 117.13px at EVERY
   width from 280 to 1440". 117.13 holds from 250 to 768 only - at 1024 it is 604.13
   and at 1440 it is 806.13, because the export switches to its desktop layout variant
   and the whole block moves. The claim that mattered is unaffected and is what the
   sentence now says: the RULE does not move the anchor's left edge at any width. Same
   fault as the "unchanged above 302" figures corrected in 05ace05 - a number measured
   over one variant quoted as if it held across the breakpoint.
   Scope: `:has(> svg)` is load-bearing. Three links on the page point at
   #testimonials and a bare href selector matches all three; the other two are the
   text links "What Our Clients Think" (300.28x35) and "See more" (72.13x20), which
   this rule must not touch. Verified matching exactly 1 element, on `/` only and on
   no other page.
   WCAG CLAIM RETRACTED 2026-09-24, by an independent adversarial review. This comment
   previously said those two text links are "exempt anyway under WCAG 2.5.8's inline
   exception, being sized by the line-height of surrounding text". That is WRONG and
   must not be repeated. The Inline exception requires the target to be "in a sentence
   or its size otherwise constrained by the line-height of NON-TARGET text" - both
   load-bearing. Measured on the hydrated page: "See more" is ALONE in its paragraph
   (its parent's text content is exactly "See more", zero non-target text), so nothing
   constrains it and the exception does not apply; at 72.13x20 it is 4px under the
   height minimum and is simply non-conformant. ("What Our Clients Think" is >=24 in
   both axes and needed no exception at all, so invoking one for it was gratuitous.)
   WHAT THE SAME MEASUREMENT FOUND, recorded because it is larger than this rule and
   is NOT ruled on: undersized text targets are SITE-WIDE and PRE-EXISTING. At 390px
   the home page alone carries 13 interactive targets under 24x24 - the four nav links
   (About Us 69.98x20, Treatments 85.2x20, FAQ 30.72x20, Contact Us 84.27x20), both
   CTAs (Book Online 100.14x22, Book Appointment Here 158x17), the phone (91.83x17),
   the address (261.61x17), both email links (167.38x17, 207.19x17) and "See more" -
   nearly all of them alone in their own paragraph, so the inline exception genuinely
   does not cover them. Only "booking" (60.91x20, inside a real sentence) is exempt.
   None of this is caused by these rules and none of it is claimed to be fixed by
   them. It needs Rob's ruling as its own item; it was deliberately NOT swept into a
   deploy-blocking gate assertion, because failing the gate on a pre-existing,
   unruled, site-wide shortfall would block a cutover over something nobody decided.
   SCOPE OF THE CENSUS in the gate, stated honestly: it counts ICON-ONLY links only
   (it skips any anchor with text, and does not look at button/input/summary at all).
   So "ZERO icon-only links under 24x24 at 327px and above" is true as written and
   says NOTHING about text targets - it is not a WCAG 2.5.8 pass for the page.
   Below 327 the header Instagram anchor stays 18x18 for the reason given in the rule
   above (no room - measured gap 0.00 to the address link), and from 250 to 277 the
   FOOTER Instagram anchor is 18x18 as well, so there are TWO undersized icon links in
   that band, not one - correcting the commit message for 7968ca7, which said exactly
   one. Not a regression: the blocked-baseline arm has three there. */
a[href*="#testimonials"]:has(> svg) {
  width: 24px !important;    /* WCAG 2.5.8 - 24x24 minimum target size */
  height: 24px !important;   /* WCAG 2.5.8 - as above */
}

/* MEASURED 2026-09-24, AFTER an independent adversarial review caught that the
   40px hero rule above shipped with NO contrast measurement behind it.
   THE CLAIM THAT WAS WRONG, retracted here in full: the 40px rule's comment says
   "the halo ... still computes (verified in the hydrated DOM at every swept width)"
   and justifies leaving the halo alone because "40px is display text and is the
   same size the /contact-us/ hero already ships". Both halves were bad reasoning.
   "Still computes" proves the DECLARATION is present, not that it WORKS - this
   file's own headline lesson is that the house 3px 3px 3px #00000040 computed
   perfectly and moved the worst pixel from 1.86 to 1.86. And /contact-us/ is a
   PALE-WASH hero with dark #0c4e6e text and no halo dependency at all, so its 40px
   is a measurement of a different colour on a different backdrop; citing it as
   evidence for white text over a PHOTOGRAPH is the false-citation failure mode this
   project's CLAUDE.md was written after. Two arms, same rig as the hero-halo tool
   (verification/round2/hero40-halo.mjs), mask threshold 40 stated as required.
   WHAT THE MEASUREMENT SHOWED - the 48->40px step really did degrade the halo, on
   both photo heroes, by the share of glyph pixels under the 3:1 large-text bar:
        page          48px (>=302, rule off)   40px (<=301, rule on, old halo)
        /             6.73 - 6.77 %            10.01 - 10.38 %
        /treatments/  8.39 - 8.46 %            12.63 - 13.02 %
   A ~52% relative increase on both, reproducible, 10 widths each. Smaller glyphs
   have thinner strokes, so a halo tuned for 48px covers proportionally less of them
   - exactly what the global rule means by "small text needs a tighter, denser
   shadow than large text". The re-wrap also lands the glyphs on different pixels of
   the photograph, which is the variable worst-pixel contrast depends on.
   THE FIX, chosen by measurement not by eye - a denser, tighter, near-zero-offset
   halo applied ONLY in the same <=301px band, so nothing at 302 and above changes:
        /             10.01-10.38 % -> 6.74 - 6.91 %   (48px baseline 6.73-6.77 %)
        /treatments/  12.63-13.02 % -> 6.69 - 6.77 %   (48px baseline 8.39-8.46 %)
   Home lands level with its own 48px figure; /treatments/ lands better than its own.
   Two rejected on measurement: the existing halo (the figures above), and a first
   candidate one step lighter (0 0 2px/.95, 0 0 5px/.9, 0 2px 6px/.8, 0 4px 14px/.6)
   which reached only 7.15-7.41 % on / - closer, but still above the 6.77 % it had
   to beat. Do not re-try either.
   INSTRUMENT NOTE worth keeping: a first attempt to measure a candidate reported
   the injected shadow changing NOTHING at all - identical figures to six decimal
   places. That was not a finding about shadows, it was specificity: the candidate
   was injected as `h1.framer-styles-preset-sei7ti` (0,1,0) against this file's
   `.framer-11z6qql h1.framer-styles-preset-sei7ti` (0,2,0), both !important, so the
   candidate simply lost the cascade. Any injected candidate must match or exceed
   the specificity of the rule it is meant to replace, or the rig will report a
   perfectly flat "no effect" for every value tried.
   HONEST CEILING, unchanged: WCAG gives NO formal credit for text-shadow, so this
   is a legibility improvement and NOT an audit pass - the rig still prints FAIL at
   every width on this hero, as it did before any of these rules existed, because it
   scores the glyph against the photograph. What is being compared here is this
   build against itself, not against the bar.
   SCOPE, stated plainly: the <=301px band is BELOW any current phone (320 is the
   narrowest in common use), so neither the regression nor this repair is visible to
   a real visitor. It is corrected because the number was wrong and was defended by
   a bad citation, not because a user was affected. Rob's call 2026-09-24. */
@media (max-width: 301px) {   /* same band as the 40px rule above - this halo exists only because that rule does */
  .framer-11z6qql h1.framer-styles-preset-sei7ti,
  .framer-8sxdx0 h1.framer-styles-preset-sei7ti {
    /* MEASURED 2026-09-24: denser + tighter than the 48px halo; takes the under-bar
       share from 10.01-10.38 to 6.74-6.91 on / and 12.63-13.02 to 6.69-6.77 on
       /treatments/, i.e. at or below each page's own 48px figure. */
    text-shadow: 0 0 2px rgba(0, 0, 0, 1), 0 0 4px rgba(0, 0, 0, 1), 0 1px 3px rgba(0, 0, 0, .95), 0 0 9px rgba(0, 0, 0, .9), 0 4px 14px rgba(0, 0, 0, .65) !important;
  }
}

/* MEASURED 2026-09-25: the ONLY genuine WCAG 2.5.8 failure left on this site. The two
   email addresses are stacked in their own paragraphs with `line-height: 22.4px` and no
   margins, and the anchors are `display:inline` and 17px tall - so the centre-to-centre
   distance between the two targets IS the line-height, 22.4px, against the criterion's
   24px. Short by 1.59-1.60px, identically on all six pages at 320/360/390/768/1440.
   2.5.8 offers two ways out and neither applies here. SPACING fails by exactly that
   1.59px (a 24px-diameter circle centred on each one overlaps its neighbour's). INLINE
   does not apply either: each address sits alone on its own line, not in a sentence of
   non-target text. A rig initially reported these two as inline-exempt and that was
   WRONG for a reason worth keeping - the markup is `<a>info@timeaesthetics.com</a>.au`
   with the `.au` tail OUTSIDE the anchor (the same quirk the colour rule above exists
   for), so "the parent has text outside the target" was true of a three-character domain
   fragment. A punctuation tail is not a sentence.
   THE VALUE IS 25px, NOT 24px, DELIBERATELY. 24 would put the gap exactly ON the bar
   with 0.00 of margin, and these numbers already move 0.01 between widths (22.41 at 320,
   22.40 at 390), so an exact-24 fix would sit inside its own measurement noise. 25 buys
   1px of headroom. Cost: each line grows 2.6px, so the footer email block grows 5.2px
   in total - below the threshold at which a reader notices, and nothing else moves.
   ⚠RETRACTED 2026-09-25, SAME DAY, BEFORE DEPLOY - AND THE RETRACTION IS THE POINT.
   This rule first shipped WITHOUT the `:not(:has(> :nth-child(2)))` guard, justified by
   a comment that read: "those two anchors [in the /contact-us/ paragraph holding both
   addresses plus the General and Doctor labels] are stacked 22.4px apart as well and
   fail the same criterion". **That was never measured. It was an inference from
   geometry, written as a finding.** An adversarial claims audit caught that no rig, log
   or JSON in this repo had ever measured that paragraph, and measuring it refuted the
   claim outright: `verification/round2/contact-combined.{mjs,log,json}`, blocked arm,
   its two anchors are **44.81px apart at 320 and 29.97px at 390/1440** - comfortably
   clear of the 24px bar at every width, because the "General" and "Doctor" labels sit
   between them. They never failed, so the wider scope fixed nothing there and only
   grew a client-visible block for no benefit.
   The guard is therefore BACK, and it is now load-bearing for two independent reasons -
   the colour hazard the rule above documents, AND the fact that the paragraph it
   excludes was never in breach. Only the standalone single-address paragraphs are.
   THE 1px MARGIN IS NOT FRAGILE, and the reason is worth stating because an independent
   verifier flagged it as such 2026-09-25 ("any sub-pixel font-metric variance could tip
   it under 24"). It cannot. The centre-to-centre distance here is the distance between
   two single-line paragraphs' LINE BOXES, and that is pinned by an explicit `25px`, not
   derived from glyph metrics - the anchor's own 17px height varies with the font, the
   line box does not. A wider substitute face can only wrap an address to a second line,
   which makes the gap larger, never smaller. So 25px holds at 1px of margin on any
   platform; the value was not inflated further.
   Both the export's own token and the plain declaration are set, for the same reason the
   rules above give: this export writes that token inline on its text nodes.
   Rob's call 2026-09-25, after the measurement showed one real defect rather than the 13
   undersized text targets an earlier count had reported. */
p.framer-text:has(> a[href^="mailto:"]):not(:has(> :nth-child(2))) {
  --framer-line-height: 25px !important;   /* MEASURED 2026-09-25: 22.4px gives a 22.40-22.41px centre-to-centre gap; 25px gives 25px, clearing WCAG 2.5.8's 24px by 1px */
  line-height: 25px !important;            /* source: as above */
}