/* ═══════════════════════════════════════════════════════════════════════════
   oro-polish.css — layer 18 · namespace `orop-`
   Loaded LAST, after oro-qa.css. Additive only: this file overrides by load
   order and specificity, and never edits a rule in a layer below it.

   Every change here was measured before it was written. The numbers are in the
   comments so the next person can re-check them rather than trust them.

   Authored in px / clamp(), never rem. `1rem == 1vw` on this build — the root
   font-size is viewport-relative and the rule lives in an inline <style> in
   index.html, which is why CSS-only searches miss it — so a rem-authored size
   collapses to nothing on a phone. 1rem is 3.9px at 390 wide, not 16px.
   ═══════════════════════════════════════════════════════════════════════════ */

:root {
  /* One warm ramp, borrowed from --orox-* so this layer cannot drift from the
     palette it decorates. Declared as orop- so nothing below can inherit it. */
  --orop-gold:    201 164 106;   /* #C9A46A  primary accent  */
  --orop-spec:    255 242 169;   /* #FFF2A9  specular        */
  --orop-bronze:  140 103  67;   /* #8C6743  shadow side     */
  --orop-grid:    rgb(var(--orop-gold) / .055);
}

/* ═══ 1 · THE POSSIBILITIES WALL WAS DIMMED THREE TIMES ═════════════════════

   Measured, not guessed. The source plates are healthy artwork:

     oro-scene-vault    mean L 83.6 / 255
     oro-scene-ring     mean L 54.7
     oro-scene-hall     mean L 52.2
     oro-scene-works    mean L 42.6
     oro-scene-horizon  mean L 36.8

   What the visitor actually saw at 1440 was mean L 18.9, with 78% of pixels
   below L24 — darker than the roadmap section, which has no imagery in it at
   all. Three separate dimmers were multiplying:

     .drift-wall__inner    opacity var(--dw-dim) = .55
     .drift-wall__overlay  #060010 at .42
     .drift-wall           an edge mask fading the outer 40%

   0.55 x 0.58 = 0.32, so roughly two thirds of the art was being thrown away
   before the mask even applied. Those are React Bits defaults, tuned for
   brighter source plates than these.

   Correcting the two multiplicative dimmers and leaving the mask alone:
   0.78 x 0.76 = 0.59, about 1.85x, which lands the wall near the #core
   section's measured L35.8 — bright enough to read as photography, still
   clearly a background. The mask stays because it is what stops the grid
   ending in a hard rectangle.

   ONLY HALF OF THAT FIX IS IN THIS FILE. createDriftWall writes --dw-dim as an
   INLINE style on the container, so no stylesheet selector can reach it — a
   `.orolux .drift-wall { --dw-dim: .78 }` rule here computed to 0.42 and was
   silently doing nothing. The opacity is therefore raised at its real
   configuration point, the options object in oro-sections.js. The overlay is
   a plain rule and is correctly overridden here.

   Hover and focus states are untouched: their selectors carry a class each
   (0,3,0) and still outrank this (0,2,0).
   ══════════════════════════════════════════════════════════════════════════ */

.orolux .drift-wall__overlay { opacity: .24; }

/* The resting grade was also fighting the lift. Slightly less desaturation
   keeps the duotone intent while letting the plates hold their own light. */
.orolux .drift-wall__inner img,
.orolux .drift-wall__tile img {
  filter:
    saturate(.42)
    sepia(.44)
    hue-rotate(-8deg)
    brightness(1.1)
    contrast(1.06);
}

/* ═══ 2 · HEADING ORPHANS ═══════════════════════════════════════════════════

   At 1440 the section titles break badly against their measure — #closing set
   "Below this line, nothing exists" on line one and "yet." alone on line two.
   An orphan in a 60px display face is the most visible typographic fault on a
   page like this.

   text-wrap: balance evens the line lengths without a hard max-width, so it
   cannot introduce the opposite problem at a width nobody tested. It degrades
   to normal wrapping where unsupported, which is exactly today's behaviour.  */

.orox__title,
.orox__lede {
  text-wrap: balance;
}

/* Body copy wants pretty, not balance: balance is capped at a few lines in
   every engine and is the wrong tool for a paragraph. */
.orox__body,
.orox p {
  text-wrap: pretty;
}

