/* Apple — a theme file. See themes/README.md for the contract.

   Loaded AFTER public/css/styles.css, so it wins on source order with no
   !important anywhere.

   ---------------------------------------------------------------------------
   LAYOUT DECISION, stated up front because the brief asked for one.

   This reads as macOS/iOS chrome: a translucent (frosted-glass) sidebar
   flush to the window's left edge, and the content pane as a rounded card
   INSET from the other three edges — the Finder/Mail/Settings.app
   arrangement the brief names directly. Both are pure CSS on the existing
   DOM (.sidebar / .topbar+.content inside .app-main): no new elements.

   The one deliberate departure from this app's own stated convention: base
   styles.css keeps the sidebar "deliberately the same in light and dark
   mode" (a fixed dark chrome). This theme does NOT do that — the sidebar
   here is a LIGHT material in light mode and a DARK material in dark mode,
   because a light sidebar is exactly what makes light-mode Finder/Mail read
   as Apple's own chrome rather than "the SCP sidebar with different link
   colours." --sidebar-* are already theme hooks for precisely this (see
   cyberpunk.css, which goes the other way and pins its sidebar dark always);
   this theme uses the same hook to do the opposite thing on purpose.

   SURFACE ELEVATION, three levels, and dark mode goes LIGHTER as it rises
   (never inverted-light-mode, which the brief calls out specifically):
     level 0 — window backdrop, behind the sidebar's blur and in the inset
               gutter around the content card. #f2f2f7 light / #000 dark.
               Custom token, --ap-window-bg: nothing here needs body-text
               contrast against it, so it never has to double as a text
               background.
     level 1 — the content card AND everything Pico calls "the page",
               because this app has exactly one page-level surface that
               real text sits on. Mapped straight onto --pico-background-
               color rather than inventing a parallel "content-bg" token,
               which is what keeps the scroll-shadow trick in styles.css
               (div[style*="overflow-x:auto"], masked with
               var(--pico-background-color)) matching the surface it
               actually fades against — #fff light / #1c1c1e dark.
     level 2 — recessed fills: form inputs, table header bands, code/
               subtotal blocks, the "grouped list" look the brief asks for.
               #f2f2f7 light (same grey as the level-0 backdrop, which is
               how iOS text fields look against a white sheet) / #2c2c2e
               dark (LIGHTER than the level-1 card, satisfying "elevated
               layers going lighter").
   Floating popovers (the Appearance panel) get their own translucent
   token rather than reusing the opaque card colour — a card elsewhere in
   this app (a Pico <article>) sits over arbitrary content and has to stay
   fully opaque to keep text legible; only a genuine floating popover gets
   vibrancy.

   SEMANTIC COLOUR IS DELIBERATELY UNTOUCHED. Every status badge, chart bar,
   stat-tile ground, flash colour, import-outcome chip and the audit-flag
   banner in styles.css is a hardcoded hex pair, not a --pico-* token, and
   every one of them already carries a measured contrast figure in that
   file's own comments. Re-tinting ~40 of those into an Apple-flavoured
   palette would mean re-deriving that whole contrast budget for no
   functional gain — the brief's instruction is "don't recolour semantic
   state into the accent", not "restyle every semantic colour to match", and
   leaving them alone is the reading that keeps overdue/available/error
   exactly as trustworthy as they are in every other theme.
   --------------------------------------------------------------------- */

:root[data-palette="apple"] {
  /* Shared regardless of light/dark: the system font stack (this is most of
     what actually reads as "Apple" — not a novelty face, but the platform's
     own sizing/weight discipline riding on top of it) and a generous but not
     full-pill corner radius. Full iOS capsule buttons were tried and
     rejected for this specific app: it is a dense desktop tool read with
     macOS conventions in mind, and macOS's own buttons are rounded-rects,
     not capsules — capsule shapes stay where this app already uses them
     (status badges, filter chips), which is honest since the theme layer
     cannot change those without re-deriving their contrast (see above). */
  --pico-font-family: -apple-system, BlinkMacSystemFont, 'SF Pro Text', 'Segoe UI', Roboto, Helvetica, Arial, sans-serif;
  --heading-font-family: -apple-system, BlinkMacSystemFont, 'SF Pro Display', 'Segoe UI', Roboto, Helvetica, Arial, sans-serif;
  /* OPTIONAL UI SOUND. Declared here, in the theme's own file, so "which themes
     have sound" is answered once — no script holds a list of theme names. Still
     off until the user turns it on in Appearance.

     The CHIME voice, not the console one. Cyberpunk's sounds are square waves and
     sawtooth sweeps that start and stop: machine noise, a device reporting. This
     theme's are sine fundamentals with one quiet octave harmonic, struck and left
     to ring — an object being touched. Confirmation is a rising perfect fifth,
     refusal a falling minor third; the intervals are what make the set read as one
     instrument rather than a pile of beeps. See public/js/uiSound.js. */
  --theme-sound: 1;
  --theme-voice: chime;

  --pico-border-radius: 0.7rem;
}

/* ------------------------------------------------------------------ Light --
   The default variant. Tokens named by ROLE first (--ap-*), then mapped onto
   Pico/sidebar tokens below them, so the mapping reads as a decision rather
   than a wall of hex. */