/* ═══ 3 · THE TWO SECTIONS THAT HAD NO BACKGROUND ═══════════════════════════

   #core has its circuit plate, #tokenomics and #faq are cream, #wall has the
   drift grid, #closing has the lightfall. #architecture and #access-tiers had
   only the shared .orox::before bloom — a single gold radial at .11 alpha —
   and at 1440 they read as flat black with type sitting on it.

   Both treatments are pure CSS gradients on a ::after at z-index -1, so they
   cost one composited layer each, no image request, and no script. .orox
   already sets `isolation: isolate` and `overflow: hidden`, so nothing here
   can escape its section.
   ══════════════════════════════════════════════════════════════════════════ */

/* ── 3a · #architecture — a drafting grid ──────────────────────────────────
   The section's own copy is "Below is the shape of those connections... Every
   line on this diagram is a design. None of it is deployed." A faint technical
   grid is the one background that argues the same thing the words do.

   Masked to a soft ellipse so it never meets an edge as a hard tile boundary,
   which is what makes a CSS grid read as a texture instead of a table.        */

.orox-architecture-sc::after {
  content: "";
  position: absolute;
  inset: 0;
  z-index: -1;
  pointer-events: none;
  background-image:
    linear-gradient(to right,  var(--orop-grid) 1px, transparent 1px),
    linear-gradient(to bottom, var(--orop-grid) 1px, transparent 1px);
  background-size: 72px 72px;
  background-position: center;
  -webkit-mask-image: radial-gradient(ellipse 82% 68% at 50% 42%, #000 18%, transparent 78%);
          mask-image: radial-gradient(ellipse 82% 68% at 50% 42%, #000 18%, transparent 78%);
}

/* A second, much larger grid square underneath reads as a major/minor rule
   pair — the thing that separates drafting paper from graph paper. */
.orox-architecture-sc .orox__container::before {
  content: "";
  position: absolute;
  inset: -20% -10%;
  z-index: -1;
  pointer-events: none;
  background-image:
    linear-gradient(to right,  rgb(var(--orop-gold) / .05) 1px, transparent 1px),
    linear-gradient(to bottom, rgb(var(--orop-gold) / .05) 1px, transparent 1px);
  background-size: 288px 288px;
  -webkit-mask-image: radial-gradient(ellipse 70% 60% at 42% 40%, #000 10%, transparent 72%);
          mask-image: radial-gradient(ellipse 70% 60% at 42% 40%, #000 10%, transparent 72%);
}

/* ── 3b · #access-tiers — four rising bands ────────────────────────────────
   The section is Observe / Use / Build / Govern, four levels that widen what
   you can reach. The background says the same: four soft bands, each a little
   warmer than the one below, so the eye reads ascent before it reads the list.

   Deliberately not four hard stripes — the stops are 6-8% apart with long
   ramps between, which at this alpha is felt rather than seen.               */

.orox-access-sc::after {
  content: "";
  position: absolute;
  inset: 0;
  z-index: -1;
  pointer-events: none;
  background:
    linear-gradient(
      to top,
      transparent                        0%,
      rgb(var(--orop-bronze) / .07)     26%,
      transparent                       34%,
      rgb(var(--orop-bronze) / .09)     52%,
      transparent                       60%,
      rgb(var(--orop-gold)   / .07)     76%,
      transparent                       84%,
      rgb(var(--orop-gold)   / .085)    96%
    ),
    radial-gradient(ellipse 60% 44% at 78% 8%,
      rgb(var(--orop-spec) / .05) 0%, transparent 70%);
  -webkit-mask-image: linear-gradient(to bottom, transparent 0%, #000 12%, #000 88%, transparent 100%);
          mask-image: linear-gradient(to bottom, transparent 0%, #000 12%, #000 88%, transparent 100%);
}

/* Reduced motion is not the axis here — none of this animates — but forced
   colours is: a user who has asked the OS for a specific palette should not
   get decorative gradients painted underneath their text. */
@media (forced-colors: active) {
  .orox-architecture-sc::after,
  .orox-architecture-sc .orox__container::before,
  .orox-access-sc::after { display: none; }
}

/* ═══ 4 · THE HERO WAS HALF EMPTY ON EVERY DESKTOP ══════════════════════════

   Measured band above the first painted hero content, at scroll 0:

     360x640 - 459x812     14%     correct, leave alone
     768x1024              23%
     1024x768              41%
     1280x800              48%
     1440x900              48%
     1920x1080             42%

   The obvious diagnosis is wrong and worth writing down so nobody re-fixes it
   that way. `.hero-text-wrapper` sits at `top: 26rem`, and 1rem == 1vw here,
   so that is 26vw — which looks exactly like the rem trap. It is not. The
   offset exists to clear the dynamic island, and the island lives inside a
   phone that is itself width-scaled, so a width-proportional offset is
   correctly tracking the thing it must clear. Changing the unit would break
   the clearance at some width nobody tested.

   What is actually wrong is that both offsets overshoot. Measured at 1440x900:

     phone stage top              144px   (.hero-scale-block inset 10rem)
     island pill bottom           292px
     headline top                 430px
     -> clearance below island    138px

   138px of undifferentiated black phone-screen between the island and the
   headline. The visitor does not read that as "inside a device", they read it
   as the page not having loaded. The clearance only ever needed to be enough
   to not collide; it was tuned to a safe number and never tightened.

   So: lift the stage, and close the gap to a deliberate one. Desktop only —
   below 1024 the composition already measures 14% and is left untouched. Both
   values stay width-proportional so the island clearance still tracks.        */

@media (min-width: 1024px) {
  .hero-scale-block {
    /* was inset: 10rem 0% auto  (144px at 1440) */
    top: clamp(40px, 4.4vw, 84px);
  }

  .hero-text-wrapper {
    /* The stage and the copy are SIBLINGS, not parent and child — lifting
       .hero-scale-block moves the phone and its island but leaves the copy
       where it was, which widens the gap instead of closing it. Both have to
       come up together.

       top was 26rem (= 26vw here, 374px at 1440); margin-top was
       clamp(84px, 7vw, 108px). Together they put the headline 138px below the
       island. Held in rem so the clearance keeps tracking the island, which is
       width-scaled for the same reason. */
    top: 18rem;
    margin-top: clamp(40px, 3.4vw, 62px);
  }
}

/* The widest desktops have height to spare and were the least crowded to begin
   with; giving the stage a little back keeps the phone from riding the nav. */
@media (min-width: 1600px) {
  .hero-scale-block { top: clamp(56px, 3.6vw, 92px); }
}

/* ═══ 5 · THE ISLAND ENTRANCE PLAYED BEHIND THE LOADING PLATE ═══════════════

   .oroi-pill runs `oroi-in .9s ... both` and the check runs `oroi-tick .5s`
   at a .55s delay, both starting at first paint. The loading plate is up for
   at least MIN 520ms plus a 430ms hold plus its own fade — so the entrance is
   over, or nearly over, by the time anything is visible. The animation was
   never broken; it was finishing in a room with the lights off.

   Pausing rather than delaying is the right tool: a fixed delay would have to
   guess the loader's duration, which varies with the network — the loader
   advances on real resource entries, not a timer. play-state resumes the
   instant the plate lifts, however long that took.

   `both` fill means the paused-at-zero state is the `from` keyframe, so the
   island is correctly invisible underneath rather than sitting there finished.

   The repeat-visit path is covered too: index.html removes aria-busy
   immediately when sessionStorage says the loader has been seen, so the
   entrance simply plays at once.                                              */

html[aria-busy] .oro-island .oroi-pill,
html[aria-busy] .oro-island .oroi-check svg {
  animation-play-state: paused;
}

/* ═══ 6 · THE INSTALL PROMPT OWNED THE WHOLE SCREEN ═════════════════════════

   It was a centred modal filling the viewport on a 390px phone, and it fired
   on desktop too. Two changes:

   · oro-pwa.js now gates the offer on (pointer: coarse) — installing is a
     phone gesture, and on a mouse the browser's own omnibox affordance is the
     right surface, not a dialog over the page the visitor came to read.

   · Below 560px it becomes a bottom sheet instead of a centred card. A sheet
     is reachable by thumb, it does not hide the content behind it, and it is
     the pattern every mobile OS already taught the visitor. The card styling,
     the focus trap, Esc and the scrim are all inherited unchanged from
     oro-pwa.css — this only moves and reshapes it.                            */

@media (max-width: 560px) {
  .oroa-modal { align-items: flex-end; }

  .oroa-dialog {
    width: 100%;
    max-width: none;
    margin: 0;
    border-radius: 22px 22px 0 0;
    padding-bottom: max(22px, env(safe-area-inset-bottom));
    transform: translateY(14%);
  }

  .oroa-modal[data-open="1"] .oroa-dialog { transform: translateY(0); }

  /* A sheet needs a grab affordance or it reads as a stuck panel. */
  .oroa-dialog::after {
    content: "";
    position: absolute;
    top: 9px;
    left: 50%;
    width: 38px;
    height: 4px;
    margin-left: -19px;
    border-radius: 999px;
    background: rgb(var(--orop-gold) / .30);
  }
}

/* ═══ 7 · THE MENU BUTTON NOW CARRIES THE READ ══════════════════════════════

   It was two strokes in a 44px box. Correct, accessible, and completely mute —
   it said "menu" and nothing else, which on a 33,000px document wastes the one
   piece of persistent chrome the visitor always has in view.

   It now wears a gold ring that fills with reading progress, driven by
   --orop-read from oro-polish.js. The strokes still cross into an X on open,
   so nothing about the existing affordance is lost — the button gained a
   second job rather than trading its first one away.

   Why a conic-gradient and a mask rather than an SVG: the button is built in
   oro-mobile.js and adding a circle element there would mean editing a layer
   below this one. A pseudo-element costs nothing, needs no markup, and is
   deleted with this file.

   The ring is deliberately quiet — a 1.6px arc at 62% gold. It is a wayfinding
   cue, not a progress bar demanding to be watched.
   ══════════════════════════════════════════════════════════════════════════ */

html[data-orop-read] .orom-burger {
  position: relative;
  isolation: isolate;
}

html[data-orop-read] .orom-burger::before {
  content: "";
  position: absolute;
  z-index: -1;
  top: 50%;
  left: 50%;
  width: 34px;
  height: 34px;
  margin: -17px 0 0 -17px;
  border-radius: 50%;
  background:
    conic-gradient(
      from -90deg,
      rgb(var(--orop-gold) / .62) calc(var(--orop-read, 0) * 360deg),
      rgb(245 242 236 / .10) 0
    );
  /* hollow it into a ring: keep only the outer 1.6px band */
  -webkit-mask: radial-gradient(circle, transparent calc(50% - 1.6px), #000 calc(50% - 1.6px));
          mask: radial-gradient(circle, transparent calc(50% - 1.6px), #000 calc(50% - 1.6px));
  transition: opacity .3s ease;
}

/* Open state: the ring is about where you are in the page, and the page is
   behind the drawer. Fade it rather than leaving a stale reading. */
html[data-orop-read] .orom-burger[aria-expanded="true"]::before {
  opacity: .25;
}

/* The bar's own 1.5px progress line and this ring say the same thing twice.
   The ring is the better instrument — it is attached to the control the thumb
   is already reaching for — so the line steps back to a hairline hint. */
html[data-orop-read] .orom-bar[data-solid="1"] .orom-bar__progress { opacity: .55; }

/* The drawer's close button is the same .orom-burger class but sits inside the
   panel, where a page-progress ring is meaningless. */
html[data-orop-read] .orom-drawer .orom-burger::before { display: none; }

@media (prefers-reduced-motion: reduce) {
  html[data-orop-read] .orom-burger::before { transition: none; }
}

@media (forced-colors: active) {
  html[data-orop-read] .orom-burger::before { display: none; }
}

/* ═══ 8 · A NOTE ON MEASURING #ai, SO NOBODY REPEATS MY MISTAKE ═════════════

   A screenshot of #ai at 390 shows "Business" rendering as "Busin", and
   probing it appears to confirm a clip:

     .headline-h5        width 163px   scrollWidth 271px
     .features-card.s1   width 210px   scrollWidth 353px, overflow:hidden

   That is not a clip. Every label reports the SAME 163/271 whatever its text
   says — "Powered by AI", "Blockchain-verified", all of them — and the ratio
   is 0.601, which is the 0.6 scale on the ancestor. getBoundingClientRect()
   returns post-transform size; scrollWidth returns layout size. Comparing the
   two across a transform measures the transform, not the content.

   The cut-off word is a frame of an IX2 card choreography caught mid-move, the
   same way the hero's "grey unreadable text" turned out to be a fade at 0.35.
   Nothing here needs fixing. Scrub the section before believing a still.

   No rule follows this comment on purpose — the fix that was here was removed
   once it was shown to be treating a measurement artefact.                    */

/* ═══ 9 · THE TIER DIAL DREW ITS ARCS THROUGH ITS OWN LABEL ═════════════════

   #access-tiers stacks a 360px SVG dial and the "Threshold to enter / not set"
   caption in ONE grid cell of .orox-at-figure, so the caption is the dial's
   centre label. That composition is right. The execution collides:

     dial      box 139,513  360x360   centre (319, 693)
     caption   box 229,660  178x66    centre (318, 693)   — same point
     arcs      r = 54, 88, 122, 156

   The caption's half-diagonal is about 95px, so the r=54 and r=88 arcs are
   drawn straight through the words. At rest, "THRESHOLD TO ENTER" has a stroke
   crossing ENTER. Measured stable across the whole scroll range — unlike the
   four earlier scares on this build, this one is not an animation frame.

   The fix is the one every real gauge uses: the centre label gets a plate, and
   the rings pass behind it. Nothing moves, nothing is rescaled, and the tier
   arcs keep their authored radii — which matters, because those radii are the
   four levels and re-spacing them would change what the diagram says.

   z-index:1 on the caption is load-bearing. It makes the caption a stacking
   context so the scrim resolves against the caption rather than against the
   section, which would put it behind the SVG and achieve nothing.            */

.orox-access-sc .orox-at-thr {
  position: relative;
  z-index: 1;
}

.orox-access-sc .orox-at-thr::before {
  content: "";
  position: absolute;
  z-index: -1;
  /* asymmetric: the label is justify-items:start, so it needs more room left
     of the text than right of it to stay optically centred on the dial */
  /* generous, because the falloff needs room — a scrim that reaches full
     transparency inside the text's own box is just a dark rectangle */
  inset: -46px -62px -44px -66px;
  background:
    radial-gradient(
      ellipse 54% 50% at 46% 50%,
      rgb(9 8 7 / .90) 0%,
      rgb(9 8 7 / .78) 26%,
      rgb(9 8 7 / .44) 52%,
      rgb(9 8 7 / .16) 74%,
      rgb(9 8 7 / 0) 100%
    );
  pointer-events: none;
}

@media (forced-colors: active) {
  .orox-access-sc .orox-at-thr::before { display: none; }
}

/* ═══ 10 · THE PAGE ANSWERED THE POINTER BUT NOT THE CLICK ══════════════════

   Counted across the eleven authored stylesheets:

     :hover          103 rules
     :active           9 rules   — all of them in oro-mobile, oro-chapters
                                   and oro-pwa, i.e. touch only
     :focus-visible   34 rules

   So on a desktop the site is alive under the cursor and completely inert
   under the finger that presses. Hover says "this is a control", and then the
   click says nothing back. That gap is most of why interactions here read as
   unfinished rather than as designed — every individual state is good, but the
   sequence hover -> press -> release is missing its middle.

   WHY `scale:` AND NOT `transform: scale()`
   These elements do not share a transition contract. Measured at 1440:

     drift-wall__tile      transition: all
     a                     transition: color, transform
     orox-alloc__i         transition: opacity, transform
     summary               transition: color
     orof__status-link     transition: gap, color

   A `transform: scale()` here would overwrite the hover lift that several of
   them already animate, and a `transition:` shorthand would silently drop
   whatever properties that element was already transitioning. `scale` is an
   independent property: it composes with an existing `transform` instead of
   replacing it, so a card can lift on hover and compress on press at once.

   NO TRANSITION IS DECLARED, DELIBERATELY. Adding one would mean rewriting
   each element's transition-property list, which is exactly the clobbering
   this avoids. An instant press is also the more correct feel — the press
   should land the moment the finger does; it is the release that wants easing,
   and the elements that already transition `all` get that for free.

   Gated to fine pointers. Touch has its own :active rules already, and a
   press-scale on a phone fires during scroll momentum.
   ══════════════════════════════════════════════════════════════════════════ */

@media (hover: hover) and (pointer: fine) {
  .orox a:active,
  .orox button:active,
  .orox summary:active,
  .orof__btn:active,
  .orof__list a:active,
  .orof__status-link:active,
  .orox-step:active,
  .orox-phase:active,
  .orox-alloc__i:active,
  .orox-at-lbl:active,
  .oropw__card:active,
  .orob__tile:active,
  .oroa-btn:active,
  .drift-wall__tile:active {
    scale: .985;
  }

  /* Small controls need a smaller compression or the movement reads as a
     glitch rather than a press — 1.5% of a 24px row is a quarter of a pixel. */
  .orof__list a:active,
  .orof__status-link:active,
  .orox a:active {
    scale: .97;
  }
}

/* ═══ 11 · THE CARDS HOVERED OUT OF SYNC WITH THEMSELVES ═══════════════════

   Measured transition-duration on every interactive family at 1440:

     .orox-step / -phase / -alloc__i / -stat    0.8s
     .oropw__card                               0.45s, 0.55s
     .orof__btn / .orox a                       0.4s
     .orob__tile / summary / footer links       0.35s

   Two separate problems in that column.

   THE MISMATCH, WHICH IS THE REAL ONE. The card families inherit their
   transition from the entrance staging:

     .orox.is-ready .orox-reveal {
       transition: opacity .8s var(--orox-ease), transform .8s var(--orox-ease);
     }

   That list is opacity and transform ONLY. But the hover changes three things:

     .orox-step:hover { transform: translateY(-4px);
                        border-color: ...;
                        box-shadow: ...; }

   border-color and box-shadow are not in the transition list, so they snap
   instantly while the transform drifts for 800ms. The shadow and the border
   arrive before the card has moved. That does not read as "slow", it reads as
   broken — the card appears to light up and then, separately, float.

   THE SPREAD. 0.35s, 0.4s, 0.45s, 0.55s and 0.8s across surfaces that sit
   inside one another. Hovering across a section changes tempo for no reason
   the visitor can see.

   Both are fixed by giving the hover families one honest scale. Longhands, not
   the shorthand, so opacity keeps its 0.8s entrance value while everything the
   hover actually touches moves together at hover speed.

   is-ready is added at boot, BEFORE the GSAP entrance runs — so this 0.8s
   transform transition has also been damping every reveal, stretching an
   authored 0.8s animation toward twice that. Bringing transform to hover speed
   moves the entrance closer to what GSAP was asked for, not further away.
   ══════════════════════════════════════════════════════════════════════════ */

:root {
  --orop-t-hover: .24s;   /* anything the cursor causes            */
  --orop-t-enter: .8s;    /* the entrance, unchanged               */
}

.orox.is-ready .orox-step,
.orox.is-ready .orox-phase,
.orox.is-ready .orox-alloc__i,
.orox.is-ready .orox-stat,
.orox.is-ready .orox-at-lbl,
/* The Possibilities Wall needs both a different ancestor and more weight. It
   does not sit under a section that receives is-ready, so the scoped selectors
   above never matched it — and a bare `.oropw__card` (0,1,0) still loses to
   `.oropw [view-item].view` (0,3,0), which the reveal layer uses to time these
   same cards. Matching that weight is what actually reaches them. */
.oropw .oropw__card[view-item] {
  transition-property: opacity, transform, border-color, box-shadow, background-color, color;
  transition-duration:
    var(--orop-t-enter),
    var(--orop-t-hover),
    var(--orop-t-hover),
    var(--orop-t-hover),
    var(--orop-t-hover),
    var(--orop-t-hover);
  transition-timing-function: var(--orox-ease, cubic-bezier(.19, 1, .22, 1));
}

/* The smaller controls were already close to hover speed; pull the two
   outliers onto the same number so a pass across a section holds one tempo. */
.orof__btn,
.orox a,
.orof__list a,
.orof__status-link,
.orob__tile,
.orox summary {
  transition-duration: var(--orop-t-hover);
}

@media (prefers-reduced-motion: reduce) {
  .orox.is-ready .orox-step,
  .orox.is-ready .orox-phase,
  .orox.is-ready .orox-alloc__i,
  .orox.is-ready .orox-stat,
  .orox.is-ready .orox-at-lbl,
  .oropw__card,
  .orof__btn,
  .orox a,
  .orof__list a,
  .orof__status-link,
  .orob__tile,
  .orox summary { transition-duration: 0s; }
}

/* A press is a movement, so honour the same preference the rest of the build
   does. The states above are the only motion this layer adds to a control. */
@media (prefers-reduced-motion: reduce) {
  .orox a:active,
  .orox button:active,
  .orox summary:active,
  .orof__btn:active,
  .orof__list a:active,
  .orof__status-link:active,
  .orox-step:active,
  .orox-phase:active,
  .orox-alloc__i:active,
  .orox-at-lbl:active,
  .oropw__card:active,
  .orob__tile:active,
  .oroa-btn:active,
  .drift-wall__tile:active {
    scale: 1;
  }
}