:root[data-palette="apple"]:not([data-theme="dark"]) {
  --ap-window-bg: #f2f2f7;
  --ap-fill: #f2f2f7;
  --ap-fill-2: #e5e5ea;
  --ap-separator: rgba(60, 60, 67, 0.29);
  --ap-separator-strong: rgba(60, 60, 67, 0.36);
  /* Translucent light material — Finder/Mail's sidebar. Alpha is low enough
     that blur does real work; see the @supports fallback further down for
     when blur isn't available. */
  --ap-sidebar-material: rgba(246, 246, 248, 0.72);
  /* The scroll-edge divider, the card's half-pixel ring, and the overlay
     scrollbar thumb. Ink on light, light on ink — a black hairline is invisible
     on a dark card, which is why these are tokens and not literals. */
  --ap-edge-line: rgba(0, 0, 0, 0.12);
  --ap-edge-shade: rgba(0, 0, 0, 0.16);
  --ap-ring: rgba(0, 0, 0, 0.08);
  --ap-scroll-thumb: rgba(0, 0, 0, 0.28);
  --ap-sidebar-hover: rgba(0, 0, 0, 0.05);
  /* The Appearance panel's own material — distinct from --pico-card-
     background-color (see the header comment on why a shared opaque card
     token can't also be a translucent popover token). */
  --ap-popover-bg: rgba(255, 255, 255, 0.82);

  --pico-background-color: #ffffff;
  --pico-color: #1d1d1f;
  --pico-muted-color: #636366;
  --pico-h1-color: #1d1d1f;
  --pico-h2-color: #1d1d1f;
  --pico-h3-color: #1d1d1f;
  --pico-h4-color: #1d1d1f;
  --pico-h5-color: #1d1d1f;
  --pico-h6-color: #1d1d1f;

  /* systemBlue. The text/link colour USED to stay the literal #007AFF, on the
     argument that ~4.0:1 on white is Apple's own real-world figure and their
     apps ship it that way. That was retired 2026-09-05: an audit measured it at
     4.02:1 against the row a link actually sits on, it was the palest link of
     the six themes, and "Apple does it too" is not a reason to ship text under
     AA in a tool someone reads all day. See --pico-primary below.
     A FILLED button background is a different case: a fixed white label
     sits on it regardless of theme, so that background is deepened one
     step for headroom rather than reusing the raw accent — same discipline
     styles.css's own stat tiles already use ("one step darker so full-white
     text clears AA"), applied to the one place this theme introduces a new
     white-on-accent surface. */
  /* Apple's own system blue is #007AFF, and on white it measures 4.02:1 — under
     AA for body text, which is what a link in a table row is. Measured
     2026-09-05: it was the palest link colour of the six themes and the only one
     that failed. Darkened one step to 5.04:1. --pico-primary-background (the
     filled-button blue) is untouched at #0066d6, and hover stays darker still,
     so hovering still darkens. Same correction, same reason, as the base theme's
     teal in backlog X11: the ink was the lever, not the paper. */
  --pico-primary: #006cdb;
  --pico-primary-background: #0066d6;
  --pico-primary-hover: #0060df;
  --pico-primary-hover-background: #0058b6;
  --pico-primary-underline: rgba(0, 122, 255, 0.4);
  --pico-primary-focus: rgba(0, 122, 255, 0.35);
  --pico-primary-inverse: #ffffff;

  /* Secondary = macOS's grey bezel button: a light fill with dark (not
     inverse-white) label text — measured 13.4:1. */
  --pico-secondary: #3a3a3c;
  --pico-secondary-background: #e5e5ea;
  --pico-secondary-hover: #1d1d1f;
  --pico-secondary-hover-background: #d1d1d6;
  --pico-secondary-focus: rgba(60, 60, 67, 0.2);
  --pico-secondary-inverse: #1d1d1f;

  --pico-mark-background-color: #ffedb0;
  --pico-mark-color: #6b5000;

  --pico-card-background-color: #ffffff;
  --pico-card-sectioning-background-color: #f2f2f7;
  --pico-card-border-color: var(--ap-separator);
  --pico-border-color: var(--ap-separator-strong);
  --pico-muted-border-color: var(--ap-separator);

  /* Inset grouped-list form fields: a tonal fill, no visible border, a
     white "lift" plus a blue ring on focus — the iOS text-field convention,
     not a bordered box. */
  --pico-form-element-background-color: var(--ap-fill);
  --pico-form-element-border-color: transparent;
  --pico-form-element-selected-background-color: var(--ap-fill-2);
  --pico-form-element-color: #1d1d1f;
  --pico-form-element-placeholder-color: #8e8e93;
  --pico-form-element-active-background-color: #ffffff;
  --pico-form-element-active-border-color: #007aff;
  --pico-form-element-focus-color: rgba(0, 122, 255, 0.35);

  --pico-table-border-color: var(--ap-separator);
  --pico-table-row-stripped-background-color: rgba(0, 0, 0, 0.02);

  --pico-code-background-color: var(--ap-fill);
  --pico-code-color: #3a3a3c;
  --pico-blockquote-border-color: #007aff;

  --pico-dropdown-background-color: #ffffff;
  --pico-dropdown-border-color: var(--ap-separator);
  --pico-dropdown-hover-background-color: var(--ap-fill);

  --pico-switch-background-color: #e5e5ea;
  --pico-switch-checked-background-color: #007aff;
  --pico-range-thumb-color: #007aff;

  /* The sidebar goes LIGHT here — see the header comment; this is the
     deliberate divergence from the base app's fixed-dark-sidebar rule. */
  --sidebar-bg: var(--ap-sidebar-material);
  --sidebar-ink: #1d1d1f;
  --sidebar-muted: #6e6e73;
  --sidebar-link: #3a3a3c;
  --sidebar-link-active: #1d1d1f;
  --sidebar-hover-bg: var(--ap-sidebar-hover);
  /* NOT the raw accent: .sidebar-nav a.active hardcodes white label text
     (styles.css), and white-on-#007AFF measures ~4.0:1 at 14px/600 weight —
     under AA at this size. Deepened until white clears AA with headroom;
     measured 5.8:1. Same value is reused in dark mode below for the same
     reason (a fixed white label doesn't get easier to read just because
     the surrounding chrome went dark). */
  --sidebar-active-bg: #0062cc;
}

/* ------------------------------------------------------------------- Dark --
   Not inverted light mode: the window backdrop is true black, and each
   surface above it gets LIGHTER as it elevates (level 0 #000 -> level 1
   #1c1c1e -> level 2 #2c2c2e), which is the opposite of how a shadow-based
   light-mode elevation system works and the exact thing the brief warned
   against skipping. The accent is brighter here on purpose (#0A84FF vs
   #007AFF) — also measured, not just asserted: #0A84FF as TEXT on the
   #1c1c1e card comes out to 4.66:1, comfortably past AA, precisely because
   Apple's dark-mode blue is tuned brighter to stay legible against dark
   surfaces. */
@media (prefers-color-scheme: dark) {
  :root[data-palette="apple"]:not([data-theme="light"]) {
    --ap-window-bg: #000000;
    --ap-fill: #2c2c2e;
    --ap-fill-2: #3a3a3c;
    --ap-separator: rgba(84, 84, 88, 0.6);
    --ap-separator-strong: rgba(84, 84, 88, 0.75);
    --ap-sidebar-material: rgba(28, 28, 30, 0.72);
    --ap-edge-line: rgba(255, 255, 255, 0.14);
    --ap-edge-shade: rgba(0, 0, 0, 0.5);
    --ap-ring: rgba(255, 255, 255, 0.09);
    --ap-scroll-thumb: rgba(255, 255, 255, 0.3);
    --ap-sidebar-hover: rgba(255, 255, 255, 0.08);
    --ap-popover-bg: rgba(44, 44, 46, 0.82);

    --pico-background-color: #1c1c1e;
    --pico-color: #f5f5f7;
    --pico-muted-color: #98989d;
    --pico-h1-color: #f5f5f7;
    --pico-h2-color: #f5f5f7;
    --pico-h3-color: #f5f5f7;
    --pico-h4-color: #f5f5f7;
    --pico-h5-color: #f5f5f7;
    --pico-h6-color: #f5f5f7;

    --pico-primary: #0a84ff;
    --pico-primary-background: #0060c9;
    --pico-primary-hover: #3fa2ff;
    --pico-primary-hover-background: #004a9e;
    --pico-primary-underline: rgba(10, 132, 255, 0.45);
    --pico-primary-focus: rgba(10, 132, 255, 0.4);
    --pico-primary-inverse: #ffffff;

    --pico-secondary: #d1d1d6;
    --pico-secondary-background: #3a3a3c;
    --pico-secondary-hover: #f5f5f7;
    --pico-secondary-hover-background: #48484a;
    --pico-secondary-focus: rgba(209, 209, 214, 0.2);
    --pico-secondary-inverse: #f5f5f7;

    --pico-mark-background-color: #4a3c00;
    --pico-mark-color: #ffe28a;

    --pico-card-background-color: #1c1c1e;
    --pico-card-sectioning-background-color: #2c2c2e;
    --pico-card-border-color: var(--ap-separator);
    --pico-border-color: var(--ap-separator-strong);
    --pico-muted-border-color: var(--ap-separator);

    --pico-form-element-background-color: var(--ap-fill);
    --pico-form-element-border-color: transparent;
    --pico-form-element-selected-background-color: var(--ap-fill-2);
    --pico-form-element-color: #f5f5f7;
    --pico-form-element-placeholder-color: #6e6e73;
    --pico-form-element-active-background-color: var(--ap-fill-2);
    --pico-form-element-active-border-color: #0a84ff;
    --pico-form-element-focus-color: rgba(10, 132, 255, 0.4);

    --pico-table-border-color: var(--ap-separator);
    --pico-table-row-stripped-background-color: rgba(255, 255, 255, 0.03);

    --pico-code-background-color: var(--ap-fill);
    --pico-code-color: #d1d1d6;
    --pico-blockquote-border-color: #0a84ff;

    --pico-dropdown-background-color: var(--ap-fill);
    --pico-dropdown-border-color: var(--ap-separator);
    --pico-dropdown-hover-background-color: var(--ap-fill-2);

    --pico-switch-background-color: #3a3a3c;
    --pico-switch-checked-background-color: #0a84ff;
    --pico-range-thumb-color: #0a84ff;

    --sidebar-bg: var(--ap-sidebar-material);
    --sidebar-ink: #f5f5f7;
    --sidebar-muted: #98989d;
    --sidebar-link: #d1d1d6;
    --sidebar-link-active: #f5f5f7;
    --sidebar-hover-bg: var(--ap-sidebar-hover);
    --sidebar-active-bg: #0062cc;
  }
}

/* The explicit-toggle half of the same pair — identical values, required
   because :root[data-theme="dark"] and the prefers-color-scheme block above
   have to agree independently (a user can force dark on a light-OS machine
   and vice versa). */
:root[data-palette="apple"][data-theme="dark"] {
  --ap-window-bg: #000000;
  --ap-fill: #2c2c2e;
  --ap-fill-2: #3a3a3c;
  --ap-separator: rgba(84, 84, 88, 0.6);
  --ap-separator-strong: rgba(84, 84, 88, 0.75);
  --ap-sidebar-material: rgba(28, 28, 30, 0.72);
  --ap-edge-line: rgba(255, 255, 255, 0.14);
  --ap-edge-shade: rgba(0, 0, 0, 0.5);
  --ap-ring: rgba(255, 255, 255, 0.09);
  --ap-scroll-thumb: rgba(255, 255, 255, 0.3);
  --ap-sidebar-hover: rgba(255, 255, 255, 0.08);
  --ap-popover-bg: rgba(44, 44, 46, 0.82);

  --pico-background-color: #1c1c1e;
  --pico-color: #f5f5f7;
  --pico-muted-color: #98989d;
  --pico-h1-color: #f5f5f7;
  --pico-h2-color: #f5f5f7;
  --pico-h3-color: #f5f5f7;
  --pico-h4-color: #f5f5f7;
  --pico-h5-color: #f5f5f7;
  --pico-h6-color: #f5f5f7;

  --pico-primary: #0a84ff;
  --pico-primary-background: #0060c9;
  --pico-primary-hover: #3fa2ff;
  --pico-primary-hover-background: #004a9e;
  --pico-primary-underline: rgba(10, 132, 255, 0.45);
  --pico-primary-focus: rgba(10, 132, 255, 0.4);
  --pico-primary-inverse: #ffffff;

  --pico-secondary: #d1d1d6;
  --pico-secondary-background: #3a3a3c;
  --pico-secondary-hover: #f5f5f7;
  --pico-secondary-hover-background: #48484a;
  --pico-secondary-focus: rgba(209, 209, 214, 0.2);
  --pico-secondary-inverse: #f5f5f7;

  --pico-mark-background-color: #4a3c00;
  --pico-mark-color: #ffe28a;

  --pico-card-background-color: #1c1c1e;
  --pico-card-sectioning-background-color: #2c2c2e;
  --pico-card-border-color: var(--ap-separator);
  --pico-border-color: var(--ap-separator-strong);
  --pico-muted-border-color: var(--ap-separator);

  --pico-form-element-background-color: var(--ap-fill);
  --pico-form-element-border-color: transparent;
  --pico-form-element-selected-background-color: var(--ap-fill-2);
  --pico-form-element-color: #f5f5f7;
  --pico-form-element-placeholder-color: #6e6e73;
  --pico-form-element-active-background-color: var(--ap-fill-2);
  --pico-form-element-active-border-color: #0a84ff;
  --pico-form-element-focus-color: rgba(10, 132, 255, 0.4);

  --pico-table-border-color: var(--ap-separator);
  --pico-table-row-stripped-background-color: rgba(255, 255, 255, 0.03);

  --pico-code-background-color: var(--ap-fill);
  --pico-code-color: #d1d1d6;
  --pico-blockquote-border-color: #0a84ff;

  --pico-dropdown-background-color: var(--ap-fill);
  --pico-dropdown-border-color: var(--ap-separator);
  --pico-dropdown-hover-background-color: var(--ap-fill-2);

  --pico-switch-background-color: #3a3a3c;
  --pico-switch-checked-background-color: #0a84ff;
  --pico-range-thumb-color: #0a84ff;

  --sidebar-bg: var(--ap-sidebar-material);
  --sidebar-ink: #f5f5f7;
  --sidebar-muted: #98989d;
  --sidebar-link: #d1d1d6;
  --sidebar-link-active: #f5f5f7;
  --sidebar-hover-bg: var(--ap-sidebar-hover);
  --sidebar-active-bg: #0062cc;
}

/* --------------------------------------------------------- Headings -------
   Slightly negative tracking at heading sizes, the way SF Pro Display is
   drawn — a small thing, but it's part of what makes headings read as
   "Apple" rather than just "a different font-family value". */
:root[data-palette="apple"] h1,
:root[data-palette="apple"] h2,
:root[data-palette="apple"] h3 {
  letter-spacing: -0.01em;
}

/* ------------------------------------------------------------- Focus -------
   A dedicated rule rather than relying on Pico's per-control focus styling:
   this fires on every focusable element, in both variants, using whichever
   --pico-primary the active variant defines above. */
:root[data-palette="apple"] :focus-visible {
  outline: 2px solid var(--pico-primary);
  outline-offset: 2px;
}

/* ----------------------------------------------------- The app shell ------
   .app-shell is the flex row (.sidebar + .app-main) from styles.css. Giving
   it the level-0 window colour is what the sidebar's blur reveals, and what
   shows in the gutter around the inset content card below. */
:root[data-palette="apple"] .app-shell {
  background: var(--ap-window-bg);
}

/* Sidebar: translucent material, flush to the window's left edge (Finder's
   own arrangement — only the CONTENT pane is inset, not the sidebar).

   THE BLUR IS ON A ::before PSEUDO-ELEMENT, NOT ON .sidebar ITSELF, and this
   is load-bearing, not a style preference. `backdrop-filter` (like
   `transform`/`filter`) creates a new containing block for any
   `position:fixed` DESCENDANT — and the Appearance panel is exactly that
   descendant (.appearance lives inside .sidebar-footer, inside .sidebar).
   Measured: with backdrop-filter on .sidebar directly, the panel stopped
   being positioned against the viewport at all and was clipped by the
   sidebar's own overflow instead — the precise failure themes/README.md
   warns about, self-inflicted. (That overflow has since moved to
   .sidebar-scroll to fix the WebKit clipping bug, so the clip half of that
   measurement no longer applies — but the CONTAINING-BLOCK half does, and it
   is the reason this rule exists. Do not move the blur back.) A
   pseudo-element can carry
   its own backdrop-filter without making its PARENT a containing block, so
   the blur lives there instead, sized to the sidebar with `inset:0` and
   pushed behind the real content with a negative z-index (safe: .sidebar's
   `position:sticky` already makes it a stacking context, so -1 stays
   contained inside it rather than falling behind unrelated page content). */
:root[data-palette="apple"] .sidebar {
  border-right: 1px solid var(--ap-separator);
  isolation: isolate;
}

:root[data-palette="apple"] .sidebar::before {
  content: '';
  position: absolute;
  inset: 0;
  z-index: -1;
  background: var(--sidebar-bg);
  backdrop-filter: blur(24px) saturate(180%);
  -webkit-backdrop-filter: blur(24px) saturate(180%);
  pointer-events: none;
}

/* The sticky footer needs its own backdrop so the scrolling nav links don't
   show through it (same reason styles.css gives it one at all) — but it
   must NOT get its own backdrop-filter, for the same containing-block
   reason as .sidebar above (.appearance is a DIRECT child of this element).
   A near-opaque flat fill sitting just above the already-blurred sidebar
   reads close enough to continuous material; the alternative (a filtered
   footer) breaks the one popover this sidebar contains. */
:root[data-palette="apple"]:not([data-theme="dark"]) .sidebar-footer {
  background: #f6f6f8;
}
:root[data-palette="apple"][data-theme="dark"] .sidebar-footer,
html[data-palette="apple"]:not([data-theme="light"]) .sidebar-footer {
  background: #1c1c1e;
}
@media (prefers-color-scheme: dark) {
  :root[data-palette="apple"]:not([data-theme="light"]) .sidebar-footer {
    background: #1c1c1e;
  }
}

/* Content: the rounded card inset from the window's top/right/bottom edges
   (no left inset — it sits flush against the sidebar's own hairline, the
   same "sidebar and content share one seam" arrangement Mail/Notes use).
   HEIGHT + overflow-y is what makes this a genuinely independent scrolling
   pane rather than a coloured box that grows past the viewport with its
   content — .sidebar is already `position:sticky; height:100vh`, which only
   reads as a real app shell if the pane beside it also stays exactly one
   viewport tall.

   NOT `overflow: hidden` on .app-main. That was the first draft, and it
   clips any Pico `details.dropdown` popover (the reports "Export" menu, the
   column chooser) the moment it would render past the card's edge — the
   exact same containing-block-adjacent clipping mistake as the sidebar
   blur, just via overflow instead of a filter. The rounded-card look is
   achieved by rounding .topbar's top corners and .content's bottom corners
   individually instead, so nothing needs to clip to look right. The
   .content pane's OWN overflow-y:auto still clips a popover that would
   render below ITS visible bottom edge — that is an unavoidable cost of a
   genuinely independent scroll pane (the same trade-off .sidebar already
   accepts for its own overflow-y:auto) and not something this rule
   introduces. */
:root[data-palette="apple"] .app-main {
  margin: 0.75rem 0.75rem 0.75rem 0;
  height: calc(100vh - 1.5rem);
  border-radius: 1rem;
  background: var(--pico-background-color);
  /* Three layers, which is what a macOS panel actually is and why a single
     drop shadow always reads as "web card" instead: a hairline ring that
     defines the edge (the platform's half-pixel stroke — 0 0 0 0.5px, not a
     border, so it costs no layout), a tight contact shadow just under the
     edge, and one wide soft shadow carrying the elevation. */
  box-shadow:
    0 0 0 0.5px var(--ap-ring),
    0 1px 2px rgba(0, 0, 0, 0.06),
    0 10px 30px rgba(0, 0, 0, 0.1);
}

:root[data-palette="apple"] .topbar {
  flex-shrink: 0;
  border-top-left-radius: 1rem;
  border-top-right-radius: 1rem;
}

:root[data-palette="apple"] .content.container {
  flex: 1;
  /* The flexbox min-height:0 gotcha: without this, a flex child cannot
     shrink below its content's natural height, so overflow-y:auto would
     never actually engage and the pane would grow instead of scrolling. */
  min-height: 0;
  overflow-y: auto;
  border-bottom-left-radius: 1rem;
  border-bottom-right-radius: 1rem;
  /* styles.css caps .content.container at max-width:1400px for every theme —
     harmless everywhere else, because in every OTHER theme the document
     itself owns the scrollbar, so content simply sits centred with plain
     background to either side of it, off past the window's true edge where
     nobody is looking for a scroll affordance. HERE this element owns its
     OWN scrollbar (the whole point of the inset card), so the cap makes the
     scrollbar stop at 1400px and leaves the rest of the card's width as a
     dead strip of plain white between the table and the card's rounded edge
     — measured on a 1768px-wide window: a 77px gap of nothing, with the
     scrollbar sitting in the middle of it, nowhere near either the table or
     the card. That is the "scrollbar detached from the window" report,
     confirmed pixel-for-pixel from a real screenshot, and it is a direct
     consequence of this theme being the only one where this cap is visible
     at all. The card IS the content pane in this theme, so it should use
     the whole card, the same way Mail/Notes' content pane does. */
  max-width: none;

  /* THE SCROLL-EDGE EFFECT, and it is the reason this theme is allowed to keep
     its own scroll pane at all. Decided by the maintainer 2026-09-05: every
     other theme scrolls the page (backlog X12), Apple is the exception, "but
     then make sure that it looks really good — just follow Apple's design
     philosophy on it".
     Apple's philosophy here is specific and old: in a macOS window the toolbar
     is flush and seamless while the content is at rest, and gains a hairline
     divider the moment content slides beneath it. Mail, Notes, Settings and
     Finder all do it. It is the detail that makes a toolbar read as a fixed
     surface the content passes UNDER rather than a bar stuck to the top of a
     page — and it is only expressible because this pane owns its own scroll.
     The exception earns itself.
     Done with container scroll-state queries (below), so there is no scroll
     listener, no JavaScript at all, and nothing for the CSP to care about. */
  container-type: scroll-state;
}

/* The divider itself: the scroller's own ::before, made sticky so it rides the
   top of the scrollport. `height: 1px` with `margin-bottom: -1px` means it
   occupies no layout space — the content does not shift by a pixel when it
   appears. z-index 3 puts it above the sticky table header (which sits at 2),
   so a frozen thead slides under the divider rather than over it. */
:root[data-palette="apple"] .content.container::before {
  content: "";
  position: sticky;
  top: 0;
  z-index: 3;
  display: block;
  height: 1px;
  margin-bottom: -1px;
  background: var(--ap-edge-line);
  box-shadow: 0 5px 10px -6px var(--ap-edge-shade);
  opacity: 0;
  transition: opacity 180ms ease;
}

/* Only once there is content above the fold — i.e. the user has actually
   scrolled. At rest the card is seamless, which is the whole point. */
@container scroll-state(scrollable: top) {
  :root[data-palette="apple"] .content.container::before {
    opacity: 1;
  }
}

/* The transition is decoration; the divider is information. Reduced motion
   keeps the information and drops the fade. */
@media (prefers-reduced-motion: reduce) {
  :root[data-palette="apple"] .content.container::before {
    transition: none;
  }
}

/* macOS overlay scrollbars: thin, rounded, translucent ink on no track. The
   platform's own scrollbar is not a chrome-coloured gutter, it is a mark on the
   content — so the track is transparent and the thumb is the page's ink at low
   alpha. `scrollbar-width`/`scrollbar-color` are the standard properties and
   need no -webkit- pseudo-element ladder. */
:root[data-palette="apple"] .content.container,
:root[data-palette="apple"] .sidebar-scroll {
  scrollbar-width: thin;
  scrollbar-color: var(--ap-scroll-thumb) transparent;
}

/* .content.container above is meant to be the ONLY scrolling region in this
   layout on desktop — that is the whole point of giving it a fixed-height
   ancestor. Without this rule, a stray pixel of rounding is enough to break
   that: .sidebar's `height:100vh` and .app-main's `height:calc(100vh -
   1.5rem)` PLUS its own 0.75rem top+bottom margins are two independent
   calculations that are each rounded to the nearest device pixel, and at
   some window widths/zoom levels those roundings don't cancel — the
   document's natural content height ends up a hair taller than the
   viewport. The result is a second, genuine scrollbar rendered flush to the
   actual browser window edge, sitting beside (not replacing) the inset
   card's own scrollbar a few pixels inboard of it — reported as the page
   scrollbar "detaching from the window", which is a fair description: on
   every other theme the page's one scrollbar IS the window's own, and here
   it visibly is not. `overflow:hidden` on `body` (not on .app-main, which
   themes/README.md already covers) removes the possibility outright rather
   than chasing the specific rounding case, since nothing in this layout
   ever intentionally needs the document itself to scroll on desktop.
   Reverted below for the mobile layout (which deliberately IS the page's
   only scroll, same as every other theme) and for print (which must lay
   out the full, unclipped page). */
:root[data-palette="apple"] body {
  overflow: hidden;
}

/* Printing (a report, a funder-facing table) must see the FULL content, not
   one screen's worth clipped by the fixed-height scroll pane above — this
   undoes the inset-card treatment for paper only. */
@media print {
  :root[data-palette="apple"] .app-main {
    height: auto;
    overflow: visible;
    margin: 0;
    border-radius: 0;
    box-shadow: none;
  }
  :root[data-palette="apple"] .content.container {
    overflow-y: visible;
  }
  :root[data-palette="apple"] body {
    overflow: visible;
  }
}

/* Below the app's one narrow breakpoint the sidebar is already an off-canvas
   drawer (styles.css: position:fixed, transform-based). A floating card with
   its own 100vh scroll pane makes no sense once the sidebar isn't a fixed
   column beside it any more, so this reverts to plain document flow —
   exactly what every other theme already gets on a phone. */
@media (max-width: 768px) {
  :root[data-palette="apple"] .app-main {
    margin: 0;
    height: auto;
    border-radius: 0;
    box-shadow: none;
    overflow: visible;
  }
  :root[data-palette="apple"] .content.container {
    overflow-y: visible;
    min-height: auto;
  }
  :root[data-palette="apple"] body {
    overflow: visible;
  }
}

/* backdrop-filter has ~96% support but is not universal (and headless
   Chrome under automation can render inconsistently), so the material still
   has to be legible with no blur at all: closer to opaque, and a touch more
   contrast so the hairline border alone still separates it from the page. */
@supports not ((backdrop-filter: blur(1px)) or (-webkit-backdrop-filter: blur(1px))) {
  :root[data-palette="apple"]:not([data-theme="dark"]) .sidebar::before {
    background: #f6f6f8;
  }
  :root[data-palette="apple"][data-theme="dark"] .sidebar::before,
  html[data-palette="apple"]:not([data-theme="light"]) .sidebar::before {
    background: #1c1c1e;
  }
  :root[data-palette="apple"] .appearance-panel {
    background: var(--pico-card-background-color);
  }
}

/* Vibrancy is a decorative effect, not information — reduced-transparency
   users get the same layout with the blur/alpha turned off instead of a
   different one. Targets the ::before pseudo-element, not .sidebar itself —
   see the containing-block comment above .sidebar::before for why the real
   element can never carry backdrop-filter here. */
@media (prefers-reduced-transparency: reduce) {
  :root[data-palette="apple"] .sidebar::before {
    backdrop-filter: none;
    -webkit-backdrop-filter: none;
  }
  :root[data-palette="apple"]:not([data-theme="dark"]) .sidebar::before {
    background: #f6f6f8;
  }
  :root[data-palette="apple"][data-theme="dark"] .sidebar::before,
  html[data-palette="apple"]:not([data-theme="light"]) .sidebar::before {
    background: #1c1c1e;
  }
  :root[data-palette="apple"] .appearance-panel {
    backdrop-filter: none;
    -webkit-backdrop-filter: none;
    background: var(--pico-card-background-color);
  }
}

/* --------------------------------------------------- Grouped-list tables --
   border-collapse:separate is required for a table's own border-radius to
   render at all (collapse ignores it outright) — only the BOTTOM edge of
   each cell gets a rule, so switching away from collapse cannot double up
   borders on adjacent cells. thead gets the level-2 recessed-fill tone, the
   same tone a grouped list's section header uses on iOS. */
:root[data-palette="apple"] table {
  border-collapse: separate;
  border-spacing: 0;
  border: 1px solid var(--ap-separator);
  border-radius: 0.85rem;
  overflow: hidden;
}

:root[data-palette="apple"] table td,
:root[data-palette="apple"] table th {
  border-bottom: 1px solid var(--ap-separator);
}

:root[data-palette="apple"] table tr:last-child > td,
:root[data-palette="apple"] table tr:last-child > th {
  border-bottom: none;
}

:root[data-palette="apple"] table thead th {
  background: var(--ap-fill);
  font-weight: 600;
}

/* -------------------------------------------------- iOS-style switches ----
   Base styles.css only ever recolours the THUMB on :checked (see
   .theme-switch-thumb's rule) — the track stays --sidebar-hover-bg/
   --pico-secondary-background regardless of state. That reads as a slider,
   not a switch; the defining trait of an iOS switch is the TRACK filling
   with colour when on. Added here as new rules layered on the existing
   classes (no styles.css edit, no new markup) rather than by fighting the
   base rule's specificity. */
:root[data-palette="apple"] .theme-switch input:checked ~ .theme-switch-track,
:root[data-palette="apple"] .theme-switch-page input:checked ~ .theme-switch-track {
  background: var(--pico-primary);
}

:root[data-palette="apple"] .theme-switch-thumb {
  box-shadow: 0 1px 3px rgba(0, 0, 0, 0.25);
}

:root[data-palette="apple"] .theme-switch input:checked ~ .theme-switch-track .theme-switch-thumb,
:root[data-palette="apple"] .theme-switch-page input:checked ~ .theme-switch-track .theme-switch-thumb {
  background: #ffffff;
}

/* ------------------------------------------------- Appearance popup -------
   COLOUR AND MATERIAL ONLY. The control's structure — position, sizing, the
   fixed panel, the marker removal, the responsive block, the page variant's
   placement — lives once in packages/hub-chrome/public/css/chrome.css (backlog
   T1, resolved 2026-09-02). Until then this file carried a full scoped copy of
   cyberpunk.css's unscoped structure, because the base stylesheet had nothing
   for the component and selecting Apple would otherwise have left it a bare
   <details>/<summary>; that copy is what T1 removed. Nothing structural may
   return here — the chrome package's test/structure.test.js refuses it — and
   the same constraints still bind the panel (position: fixed; nothing between
   it and the viewport may scroll or establish a containing block; see
   themes/README.md and the .sidebar-scroll comment in the Asset Manager's
   styles.css). What is left is what makes it Apple's. */

/* The trigger takes the drawer's slightly rounder corner. */
:root[data-palette="apple"] .appearance-trigger {
  border-radius: 0.55rem;
}

/* A real macOS popover: its own translucent material (see --ap-popover-bg
   in the header comment for why this isn't --pico-card-background-color),
   a hairline border standing in for the platform's popover stroke, and a
   soft two-layer shadow rather than one hard drop shadow. */
:root[data-palette="apple"] .appearance-panel {
  border: 1px solid var(--ap-separator);
  border-radius: 1rem;
  background: var(--ap-popover-bg);
  backdrop-filter: blur(20px) saturate(180%);
  -webkit-backdrop-filter: blur(20px) saturate(180%);
  box-shadow: 0 12px 32px rgba(0, 0, 0, 0.18), 0 2px 8px rgba(0, 0, 0, 0.1);
}

/* Apple's tighter caption tracking (the base is 0.07em). */
:root[data-palette="apple"] .appearance-field-label {
  letter-spacing: 0.05em;
}

/* ---------------------------------------------------- attention tiles -------
   The five dashboard attention tiles kept the base theme's warm palette, which
   on a clean Apple sheet reads as a mistake: SCP's amber is #7f5d09, an olive
   brown, and it looked pasted in. (Measured before this block: the tile
   background computed to rgb(127,93,9) under this theme.)

   SEMANTIC MEANING IS UNCHANGED — salmon still means "a problem", amber "soon",
   teal "in flight", quiet "nothing to do". Only the mixture moves, onto Apple's
   own system colours, and NOT onto the theme's blue accent: a tile whose colour
   means "on brand" instead of "this needs you" has stopped carrying information,
   which is the entire job of the attention row.

   TINTED FILLS RATHER THAN SATURATED BLOCKS, because that is the actual iOS
   idiom — a low-opacity wash of the system colour with the colour itself as the
   text, the way a Badge or a filled Label is drawn. It also solves the contrast
   problem that saturated blocks create: coloured text on a light tint clears AA
   comfortably, whereas white text on systemOrange does not. */
:root[data-palette="apple"] .stat-tile-salmon {
  /* Opaque, pre-mixed from systemRed at 12% over the card white. rgba() would
     leave the real contrast dependent on whatever surface happens to be behind
     the tile, which is both unmeasurable in isolation and liable to change. */
  background: #ffebe9;
  border: 1px solid #ffd0cc;
  color: #a1160d;
}

:root[data-palette="apple"] .stat-tile-amber {
  background: #fff0db;
  border: 1px solid #ffdcae;
  color: #8a4b00;
}

:root[data-palette="apple"] .stat-tile-teal {
  background: #e6f6f9;
  border: 1px solid #bde6ee;
  color: #0b5c6b;
}

:root[data-palette="apple"] .stat-tile-quiet {
  color: var(--pico-muted-color);
}

/* The figure and caption take the tile's own hue rather than the accent, or the
   colour carrying urgency stops being visible exactly where it matters. */
:root[data-palette="apple"] .stat-tile-salmon .stat-tile-value,
:root[data-palette="apple"] .stat-tile-amber .stat-tile-value,
:root[data-palette="apple"] .stat-tile-teal .stat-tile-value {
  color: inherit;
}

:root[data-palette="apple"] .stat-tile-salmon .stat-tile-label,
:root[data-palette="apple"] .stat-tile-amber .stat-tile-label,
:root[data-palette="apple"] .stat-tile-teal .stat-tile-label,
:root[data-palette="apple"] .stat-tile-salmon .stat-tile-caveat,
:root[data-palette="apple"] .stat-tile-amber .stat-tile-caveat,
:root[data-palette="apple"] .stat-tile-teal .stat-tile-caveat {
  color: inherit;
  opacity: 0.78;
}

/* Dark mode uses the brighter dark-variant system colours (Apple publishes a
   separate set — systemOrange is #FF9F0A dark against #FF9500 light) and a
   stronger tint, because a 12% wash disappears on a near-black ground. */
:root[data-palette="apple"][data-theme="dark"] .stat-tile-salmon {
  background: #45211f;
  border-color: #6b2f2b;
  color: #ff9c94;
}

:root[data-palette="apple"][data-theme="dark"] .stat-tile-amber {
  background: #453419;
  border-color: #6b4f1f;
  color: #ffc978;
}

:root[data-palette="apple"][data-theme="dark"] .stat-tile-teal {
  background: #17383f;
  border-color: #235761;
  color: #8fdff0;
}