@tailwind base;
@tailwind components;
@tailwind utilities;

/* =========================================================
   MANROPE — the app's typeface. Decided 2026-08-13 by Spencer with Toncy and Ed, over Source Sans 3,
   Public Sans, IBM Plex Sans and Atkinson Hyperlegible (all five compared at the product's real
   strings and real sizes). Recorded as D9 in `akashic-docs/_CLAUDE/2026-08-12-design-direction.md`.

   📌 THIS CLOSES A DEFECT RATHER THAN ADDING A DEPENDENCY. The font stack below has named "Manrope"
   first for a long time and nothing ever loaded it, so every screen has silently rendered in
   `system-ui` — Segoe UI on Windows, San Francisco on iPhone, Roboto on Android. Three typefaces,
   three sets of metrics, none of them chosen.

   🚨 SELF-HOSTED, NEVER A CDN. A font CDN is a third-party request from a page that renders PHI and
   it defeats the isolation work outright. This is the latin subset only — VARIABLE, so one 24.3 KB
   file covers weights 400–800 rather than five static files.
   ⚠️ Latin only: it drops Cyrillic, Greek and Vietnamese. Correct for this market today, and a
   decision to revisit if the product is ever localised.

   `font-display: swap` so text paints immediately in the fallback and never blocks on the font.

   🔧 The URL is rewritten by webpack at build time — wp-scripts has a first-class rule for woff2
   (`asset/resource` → `fonts/[name].[hash:8][ext]`) and its `clean` step explicitly preserves
   `^fonts/`, so no config change was needed. ⛔ Do not "helpfully" inline this as a data URI: a
   separate file is cacheable across releases, where the stylesheet is not.

   📏 HOW MUCH WIDER, MEASURED PROPERLY — it is a DISTRIBUTION, not a number. Across 48 samples
   (eight real app strings × six size/weight pairs, DOM, inside the mount, against this very stack
   minus Manrope): aggregate 3.4%, median 3.8%, range −2.2% to +11%. Manrope is NARROWER than the
   system face on some strings. ⛔ Do not quote a single percentage from one string — two earlier
   figures (19.9%, then 10.6%) were each one string's ratio, and both overstated the typical case.
   🔬 And do not measure it in canvas `measureText`: a control against a deliberately NONEXISTENT
   family returned the IDENTICAL width as `ui-sans-serif`, so canvas never resolved the system stack
   at all — it was comparing Manrope to its own default fallback.

   ✅ THE RELAYOUT WAS WALKED SIGNED-IN AND IT IS ESSENTIALLY NIL. Sixteen staff surfaces at 1280 and
   1024 with real data — organization, staff directory, schedules, invoices, audit events, the
   patient chart's six tabs, the portaled Encounter Details dialog, the practitioner queue — each
   measured twice on the SAME nodes, once shipped and once with this stack's fallback forced over the
   mount. Whole-surface line totals: 204→203, 85→85, 74→74. ONE cosmetic 1→2 line wrap in the lot.
   ⭐ THE INSTRUMENT LESSON: a per-string width ratio never predicted this. Line counts do not move
   linearly with glyph width — a string only re-wraps if the extra width crosses its container edge,
   and almost none did. The whole-surface line delta is the instrument; the ratio is trivia.
   ⛔ A green build still does not mean it fits — the walk is what said so.
   ========================================================= */
@font-face {
  font-family: 'Manrope';
  font-style: normal;
  /* 🚨 THE RANGE MUST MATCH THE FILE, AND IT DID NOT. This said `400 800` while the subsetted file
     carries the full 200-800 wght axis. A variable face CLAMPS a requested weight into the declared
     range, so every `font-weight: 300` in the app silently rendered at 400 - a no-op with no error,
     no warning and nothing in the build to catch it. It was invisible on this dev box because the
     Twenty Twenty-Five theme injects its OWN Manrope declared 200 800, and that face (declared later,
     same family) was shadowing ours: our face measured `unloaded` in the browser while the theme's
     did the rendering. On a practice site with any other theme, ours is the only Manrope and 300
     would have quietly become 400.
     ⭐ MEASURED, not assumed: loading our own build/fonts/Manrope-latin.woff2 under a 1-1000
     declaration and instancing the axis gives 359.5 / 366.4 / 373.2 / 380.1 / 393.8px for the same
     string at 200 / 300 / 400 / 500 / 700 - five distinct widths, so the file interpolates for real
     below 400 and nothing here is synthesised. */
  font-weight: 200 800;
  font-display: swap;
  src: url('./fonts/Manrope-latin.woff2') format('woff2');
}

/* =========================================================
   1. AKASHIC APP CONTAINMENT (CRITICAL)
   Everything should stay inside the app root so we:
   - block WordPress/theme/plugin bleed into the app
   - prevent app styles from leaking back out
   ========================================================= */

#akashic-health-records-patient-portal-root {
  box-sizing: border-box;
  width: 100%;
  max-width: 100%;
  margin: 0;
  padding: 0;
  /* NOTE: intentionally NOT `isolation: isolate` here. Isolating the root creates a stacking context that TRAPS
     #akashic-overlay-root's z-index inside the plugin's own layer, so a host WordPress theme's positioned nav/menu
     (or the WP admin bar) bleeds THROUGH our modals/sheets. The overlay-root only holds portalled modals (it is
     empty when nothing is open), so letting its high z-index compete at the document level is safe and is what
     makes a modal actually cover the theme chrome. */
  text-align: left;
  /* 🗣️ Spencer, 2026-09-09: *"Your letter-spacing is too tight as well, just gives an outdated
     newspaper 2005 website feel. Add just a little bit of letter spacing."* 0.01em -> 0.02em.
     ⭐ IT PAIRS WITH THE WEIGHT DROP ABOVE AND IS NOT AN INDEPENDENT TASTE CALL. Lighter strokes
     need more room around them: at 300 the letterforms are thinner, so the counters and gaps that
     used to be held open by the stroke itself have to be held open by tracking instead. Tightening
     this back up without also putting the weight back is what would return the 2005 feel. */
  letter-spacing: 0.02em;
  font-family:
    "Manrope",
    system-ui,
    -apple-system,
    BlinkMacSystemFont,
    "Segoe UI",
    Roboto,
    "Helvetica Neue",
    Arial,
    sans-serif;
  font-size: 15px;
  line-height: 1.45;
  /* Base text color + inheritable-text defaults, so the host theme's typography can't bleed into any text we
     don't explicitly class (card 035 / AHR-64 / AHR-217). These are INHERITED defaults: elements with their own
     rule keep it — headings/labels via utilities, <strong>/<b>/<pre> via Tailwind preflight — so nothing semantic
     is clobbered and app utility classes still win. In particular this makes the existing `a { color: inherit }`
     resolve to our --foreground instead of the theme's link color. Theme rules that DIRECTLY target an element
     (e.g. `.theme-content p{}`) still bleed; the categorical fix for those is Shadow DOM (card 036). */
  /* 🚨 THE GROUND, AND IT WAS DECLARED FOR MONTHS WITHOUT EVER BEING PAINTED. `--paper` and
     `--background` were both defined as #faf9f7 on this element and NOTHING applied either one:
     measured in the browser 2026-09-09, the mount computed `rgb(255, 255, 255)` and a sweep of every
     stylesheet for a rule setting `background` on this selector returned nothing at all. The portal
     was rendering on the host WordPress theme's white body.
     ⛔ THIS IS THE LOAD-BEARING HALF OF THE SURFACE SCALE, not decoration. `--surface` is #ffffff
     and its own comment says cards "sit ABOVE the paper, so they stay pure"; `--sunken` means
     recessed relative to this; `--ak-card-lift` is a shadow tuned against it. With the ground
     rendering pure white, a white card had nothing to sit above - which is why the portal read flat
     and why the summary tiles depended entirely on their borders to exist.
     ⭐ The value needed no change. Spencer walked a ladder from #EDEDE3 (rejected as too dark)
     up through #F6F5EF, #F8F7F3, #F9F8F4 and #F9F8F5, and landed back on this token: at that
     lightness the separation comes from the cards being pure white, not from the ground's shade, and
     the three lightest candidates were within 3/255 of each other. The design system's own number
     was right all along. */
  background: var(--background);
  color: var(--foreground);
  font-weight: var(--ak-body-weight);
  font-style: normal;
  text-transform: none;
  word-spacing: normal;
  white-space: normal;

  /* ── THE TYPE SCALE. Ruled app-wide by Spencer 2026-08-13, WIDENED 2026-09-07 ────────────────────────
     🔒 TWELVE TEXT STEPS: 9 · 10 · 10.5 · 11 · 11.5 · 12 · 12.5 · 13 · 14 · 15 · 17 · 18,
     and TWO DISPLAY STEPS above them (24, 42) for a number that IS the screen. Patient portal AND staff
     portal — ⚠️ this selector is NOT "the patient portal": all five mounts render the same element id
     (main.tsx says so at the mount), so a rule written here lands on staff and wp-admin too.
     ⛔ Reuse a step. Do NOT invent a neighbour half a pixel away, and do NOT hardcode a literal to dodge
     a missing step — that is what this block exists to make unnecessary.

     🔻 16px and 20px ARE RETIRED as values. 14px is NOT any more: it was retired on 2026-08-13, and
     the patient-portal deck - refined and frozen three weeks later - draws it sixteen times. This file
     already carried one 14px written with a literal fallback beside the token name, which is a fallback
     somebody added BECAUSE the token was missing. The six t-shirt names below survive as the ramp
     everything already consumes, repointed onto real steps, so no call site had to change.

     🔑 WHY THE RULING MOVED RATHER THAN THE DECK. The eight-size ruling predates by three weeks the
     deck it is measured against. Across the thirty patient-portal decks the product draws 13px 1,148
     times, 15px 345 times, and - the fact that settles it - 11px 312 times, which the ruling did not
     contain at all. 12.5px is the navigation and secondary-control size; 10.5px and 14px carry real
     work. A ruling that omits the third most used size in the deck it governs is not a scale being
     violated. It is a scale that was measured too early.

     ⛔ STILL FOLD, do not add: 13.5 to 13 (half a pixel nobody can see), 20 to 18, and 16 stays
     retired. 14.5, 16.5, 25 and 21 appear ONLY in the mockup's own annotation prose and page headings,
     never inside a drawn screen - a first count read those as product and put the deck at ten sizes,
     which is the same error as counting comments as code. SVG text inside icon artwork is out of
     scope entirely, as it already was for the 7.6px nodes.

     🚨 THE ONE VISIBLE CONSEQUENCE, stated rather than buried: with body fixed at 15 the ruled scale has
     only TWO steps above it (17, 18) while the heading ramp has THREE levels (h1 · h2–h4 · h5–h6). Three
     into two does not go, so `--ak-font-md` (h5/h6) lands ON body size and is distinguished by WEIGHT
     alone — h5/h6 were only ever 1px above body, which was never a real step. That is forced by the
     ruled scale, not a preference; if Spencer wants h5/h6 visibly larger, the scale needs a step
     between 15 and 17 and that is his call, not a literal sprinkled at a call site. */
  --ak-font-9: 9px;
  --ak-font-10: 10px;
  --ak-font-10-5: 10.5px;  /* the smallest label that is not 10 - a section-head count, a tag */
  --ak-font-11: 11px;      /* 🔑 THE ONE THE RULING WAS MISSING. 312 uses in the reviewed deck: the
                              meta line under a name, a workspace label, the "none" in an empty row. */
  --ak-font-11-5: 11.5px;   /* ⛔ NOT a rounding error. The summary VALUE sits directly beneath its own
                               LABEL (12px) inside one box, so here the half-pixel IS the hierarchy.
                               🔑 The test is never "are these within 0.5px" — it is "do these two ever
                               appear TOGETHER?" Sizes that never meet may share a value. */
  --ak-font-12: 12px;
  --ak-font-12-5: 12.5px;  /* navigation rows and secondary controls - a side-nav item, a search or
                              density button. It is the size a navigation label is drawn at. */
  --ak-font-13: 13px;
  --ak-font-14: 14px;      /* a value that wants reading before its neighbours without becoming a
                              heading - a record value, a step's own label, a preference name. */
  --ak-font-15: 15px;
  --ak-font-17: 17px;
  --ak-font-18: 18px;
  --ak-font-20: 20px;

  /* DISPLAY, above the text scale. ⚠️ These two are for a NUMBER THAT IS THE POINT OF THE SCREEN -
     a result value with its unit beside it, a large view title. They are not a heading ramp and they
     are not available to body text; reaching for one to make a paragraph louder is the misuse. */
  --ak-font-24: 24px;
  --ak-font-42: 42px;

  /* The consumed ramp, every name now pointing AT a step above. */
  --ak-font-xs: var(--ak-font-12);     /* was 13 — `small`, `.text-xs`, select labels */
  --ak-font-sm: var(--ak-font-13);     /* was 14 (RETIRED) — `.text-sm` and `.btn`; this is also the
                                          13px Spencer ruled for the staff portal, and `.text-sm` is
                                          written 1,018 times, so this one line is what moves them. */
  --ak-font-base: var(--ak-font-15);   /* unchanged — p / li / label, the ordinary body size */
  --ak-font-md: var(--ak-font-15);     /* was 16 (RETIRED) — see the three-into-two note above */
  --ak-font-lg: var(--ak-font-17);     /* was 18 — h2 / h3 / h4 */
  --ak-font-xl: var(--ak-font-18);     /* was 20 (RETIRED) — h1, now the top of the scale */
  --ak-line-tight: 1.2;
  --ak-line-base: 1.45;
  /* ── THE WEIGHT SCALE. Ruled by Spencer 2026-09-09, walking the patient portal ──────────────────
     🗣️ *"Much of the font is just too bold I think and adding to the newspaper stark feel. Regular
     font should be 300 and bold font should be 400 and light font should be 100."*

     ⛔ THE WHOLE SCALE COMES DOWN, NOT THE HEADINGS ALONE. A newspaper is uniform dark type at one
     heavy weight; dropping only the headings would have left 400 body copy carrying the same feel.
     Regular 400 -> 300 and heading 700 -> 400 is a four-step drop at the top and one at the bottom,
     which is what takes the density out without touching a single colour or the ground.

     🚨 LIGHT IS 200 AND NOT THE 100 THAT WAS ASKED FOR, because 100 does not exist in the file.
     Manrope's wght axis floors at 200: measured on our own build/fonts/Manrope-latin.woff2 under a
     1-1000 declaration, the same string renders 357.70px at each of 100, 150 and 200 and only starts
     moving at 250 (360.99) and 300 (364.33). A request for 100 is clamped to 200 and renders
     identically, so 200 is written here to say what actually happens rather than to record an
     intention the font cannot honour. ⚠️ Going genuinely lighter than 200 means shipping a
     different font file, not changing this number.

     📌 LABEL SITS AT 350, WHICH IS A REAL WEIGHT ON A VARIABLE AXIS. With bold capped at 400, a
     label at 400 would be indistinguishable from a heading and the middle of the scale would be
     gone. 350 keeps a label separable from 300 body copy while staying under the 400 ceiling. The
     same reasoning puts `.font-medium` at 350 in the utility block further down. */
  --ak-heading-weight: 400;
  --ak-body-weight: 300;
  --ak-label-weight: 350;

  --ak-field-height: 42px;
  /* 🚨 CARD 263 E6 / card 261 B65 — the floor for a field that holds PROSE, not a value.
     ⭐ 84px is not a new number: `.ahr-patient-notes__textarea` has used it since patient notes shipped.
     Somebody already decided ~4 lines plus a resize grip was right for writing in; it was simply never
     generalised, so every other multi-line field in the product opened at the SINGLE-LINE height. */
  --ak-prose-field-height: 84px;
  --ak-field-radius: var(--ak-control-radius);
  --ak-field-padding-x: 14px;
  --ak-field-font-size: 15px;
  --ak-field-line-height: 18px;

  /* Card 235 — these track --primary so any WordPress chrome still rendering in the app
     (CheckboxControl, FormTokenField) shows the SAME blue as everything else. The darker
     ramp keeps WordPress's own HSL lightness deltas: -6.1% and -13.1%. */
  --wp-admin-theme-color: #2f6fa5;
  --wp-admin-theme-color-darker-10: #285f8d;
  --wp-admin-theme-color-darker-20: #204c71;
  --wp-admin-border-width-focus: 2px;
  --wp-block-border-radius: 2px;

  /* =========================================================
     Card 271 (D8) — THE WARM NEUTRAL RAMP. Settled with Spencer on the agreed mockups
     (`akashic-docs/_CLAUDE/2026-08-12-ui-direction-mockups.html`, locked in
     `2026-08-12-design-direction.md` §1d D8). These are DECISIONS, not proposals.

     WHY warm and not cool, in Spencer's words: "we don't want to make it 'feel' cold and
     depressing. Staff spend their entire days in the system." Pure white + neutral grey + one
     blue is the sterile look — it reads as medical equipment rather than somewhere a person
     sits for eight hours. Calm comes from SPACE and CONSISTENCY, never from desaturation.

     ⛔ NEVER a pure grey next to the saturated blue — an unmixed #888 reads dirty. Every neutral
        here carries the same slightly warm cast, which is the whole point of the ramp.
     ⛔ Warmth applies to SURFACES, never to text. Body copy stays at full strength.

     🚨 NAMING TRAP — the one thing to not get wrong. The mockup calls its muted TEXT colour
        `--muted`, but `--muted` ALREADY EXISTS below as shadcn's near-white SURFACE, consumed by
        `bg-muted` in 538 places across 144 files and mapped into Tailwind by the `@theme inline`
        block in section 8. Defining the mockup's value under that name would turn every one of
        those backgrounds dark, on every screen, with nothing erroring. The warm text tone is
        therefore `--ink-muted`, and the ramp is mapped onto the shadcn tokens BY MEANING below.
     ========================================================= */
  --paper: #faf9f7;         /* the page ground — a barely-off-white with a warm undertone */
  --surface: #ffffff;       /* raised: cards and popovers sit ABOVE the paper, so they stay pure */
  --sunken: #efece6;        /* recessed: inset wells, table stripes, disabled fields */
  --line: #e5e0d8;          /* the standard border */
  --scrim: rgba(31, 26, 20, 0.38); /* behind an overlay; warm, never black (mockup standard) */
  --sheet-radius: 14px;     /* the top corners of a phone sheet (mockup standard) */
  --sheet-lift: 0 -8px 40px rgba(31, 26, 20, 0.3); /* a phone sheet's upward shadow (mockup standard) */
  /* Measured off the approved patient-portal deck rather than invented. Spencer, 2026-09-08:
     "Card style box shadow like in the mockup is missing." An offset shadow rather than a
     centred blur - the deck's cards sit ON the paper with the light from the top left, which
     is what makes a square card read as a card at all once the corner radius is gone. */
  /* LIGHTER THAN THE DECK'S OWN VALUE, on purpose. The deck draws 2px 2px 3px at .1 alpha and
     its cards are 620px wide; ours run to 1030, so the same shadow follows two-thirds more edge
     and reads heavier on screen than it does in the drawing. Spencer, 2026-09-08, after seeing
     both: "the lighter is what we want." Chosen against the rendered page, not the source. */
  --ak-card-lift: 2px 2px 3px rgba(31, 26, 20, 0.1);    /* the lift under every card (mockup .lcard) */
  --ak-card-radius: 0;
  --ak-card-pad: 12px 14px;
  --ak-card-list-pad: 8px 12px;
  --ak-switch-width: 34px;
  --ak-switch-height: 19px;
  --ak-switch-thumb: 15px;
  --ak-progress-height: 6px;
  --ak-popup-radius: 8px;
  --panel-radius: 12px;
  --panel-lift: 0 16px 44px rgba(31, 26, 20, 0.32);
  --ak-list-gap: 4px;
  --ak-control-radius: 2px;
  --ak-avatar-md: 34px;
  --ak-avatar-sm: 22px;
  --ak-mark-md: 30px;
  --ak-mark-sm: 20px;
  /* 🔻 THE CONTENT COLUMN, declared ONCE. Spencer, 2026-09-08: "Now I have a very wide margin
     on the right side of the screen." At 1920 the header band ran edge to edge while everything
     below it was capped and centred, so the phone number sat 240px further right than any content
     under it and the page looked lopsided rather than wide. The number lived in three separate
     rules; a header that does not know the body's width is how that happens. */
  /* NO CAP. 1440 was the deck's number and it was tried on a real screen twice: at 1500 it left
     219px a side and at 1920 it left 240, and both times the answer was the same - "big margins on
     both sides". The window's own edge is the column now, with the shell's 16px padding as the only
     gutter. ⚠️ The consequence, written down rather than discovered later: on a very wide monitor
     the queue keeps growing and a task line gets long. The reference column stays pinned at 380, so
     it is only ever the queue that absorbs the extra. */
  --ak-content-max: none;                               /* every row of the portal shares this */
  --line-soft: #f0ede7;     /* a border or hover tint that should barely register */
  /* 🔻 REVISED 2026-08-13 (Spencer, reviewing the patient-home mockup) — was #232323 / #14161a.
     "Anywhere we're using black font we should use a dark gray shade instead of pure black, since
     it's just too abrupt and makes the app feel dated."
     ⛔ These are a small step OFF black, NOT a step toward mid-grey. Spencer tried #666–#888 and
     disliked all of them, correctly: those are SECONDARY-text values — that is --ink-muted's job —
     and using them for body copy drops contrast toward the floor and reads washed out rather than
     soft. 10.2:1 and 15.2:1 on --paper, so nothing is given up on legibility. */
  --ink: #423d36;           /* body copy; the mockup standard's value */
  --ink-strong: #24211d;    /* headings */
  --ink-muted: #6c665c;     /* secondary text. 5.40:1 on --paper — passes AA for normal text,
                               and it is BETTER than the pure grey it replaces, which measured
                               ~4.2:1 and was quietly under the floor. */
  --faint: #948f85;         /* 🚨 3.06:1 on --paper — AA for LARGE text and UI borders ONLY.
                               ⛔ Never use --faint for body copy; that is a real AA failure. */

  --radius: 0.625rem;
  /* Card 271 — the shadcn surface/text tokens now READ the warm ramp. Mapped by meaning, which is
     why --muted (a surface) takes --sunken while --muted-foreground (text) takes --ink-muted.
     No call site changes: everything already consuming these tokens warms up automatically. */
  --background: var(--paper);
  --foreground: var(--ink);
  --card: var(--surface);
  --card-foreground: var(--ink);
  --popover: var(--surface);
  --popover-foreground: var(--ink);

  /* Card 235 — THE brand blue, sampled from assets/logo.png: #2f6fa5 is the mark and the
     "AKASHIC" wordmark (25,289px). The app previously used var(--primary), which is the logo's
     lighter "HEALTH RECORDS" subtitle AND, byte-identical, WordPress's --wp-admin-theme-color.
     5.33:1 against white — passes WCAG AA for normal text.

     🚨 CHANGE IT HERE AND NOWHERE ELSE. --primary-rgb carries the raw channels so every
     translucent variant derives from the same source: write `rgb(var(--primary-rgb) / 0.9)`,
     NEVER a literal `rgba(47, 111, 165, 0.9)`. Card 235 found 40 sites across 4 stylesheets
     that had silently forked from this token — 29 translucent `rgba(60,115,166,a)`, 6 plain
     hex, 4 `var(--primary, #3c73a6)` fallbacks and 1 inside an SVG data URI. A hardcoded
     alpha variant does not follow the token, so the base recolours and every hover state
     stays the old blue. */
  --primary-rgb: 47 111 165;
  --primary: rgb(var(--primary-rgb));
  --primary-foreground: #ffffff;

  /* REPOINTED 2026-09-07 onto the warm ramp. This was shadcn's default, an OKLCH cool grey at hue
     285, and `text-secondary` resolves through it in 103 FILES - so a blue-purple grey was the
     secondary text colour across most of the app, inside a ramp whose ink steps are all R>G>B.
     It survived two full sweeps for hardcoded colour because it has no `#` in it; only measuring a
     rendered element found it.
     --ink-muted is the same semantic stated warm: "secondary text, 5.40:1 on --paper, passes AA".
     Pointing at the TOKEN rather than its value is what makes it follow the dark theme for free. */
  --secondary: var(--ink-muted);
  /* AND THE LABEL MOVES WITH THE GROUND. This pair is what a Badge or a Button of the secondary
     variant paints itself with, and it was already failing before this change: shadcn's dark
     `--secondary` under shadcn's dark `--secondary-foreground` measured 2.32:1, which is a chip
     whose own text is not readable on it. Pointing the label at --paper puts the opposite end of
     the ramp on a mid-value ground - 5.40:1 in light, 6.73:1 in dark - and does it by following
     the theme rather than by remembering a literal per component. */
  --secondary-foreground: var(--paper);
  /* Card 271 — ⚠️ READ THE NAMING TRAP AT THE TOP OF THIS BLOCK BEFORE CHANGING EITHER OF THESE.
     `--muted` is a SURFACE (bg-muted) and `--muted-foreground` is TEXT. Swapping them inverts 538
     usages across 144 files.

     🔻 CORRECTED: --muted took --sunken and that was the wrong SURFACE. The token split is right —
     surface vs text — but --sunken is documented above as "recessed: inset wells, table stripes,
     disabled fields", i.e. SMALL things. The app shell uses `bg-muted` for the PAGE CANVAS: measured
     live, one `div.bg-muted` paints 905x900px. A recessed-well tone stretched that far stops reading
     as warmth and reads as dinge — Spencer flagged it as "an odd gray/beige background all over".
     ⭐ The canvas is --paper's job; the name says so ("the page ground"), and --background already
     takes it, so this also makes the two agree instead of quietly disagreeing.
     ⚠️ Consequence to accept deliberately: a chip or skeleton that used `bg-muted` for a subtle inset
     is now near-invisible against a white card. That is the RIGHT direction to err — those want
     `--sunken` named explicitly, and too-light is a smaller sin than a whole app looking soiled. */
  --muted: var(--paper);
  --muted-foreground: var(--ink-muted);
  --accent: var(--line-soft);
  --accent-foreground: var(--ink-strong);
  /* 🔻 ALIASED TO --danger 2026-09-09. This was shadcn's stock oklch red and it was a SECOND red
     living beside ours: `--destructive` drives the shadcn slots (button variant, aria-invalid rings,
     the destructive text utilities) while `--danger` drives our own button classes and notices, so
     the same "this is dangerous" idea rendered as two different colours depending on which layer
     drew it. Softening only one of them would have made that split visible for the first time.
     Pointing it at the token means one red, one place to change it. */
  --destructive: var(--danger);
  --border: var(--line);
  --input: var(--line);
  --ring: oklch(0.708 0 0);

  /* Card 235 — the ramp moved DOWN one step for accessibility, not for taste. The old base
     #16a34a (Tailwind green-600) measures 3.30:1 against white text, under WCAG AA's 4.5:1
     floor, and it carries white text on every Save/Submit button in the app. #15803d — which
     was already sitting here as the hover shade — is 5.02:1. No new colour was introduced. */
  /* ── THE GREEN IS SAGE NOW. Spencer, 2026-09-09 ────────────────────────────────────────────────
     🗣️ *"I'm not so sure that we shouldn't do make our green buttons sage also"*, alongside the red
     going to indianred. This was Tailwind green-600 #15803d - a saturated flat green that was the
     last loud fill on the page once the reds and the ground had softened.

     🚨 IT IS `--sage-deep`, NOT `--sage`, AND THE REASON IS THE LABEL ON TOP OF IT. A filled button
     carries WHITE text, so the fill has to clear 4.5:1 against white rather than against the paper.
     `--sage` #8a9475 is 3.19:1 under white and would have put an unreadable label on every green
     button in the app; #6b7a58 is 4.62:1. The old green measured 5.02:1, so this gives up a little
     headroom and still clears AA - checked rather than assumed, because "softer" and "still legible
     under a white label" pull against each other and this is where they meet.
     📌 Hover and active step down the same hue, 5.72:1 and 6.71:1, so both interaction states get
     MORE contrast rather than less - which is the right direction for a control being pressed. */
  /* 🔻 IT IS THE LIGHT SAGE, and it carries white text with a STROKE rather than being darkened.
     🗣️ Spencer, 2026-09-09: *"Sage looked fine before with white text in it without using the darker
     version. What you can do is use the regular sage we had before and just add a stroke with the
     darker sage to the white text in it."* This sat at #6b7a58 for exactly one build - my choice, to
     get white to 4.5:1 the arithmetic way - and it read as a different, darker green than the sage he
     picked, which was the whole objection.
     ⚠️ THE HONEST CAVEAT, ON RECORD: a stroke is not part of how contrast ratio is computed. WCAG
     compares two flat colours, so white on #8a9475 measures 3.19:1 to any automated checker no matter
     how legible the outlined glyph actually is. The outline genuinely helps a reader and will not
     help an audit. Spencer chose this with that stated; it is a deliberate call, not an oversight.
     📌 Hover and active step down the same hue rather than jumping to a different one, so a pressed
     button darkens without changing colour. */
  --success: #8a9475;
  --success-hover: #7e8a69;
  --success-active: #6b7a58;
  /* SAGE AS TEXT NEEDS THE DEEP END, and this is a fourth sage value, not a redefinition. A fill
     carries white on top of it and text sits on a tint, which are opposite ends of the ramp.
     --success is 3.19:1 on paper and 2.64:1 on --green-soft, both under the 4.5 floor for body
     copy. --sage-ink is 5.44:1 on paper and 4.73:1 on --green-soft. --success does not move. */
  --sage-ink: #5c6b4e;
  /* ── THE RED. Ruled by Spencer 2026-09-09: *"make our standard red indianred so it's not so
     bright and in your face."* ────────────────────────────────────────────────────────────────────
     🚨 IT IS A DEEPENED INDIANRED, NOT CSS `indianred`, AND THE DIFFERENCE IS AN ACCESSIBILITY
     FLOOR RATHER THAN A PREFERENCE. Our red has TWO jobs and has to clear 4.5:1 in both
     directions, which is unusual and is what catches people out:
       ① as TEXT on the paper ground - "N items need attention", inline error copy;
       ② as a BUTTON FILL under a WHITE label - the destructive button.
     Measured on #faf9f7: `indianred` #cd5c5c is 3.78:1 as text and 3.98:1 under white, so it fails
     AA at BOTH jobs - the delete button's own label would have been the worst offender. #b94b4b is
     4.79:1 and 5.03:1, clears both, and is visually almost indistinguishable from #cd5c5c while
     being obviously softer than the red-600 it replaces (4.59:1 / 4.83:1).
     ⛔ Do not "correct" this to the CSS keyword. A red that fails under its own white label is a
     regression dressed as fidelity to a colour name. If a softer red is wanted, the fill and the
     text need to become two different tokens first, because one value cannot go lighter and keep
     both jobs.
     📌 Hover and active are the same hue stepped down, keeping the family internally consistent the
     way --success does above. */
  --danger: #b94b4b;
  --danger-hover: #a64343;
  --danger-active: #933b3b;
  /* ── SAGE. A fourth hue, chosen by Spencer 2026-09-09 ──────────────────────────────────────────
     🗣️ *"I think I like the sage, at least it adds some color that's not blue amber or black."*
     That sentence is the whole reason it exists: the portal had exactly three hues - primary blue,
     warning amber, danger red - and every other mark on the page was a step of warm near-black. So
     a heading had no colour available to it that was not already carrying a MEANING. Blue says
     "this acts", amber says "notice this", red says "this is dangerous"; a title needs to say none
     of those. Sage is the first colour here with no state attached to it.
     🚨 IT IS ONLY LEGAL ON LARGE TEXT. 3.04:1 on --paper, which clears the 3:1 large-text floor and
     fails the 4.5:1 normal-text one. ⛔ Never put it on body copy, a label, or an icon that carries
     meaning on its own - it is an overlay-title colour and the rule below is deliberately the only
     consumer. Anything smaller needs a deeper green (about #5d7359 reaches 4.5:1). */
  --sage: #8a9475;
  /* 🚨 THE SECOND SAGE, AND IT EXISTS BECAUSE ONE VALUE CANNOT DO BOTH JOBS. `--sage` above is
     3.04:1 on paper: legal for large text and for a glyph, and NOT legal under a white label -
     white on it is 3.19:1. The moment sage had to FILL something carrying white text (the header's
     unread count) a deeper value was forced. This is 4.62:1 under white and reads as the same hue.
     ⚖️ THE SPLIT IS BY ROLE, NOT BY TASTE, so it stays legible as a pair: `--sage` for INK on the
     paper - overlay titles, icons; `--sage-deep` for a SURFACE that carries white on top of it.
     ⛔ Do not collapse them. Using --sage-deep for the overlay title darkens the title Spencer
     settled on; using --sage as a fill makes the numeral on it unreadable. */
  --sage-deep: #6b7a58;
  /* The lift under a bare glyph. ⚠️ `drop-shadow`, not `box-shadow`: these icons sit on buttons with
     no fill, so a box shadow would outline a rectangle that is not there. It follows the stroked
     path instead. 🔻 Spencer tried 2px/40% and sent it back - *"I don't like it increased"* - so
     1px/1.5px/28% is the ruled value and the heavier one is on record as rejected. */
  --ak-icon-lift: drop-shadow(0 1px 1.5px rgba(31, 26, 20, 0.28));
  /* Card 132 — the two <Notice> statuses that had no token. `--warning` follows the family already
     here (`--success` #16a34a is Tailwind green-600, `--danger` #dc2626 is red-600), so amber-600.
     `--info` deliberately ALIASES the app's own primary blue rather than introducing a second blue:
     an informational banner reading in the app's blue is the coherent choice, and keeping it a named
     token means it can diverge later without hunting down call sites. */
  /* Card 235 — amber-600 #d97706 was 3.19:1 against white, under the AA floor, same class of
     defect as --success above. amber-700 #b45309 is 5.02:1. */
  --warning: #b45309;
  /* THE ASSISTANT'S MARK, AND IT IS DELIBERATELY NOT `--warning`. Spencer approved this exact amber
     for the assistant on 2026-08-26, from the mockup decks, alongside the question-bubble glyph.
     ⛔ IT IS FOR AN ICON AND MUST NEVER BE USED FOR TEXT. That is the whole reason it is a separate
     token rather than a second opinion about `--warning`: the note above is right that #d97706 is
     3.19:1 on white and fails the 4.5:1 floor for body text. A mark is a non-text UI component,
     where the floor is 3:1 (WCAG 1.4.11), and 3.19:1 clears it. Borrowing `--warning` for the mark
     is what made it look like those two decisions disagreed; they never did — they are about two
     different things. */
  --assistant-mark: #d97706;
  --info: var(--primary);

  /* Card 271 (D8/D7) — the SOFT tint for each role colour, from the same agreed mockups. A soft
     tint is the low-priority form of a role, never a new role: `--blue-soft` behind blue text still
     means "opens something", it just is not shouting. ⛔ Do NOT introduce a soft tint for a role
     that does not already exist — the roles are fixed at blue opens / green commits / red destroys.
     📌 Only --blue-soft has a consumer today (`.btn-blue-tonal` below). The other three are landed
     because the mockup records them and the alert-toast card is explicitly waiting on these values;
     they are values, not usage. */
  /* 🔻 2026-09-09 - was #e8f0f7. 🗣️ Spencer: *"I've never liked that softblue we use to be honest"*,
     and after the palette softened it was the one tint still reading as a pale sky blue against a
     warm ground. Shown four candidates on the header's Messages button and he chose this one - a
     desaturated slate that keeps the blue family without the sky. */
  --blue-soft: #e7ebef;

  /* THE HAIRLINE THAT GOES WITH THE TINT, and it arrives late because nothing needed it until
     a tinted PANEL did. A tonal BUTTON fills and draws no edge, so --blue-soft alone was enough
     for it; a panel sitting on --paper needs its own boundary or the tint just fogs the ground.
     Taken verbatim from the patient-portal deck, which carries the whole -line family beside the
     -soft one for exactly this reason, and named to match --amber-line, which is already here. */
  --blue-line: #bcd6ec;

  /* THE FOUR CATEGORY COLOURS, taken verbatim from the patient portal - the deck Spencer has
     reviewed - and ruled by him on 2026-08-31: a card's coloured edge takes its CATEGORY colour,
     and category means KIND, never status. Cool inside a warm ramp on purpose: their whole job is
     to be told apart from each other, and warming them toward the ground would undo that. */
  /* ── THE FOUR ITEM KINDS, BROUGHT ONTO THE PALETTE 2026-09-09 ─────────────────────────────────
     🗣️ Spencer: *"your icon colors in the needs attention cards need to be brought in line with our
     new color palette"*, then *"our success green, warning red, etc all need to be set to our new
     palette versions."* These were purple-800, blue-700, teal-700 and indigo-700 with Tailwind's
     100-step tints. Purple, indigo and teal are not colours this product has - they came off a
     drawing and survived every palette pass because nothing connects a raw Tailwind hex to a token.

     🚨 THE TEXT VALUES ARE THE DEEP END OF EACH HUE, NOT THE BUTTON VALUE, AND THAT IS THE WHOLE
     TRAP HERE. These are chip colours: small text sitting on their OWN tint, so each pair has to
     clear 4.5:1 against the other. A hue cannot serve both jobs - `--success` #6b7a58 is chosen to
     carry WHITE on top of it, and the same value as TEXT on a sage tint is only 3.81:1. Measured
     pairs, each against the tint on the line below it: task 4.82, message 5.39, payment 5.65,
     appointment 4.73. ⛔ Do not "unify" a --cat- value with the button token of the same colour;
     they sit at opposite ends of the ramp on purpose, and the failure is unreadable chip text.

     📌 A TASK IS NEUTRAL INK, deliberately - four kinds share one list and every row already carries
     an amber deadline, so a fourth hue competed with the urgency signal instead of adding to it.
     ⚠️ `--cat-task` has eight consumers outside the queue (chips in the FHIR display components),
     so this is where those stop being purple. */
  --cat-task: var(--ink-muted);
  --cat-task-soft: var(--sunken);
  --cat-message: #2a6291;
  --cat-message-soft: var(--blue-soft);
  --cat-payment: #9c4708;
  --cat-payment-soft: var(--amber-soft);
  --cat-appointment: #5c6b4e;
  --cat-appointment-soft: var(--green-soft);
  /* The soft tints follow their own hue's new value: sage rather than mint, indianred rather than
     pink. Amber is unchanged - Spencer kept the amber buttons as they were. */
  --green-soft: #eef0e9;
  --amber-soft: #fdf0e3;
  --red-soft: #f7eceb;
  /* The deck's edges for a green or red tinted badge. */
  --green-line: #d5dacd;
  --red-line: #e3c3c1;

  /* THE AMBER BUTTON'S OWN THREE, taken value for value from `mockups/_standard.css` rather than
     mixed here - amber is the one variant the standard paints TINTED, so it needs a fill and an ink
     of its own where blue, green and red reuse `--primary`, `--success` and `--danger`. The two
     hover/active steps are this file's, following the same darkening the other solids use. */
  --amber-fill: #f7dcb4;
  --amber-fill-hover: #f2d0a0;
  --amber-fill-active: #ecc48c;
  --amber-ink: #5c3d0b;
  --amber-line: #e8c9a0;
  /* The deck's In progress ink. */
  --amber-link: #8a5a10;

  --chart-1: oklch(0.646 0.222 41.116);
  --chart-2: oklch(0.6 0.118 184.704);
  --chart-3: oklch(0.398 0.07 227.392);
  --chart-4: oklch(0.828 0.189 84.429);
  --chart-5: oklch(0.769 0.188 70.08);

  /* Card 271 — the sidebar rides the same ramp so it cannot drift cool while the content warms.
     Only the surface/border/text roles are repointed; --sidebar-primary stays as it is, because
     it is an active-item FILL and the ramp does not specify one. */
  --sidebar: var(--paper);
  --sidebar-foreground: var(--ink);
  --sidebar-primary: oklch(0.205 0 0);
  --sidebar-primary-foreground: oklch(0.985 0 0);
  --sidebar-accent: var(--line-soft);
  --sidebar-accent-foreground: var(--ink-strong);
  --sidebar-border: var(--line);
  --sidebar-ring: oklch(0.708 0 0);

  /* The patient drawer, approved 2026-08-28 (navigation deck, skin s5). Dark and square, and only
     ever the patient's menu - the staff rail keeps the light --sidebar roles above. Tokens rather
     than hexes in the rules below so the ramp stays in one place. */
  --patient-nav: #36332f;                     /* the patient drawer's own dark ground */
  --patient-nav-foreground: #d8d3cc;          /* an ordinary row in the patient drawer */
  --patient-nav-selected: #45413b;            /* the row you are on: a lift in the same grey, not a different material */
  --patient-nav-selected-foreground: #f3efe9; /* text on the row you are on */
  --patient-nav-child-foreground: #a9a39a;    /* a child row, quieter than its parent */
  --patient-nav-accent: #dda44e;              /* the drawer's warm accent: sign out, and a count on a row */
  --patient-nav-header-from: #3480c6;         /* top of the profile card gradient at the head of the drawer */
  --patient-nav-header-to: #1f4f7d;           /* bottom of that gradient */
}

#akashic-health-records-patient-portal-root *,
#akashic-health-records-patient-portal-root *::before,
#akashic-health-records-patient-portal-root *::after {
  box-sizing: inherit;
}

/* 🎨 THE ASSISTANT'S MARK — ONE RULE, ONE PLACE TO CHANGE IT.
   Spencer, 2026-08-27: *"dont use an inline style you have to replicate everywhere. make it a css
   class or id rule. its easier to change from one place that way!"* The control renders at three
   sites; this is the only place its colour is stated.

   🔑 WHY A PLAIN CLASS IS ENOUGH HERE, when `!text-warning` needed the `!` to survive. That utility
   was on the BUTTON, competing head-on with `#…-root button { color: var(--foreground) }` — a real
   declaration at (1,0,1) against a utility at (0,1,0). This class sits on the ICON, where the button
   rule reaches it only by INHERITANCE, and any direct declaration beats an inherited value whatever
   the specificity. It also keeps working for the portaled crumb-row trigger, which may render
   outside the root entirely.

   ⛔ Do not "simplify" this to `text-warning`. That token is `#b45309` and belongs to TEXT; this mark
   is `#d97706`, and the two are different decisions about different things — see the note beside
   `--assistant-mark`. */
.assistant-mark {
  color: var(--assistant-mark);
}

/* =========================================================
   🚨 THE INHERIT CHAIN ABOVE BREAKS AT <details> — CARD 286
   =========================================================
   📏 MEASURED IN A BROWSER, on this stylesheet, not reasoned about. The practitioner's "Later today"
   queue row rendered `10:30 AM` **16.3px outside its own card**, and the card clips: it read *"10:30 A"*.

   🔑 THE CAUSE IS THIS FILE, three rules up. `box-sizing: inherit` resolves through the FLAT tree, and a
   `<details>` renders its non-summary children through a UA-generated content box. Inheritance passes
   through that box — which carries the UA default `content-box` — so **everything inside any `<details>`
   computes to content-box while the rest of the app is border-box.**
   ⇒ The queue row's `w-full` (`width: 100%`) then ADDED its 14px+14px padding and 3px border on top of
   100%, making the row **31px wider than the card that contains it**.

   🔬 CONTROL, run in the same page: the identical `<ul><li>` markup OUTSIDE a `<details>` computes to
   **border-box**. `<details>` is the discriminator, not lists and not the queue.
   📊 With this rule: row width 349.7px → 318.9px, and the time moves from **+16.3px outside** the card to
   **−14.6px inside** it.

   ⛔ IT IS NOT THE TYPEFACE. Measured on both faces before and after Manrope: the overflow is 16.3px
   either way, because the grid column's position does not move with glyph width.

   ⚠️ WHY THIS AND NOT `box-sizing: border-box` ON `*`: `inherit` is deliberate — it lets a subtree opt
   into content-box where a third-party widget needs it. Flipping the universal rule would take that away
   from every embedded control at once. This restores the chain exactly where the flat tree breaks it.

   🩻 AND WHY NOTHING CAUGHT IT: the time element's own `scrollWidth - clientWidth` is **0** — it is sized
   correctly and reports itself as fine. The clipping is done by an ancestor three levels up, so every
   overflow probe that asks an element about itself returns green
   ⇒ [[reference-css-defects-that-pass-every-check]] · [[feedback-ui-walk-must-look-at-screenshots]] */
#akashic-health-records-patient-portal-root details > *:not(summary) {
  box-sizing: border-box;
}

/* Dark theme tokens if .dark is applied on the root or inside it.
   ⚠️ Card 271 — DORMANT: nothing in `src/` ever applies `.dark`, and there is no
   `prefers-color-scheme` rule anywhere, so this block is unreachable in the product today. The warm
   ramp is landed here anyway because the same approved mockup records the dark values, and a ramp
   that exists in only one theme is how a later "consistency pass" reintroduces the cool greys.

   🚨 WHOEVER TURNS DARK MODE ON: A FILL IS NOT AN ACCENT. Do not lighten a saturated colour for its
   use as a SURFACE and then flip its label to near-black to hold contrast. Every contrast reading
   passes and the result is black-on-salmon and black-on-pale-blue, which Spencer rejected three
   times over on 2026-08-13. A saturated colour used as a surface (buttons, solid banners, the logo
   tile) keeps its mid/dark value in BOTH themes and always carries white text; only saturated colour
   used as TEXT lightens here, because there it sits on a dark ground and has to. Done that way
   nothing flips, which deletes the entire "correct in light, unreadable in dark" defect class
   instead of asking each new component to remember it.
   🚨 Because it is unreachable, this half CANNOT be verified in a browser — do not report it as
   observed. Only the light ramp above has been seen rendering. */
#akashic-health-records-patient-portal-root.dark,
#akashic-health-records-patient-portal-root .dark {
  --paper: #171614;
  --surface: #201e1b;
  --sunken: #26241f;
  --line: #35322c;
  --line-soft: #2b2823;
  --ink: #e8e4dd;
  --ink-strong: #f6f3ed;
  --ink-muted: #a49d92;
  --faint: #7d766c;
  --blue-line: #2b3d4d;

  --background: var(--paper);
  --foreground: var(--ink);
  --card: var(--surface);
  --card-foreground: var(--ink);
  --popover: var(--surface);
  --popover-foreground: var(--ink);
  --primary: oklch(0.922 0 0);
  --primary-foreground: oklch(0.205 0 0);
  --secondary: var(--ink-muted);
  --secondary-foreground: var(--paper);
  /* Same meaning-not-name mapping as the light block — and the same correction: the canvas is
     --paper's job, not --sunken's. Kept identical to light so the two themes cannot drift; a token
     that means "page canvas" in one theme and "inset well" in the other is the bug this pair already
     produced once. */
  --muted: var(--paper);
  --muted-foreground: var(--ink-muted);
  --accent: var(--line-soft);
  --accent-foreground: var(--ink-strong);
  --destructive: var(--danger);
  --border: var(--line);
  --input: var(--line);
  --ring: oklch(0.556 0 0);
  --chart-1: oklch(0.488 0.243 264.376);
  --chart-2: oklch(0.696 0.17 162.48);
  --chart-3: oklch(0.769 0.188 70.08);
  --chart-4: oklch(0.627 0.265 303.9);
  --chart-5: oklch(0.645 0.246 16.439);
  --sidebar: var(--surface);
  --sidebar-foreground: var(--ink);
  --sidebar-primary: oklch(0.488 0.243 264.376);
  --sidebar-primary-foreground: oklch(0.985 0 0);
  --sidebar-accent: var(--line-soft);
  --sidebar-accent-foreground: var(--ink-strong);
  --sidebar-border: var(--line);
  --sidebar-ring: oklch(0.556 0 0);
}

#akashic-health-records-patient-portal-root .absolute {
  position: absolute;
}

#akashic-health-records-patient-portal-root .relative {
  position: relative;
}

#akashic-health-records-patient-portal-root .bottom-0 {
  bottom: 0;
}

#akashic-health-records-patient-portal-root .right-0 {
  right: 0;
}

#akashic-health-records-patient-portal-root .z-10 {
  z-index: 10;
}

/* =========================================================
   3. BASE ELEMENT NORMALIZATION
   Neutralize browser/WP/theme defaults inside the app only
   ========================================================= */

#akashic-health-records-patient-portal-root,
#akashic-health-records-patient-portal-root p,
#akashic-health-records-patient-portal-root li,
#akashic-health-records-patient-portal-root label,
#akashic-health-records-patient-portal-root input,
#akashic-health-records-patient-portal-root textarea,
#akashic-health-records-patient-portal-root select,
#akashic-health-records-patient-portal-root button {
  font-family:
    "Manrope",
    system-ui,
    -apple-system,
    BlinkMacSystemFont,
    "Segoe UI",
    Roboto,
    "Helvetica Neue",
    Arial,
    sans-serif;
  /* 🚨 REPOINTED 2026-08-14. This was a literal `#111827` — Tailwind's COOL gray-900 — and because this
     rule is (1,0,1) and sits LATER in the file than the utility layer, it beat `--foreground` on the root
     AND on every p / li / label / input / select / textarea / button in the app. ⇒ Card 271's warm ramp
     was landed, registered and then overridden on essentially all body copy, with nothing reporting it:
     the two values are both near-black, so the only visible difference is warmth.
     ⛔ This is a REPOINT AT the token, not a change to what the token equals — `--foreground` resolves to
     `--ink`, the value Spencer settled on 2026-08-13 ("a dark gray shade instead of pure black"). The
     normalization job this rule exists for is unchanged; it still beats host-theme text colour at the
     same specificity and the same place in the cascade.
     📌 It does NOT fix the wider trap that a `text-…` UTILITY still loses to this rule on those eight
     elements — that needs `!text-[var(--token)]`, and moving this rule earlier would silently activate
     hundreds of currently-inert colour classes at once. */
  color: var(--foreground);
}

/* Scoped so it outranks the colour normalization on p, li, label, input, select, textarea and
   button, where a bare utility loses. --ink-muted is the ramp's step for labels and supporting
   facts, which is what every call site of this class is. */
#akashic-health-records-patient-portal-root .text-ink-muted {
  color: var(--ink-muted);
}

/* VideoTileGrid said this in a comment the whole time: the colour was never wrong - #948f85 is
   5.51:1 on the dark tile - but the class never applied, so two sentences explaining an empty
   video region rendered in body ink on a dark ground. A sibling span was already worked around it. */
#akashic-health-records-patient-portal-root .text-faint {
  color: var(--faint);
}

/* Same reason as the rule above: --ink-strong is the ramp's heading and card-subject step, and a bare
   utility loses to the colour normalization on p and label. Heading elements already take it from the
   h1-h6 rule; this is for the subjects and confirmations that are not headings. */
#akashic-health-records-patient-portal-root .text-ink-strong {
  color: var(--ink-strong);
}

/* Same reason as the rules above: a bare utility loses to the colour normalization on p and label.
   --sage-ink is the sage hue deep enough to carry text, which --success is not. */
#akashic-health-records-patient-portal-root .text-sage-ink {
  color: var(--sage-ink);
}

#akashic-health-records-patient-portal-root h1,
#akashic-health-records-patient-portal-root h2,
#akashic-health-records-patient-portal-root h3,
#akashic-health-records-patient-portal-root h4,
#akashic-health-records-patient-portal-root h5,
#akashic-health-records-patient-portal-root h6 {
  margin: 0;
  font-family:
    "Manrope",
    system-ui,
    -apple-system,
    BlinkMacSystemFont,
    "Segoe UI",
    Roboto,
    "Helvetica Neue",
    Arial,
    sans-serif;
  /* 🔻 2026-09-09 - was -0.01em, i.e. NEGATIVE, and that is what Spencer caught. The tracking
     ruling opened the body up from 0.01em to 0.02em, and headings were quietly going the other way,
     so the card headings came out at -0.13px while the paragraph under them sat at +0.3px - the
     exact "tight 2005 website" feel the ruling was removing, surviving in the one place the eye
     lands first.
     📌 +0.01em RATHER THAN THE BODY'S 0.02em, and the difference is deliberate: larger type needs
     less tracking than small type to read as open, so matching the body value exactly would make a
     24px heading look gappy. This is the smaller positive step, not a copy of the body's. */
  letter-spacing: 0.01em;
  /* Same repoint as the body rule above, onto the ramp's HEADING tone. ⛔ Not `--foreground` — the ramp
     draws a deliberate distinction between body copy (`--ink`) and headings (`--ink-strong`), and
     collapsing them here would quietly discard half of it. */
  color: var(--ink-strong);
  font-weight: var(--ak-heading-weight);
  line-height: var(--ak-line-tight);
}

#akashic-health-records-patient-portal-root h1 {
  font-size: var(--ak-font-20);
  font-weight: 600;
  color: var(--sage);
}

#akashic-health-records-patient-portal-root h2 {
  font-size: var(--ak-font-lg);
  font-weight: 500;
  color: var(--ink-strong);
}

#akashic-health-records-patient-portal-root h3 {
  font-size: var(--ak-font-15);
  font-weight: 400;
  color: var(--ink-strong);
}

#akashic-health-records-patient-portal-root h4 {
  font-size: var(--ak-font-13);
}

#akashic-health-records-patient-portal-root h5,
#akashic-health-records-patient-portal-root h6 {
  font-size: var(--ak-font-md);
}

#akashic-health-records-patient-portal-root p,
#akashic-health-records-patient-portal-root li {
  font-size: var(--ak-font-base);
  font-weight: var(--ak-body-weight);
  /* 🚨 UNITLESS, AND THE PIXEL VALUE THAT WAS HERE WAS A REAL BUG. It said `22px`, which is the
     right leading for the 15px this rule also sets - but an ABSOLUTE line-height does not travel
     with an overridden font-size, and it is INHERITED as a fixed pixel value rather than recomputed.
     🔍 Found 2026-09-09. Spencer: *"Why is the line spacing so much on the Due by: text?"* That line
     is a <p> that drops itself to 11px and sets no leading of its own, so it kept the 22px from
     here: 11px text on a 22px line, a ratio of 2.00 against the app's 1.45, and it read as
     double-spaced because it WAS double-spaced.
     ⛔ THE BUG IS THE UNIT, NOT THE NUMBER, so it is fixed here rather than by giving that one class
     a line-height. Every <p> and <li> in the app that overrides font-size downward - and there are
     many, since 15px is the base and most small print is a <p> - had the same defect waiting in it.
     Patching the call site would have left the trap armed for the next one.
     ⭐ `--ak-line-base` is 1.45 and already exists for this; two other rules in this file consume it
     correctly. At 15px it computes to 21.75px, so ordinary body copy moves by a quarter of a pixel
     and nothing reflows; at 11px it now computes to 15.95px instead of 22px, which is the whole
     visible change. */
  line-height: var(--ak-line-base);
}

#akashic-health-records-patient-portal-root label {
  font-size: var(--ak-font-base);
  font-weight: var(--ak-label-weight);
  line-height: var(--ak-line-tight);
  /* Repointed with the two normalization rules above — same literal cool grey, same override of the ramp. */
  color: var(--foreground);
}

#akashic-health-records-patient-portal-root small {
  font-size: var(--ak-font-xs);
  line-height: 16px;
  color: var(--ink-muted);
}


/* =========================================================
   FORM LABEL TYPOGRAPHY NORMALIZATION
   Catch label-like wrappers that are not literal <label> tags
   ========================================================= */
#akashic-health-records-patient-portal-root .components-base-control__label,
#akashic-health-records-patient-portal-root .components-base-control label,
#akashic-health-records-patient-portal-root .components-base-control__field label,
#akashic-health-records-patient-portal-root .components-base-control__field > label,
#akashic-health-records-patient-portal-root .components-base-control__field > span,
#akashic-health-records-patient-portal-root .components-base-control .components-text,
#akashic-health-records-patient-portal-root .components-base-control .components-truncate {
  font-family:
    "Manrope",
    system-ui,
    -apple-system,
    BlinkMacSystemFont,
    "Segoe UI",
    Roboto,
    "Helvetica Neue",
    Arial,
    sans-serif;
  font-size: var(--ak-font-base);
  font-weight: var(--ak-label-weight);
  line-height: 18px;
  /* Repointed with the normalization rules above — same literal cool grey, same override of the ramp. */
  color: var(--foreground);
  letter-spacing: 0;
}

#akashic-health-records-patient-portal-root .text-xs {
  font-size: var(--ak-font-xs);
  line-height: 16px;
}

#akashic-health-records-patient-portal-root .text-sm {
  font-size: var(--ak-font-sm);
  line-height: 20px;
}

#akashic-health-records-patient-portal-root .text-base {
  font-size: var(--ak-font-base);
  line-height: 22px;
}

/* THE REST OF THE RAMP, which was never brought onto the scale.
   `.text-base` above has been mapped for a long time and these four were not, so they resolved to
   Tailwind's own 18 / 20 / 24 / 30 at 241 call sites - every one of them correct-looking where it
   was written and none of them on the eight sizes ruled app-wide on 2026-08-13.

   THE SCALE STOPS AT 18. So `text-2xl` and `text-3xl` have nowhere above it to go and land on 18
   with `text-xl`. That is the ruling working rather than a rounding: a size that is not one of the
   eight is not a size this product has, and a call site asking for 30px is asking for something the
   design does not offer.

   Fixed HERE rather than at the call sites, because the ruling is stated here. Editing 241 files
   would move the decision into 241 places and leave the next `text-2xl` to be caught by review. */
#akashic-health-records-patient-portal-root .text-lg {
  font-size: var(--ak-font-lg);
  line-height: 24px;
}

/* EVERY RULED STEP, BY NAME, AND ID-SCOPED SO A CALL SITE CAN WIN.
   The five t-shirt names above are hand-written here for exactly this reason: a rule in this file
   carries the mount id at (1,1,0) and beats the base element rules at (1,0,1). A generated utility
   does not - Tailwind emits `text-[10px]` bare at (0,1,0), so it loses to `#…root p` and the
   paragraph renders at body size while the source looks right.

   That is the mechanism behind the twenty-seven call sites pinned by
   anArbitraryUtilityCannotBeatABaseElementRule. It was never carelessness: there was no name for
   10px, 11px or 12.5px, so the only way to write them was the one that cannot win.

   NO LINE-HEIGHT HERE, deliberately. The five above pair a size with a rhythm because they are the
   ramp. These are steps: a call site choosing 10.5px for an eyebrow is not also asking for a line
   box, and inventing one per step would put a second unruled number beside every size. */
/* THE RULED LINE RATIO, BY NAME. The step rules above carry no line height on purpose, so a call
   site that needs one asks for this rather than inventing a second number beside the size. It is
   id-scoped for the same reason they are: the base rules fix a PIXEL height for body text at body
   size, and a bare `leading-[1.45]` at (0,1,0) loses to `#…root p` at (1,0,1). */
#akashic-health-records-patient-portal-root .leading-base {
  line-height: var(--ak-line-base);
}

#akashic-health-records-patient-portal-root .text-step-9 {
  font-size: var(--ak-font-9);
}

#akashic-health-records-patient-portal-root .text-step-10 {
  font-size: var(--ak-font-10);
}

#akashic-health-records-patient-portal-root .text-step-10-5 {
  font-size: var(--ak-font-10-5);
}

#akashic-health-records-patient-portal-root .text-step-11 {
  font-size: var(--ak-font-11);
}

#akashic-health-records-patient-portal-root .text-step-11-5 {
  font-size: var(--ak-font-11-5);
}

#akashic-health-records-patient-portal-root .text-step-12 {
  font-size: var(--ak-font-12);
}

#akashic-health-records-patient-portal-root .text-step-12-5 {
  font-size: var(--ak-font-12-5);
}

#akashic-health-records-patient-portal-root .text-step-13 {
  font-size: var(--ak-font-13);
}

#akashic-health-records-patient-portal-root .text-step-14 {
  font-size: var(--ak-font-14);
}

#akashic-health-records-patient-portal-root .text-step-15 {
  font-size: var(--ak-font-15);
}

#akashic-health-records-patient-portal-root .text-step-17 {
  font-size: var(--ak-font-17);
}

#akashic-health-records-patient-portal-root .text-step-18 {
  font-size: var(--ak-font-18);
}

#akashic-health-records-patient-portal-root .text-step-24 {
  font-size: var(--ak-font-24);
}

#akashic-health-records-patient-portal-root .text-step-42 {
  font-size: var(--ak-font-42);
}

#akashic-health-records-patient-portal-root .text-xl,
#akashic-health-records-patient-portal-root .text-2xl,
#akashic-health-records-patient-portal-root .text-3xl {
  font-size: var(--ak-font-18);
  line-height: 26px;
}

/* AND THE WEIGHTS, on the same principle and from the same measurement.
   The approved decks were measured across 8,367 rendered text nodes: they use 400, 500 and 600, and
   NOTHING HEAVIER. Not one node at 700. The app calls `font-bold` 303 times and `font-extrabold`
   four, so the heaviest thing in the product is a weight the design does not contain.

   600 IS THE TOP OF THE VOCABULARY, so both land there. A heading that needed to shout louder than
   600 in a drawing would have been drawn that way; what these call sites actually wanted was "the
   strongest emphasis available", and this is it.

   Mapped rather than swept for the same reason as the sizes above: the next `font-bold` somebody
   writes is already correct instead of waiting to be caught in review. */
#akashic-health-records-patient-portal-root .font-bold,
#akashic-health-records-patient-portal-root .font-extrabold {
  font-weight: 600;
}

:where(#akashic-health-records-patient-portal-root img,
#akashic-health-records-patient-portal-root svg,
#akashic-health-records-patient-portal-root video,
#akashic-health-records-patient-portal-root canvas) {
  display: block;
  max-width: 100%;
}

:where(#akashic-health-records-patient-portal-root img,
#akashic-health-records-patient-portal-root video) {
  height: auto;
}

#akashic-health-records-patient-portal-root ul,
#akashic-health-records-patient-portal-root ol {
  margin: 0;
  padding: 0;
  list-style: none;
}

/* A bulleted list opts back in; nested lists indent one step and take the next marker. */
#akashic-health-records-patient-portal-root .ak-bullets,
#akashic-health-records-patient-portal-root .ak-bullets ul {
  padding-left: 20px;
  list-style: disc;
}
#akashic-health-records-patient-portal-root .ak-bullets ul {
  margin-top: 4px;
  padding-left: 40px;
  list-style-type: circle;
}
#akashic-health-records-patient-portal-root .ak-bullets ul ul {
  list-style-type: square;
}
#akashic-health-records-patient-portal-root .ak-bullets li + li {
  margin-top: 4px;
}

/* A numbered list opts back in the same way. An agreement's ordered list carries no number in its text -
   the marker is the only place the reader sees it - so losing it to the reset above loses the numbering. */
#akashic-health-records-patient-portal-root .ak-numbers {
  list-style: decimal;
  padding-left: 20px;
}

#akashic-health-records-patient-portal-root a {
  color: inherit;
  text-decoration: none;
}

/* A link inside agreement text has to read as one: the reset above strips both its colour and its
   underline, and an `underline` utility cannot outrank a rule scoped to the root id. */
#akashic-health-records-patient-portal-root a.ak-agreement-link {
  color: var(--primary);
  text-decoration: underline;
  text-underline-offset: 2px;
}

#akashic-health-records-patient-portal-root table {
  border-collapse: collapse;
  border-spacing: 0;
}

#akashic-health-records-patient-portal-root nav,
#akashic-health-records-patient-portal-root .sidebar {
  font-size: var(--ak-font-base);
  line-height: var(--ak-line-base);
}

#akashic-health-records-patient-portal-root [data-wp-component="Scrollable"] {
  height: auto;
  max-height: none;
  overflow: visible;
}

#akashic-health-records-patient-portal-root input,
#akashic-health-records-patient-portal-root textarea,
#akashic-health-records-patient-portal-root select,
#akashic-health-records-patient-portal-root button {
  font-family: inherit;
}

#akashic-health-records-patient-portal-root input.font-mono,
#akashic-health-records-patient-portal-root textarea.font-mono {
  font-family: var(--font-mono, ui-monospace, SFMono-Regular, Menlo, Consolas, monospace);
}

#akashic-health-records-patient-portal-root input,
#akashic-health-records-patient-portal-root textarea,
#akashic-health-records-patient-portal-root select {
  max-width: none;
  box-shadow: none;
  -webkit-appearance: none;
  appearance: none;
  background-color: #fff;
  background-image: none;
}

/* =========================================================
   FORM CONTROL NORMALIZATION
   Keep text inputs, token fields, and selects visually aligned
   without duplicate shells or duplicated selectors
   ========================================================= */

#akashic-health-records-patient-portal-root .components-form-token-field,
#akashic-health-records-patient-portal-root .components-form-token-field__input-container,
#akashic-health-records-patient-portal-root .components-input-control__container,
#akashic-health-records-patient-portal-root .components-input-control__backdrop,
#akashic-health-records-patient-portal-root .components-base-control__field {
  box-sizing: border-box;
  width: 100%;
  min-width: 0;
  max-width: none;
  margin: 0;
  padding: 0;
  border: 0;
  background: transparent;
  box-shadow: none;
  outline: none;
}

#akashic-health-records-patient-portal-root .components-input-control__container {
  display: flex;
  align-items: center;
  gap: 0;
  width: 100%;
  min-width: 0;
  max-width: none;
}

/* Standard text inputs own their own shell */
#akashic-health-records-patient-portal-root .ak-field,
#akashic-health-records-patient-portal-root input[type="text"]:not(.components-form-token-field__input):not(.components-input-control__input):not(.components-search-control__input):not(.components-combobox-control__input):not(:where(.ak-field-shell) *),
#akashic-health-records-patient-portal-root input[type="search"]:not(.components-input-control__input):not(.components-search-control__input):not(.components-combobox-control__input):not(:where(.ak-field-shell) *),
#akashic-health-records-patient-portal-root input[type="email"]:not(:where(.ak-field-shell) *),
#akashic-health-records-patient-portal-root input[type="number"]:not(:where(.ak-field-shell) *),
#akashic-health-records-patient-portal-root input[type="date"]:not(:where(.ak-field-shell) *),
#akashic-health-records-patient-portal-root input[type="datetime-local"]:not(:where(.ak-field-shell) *),
#akashic-health-records-patient-portal-root input:where([data-slot="input"]:not([type])):not(:where(.ak-field-shell) *),
#akashic-health-records-patient-portal-root textarea {
  box-sizing: border-box;
  width: 100%;
  min-width: 0;
  max-width: none;
  min-height: var(--ak-field-height);
  height: var(--ak-field-height);
  margin: 0;
  /* Left/right padding are individually overridable (default to the standard --ak-field-padding-x),
     so an input with a leading icon can widen only its left side. See .ahr-input-icon-left below. */
  padding: 0 var(--ak-field-padding-right, var(--ak-field-padding-x)) 0 var(--ak-field-padding-left, var(--ak-field-padding-x));
  border: 1px solid var(--line);
  border-radius: var(--ak-field-radius);
  background-color: var(--surface);
  color: var(--ink);
  font-size: var(--ak-field-font-size);
  line-height: var(--ak-field-line-height);
  box-shadow: none;
  outline: none;
}

/* A wrapper that draws the field's box owns it: the input inside is bare text, not a second box. */
#akashic-health-records-patient-portal-root .ak-field-shell :where(input) {
  min-height: 0;
  height: auto;
  padding: 0;
  border: 0;
  border-radius: 0;
  background-color: transparent;
  box-shadow: none;
  outline: none;
}

#akashic-health-records-patient-portal-root .ak-field-shell:focus-within {
  border-color: var(--primary);
}

/* The ring is left weak so a shell that draws its own open state keeps it. */
:where(#akashic-health-records-patient-portal-root) .ak-field-shell:focus-within {
  box-shadow: 0 0 0 3px rgb(var(--primary-rgb) / 0.15);
}

/* FILE PICKERS ARE THE ONE FIELD THE SHELL ABOVE NEVER NAMED.

   The rule above enumerates text, search, email, number, date, datetime-local and textarea.
   `input[type="file"]` is not in that list and never has been, so the browser's own file-selector
   button is the only control in this product that no house rule reaches. There are 18 files under
   `src/` carrying a bare `type="file"` and no file-input primitive in `components/ui/` for them to
   have adopted instead.

   WHAT THAT DRAWS, measured on the Record authorization dialog's *Signed form (optional)* field:
   background-color `rgba(0, 0, 0, 0)`, border `0px`, border-radius `0px`, cursor `default`.
   Tailwind's preflight had already stripped the browser's grey fill and outset border, and nothing
   was ever put back - so the control reads as a run of prose sitting inside a bordered field, with
   no fill, no edge, no corner and not even a pointer to say it can be pressed. It is the same
   flat-control shape section 3A produces on the button primitive, arriving by the opposite route:
   not a rule that overrides, a rule that was never written.

   The treatment is `.btn-blue-ghost` (2389 below) expressed as properties, because a pseudo-element
   cannot carry a class - a transparent fill and a primary-coloured edge, so the picker announces
   itself as a control without competing with the affirmative in the same dialog. The 2px corner is
   the settled one from `.btn` (2323 below), not a fresh value.

   The padding is deliberately smaller than `.btn`'s `0.5rem 1rem`: this button renders INSIDE the
   field's own 36px box and has about 26px to live in, so the full button padding would overflow the
   field it sits in. */
#akashic-health-records-patient-portal-root input[type="file"]::file-selector-button {
  margin-right: 0.75rem;
  padding: 2px 10px;
  border: 1px solid var(--primary);
  border-radius: 2px;
  background-color: transparent;
  color: var(--primary);
  font-size: var(--ak-font-sm);
  font-weight: 500;
  line-height: 1.2;
  cursor: pointer;
}

#akashic-health-records-patient-portal-root input[type="file"]::file-selector-button:hover {
  background-color: rgb(var(--primary-rgb) / 0.08);
}

/* Disabled while a submit is in flight - the pointer must stop promising a press. */
#akashic-health-records-patient-portal-root input[type="file"]:disabled::file-selector-button {
  cursor: default;
}

/* =========================================================
   MULTI-LINE FIELDS OPEN AT PROSE HEIGHT — card 263 E6 / card 261 B65
   =========================================================
   📏 The clinical note — the field a practitioner documents an entire visit in — measured **42px, 2.1
   visible lines**. A writer is in a scrolling porthole from the third sentence on.

   🚨 AND THE CAUSE WAS NOT A MISSING VALUE. `ClinicalNoteEditor` has asked for `min-h-[220px]` all
   along. It never applied: the shared field rule ABOVE sets `height` (not merely `min-height`) on
   `textarea` at `#…root textarea` = specificity **(1,0,1)**, and a Tailwind utility class is **(0,1,0)**.
   The id-scoped base style silently beat every component that tried to be taller, and nothing errored.
   ⭐ Same family as the trap P8 already paid for once (id-vs-attribute) and the container-query trap
   ⇒ [[reference-css-defects-that-pass-every-check]]. **A rule can be correct and inert.**

   ⚠️ SOURCE ORDER IS LOAD-BEARING: this matches the base rule's specificity exactly, so it wins only by
   sitting BELOW it. Moving it above turns it off, silently. Do not reorder this file's field rules.

   ⛔ `height: auto` is the half that actually frees the element — a fixed `height` cannot be overridden
   by any `min-height`, so leaving it would make the floor below decorative. */
#akashic-health-records-patient-portal-root textarea {
  height: auto;
  min-height: var(--ak-prose-field-height);
  resize: vertical;
  /* Multiline text starts below the top edge; the inline padding stays the field standard. */
  padding-top: 10px;
  padding-bottom: 10px;
}

/* The clinical note is the LARGEST element on the encounter screen — E6's actual ruling, and the reason
   the floor above is not enough on its own. `(1,1,0)` so it beats the element rule; a utility class
   never could. Applied via `ak-prose-field--note`, not by widening the base rule, so this stays one
   surface's decision rather than every textarea in the product growing to 220px. */
#akashic-health-records-patient-portal-root .ak-prose-field--note {
  min-height: 220px;
}

/* A filed note compacts so the record suggestions below it have the room. */
#akashic-health-records-patient-portal-root .ak-prose-field--note[data-filed] {
  min-height: 110px;
  height: 110px;
}

/* Standard for inputs with a LEADING icon (e.g. a search glyph absolutely positioned on the left of
   the field's relative wrapper). Widens the text's left padding so it clears the icon — uniform
   site-wide. Add `ahr-input-icon-left` to any such input; pair with an icon at ~left-2 (0.5rem). */
#akashic-health-records-patient-portal-root .ahr-input-icon-left,
#akashic-health-records-patient-portal-root .ak-field--search {
  --ak-field-padding-left: 2rem;
}

/* The same standard for a TRAILING control (e.g. a search field's reset button, absolutely
   positioned on the right of the same relative wrapper). A Tailwind `pr-*` utility cannot do this
   job: the shell rule above is id-scoped at (1,1,0) and a utility is (0,1,0), so the utility is
   overridden and the text runs under the button. Pair with a control at ~right-2 (0.5rem). */
#akashic-health-records-patient-portal-root .ahr-input-icon-right,
#akashic-health-records-patient-portal-root .ak-field--trailing {
  --ak-field-padding-right: 2rem;
}

/* The unread-count badge on a control, drawn the way every messaging product draws one: a filled
   disc for a single digit that grows sideways into a short pill for two or three, never a fixed
   circle that clips its own number. `min-width` and `height` are equal, so one digit is round.

   IT IS CSS RATHER THAN UTILITIES because the min-width class this needs is not in the built
   stylesheet - Tailwind emits only what a source file has written, and `min-w-4` has never been
   written here, so it resolves to nothing and the disc comes out an oval. Measured, not assumed.

   AMBER, AND THERE IS NO LONGER AN EXCEPTION. Spencer, 2026-09-10: "count badges should be
   consistent across the app so the design feels cohesive." This app's amber means notice this and
   its blue means somewhere to go, so a count in blue reads as a control rather than a quantity -
   and the count is the one thing on a row that is neither a control nor a destination.

   CONTRAST DID NOT DECIDE IT AND COULD NOT: white on --warning is 5.02:1 and white on --primary is
   5.33, so both clear AA comfortably and the choice was free to be made on meaning alone.

   The blue here was inherited from a measurement that no longer describes anything: amber came to
   4.36:1 as a NUMBER on the old tonal button's ground. That button is bare now, and this is a white
   numeral on an amber FILL - a different pair entirely. Do not restore the blue from that number.

   Add `ahr-count-badge` to any count that sits on a button or a nav row. */

/* 🗣️ Spencer, 2026-09-10: *"Tabs text needs font-weight: 500."*

   ⚠️ A UTILITY CANNOT SAY THIS HERE. `font-medium` is remapped under this mount to
   `--ak-label-weight` (350) along with every other weight utility, which is what made the 2026-09-09
   scale actually take effect across a thousand call sites. So 500 has to be a NAMED rule, and it is
   the fourth deliberate exception above the 400 cap - overlay title 600, practice phone 600, summary
   tile labels 500, and now these.

   ⚖️ It earns it on the same grounds as the summary tiles: this row is navigation rather than a
   caption, and at 13px on a warm ground the difference between 350 and 500 is what separates the tab
   you are on from the two you are not. */
/* A MESSAGE BUBBLE, AND THERE IS ONLY ONE.

   🗣️ Spencer, 2026-09-09: *"update the ai assistant messages to match the messages design in the
   patient portal mockup"* - and on 2026-09-10, that the real thread still had not caught up with the
   assistant that was updated to match it. The help panel looked more like the product than the
   product did.

   ⭐ SO THE VALUES LIVE HERE RATHER THAN IN EITHER SURFACE. `AssistantPanel.css` draws the same
   anatomy for the assistant; two copies of one design are two designs a fortnight later.

   ⚖️ THE TAIL RADIUS IS THE POINT, not decoration. It is what lets a run of bubbles read as one
   speaker without a rule between them - a divider drawn across a conversation separates the wrong
   thing, which is what the earlier stacked list did.

   ⛔ The outbound fill is --primary and not a grey. It was `bg-gray-100 text-gray-900`: a cool grey
   in a warm product, and the same grey on both sides, so the only thing telling a reader who spoke
   was which edge the bubble touched. */
#akashic-health-records-patient-portal-root .ahr-msg-bubble {
  /* SHRINK TO THE WORDS. Without fit-content the bubble fills the track its wrapper gives it, so a
     one-word reply draws as a full-width bar and the side it sits on stops being readable at a
     glance - which is the only thing telling you who spoke. */
  width: fit-content;
  /* NEITHER SIDE EVER TOUCHES BOTH EDGES, and that is the whole point rather than a nicety.
     Spencer, 2026-09-10: capped so you can *"easily see if a message is from me or to me"* - the side
     a bubble sits on only reads as a side while there is visible ground on the other one. A message
     that spans the pane has no side.

     TWO LIMITS, WHICHEVER BINDS FIRST. 32rem is a readable measure - past about that the eye loses
     its place coming back to the left margin - and it binds on a wide screen. The 78% binds on a
     narrow one, where 32rem would be wider than the pane and the cap would do nothing. Both wrappers
     are 78% now too, so the gap is the same size whichever side the bubble is on; they were 75 and 85,
     which made inbound messages reach 10% further and quietly undid the cue. */
  max-width: min(32rem, 100%);
  padding: 8px 12px;
  border-radius: 8px;
  /* 🗣️ Spencer, 2026-09-10: 12px, weight 400. A message is the one place in this product where the
     words are the whole content rather than a label on something else, so they read at their own size
     rather than the app's small step - and at 400 rather than the 300 body weight, because a bubble is
     read in isolation instead of scanned. */
  font-size: 12px;
  font-weight: 400;
  line-height: 1.45;
  white-space: pre-wrap;
  overflow-wrap: break-word;
}

#akashic-health-records-patient-portal-root .ahr-msg-bubble--me {
  margin-left: auto;
  background: var(--primary);
  color: var(--primary-foreground);
  border-bottom-right-radius: 4px;
}

#akashic-health-records-patient-portal-root .ahr-msg-bubble--them {
  margin-right: auto;
  background: var(--sunken);
  color: var(--ink);
  border-bottom-left-radius: 4px;
}

/* The paragraph inside a bubble inherits the bubble's colour rather than the mount's body ink,
   which would otherwise repaint white text on --primary back to dark. */
#akashic-health-records-patient-portal-root .ahr-msg-bubble p {
  color: inherit;
  font-size: inherit;
  /* ⚠️ AND THE WEIGHT, which is the half that was missing. The bubble was set to 400 and measured
     at 400 - but the WORDS are the `p` inside it, and this mount gives every `p` the 300 body
     weight at a specificity the bubble's own rule never contested. So the rule was correct, the
     measurement of the rule was correct, and the thing on screen was still 300. Measure the element
     that carries the text, not the box around it. */
  font-weight: inherit;
  line-height: inherit;
  margin: 0;
}

/* WHO SAID IT, UNDER WHAT THEY SAID. It used to sit above the bubble as a heading, which reads as a
   label introducing a section rather than a signature on a message - and put the name further from
   the words than the next speaker's name was. Same anatomy as the assistant panel. */
#akashic-health-records-patient-portal-root .ahr-msg-attr {
  display: flex;
  flex-wrap: wrap;
  align-items: center;
  gap: 2px 8px;
  margin-top: 4px;
  font-size: var(--ak-font-11-5);
  color: var(--ink-muted);
}

#akashic-health-records-patient-portal-root .ahr-msg-attr--me {
  justify-content: flex-end;
}

/* The name inside it stops being a heading too - it was `text-sm font-semibold text-foreground`,
   which outweighed the message under it. */
#akashic-health-records-patient-portal-root .ahr-msg-attr span {
  font-size: inherit;
  font-weight: 400;
  color: inherit;
}

/* HOW LONG AGO, IN A LIST OF CONVERSATIONS. 🗣️ Spencer, 2026-09-10: 10px in the inbox list.

   ⚖️ It is the least important thing in the row and was set at the same size as the practice name
   under the correspondent, so three lines competed for the same rank. At 10px it is read when looked
   for and ignored otherwise, which is what a timestamp in a list is for. `whitespace-nowrap` because
   `14w ago` breaking after the number is worse than the column being a few pixels wider.

   ⚠️ A utility cannot express this: the mount gives every `p` its own size at a specificity no
   `text-*` class reaches, which is the trap this stylesheet documents six times over. */
#akashic-health-records-patient-portal-root .ahr-row-time {
  font-size: 10px;
  line-height: 1.45;
  color: var(--ink-muted);
  white-space: nowrap;
}

/* THE PATIENT MESSAGES SPLIT, at the deck's widths: 320px beside the thread on a tablet, 360px on a
   laptop, 20px between the two panels. */
@media (min-width: 768px) {
  #akashic-health-records-patient-portal-root .ahr-messages-split {
    grid-template-columns: minmax(16rem, 20rem) minmax(0, 1fr);
    gap: 20px;
  }
}

@media (min-width: 1024px) {
  #akashic-health-records-patient-portal-root .ahr-messages-split {
    grid-template-columns: minmax(16rem, 22.5rem) minmax(0, 1fr);
  }
}

/* The tabs open the panel and start where the search field and the rows start. */
#akashic-health-records-patient-portal-root .ahr-messages-tabs {
  padding: 4px 8px 0;
}

#akashic-health-records-patient-portal-root .ahr-messages-tabs > .ahr-tab:first-child {
  padding-left: 0;
}

#akashic-health-records-patient-portal-root .ahr-messages-search {
  height: auto;
  margin: 0 0 12px;
  border-radius: var(--ak-field-radius);
  background: var(--surface);
}

#akashic-health-records-patient-portal-root .ahr-messages-search input {
  height: 42px;
  background: transparent;
  font-size: 13px;
}

/* The drawn 38px with a mouse; the 44px floor is for a finger. */
@media (hover: hover) and (pointer: fine) {
  #akashic-health-records-patient-portal-root .ahr-messages-search input {
    height: 36px;
  }
}

/* The list below the search keeps the deck's 12px, not the description's 20px stack gap. */
#akashic-health-records-patient-portal-root .ahr-messages-search + * {
  margin-top: 0;
}

/* A MESSENGER ROW, NOT A CARD (the 2026-09-14 ruling), drawn to the deck's anatomy: a 34px mark,
   name and time on one line, who they are under it, then the last thing said. The ground on hover
   and the rail on the right for the open conversation. */
#akashic-health-records-patient-portal-root .ahr-inbox-list {
  display: flex;
  flex-direction: column;
  gap: 4px;
}

#akashic-health-records-patient-portal-root .ahr-inbox-row {
  display: flex;
  align-items: flex-start;
  gap: 12px;
  padding: 8px 12px;
  border-right: 4px solid transparent;
  text-align: start;
  cursor: pointer;
}

#akashic-health-records-patient-portal-root .ahr-inbox-row:hover {
  background: var(--line-soft);
  border-right-color: var(--line);
}

#akashic-health-records-patient-portal-root .ahr-inbox-row.ahr-inbox-row--on {
  background: var(--blue-soft);
  border-right-color: var(--primary);
}

#akashic-health-records-patient-portal-root .ahr-inbox-avatar-wrap {
  position: relative;
  flex: none;
}

#akashic-health-records-patient-portal-root .ahr-inbox-avatar {
  display: grid;
  place-items: center;
  width: 34px;
  height: 34px;
  overflow: hidden;
  border-radius: 50%;
  background: var(--sunken);
  color: var(--ink-muted);
  font-size: 13px;
  font-weight: 500;
  line-height: 1;
}

#akashic-health-records-patient-portal-root .ahr-inbox-avatar img {
  width: 100%;
  height: 100%;
  object-fit: cover;
}

/* A practice's logo sits on the row as it is: no plate behind it and nothing cropped off it. */
#akashic-health-records-patient-portal-root .ahr-inbox-avatar.ahr-inbox-avatar--logo {
  border-radius: 0;
  background: transparent;
}

#akashic-health-records-patient-portal-root .ahr-inbox-avatar.ahr-inbox-avatar--logo img {
  object-fit: contain;
}

#akashic-health-records-patient-portal-root .ahr-inbox-row--on .ahr-inbox-avatar:not(.ahr-inbox-avatar--logo) {
  background: var(--surface);
  color: var(--primary);
}

#akashic-health-records-patient-portal-root .ahr-inbox-presence {
  position: absolute;
  right: -1px;
  bottom: -1px;
  width: 11px;
  height: 11px;
  border: 2px solid var(--surface);
  border-radius: 50%;
  background: var(--success);
}

#akashic-health-records-patient-portal-root .ahr-inbox-body {
  display: flex;
  flex: 1;
  flex-direction: column;
}

#akashic-health-records-patient-portal-root .ahr-inbox-top,
#akashic-health-records-patient-portal-root .ahr-inbox-bottom {
  display: flex;
  justify-content: space-between;
  align-items: baseline;
  gap: 8px;
}

#akashic-health-records-patient-portal-root .ahr-inbox-bottom {
  align-items: center;
}

#akashic-health-records-patient-portal-root .ahr-inbox-name {
  font-size: 15px;
  font-weight: 500;
  line-height: 1.55;
  color: var(--ink-strong);
}

#akashic-health-records-patient-portal-root .ahr-inbox-sub {
  margin: 2px 0;
  font-size: 13px;
  line-height: 1.55;
  color: var(--ink-muted);
}

#akashic-health-records-patient-portal-root .ahr-inbox-preview {
  font-size: 13px;
  line-height: 1.55;
  color: var(--ink-muted);
}

/* A person inside a practice: a round mark and a hover ground, no card of its own inside the card. */
#akashic-health-records-patient-portal-root .ahr-person-row {
  padding: 8px;
  border-radius: 8px;
}

#akashic-health-records-patient-portal-root .ahr-person-row:not([aria-disabled]):hover {
  background: var(--sunken);
}

#akashic-health-records-patient-portal-root .ahr-person-row--desk,
#akashic-health-records-patient-portal-root .ahr-person-row--desk:not([aria-disabled]):hover {
  background: var(--blue-soft);
}

#akashic-health-records-patient-portal-root .ahr-person-row--desk p:first-child {
  color: var(--primary);
}

#akashic-health-records-patient-portal-root .ahr-person-avatar,
#akashic-health-records-patient-portal-root .ak-avatar {
  flex: none;
  width: var(--ak-avatar-md);
  height: var(--ak-avatar-md);
  border-radius: 9999px;
}

#akashic-health-records-patient-portal-root .ahr-person-avatar--desk {
  background: var(--sunken);
  color: var(--ink-muted);
}

/* Each fact wraps as a whole, carrying the separator after it, so neither an icon nor a bullet is
   left at the edge of a line on its own. */
#akashic-health-records-patient-portal-root .ahr-thread-fact {
  display: inline-block;
  max-width: 100%;
}

#akashic-health-records-patient-portal-root .ahr-thread-fact svg {
  display: inline-block;
  margin-right: 4px;
  vertical-align: -2px;
}

#akashic-health-records-patient-portal-root .ahr-thread-fact-sep {
  margin-left: 6px;
  color: var(--faint);
}
/* A CONTROL THAT IS ONLY ITS ICON - no box, no ground, no border, and no button padding. For the
   footnote-weight things that sit beside a heading: a details panel, an explainer. It is deliberately
   NOT one of the eight buttons and must not grow into one; if something needs to be pressed rather
   than merely available, it is a button and should look like one.

   ⚠️ It keeps a real hit area even though it has no visible box, because a 18px glyph is a hard
   target and the invisible half of a control is still the half people miss. */
#akashic-health-records-patient-portal-root .btn.ahr-icon-plain,
#akashic-health-records-patient-portal-root [data-slot="button"].ahr-icon-plain,
#akashic-health-records-patient-portal-root button.ahr-icon-plain {
  padding: 4px;
  min-height: 0;
  min-width: 0;
  border: 0;
  background: transparent;
  color: var(--ink-muted);
  box-shadow: none;
}

/* AND ITS SIZE, because `size={22}` on the element loses. `#root .btn svg` hardens every button glyph
   to 16px, and a CSS rule beats the presentational width/height attribute lucide writes - so the
   source said 22, the screen drew 16, and nothing reported a thing. TWO CLASSES plus the id scores
   (1,2,1) against the hardening's (1,1,1), so this wins on specificity rather than on source order.
   Same trap the header glyphs hit; this is its third appearance in one file. */
#akashic-health-records-patient-portal-root .btn.ahr-icon-plain svg,
#akashic-health-records-patient-portal-root button.ahr-icon-plain svg {
  width: 22px;
  height: 22px;
}

#akashic-health-records-patient-portal-root button.ahr-icon-plain:hover:not(:disabled) {
  background: transparent;
  color: var(--primary);
}

/* WHO YOU ARE TALKING TO. 🗣️ Spencer, 2026-09-10: sage, 600, medium.

   Same hue and weight as an overlay title, and for the same reason: it is the only heading on its
   pane, so nothing competes with it and it can carry a weight the 400 cap otherwise forbids. That
   makes it the fifth named exception, all of them deliberate and all of them written down.

   ⚠️ `medium` is the CSS keyword - 16px on this mount - and not a step token, because it is the size
   he named. Stated here rather than as a utility for the reason this file repeats: an element rule
   under the mount id outranks a `text-*` class, so the utility would have lost silently. */
#akashic-health-records-patient-portal-root .ahr-thread-title {
  color: var(--sage);
  font-weight: 600;
  font-size: medium;
}

/* The icon and presence dot inside it keep their own colours - the heading colours the WORDS. */
#akashic-health-records-patient-portal-root .ahr-thread-title svg {
  color: var(--sage);
}

/* THE PATIENT'S THREAD, as its deck draws it: who you are talking to sits on the page above the
   conversation, and the messages and the composer share one card beneath it. */
#akashic-health-records-patient-portal-root .ahr-chat--portal {
  gap: 0;
  border: 0;
  border-radius: 0;
}

#akashic-health-records-patient-portal-root .ahr-chat--portal .ahr-chat-head {
  padding: 0 0 12px;
  border: 0;
  background: transparent;
}

#akashic-health-records-patient-portal-root .ahr-chat--portal .ahr-thread-plainfacts {
  font-size: 13px;
  color: var(--ink-muted);
}

#akashic-health-records-patient-portal-root .ahr-chat--portal .ahr-chat-body {
  padding: 12px 14px 4px;
  border: 1px solid var(--line);
  border-bottom: 0;
  background: var(--surface);
}

#akashic-health-records-patient-portal-root .ahr-chat--portal .ahr-chat-foot {
  padding: 10px 14px 12px;
  border: 1px solid var(--line);
  border-top: 0;
  background: var(--surface);
}

#akashic-health-records-patient-portal-root .ahr-chat--portal .ahr-chat-empty {
  border: 1px solid var(--line);
  background: var(--surface);
}

#akashic-health-records-patient-portal-root .ahr-chat--portal .ahr-chat-days,
#akashic-health-records-patient-portal-root .ahr-chat--portal .ahr-chat-day-group,
#akashic-health-records-patient-portal-root .ahr-chat--portal .ahr-chat-stack {
  display: grid;
  gap: 8px;
}

#akashic-health-records-patient-portal-root .ahr-chat--portal .ahr-chat-day {
  margin: 6px 0 2px;
  font-size: 11px;
  font-weight: 400;
  letter-spacing: 0.04em;
  /* --ink-muted, not the deck's --faint: at 11px --faint is under the AA floor. */
  color: var(--ink-muted);
}

/* The signature matches the words above it, as the deck pairs them; the bubble is ruled at 12px. */
#akashic-health-records-patient-portal-root .ahr-chat--portal .ahr-msg-attr {
  margin-top: 2px;
  font-size: 12px;
}

/* Delivery status rides on the signature's line: "You · 1:20 AM  Sent". */
#akashic-health-records-patient-portal-root .ahr-chat--portal .ahr-msg-attr--me {
  align-items: flex-start;
}

#akashic-health-records-patient-portal-root .ahr-chat--portal .ahr-msg-attr--me > div {
  margin-top: 0;
}

#akashic-health-records-patient-portal-root .ahr-chat--portal button.ahr-attach {
  width: 26px;
  height: auto;
  align-self: center;
  color: var(--ink-muted);
}

#akashic-health-records-patient-portal-root .ahr-chat--portal button.ahr-attach svg {
  width: 18px;
  height: 18px;
  color: var(--ink-muted);
}

#akashic-health-records-patient-portal-root .ahr-chat--portal button.ahr-attach:hover svg {
  color: var(--primary);
}

/* THE PARTICIPANT COUNT IS A CONTROL, and has to look like one without becoming a button. It sits in
   a row of plain facts, so it takes the underline a reader already reads as "this opens something"
   rather than a box that would outweigh the heading above it. */
#akashic-health-records-patient-portal-root button.ahr-participants-link {
  padding: 0;
  border: 0;
  background: none;
  color: inherit;
  font: inherit;
  text-decoration: underline;
  text-underline-offset: 2px;
  cursor: pointer;
}

#akashic-health-records-patient-portal-root button.ahr-participants-link:hover {
  color: var(--primary);
}

/* A WORD THE READER IS MEANT TO TAP, AND IT HAD STOPPED LOOKING LIKE ONE.

   Two surfaces draw a real button as a word inside a sentence: the outstanding-agreements notice, whose
   three names open the agreement, and the unreplied banner's Dismiss. Both stated their colour with a
   utility, and both lost - `#akashic-health-records-patient-portal-root button` at line 755 sets
   `color: var(--foreground)` at (1,0,1), and `.text-amber-800` is (0,1,0). The weight went the same way:
   `.font-medium` is remapped under this mount to `--ak-label-weight`, which is 350, so asking for medium
   made the word LIGHTER than the prose beside it.

   Nothing errors when that happens and the source keeps reading as though it applied. The agreements
   notice even carried a comment saying "a name to tap, not a button", which is precisely what it had
   stopped being - while the consent blocker was telling stuck patients that notice is the way out.

   NAMED RULES RATHER THAN `!`, which is DESIGN.md section 10 trap 1's own remedy. An `!` utility would
   make these two screens right and leave the mechanism live everywhere else, which hides the fault
   instead of removing it. Whether the theme should keep beating every utility inside the root is a
   theme decision and is not settled here.

   THE COLOUR IS `--amber-ink`, THE TOKEN, not the utility's hex. The palette already names this colour;
   a second copy of it is a second decision a fortnight later.

   THE WEIGHT IS THE FIFTH DELIBERATE EXCEPTION above the 400 cap - after the overlay title at 600, the
   practice phone at 600, the summary tile labels at 500 and the tabs at 500. It earns it on the tab
   row's grounds: this word is the control in its sentence, and at 350 against prose at 400 it was the
   lightest thing in a line it is supposed to lead. */
#akashic-health-records-patient-portal-root button.ahr-inline-word-control {
  padding: 0;
  border: 0;
  background: none;
  color: var(--amber-ink);
  font-family: inherit;
  font-size: inherit;
  font-weight: 500;
  text-decoration: none;
  cursor: pointer;
}

#akashic-health-records-patient-portal-root button.ahr-inline-word-control:hover:not(:disabled) {
  text-decoration: underline;
  text-underline-offset: 2px;
}

/* Dismiss sits in a banner rather than in a sentence, so it keeps the padded, rounded hit area and the
   hover plate it already had - only the colour and weight come from the rule above. Stated here rather
   than left on utilities for the reason this whole block exists: the padding utilities survive, the
   colour and weight do not, and a call site carrying half its own styling is where the next silent loss
   hides. */
#akashic-health-records-patient-portal-root button.ahr-inline-word-control.ahr-banner-dismiss {
  padding: 2px 8px;
  /* 2px, the settled button corner - not a radius token, because this is a control. */
  border-radius: 2px;
  font-size: 0.75rem;
}

#akashic-health-records-patient-portal-root button.ahr-inline-word-control.ahr-banner-dismiss:hover:not(:disabled) {
  /* The soft plate, not --amber-fill: a hover on a word should darken the ground under it,
     not fill it the way a pressed amber button does. */
  background: var(--amber-soft);
  text-decoration: none;
}

/* THE TOAST'S OWN ACTION CONTROL, WHICH THE HOUSE INK WAS MAKING UNREADABLE. Sonner draws this button
   as a deliberate INVERSION of the toast it sits in - `color: var(--normal-bg)` over
   `background: var(--normal-text)` - so on our white toast it is meant to be a white label on a
   near-black fill. Only half of that survived. Sonner asks for it at
   `[data-sonner-toast][data-styled='true'] [data-button]`, which is (0,3,0), and the house rule above
   at line 732 - `#...-root button { color: var(--foreground) }` - is (1,0,1). An id beats any number
   of classes, so 732 won the COLOUR and left the FILL alone, which is the worst of the two outcomes:
   the warm dark ink #33302c drawn on Sonner's near-black, measured at 1.37:1 against a 4.5:1 floor for
   12px text. The control was drawn, sized, positioned and clickable and simply could not be read.

   NOTE: this is the loudest control in the product to lose - the un-dismissable unfinished-note reminder
   has no dismiss by design, so its action IS the only way out of the toast. 18 call sites pass an
   `action`, and every one of them was drawing the same 1.37:1.

   Scoped to the toast rather than to a new class, so no call site changes and the fix reaches all 18.
   It restores Sonner's OWN variable rather than naming a colour, so the inversion stays correct if the
   toast ground ever changes - and so there is no hex literal here for the colour ratchet to find. */
#akashic-health-records-patient-portal-root [data-sonner-toast] [data-button] {
  color: var(--normal-bg);
}

/* THE EMOJI PANEL. Anchored above the composer rather than below it, because below is off the bottom
   of a window the composer is already pinned to. A fixed grid of six, so the panel is the same shape
   every time it opens and the thing you picked last is where you left it. */
/* THE EMOJI CONTROL SITS INSIDE THE FIELD, on its right edge, which is where every messenger puts it
   and therefore where a reader's eye already goes. Absolute rather than a flex sibling so the input
   keeps its full width and the glyph does not shorten the place you type. */
/* THE MESSAGE COMPOSER: one line that grows with the text to 110px and then scrolls. 44px floor for a
   thumb; the right padding keeps a long message out from under the emoji control inside the field. */
#akashic-health-records-patient-portal-root .ahr-composer-field {
  display: block;
  width: 100%;
  min-height: 44px;
  max-height: 110px;
  padding: 11px 44px 11px 16px;
  field-sizing: content;
  resize: none;
  overflow-y: auto;
  border: 1px solid var(--line);
  border-radius: var(--ak-field-radius);
  background: var(--surface);
  color: var(--ink);
  font-size: 14px;
  line-height: 20px;
  box-shadow: none;
}

#akashic-health-records-patient-portal-root button.ahr-emoji-trigger {
  position: absolute;
  top: 50%;
  right: 6px;
  transform: translateY(-50%);
  display: inline-flex;
  align-items: center;
  justify-content: center;
  width: 32px;
  height: 32px;
  padding: 0;
  border: 0;
  border-radius: 9999px;
  background: transparent;
  color: var(--ink-muted);
  cursor: pointer;
}

#akashic-health-records-patient-portal-root button.ahr-emoji-trigger:hover {
  background: var(--sunken);
  color: var(--primary);
}

/* ONE LINE AT REST, the placeholder included. A placeholder that wraps sizes the field to two. */
#akashic-health-records-patient-portal-root .ahr-composer-field::placeholder {
  overflow: hidden;
  white-space: nowrap;
  text-overflow: ellipsis;
}

/* With a mouse the composer takes the drawn desktop size; the 44px floor is for a finger. */
@media (hover: hover) and (pointer: fine) {
  #akashic-health-records-patient-portal-root .ahr-composer-field {
    min-height: 34px;
    padding: 6px 40px 6px 12px;
    font-size: 13px;
  }

  #akashic-health-records-patient-portal-root button.ahr-emoji-trigger {
    width: 28px;
    height: 28px;
  }

  #akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .btn.ahr-composer-send {
    min-height: 34px;
    height: 34px;
  }
}

#akashic-health-records-patient-portal-root .ahr-emoji-panel {
  position: absolute;
  bottom: calc(100% + 8px);
  right: 0;
  z-index: 50;
  display: grid;
  grid-template-columns: repeat(8, 1fr);
  gap: 2px;
  padding: 6px;
  border: 1px solid var(--line);
  border-radius: 8px;
  background: var(--surface);
  box-shadow: 0 6px 20px rgba(31, 26, 20, 0.14);
}

#akashic-health-records-patient-portal-root button.ahr-emoji-key {
  padding: 0;
  border: 0;
  background: none;
  /* Big enough to hit on a phone, which is where an emoji is most likely to be used. */
  min-width: 34px;
  height: 34px;
  border-radius: 6px;
  font-size: 20px;
  line-height: 1;
  cursor: pointer;
}

#akashic-health-records-patient-portal-root button.ahr-emoji-key:hover {
  background: var(--sunken);
}

#akashic-health-records-patient-portal-root .ahr-tab {
  font-weight: 500;
}

#akashic-health-records-patient-portal-root .ahr-count-badge,
#akashic-health-records-patient-portal-root .ak-count {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  min-width: 15px;
  height: 15px;
  padding: 0 4px;
  border-radius: 9999px;
  background: var(--warning);
  color: #ffffff;
  font-size: 10px;
  font-weight: 500;
  line-height: 1;
  font-variant-numeric: tabular-nums;
}

/* THE QUEUE BUCKET’S DISCLOSURE MARK.

   Every bucket on the clinician overview is a <details>, and every <summary> carries `list-none` to
   suppress the native triangle. Four buckets open by default so their state reads off their own
   contents - but `Seen today` is `collapsedByDefault`, so the ONE bucket whose rows are hidden was
   also the only one with nothing on screen saying it opens. The mark goes on all five, because all
   five close, and a mark that appears only on the shut one would be a second thing to learn. */
#akashic-health-records-patient-portal-root .ahr-queue-bucket .ahr-queue-chevron {
  transition: transform 150ms ease;
}

#akashic-health-records-patient-portal-root .ahr-queue-bucket[open] .ahr-queue-chevron {
  transform: rotate(90deg);
}

/* Respect a reduced-motion preference: keep the rotation, drop the travel. */
@media (prefers-reduced-motion: reduce) {
  #akashic-health-records-patient-portal-root .ahr-queue-bucket .ahr-queue-chevron {
    transition: none;
  }
}

/* =========================================================
   THE WEIGHT UTILITIES, REMAPPED TO THE SCALE ABOVE.

   🚨 THE TOKENS ALONE WOULD HAVE MOVED ALMOST NOTHING. The weight tokens are consumed by a handful
   of element rules, while the app writes Tailwind's weight utilities directly: `font-medium` 432
   times, `font-semibold` 333, `font-bold` 302, `font-normal` 101, `font-extrabold` 7. Every one of
   those emits an absolute weight of its own, so lowering `--ak-body-weight` would have left 1,175
   call sites drawing at exactly the weight the ruling was removing. This block is where the ruling
   actually lands.

   ⚖️ SPECIFICITY IS THE POINT: an id plus a class is (1,1,0) and beats Tailwind's bare (0,1,0), so
   these win without `!important` and without touching a single component. Bare utilities keep
   working normally outside this mount.

   📌 THE CEILING IS 400 AND NOTHING ABOVE IT SURVIVES. semibold, bold and extrabold all resolve to
   400, because the ruling names 400 as bold and there is nothing heavier in the scale. `font-medium`
   is 350 rather than 400 so that the middle of the scale still exists - a variable axis makes 350 a
   real weight, not a rounding. ⛔ Do not "restore" a heavier bold here; the flatness at the top is
   the ruling, not an oversight.
   ========================================================= */
#akashic-health-records-patient-portal-root .font-light {
  font-weight: 200;
}
#akashic-health-records-patient-portal-root .font-normal {
  font-weight: var(--ak-body-weight);
}
#akashic-health-records-patient-portal-root .font-medium {
  font-weight: var(--ak-label-weight);
}
#akashic-health-records-patient-portal-root .font-semibold,
#akashic-health-records-patient-portal-root .font-bold,
#akashic-health-records-patient-portal-root .font-extrabold {
  font-weight: var(--ak-heading-weight);
}

/* =========================================================
   THE OVERLAY TITLE. 20px, weight 600, sage.

   🗣️ Spencer, 2026-09-09: *"The large headings like at the top of overlays should be 600 weight, one
   of the only things that would carry a weight that heavy"*, then *"reduce to 20px"*.

   ⚖️ 600 IS A DELIBERATE EXCEPTION TO THE 400 CAP, not a rule that escaped the weight sweep. The
   scale set that same day caps bold at 400 and every literal weight above it was brought down; this
   one is allowed back up because an overlay title is the only text on screen with nothing competing
   with it - it is the answer to "what is this window", and it is read once and then ignored. Anything
   else at 600 is a bug. ⛔ Do not "harmonise" this to 400.

   🚨 THE SIZE IS LOAD-BEARING FOR THE COLOUR, AND THIS IS THE ONE CAVEAT ON RECORD. Sage is 3.04:1,
   so it is legal on LARGE text (3:1) and illegal on normal text (4.5:1). WCAG's large-scale
   definition is 18 point (24px) at any weight, OR 14 point (18.66px) BOLD - and it does not define
   "bold" numerically. Audit tooling generally reads bold as 700, so 20px at 600 relies on 600 being
   accepted as bold and is very likely to be FLAGGED. Spencer chose 20px with that stated. ⭐ Two
   one-line fixes exist if it ever needs to hold up: take the size to 24px, where the exemption
   applies at any weight, or deepen the colour to about #5d7359, which reaches 4.5:1 and needs no
   size change. Do not "fix" it by nudging to 19px - that changes nothing about which floor applies.

   📌 IT COVERS THREE SELECTORS BECAUSE OVERLAYS TITLE THEMSELVES TWO DIFFERENT WAYS. Most use
   `DialogTitle`/`SheetTitle`, but some - the booking modal among them - keep the real title
   screen-reader-only and draw a separate visible heading, so a rule on the slot alone would style
   the invisible one and miss the one on screen. `.ahr-overlay-title` is for those. Styling an
   sr-only title is harmless: it is absolutely positioned at 1px and nothing shows.
   ========================================================= */
#akashic-health-records-patient-portal-root [data-slot="dialog-title"],
#akashic-health-records-patient-portal-root [data-slot="sheet-title"],
#akashic-health-records-patient-portal-root .ahr-overlay-title,
#akashic-health-records-patient-portal-root .ak-overlay__title {
  font-size: 20px;
  font-weight: 600;
  line-height: 1.3;
  letter-spacing: 0.01em;
  color: var(--sage);
}

/* Standard for explanatory text under a field or control — the "why"/"how" note that supports a label
   rather than being content in its own right. Small and italic so it reads as secondary and never
   competes with the value above it. Add `ahr-field-help` to any such text, site-wide. */
/* =========================================================
   THE HEADER ACTIONS. Bare icons, not chips.

   🗣️ Spencer, 2026-09-09: *"what I don't like are the buttons in the header"*, then *"Use just icons
   but make the appointments icon our sage color and make messages our primary blue color with count
   circle background sage. Icons need to be large and the count on messages a little smaller."*

   ⛔ WHAT WAS WRONG WAS NOT THE ICONS, IT WAS THREE IDIOMS IN ONE ROW. Schedule was a SOLID chip,
   Messages a TONAL chip, and the hamburger and org switcher were already bare - so the row had a
   loud thing, a quiet thing and two invisible things with no relationship between them. Stripping
   the two fills leaves ONE idiom for every control in the band, and after the palette softened, those
   two blue chips were the loudest surface left on the page.

   🚨 THE COLOUR IS ON THE ICON, NEVER ON THE BUTTON, and that is a contrast rule rather than a
   preference. Both buttons still render a text LABEL at >=640px (`hidden sm:inline` in the markup),
   and sage is 3.04:1 - legal for a glyph against the 3:1 UI floor, illegal for a label against 4.5:1.
   Colouring the button would have coloured the label with it and broken the wide layout silently
   while the phone looked fine. So the button keeps `--ink` for its text and the svg carries the hue.

   📌 THE COUNT IS A CORNER BADGE BECAUSE A FLAT ICON HAS NO INSIDE. The mockups put the number
   inside the speech bubble, which works when the bubble is a bespoke drawing and cannot work with a
   stroked lucide glyph. Pinning it to the corner over the glyph is the same idea from the outside,
   it survives swapping the icon for any other, and the paper-coloured ring is what keeps it reading
   as a badge ON the icon rather than a shape floating beside it.
   ⚠️ 0/0 is a MEASURED position, not a default: at -3px it looked detached, at +2/+4 it swallowed
   the glyph, and Spencer asked for the middle of the two. It overlaps by about 8.5px on each axis.
   ========================================================= */
/* 🗣️ Spencer, 2026-09-10: *"The schedule appointment button should be sage with white text/icon and
   messages should be blue with white text/font and the amber count badge on the icon just like the
   mobile version has."*

   ⛔ THIS SUPERSEDES THE BARE TREATMENT, and the note below the icon rule that forbade anchoring the
   badge to the glyph. Bare icons were tried on the running app: with flat lucide strokes and a label
   beside them they read as links rather than controls, which is not what the decks draw either - the
   deck's buttons carry no fill but their icons are 28px filled multi-colour glyphs doing that job.
   Our icons cannot, so the button does. */
/* On a phone the pair stay bare glyphs in their own colours - "keep the mobile version like we had
   it" (Spencer, 2026-09-10) - and only the labelled buttons above 640px take the fill. */
#akashic-health-records-patient-portal-root .btn.ahr-header-action {
  padding: 0;
  position: relative;
  /* the badge hangs over the glyph's corner, so nothing in the chain may clip it */
  overflow: visible;
  background-color: transparent;
  border-color: transparent;
  color: var(--ahr-header-fill);
}

/* 📏 THE TWO FLOORS, AND WHY THEY ARE HERE RATHER THAN ON THE ELEMENT.

   The patient mount puts a blanket 44px minimum on every `.btn` - Spencer's P8 ruling - and that rule
   sits about four hundred lines BELOW this one at the same specificity, so it wins on source order and
   an ordinary rule here cannot reach it. The markup used to fight that with four `!important`
   utilities (`!min-h-[34px] !min-w-[34px] sm:!min-h-0 sm:!min-w-0`), which worked and put this
   button's size in a different file from the rest of its design.

   ⭐ Adding the mount attribute scores (1,3,0) against the floor's (1,2,0), so this wins on
   SPECIFICITY and stops caring where it sits in the file. Same scope as the rule it overrides, which
   is what makes that honest rather than a trick: it is the one place the 44px floor applies.

   ⚠️ 34px is a DRAWN size from the decks, and it is the one place in this product where a drawing and
   the touch-target rule disagree. Icon-only, in a header row, at the top of the screen - kept because
   Spencer ruled the drawing, and flagged because it is a real exception rather than an oversight. */
#akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .btn.ahr-header-action {
  min-height: 34px;
  min-width: 34px;
}

#akashic-health-records-patient-portal-root .ahr-header-action--sage {
  --ahr-header-fill: var(--success);
  /* ⚠️ WHITE ON SAGE IS 3.19:1 AND KNOWINGLY UNDER THE FLOOR - the same call Spencer made for the
     green buttons, with the same mitigation, so the two cannot drift apart. A stroke does not change
     the measured ratio; it makes the label readable to a person and an automated checker will still
     flag it. ⛔ Do not remove it as decoration - it is the only reason the label holds together. */
  text-shadow:
    0 0 1px var(--success-active),
    0 0 1px var(--success-active),
    0 1px 1px var(--success-active);
}

#akashic-health-records-patient-portal-root .ahr-header-action--blue {
  --ahr-header-fill: var(--primary);
  /* No stroke here, and the difference is measured rather than stylistic: white on --primary is
     5.33:1, comfortably over the floor, so a halo would only thicken the letters. */
}

/* The label comes back at the width that shows it, and so does the padding it needs. Below this the
   button is icon-only and any horizontal padding just pushes the two icons apart. */
/* 🗣️ Spencer, 2026-09-10: *"Make those buttons in the header the same size as the 'Start again'
   button in the id verification box"* - and, in the same breath, *"keep the mobile version like we had
   it, this is just on larger screens when we show the actual buttons instead of icon only."*

   ⭐ SO THIS IS THE WHOLE OF THE CHANGE: above 640px the header actions are ORDINARY BUTTONS and take
   the standard's own geometry - 8px/16px padding on a 32px floor, measured off `Start again` on the
   running mount rather than copied from a number in a document. Below it nothing moves: a 34px
   icon-only square with a 24px glyph and the count in its corner.

   ⚠️ The icon has to come down to 16px here or the button cannot BE 32px - a 24px glyph plus 8px of
   padding each side is 40. That override lives in its own block further down, after the 24px rule it
   has to beat, because the two selectors tie and source order is the only thing separating them. */
@media (min-width: 640px) {
  #akashic-health-records-patient-portal-root .btn.ahr-header-action {
    padding: 8px 16px;
    gap: 0.5rem;
    background-color: var(--ahr-header-fill);
    border-color: var(--ahr-header-fill);
    color: #ffffff;
  }

  /* Carries the mount attribute for the same reason the block above does - without it the 44px floor
     further down the file wins and the button is 44px rather than the 32 it is being matched to. */
  #akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .btn.ahr-header-action {
    min-height: 32px;
    min-width: 0;
  }
}

/* ⚖️ `.btn.ahr-header-action`, TWO CLASSES, AND THE SECOND ONE IS LOAD-BEARING. Written as
   `#…root .ahr-header-action > svg` this scored (1,1,0) - and so does
   `#…root .btn svg { width: 16px }` three thousand lines further down this same file, which
   therefore won on source order and held the icons at 16px while the shadow and the colour from
   this very block applied normally. Measured: 16px on the running mount, with `filter` and `color`
   both correct, which is the tell for a tie rather than a missing rule.
   ⛔ Do not "simplify" this back to one class. */
/* The glyph now sits inside .ahr-header-glyph rather than directly in the button, so the child
   combinator that used to reach it no longer matches. Kept at TWO classes plus the id for the
   reason stated above - one class would tie with `.btn svg { width: 16px }` further down and lose
   on source order, silently, which is exactly how these icons were held at 16px before. */
#akashic-health-records-patient-portal-root .btn.ahr-header-action .ahr-header-glyph > svg {
  width: 24px;
  height: 24px;
  /* ⭐ A DROP-SHADOW ON THE GLYPH, NOT A BOX-SHADOW ON THE BUTTON. The button has no fill any more,
     so a box shadow would draw a rectangle around nothing. `drop-shadow` follows the stroked path
     itself, which is the only thing on screen to lift. */
  filter: var(--ak-icon-lift);
}

/* ⚙️ EQUAL SPECIFICITY, SO THIS MUST STAY BELOW THE RULE IT OVERRIDES. Both selectors score the
   same; nothing but source order decides which 16px-or-24px wins, and moving this block above the
   other one would silently restore a 41px button that looks almost right. */
@media (min-width: 640px) {
  #akashic-health-records-patient-portal-root .btn.ahr-header-action .ahr-header-glyph > svg {
    width: 16px;
    height: 16px;
    /* ⛔ AND NO LIFT ON A FILLED BUTTON. The drop-shadow exists to give a BARE glyph an edge against
       the page ground. Under a white icon on sage or blue it is a smudge, not a lift. Mobile keeps it,
       because there the glyph really is bare. */
    filter: none;
  }
}

/* 🔻 THE GLYPH IS THE BADGE'S ANCHOR, AT EVERY WIDTH. It used to be the BUTTON, which worked
   while the button was icon-sized and broke the moment the label appeared: at 640px the button grows
   to about 122px and `right: 0` parked the count over the last letter of "Messages". The old answer
   was to drop the corner idiom above 640px and set the count inline. Spencer's answer is the corner
   everywhere, on the icon - so the icon gets a box of its own to be the corner OF. */
#akashic-health-records-patient-portal-root .ahr-header-glyph {
  position: relative;
  display: inline-flex;
  flex: none;
  /* nothing here may clip a badge that deliberately overhangs */
  overflow: visible;
}

/* 🚨 WHITE NUMERAL, WHICH IS WHY THIS IS `--sage-deep` AND NOT `--sage`. Spencer: *"count number
   needs to be white"*. White on --sage #8a9475 is 3.19:1 and a 9px numeral needs 4.5:1, so the light
   sage cannot carry it; --sage-deep is 4.62:1 under white and still reads as the same hue. ⛔ Do not
   "unify" this back to --sage - the number becomes unreadable and nothing will report it. */
#akashic-health-records-patient-portal-root .ahr-header-action .ahr-count-badge {
  position: absolute;
  top: 0;
  right: 0;
  min-width: 13px;
  height: 13px;
  font-size: 9px;
  /* 🔻 IT STATES NO COLOUR, AND THAT IS THE POINT. This rule used to repeat --warning and white
     because it was the one amber count in a product of blue ones. Since 2026-09-10 every count is
     amber, so the colour comes from `.ahr-count-badge` above and this rule carries only what is
     genuinely different about sitting on a bare glyph: the corner position, the smaller size, and
     the ring. ⛔ Do not re-state the fill here "to be explicit" - a value written in two places is
     how the header drifted away from the standard in the first place.
     🗣️ Spencer, 2026-09-09, on the count that started here: *"for the messages count we could use
     --amber-ink for the background instead of sage."* (`--amber-ink` exists now and is the notice-copy
     step; `--warning` is the accent, and `--amber-fill` is the pale button one.) White on --warning is
     5.02:1, so the numeral clears AA with no outline - which matters most at 9px, the smallest text
     in the whole band, where the stroke the sage buttons rely on would smother the digit. */
  /* The ring is cut from the header's own ground, which is what shows round a bare glyph. */
  box-shadow: 0 0 0 2px var(--card);
}

/* 🚨 THE CORNER BADGE IS AN ICON-ONLY IDIOM, AND IT BREAKS THE MOMENT THE LABEL APPEARS. It is
   positioned against the BUTTON, not the glyph - they are siblings, so there is nothing narrower to
   anchor to - and above 640px the button grows to about 122px to fit the word "Messages". `right: 0`
   then parks the count at the far end of that box, over the label's last letter, where it reads as a
   badge on the WORD rather than on the icon. Caught at 1366 after the phone looked correct.
   ⭐ SO IT GOES BACK TO BEING INLINE AT THAT WIDTH, which is what it always was and is the better
   idiom there anyway: with the word "Messages" on screen, "Messages 4" needs no corner trick. The
   corner exists to attach a number to a glyph that has no room for one, and above 640px that problem
   does not exist. ⛔ Do not "fix" this by wrapping the icon in a positioned span to keep the corner
   at every width - that would hang a count off the icon while the label sits beside it unrelated. */
@media (min-width: 640px) {
  /* ⭐ INLINE, BESIDE THE LABEL, because above this width there is a label to sit beside. The corner
     treatment exists to attach a number to a glyph that has no room for one; a 16px glyph in a real
     button has less room still, and a badge small enough to fit its corner is too small to read.
     ⛔ Do not re-anchor this to the glyph "for consistency with mobile" - the two widths are drawing
     different objects, an icon and a button, and the badge belongs to whichever one is on screen. */
  #akashic-health-records-patient-portal-root .ahr-header-action .ahr-count-badge {
    position: static;
    box-shadow: none;
    /* back onto the count-badge standard's own size, which the corner treatment shrank */
    min-width: 15px;
    height: 15px;
    font-size: 10px;
  }
}

/* The assistant's mark gets the same lift - Spencer asked for it alongside the header pair, and it
   is the third bare glyph on the page. Its COLOUR is untouched: --assistant-mark is a ruling of its
   own and sits at 3.03:1 with no headroom to spend. */
#akashic-health-records-patient-portal-root .assistant-mark {
  filter: var(--ak-icon-lift);
}

/* THE ORGANIZATION MARK IS ALWAYS ROUND, on every surface. A logo fills the disc; a practice without
   one gets its initials on primary, so the brand block always has a mark beside the name. */
#akashic-health-records-patient-portal-root .ahr-org-mark,
#akashic-health-records-patient-portal-root .ak-org-mark {
  display: inline-grid;
  place-items: center;
  flex: none;
  width: var(--ak-mark-md);
  height: var(--ak-mark-md);
  border-radius: 50%;
  overflow: hidden;
  background-color: var(--primary);
  color: #ffffff;
  font-size: 12px;
  font-weight: 600;
  line-height: 1;
}

#akashic-health-records-patient-portal-root .ahr-org-mark img,
#akashic-health-records-patient-portal-root .ak-org-mark img {
  width: 100%;
  height: 100%;
  object-fit: cover;
  background-color: var(--surface);
}

/* The drawer's menu button: a 34px square on the surface with the standard line, radius 8. The
   attribute and element lift it over the header's bare-button reset. */
#akashic-health-records-patient-portal-root button.ahr-nav-menu-button[data-slot="button"] {
  width: 34px;
  height: 34px;
  min-width: 34px;
  min-height: 34px;
  padding: 0;
  border: 1px solid var(--line);
  border-radius: 8px;
  background-color: var(--surface);
  color: var(--ink-strong);
}

#akashic-health-records-patient-portal-root button.ahr-nav-menu-button[data-slot="button"]:hover {
  background-color: var(--sunken);
}

/* CURRENT WORKSPACE, above the staff navigation: a quiet caption over the standard select field. */
#akashic-health-records-patient-portal-root .ahr-ws-block {
  padding: 0 14px 14px;
}

#akashic-health-records-patient-portal-root .ahr-ws-label {
  font-size: 11px;
  font-weight: 500;
  letter-spacing: 0.06em;
  text-transform: uppercase;
  color: var(--ink-muted);
}

#akashic-health-records-patient-portal-root .ahr-ws-info {
  display: inline-flex;
  align-items: center;
  color: var(--ink-muted);
}

#akashic-health-records-patient-portal-root .ahr-ws-info svg {
  width: 13px;
  height: 13px;
}

#akashic-health-records-patient-portal-root .ahr-ws-info:hover {
  color: var(--ink-strong);
}


/* 🔻 THE PRACTICE'S PHONE NUMBER. Spencer, 2026-09-09: 600.
   ⚖️ THAT IS ABOVE THE 400 BOLD CAP, AND IT IS THE SECOND DELIBERATE EXCEPTION, after the overlay
   title. It is a named rule rather than a `font-semibold` utility for exactly that reason: a literal
   weight here would be indistinguishable from the ones the weight sweep exists to find and bring
   down, and the next person doing that sweep would "fix" it.
   ⭐ WHY IT EARNS THE EXCEPTION: this number is the fallback for a patient the interface has already
   defeated. Everything else in the band is a control they can hunt for; this is the one that has to
   be findable without hunting, and after the whole scale came down to 300/400 it was the quietest
   thing in the header rather than the clearest. */
#akashic-health-records-patient-portal-root .ahr-header-phone {
  font-weight: 600;
}

/* 🔻 THE FOUR SUMMARY TILE LABELS. Spencer, 2026-09-09: *"appointments, new message, tasks to
   complete and unpaid invoices should all have font-weight 500."*
   ⚖️ THE THIRD DELIBERATE EXCEPTION ABOVE THE 400 CAP, after the overlay title and the phone number,
   and it is a named rule for the same reason both of those are: a bare `font-medium` here resolves
   to 350 through the utility remap, and a literal `font-weight: 500` would be indistinguishable
   from the ones the weight sweep is meant to find and bring down.
   ⭐ WHY THE LABEL AND NOT THE COUNT: the count beside it is already coloured and half a pixel
   larger, so it needs no weight to lead. The label was the flattest thing in the band at 300 - the
   four tiles are the portal's primary navigation, and at body weight they read as captions rather
   than as the doors they are. */
#akashic-health-records-patient-portal-root .ahr-summary-label {
  font-weight: 500;
}

#akashic-health-records-patient-portal-root .ahr-field-help,
#akashic-health-records-patient-portal-root .ak-help {
  display: block;
  font-size: 0.75rem;
  font-style: italic;
  /* 🗣️ Spencer, 2026-09-09: *"Italic text under New Appointment heading should also be
     font-weight: 300"*. Explanatory text is the one place the app deliberately goes BELOW the body
     weight: italic already separates it, and 300 lets it recede without shrinking further.
     ⚠️ THIS ONLY RENDERS BECAUSE THE @font-face ABOVE DECLARES 200 800. It declared `400 800` until
     today, which CLAMPS a request for 300 up to 400 - so the whole rule was a silent no-op on every
     site except this dev box, where the WordPress theme happens to ship its own Manrope declared
     200 800 and that face was shadowing ours. Measured: our own subsetted file instances the wght
     axis at 300 (366.4px vs 373.2px for the same string at 400), so the glyphs are real and not
     synthesised. Narrow the declaration again and this weight silently becomes 400. */
  font-weight: 300;
  line-height: 1.4;
  color: var(--ink-muted);
}

/* The CAUTION modifier on the standard above - same size, same italic, same weight, amber instead of
   muted. It exists so a screen that needs to flag an explanatory line has ONE NAMED RULE to reach for
   rather than inventing a per-screen colour, and so every such line in the app moves together.
   ⛔ It is a MODIFIER and never stands alone: `ahr-field-help ahr-caution`, both classes. On its own
   it sets a colour on text that has none of the size, style or weight that make the standard read as
   secondary. Its first consumer is the booking modal's locked answers (the only location / the only
   practitioner offering this service), where the amber says "you could not choose this" without
   raising an alarm about it. */
#akashic-health-records-patient-portal-root .ahr-field-help.ahr-caution {
  color: var(--warning);
}

#akashic-health-records-patient-portal-root .components-input-control__input,
#akashic-health-records-patient-portal-root .components-text-control__input {
  box-sizing: border-box;
  width: 100%;
  min-width: 0;
  max-width: none;
  height: auto;
  margin: 0;
  padding: 0;
  border: 0;
  background: transparent;
  color: inherit;
  font: inherit;
  line-height: inherit;
  box-shadow: none;
  outline: none;
}

#akashic-health-records-patient-portal-root .components-input-control__backdrop {
  border: 0;
  background: transparent;
  box-shadow: none;
}

/* WordPress search and combobox controls use the wrapper as the single visible shell. */
#akashic-health-records-patient-portal-root .components-search-control input,
#akashic-health-records-patient-portal-root .components-combobox-control input {
  border: 0;
  background: transparent;
  box-shadow: none;
  outline: none;
}

#akashic-health-records-patient-portal-root .components-search-control input:focus,
#akashic-health-records-patient-portal-root .components-search-control input:focus-visible,
#akashic-health-records-patient-portal-root .components-combobox-control input:focus,
#akashic-health-records-patient-portal-root .components-combobox-control input:focus-visible {
  border: 0;
  box-shadow: none;
  outline: none;
}

/* Focus handling for visible shells */
#akashic-health-records-patient-portal-root .components-form-token-field__input:focus,
#akashic-health-records-patient-portal-root .components-form-token-field__input:focus-visible,
#akashic-health-records-patient-portal-root input[type="text"]:not(.components-form-token-field__input):not(.components-input-control__input):not(.components-search-control__input):not(.components-combobox-control__input):not(:where(.ak-field-shell) *):focus,
#akashic-health-records-patient-portal-root input[type="text"]:not(.components-form-token-field__input):not(.components-input-control__input):not(.components-search-control__input):not(.components-combobox-control__input):not(:where(.ak-field-shell) *):focus-visible,
#akashic-health-records-patient-portal-root input[type="search"]:not(.components-input-control__input):not(.components-search-control__input):not(.components-combobox-control__input):not(:where(.ak-field-shell) *):focus,
#akashic-health-records-patient-portal-root input[type="search"]:not(.components-input-control__input):not(.components-search-control__input):not(.components-combobox-control__input):not(:where(.ak-field-shell) *):focus-visible,
#akashic-health-records-patient-portal-root input[type="email"]:not(:where(.ak-field-shell) *):focus,
#akashic-health-records-patient-portal-root input[type="email"]:not(:where(.ak-field-shell) *):focus-visible,
#akashic-health-records-patient-portal-root input[type="number"]:not(:where(.ak-field-shell) *):focus,
#akashic-health-records-patient-portal-root input[type="number"]:not(:where(.ak-field-shell) *):focus-visible,
#akashic-health-records-patient-portal-root input[type="date"]:not(:where(.ak-field-shell) *):focus,
#akashic-health-records-patient-portal-root input[type="date"]:not(:where(.ak-field-shell) *):focus-visible,
#akashic-health-records-patient-portal-root input[type="datetime-local"]:not(:where(.ak-field-shell) *):focus,
#akashic-health-records-patient-portal-root input[type="datetime-local"]:not(:where(.ak-field-shell) *):focus-visible,
#akashic-health-records-patient-portal-root input:where([data-slot="input"]):not([type]):not(:where(.ak-field-shell) *):focus,
#akashic-health-records-patient-portal-root input:where([data-slot="input"]):not([type]):not(:where(.ak-field-shell) *):focus-visible,
#akashic-health-records-patient-portal-root textarea:focus,
#akashic-health-records-patient-portal-root textarea:focus-visible {
  border-color: var(--primary);
  box-shadow: 0 0 0 3px rgb(var(--primary-rgb) / 0.15);
  outline: none;
}


/* =========================================================
   WORDPRESS CHECKBOXCONTROL NORMALIZATION
   Use the native checkbox box for state and suppress Gutenberg's
   separate SVG checkmark so it cannot drift outside the input.
   ========================================================= */

#akashic-health-records-patient-portal-root .components-checkbox-control__input-container {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  width: 24px;
  height: 24px;
  min-width: 24px;
  flex: 0 0 24px;
}


#akashic-health-records-patient-portal-root .components-checkbox-control__checked {
  display: none;
}

/* =========================================================
   GLOBAL FOCUS DISABLE (INTENTIONAL)
   Remove all focus outlines/rings across the app
   ========================================================= */

#akashic-health-records-patient-portal-root *:focus,
#akashic-health-records-patient-portal-root *:focus-visible {
  outline: none;
}

/* =========================================================
   3A. BUTTON VISUAL NORMALIZATION
   Prevent theme/plugin button bleed while retaining layout/positioning
   ========================================================= */

#akashic-health-records-patient-portal-root [data-slot="button"] {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  box-sizing: border-box;
  font-family: inherit;
  user-select: none;
  -webkit-user-select: none;
  -webkit-tap-highlight-color: transparent;
  cursor: pointer;
  color: inherit;
  background-color: transparent;
  background-image: none;
  border: none;
  box-shadow: none;
  text-decoration: none;
  text-shadow: none;
}

#akashic-health-records-patient-portal-root [data-slot="button"]:hover,
#akashic-health-records-patient-portal-root [data-slot="button"]:focus,
#akashic-health-records-patient-portal-root [data-slot="button"]:active {
  background-image: none;
  box-shadow: none;
  text-decoration: none;
  text-shadow: none;
}

#akashic-health-records-patient-portal-root [data-slot="button"]:disabled,
#akashic-health-records-patient-portal-root [data-slot="button"][disabled],
#akashic-health-records-patient-portal-root [data-slot="button"][aria-disabled="true"] {
  pointer-events: none;
  opacity: 0.5;
  cursor: default;
}

#akashic-health-records-patient-portal-root [data-slot="button"][data-state="open"]:focus-visible,
#akashic-health-records-patient-portal-root [data-slot="button"][data-state="checked"]:focus-visible,
#akashic-health-records-patient-portal-root [data-slot="button"][data-state="active"]:focus-visible,
#akashic-health-records-patient-portal-root [data-slot="button"][data-state="on"]:focus-visible,
#akashic-health-records-patient-portal-root [data-slot="button"][aria-pressed="true"]:focus-visible,
#akashic-health-records-patient-portal-root [data-slot="button"][aria-current="true"]:focus-visible,
#akashic-health-records-patient-portal-root [data-slot="button"][data-selected="true"]:focus-visible {
  outline: 2px solid var(--ring);
  outline-offset: 2px;
}

#akashic-health-records-patient-portal-root [data-slot="button"][data-selected="true"],
#akashic-health-records-patient-portal-root [data-slot="button"][aria-pressed="true"] {
  border-color: inherit;
}

/* =========================================================
   3A-TOUCH. TOUCH TARGETS — PATIENT PORTAL ONLY (card 235, finding P8)
   =========================================================

   Spencer, 2026-08-11, ruling on P8: 44px minimum across the PATIENT PORTAL.

   Measured before the ruling, across all 26 patient surfaces at 390x844: the smallest interactive
   element was 20px on nearly every page, 16px for the dashboard's "View All", and 14px on
   My Records > Profile, where 21 of 23 controls were under 44. Apple's HIG floor and WCAG 2.5.5
   are both 44x44. The patient portal is the surface deliberately optimized for a phone, and the
   beta cohort skews senior — this is operability, not polish.

   🚨 WHY THE SELECTOR IS `#id[data-akashic-mount="frontend"]` AND NOT EITHER HALF ALONE

   1. The ID alone would be WRONG. All five mounts render the SAME element id — the patient
      shortcode, the STAFF shortcode, both public-form paths and the wp-admin menu page. Scoping on
      `#akashic-health-records-patient-portal-root` means "anywhere this plugin renders", so it
      would push 44px onto dense staff tables and WordPress admin, which the ruling did not ask for.
      `data-akashic-mount` is published by `main.tsx` from `getMountContext()` for exactly this.

   2. The ATTRIBUTE alone would be INERT. `[data-akashic-mount="frontend"] .btn` scores (0,2,0)
      while the existing `#…root .btn { min-height: 2.25rem }` scores (1,1,0) — an id beats any
      number of classes and attributes, so the override would silently lose and nothing would move.
      Writing both on the same compound gives (1,2,0), which wins by one attribute.

   ⚖️ TWO DIFFERENT TREATMENTS, deliberately:
   - CONTROLS (buttons, tabs, fields) get a real `min-height`. They SHOULD look tappable, and
     growing 36 -> 44 is a visible, intended change.
   - BARE TEXT LINKS get a padding + equal negative margin instead. That expands the hit area to
     44px while leaving the layout byte-identical, so a link inside a sentence does not blow its
     line spacing apart and the screens already walked in this pass stay valid.
     ⚠️ The trade: two links stacked closer than 28px apart will have overlapping hit areas. Check
     any vertical list of links before assuming this is free.
   ========================================================= */

#akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] {
  /* Fields rise with the buttons so a form does not end up with 44px buttons beside 42px inputs. */
  --ak-field-height: 44px;
}

#akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .btn,
#akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .btn-blue-sm,
#akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .btn-blue-ghost-sm,
#akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] [data-slot="button"],
#akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] [role="tab"],
#akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] [data-slot="tabs-trigger"] {
  min-height: 44px;
}

/* Bare text links - hit area only, zero layout movement (see the note above). `inline-flex` is NOT
   applied here on purpose: changing a link's display is what moves the surrounding text.

   `.ahr-link-panel` IS THE EXCEPTION THIS RULE'S OWN NOTE PREDICTS. "Zero layout movement" holds for
   a link inside a sentence, where nothing is painted: the padding grows an invisible box and the
   negative margin gives the space straight back. A link drawn as a PANEL paints its box - border and
   tint - so the same pair grows the visible panel by 28px and then lifts it 14px over whatever sits
   above it.

   Measured on the mount, patient Collaboration Teams -> a team, 1400x950: "Go to the conversation" is
   a full-width tinted bar with a hairline, and its top edge landed at y=411 against a subtitle whose
   line box ends at y=425. The bottom 14px of "8 members across 3 practices and your family" was
   underneath an opaque panel.

   Panel-shaped links carry this class and keep their own box. They do not need the rule: this one is
   44px tall on its own (11 + 20 + 11 + 2px of border). ANY link that paints a background or a border
   should take it. */
#akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] a:not(.btn):not([data-slot="button"]):not(.ahr-link-panel) {
  padding-block: 14px;
  margin-block: -14px;
}

/* Icon-only controls need WIDTH as well as height — a 44px-tall, 40px-wide target is still a miss,
   and the portal's own nav toggle is exactly that. Deliberately NOT excluding `[data-slot="button"]`
   here: the rule above gives those height only, and the nav toggle is one of them (measured 40x36).
   Scoped to buttons whose sole child is an icon, so a button with a text label is untouched — its
   width comes from its text and forcing 44px on it would stretch short labels. */
/* Only a NAMED button is icon-only: :only-child ignores text, so an icon beside a bare label matches too. */
#akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] button:is([aria-label], [aria-labelledby], [title]):has(> svg:only-child) {
  min-width: 44px;
  min-height: 44px;
}

/* ── Card 275 — the STAFF pointer floor. 24px, and ONLY the hit area grows ─────────────────────────
   🗣️ Spencer, 2026-08-13: *"the front desk likely uses a large monitor on a desktop computer but more
   info in view in my opinion is more valuable than larger font size here."* The type stays small; the
   original finding conflated a glyph size with a CLICK TARGET, and in a dense patient list a mis-click
   means opening the wrong patient's chart.

   🚨 24 AND NOT 44, AND THE PAIR IS THE POINT. 44px is the TOUCH floor (Apple HIG / WCAG 2.5.5 AAA) and
   belongs to the patient portal, where P8 shipped it above. 24px is the POINTER floor (WCAG 2.5.8 AA)
   and is what a mouse-driven staff surface needs. ⛔ Do not "harmonise" these to one number — they are
   different input devices, and raising staff to 44 destroys the density this rule exists to protect.

   ⛔ THE VISIBLE SIZE MUST NOT GROW TO MEET THE TARGET. That is the whole mechanism: `min-height` on a
   control whose text is smaller simply pads it. A later accessibility sweep that sees a small type size
   and "fixes" it by enlarging the glyph destroys the density deliberately being kept. The paired
   assertion lives in `typeScaleTokens`/`staffPointerTarget` — both numbers together, never one alone.

   🔑 THE SELECTOR IS A COMPOUND FOR THE REASON P8 ALREADY PAID FOR: all five mounts render the SAME
   element id, so the id alone would push this onto the patient portal and wp-admin. The attribute ALONE
   would be inert — `[data-akashic-mount="staff"] .btn` scores (0,2,0) against the existing
   `#…root .btn` at (1,1,0). Both halves, on one compound, or the rule silently does nothing.
   :where keeps the floor below .btn and its small sizes. */
#akashic-health-records-patient-portal-root[data-akashic-mount="staff"] :where(.btn, [data-slot="button"]),
#akashic-health-records-patient-portal-root[data-akashic-mount="staff"] [role="tab"],
#akashic-health-records-patient-portal-root[data-akashic-mount="staff"] [data-slot="tabs-trigger"] {
  min-height: 24px;
}

/* Icon-only controls need WIDTH too — a 24px-tall, 18px-wide target is still a miss. Scoped to buttons
   whose sole child is an icon, so a labelled button keeps its text-derived width. */
/* Only a NAMED button is icon-only: :only-child ignores text, so an icon beside a bare label matches too. */
#akashic-health-records-patient-portal-root[data-akashic-mount="staff"] button:is([aria-label], [aria-labelledby], [title]):has(> svg:only-child) {
  min-width: 24px;
  min-height: 24px;
}

/* =========================================================
   3B. BUTTON VARIANT SYSTEM
   Shared semantic button classes for consistency and easier overrides
   ========================================================= */

#akashic-health-records-patient-portal-root .btn {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  gap: 7px;
  min-height: 30px;
  padding: 0 12px;
  border: 1px solid transparent;
  /* 🔻 2026-09-08 - 2px, the settled corner. It was 0.3rem, which is ~6px here and reads as a
     different button from the one the approved decks draw. An absolute value on purpose: the
     standard is two pixels, not a fraction of whatever root size a mount happens to set.
     The base is the standard deck button, 30px with 12px sides; the frontend mount lifts it to 44px. */
  border-radius: 2px;
  font-size: var(--ak-font-sm);
  font-weight: 500;
  line-height: 1;
  white-space: nowrap;
  text-align: center;
  box-sizing: border-box;
  user-select: none;
  transition:
    background-color 0.2s ease,
    border-color 0.2s ease,
    color 0.2s ease,
    opacity 0.2s ease,
    transform 0.15s ease,
    box-shadow 0.2s ease;
}

#akashic-health-records-patient-portal-root .btn svg {
  flex-shrink: 0;
}

#akashic-health-records-patient-portal-root .btn:not(:disabled):active {
  transform: translateY(1px);
}

/* WordPress's .components-button adds a blue focus box-shadow that lingers after a mouse click and mismatches
   the colored btn variants. Suppress it to match the app's ring-free focus convention (see section 3A). */
#akashic-health-records-patient-portal-root .btn:focus {
  box-shadow: none;
}

/* Disabled buttons read as disabled (ghosted). Cursor deliberately left as-is (no not-allowed). */
#akashic-health-records-patient-portal-root .btn:disabled {
  opacity: 0.5;
}

/* BLUE BUTTONS (PRIMARY) */
#akashic-health-records-patient-portal-root .btn-blue {
  background-color: var(--primary);
  border-color: var(--primary);
  color: var(--primary-foreground);
}

#akashic-health-records-patient-portal-root .btn-blue:hover:not(:disabled) {
  background-color: rgb(var(--primary-rgb) / 0.9);
  border-color: rgb(var(--primary-rgb) / 0.9);
  color: var(--primary-foreground);
}

#akashic-health-records-patient-portal-root .btn-blue:active:not(:disabled) {
  background-color: rgb(var(--primary-rgb) / 0.82);
  border-color: rgb(var(--primary-rgb) / 0.82);
  color: var(--primary-foreground);
}

/* BLUE GHOST BUTTONS (BORDER ONLY) */
/* THE GREY BUTTON IS GONE, 2026-09-07, and it is not coming back.
   The standard has eight buttons and the colour is the purpose; grey carried no purpose, and the
   decks never drew one - 68 neutral and exit acts across them are all blue-ghost. Every one of the
   31 uses became blue-ghost to match.
   The decisive reason is the dark theme: the four coloured variants resolve through tokens and flip
   with it for free, but this one mixed an #eaeaea background literal with var(--foreground) text, so
   in dark mode the text would flip to near-white over a near-white button and the control would
   disappear. A hue survives a theme flip; a neutral is defined against the background and has to be
   re-derived per theme, which is where theme bugs live.
   Reasoning: akashic-docs/_CLAUDE/deck-vs-app-answers.md and RULINGS.md, 2026-09-07. */
#akashic-health-records-patient-portal-root .btn-blue-ghost {
  background-color: transparent;
  border-color: var(--line);
  color: var(--primary);
}

#akashic-health-records-patient-portal-root .btn-blue-ghost:hover:not(:disabled) {
  background-color: rgb(var(--primary-rgb) / 0.08);
  color: var(--primary);
}

#akashic-health-records-patient-portal-root .btn-blue-ghost:active:not(:disabled) {
  background-color: rgb(var(--primary-rgb) / 0.14);
  color: var(--primary);
}

/* =========================================================
   BLUE TONAL BUTTONS — card 271, ruling D7 ("Persistent ≠ loud")

   A standing utility is a control that is ALWAYS on screen (Schedule appointment, Contact us, the
   patient header actions). It has to stay reachable without competing with the one thing the user
   actually came to do.

   WHY TONAL RATHER THAN A NEW COLOUR: these navigate, so they stay in the BLUE role — soft fill,
   blue text, instead of solid. A different hue would assert "a different kind of action happens
   here", which is false and muddies the role system.
      solid = act now  ·  tonal = same role, lower priority  ·  ghost = secondary/inline
   ⛔ Do not "simplify" a tonal button into a ghost. Ghost is transparent and reads as optional;
      tonal is a filled, standing control that is simply quiet.

   🚨 SMALLER TO LOOK AT, NOT SMALLER TO HIT — this is the half that gets lost.
   The visible box is 34px; the tap target is padded back to 44px with a transparent ::after that
   takes no layout space. Literally shrinking these to 34px would break the touch-target floor for
   exactly the older, tech-averse patients that "nothing important lives only behind an icon" (D6)
   exists to protect — and standing utilities are the controls those users need most.

   ⚠️ SPECIFICITY, and it is load-bearing (the trap P8 already paid for once): on the patient
   portal, `#…root[data-akashic-mount="frontend"] .btn` sets min-height 44px at (1,2,0). A rule
   written as `#…root .btn-blue-tonal` scores (1,1,0) and would SILENTLY LOSE — the button would
   look identical to every other one and nothing would error. The frontend override below repeats
   the attribute on the same compound so it matches at (1,2,0) and wins on source order.
   ========================================================= */
#akashic-health-records-patient-portal-root .btn-blue-tonal {
  position: relative;
  min-height: 34px;
  background-color: var(--blue-soft);
  border-color: transparent;
  color: var(--primary);
}

/* The hit area. `content` + `position:absolute` keep it out of layout entirely, so a tonal button
   in a tight header does not push its neighbours around. Hit-testing attributes a click on a
   pseudo-element to its originating element, so this genuinely enlarges the target. */
#akashic-health-records-patient-portal-root .btn-blue-tonal::after {
  content: '';
  position: absolute;
  left: 0;
  right: 0;
  top: 50%;
  height: 44px;
  transform: translateY(-50%);
}

/* Patient portal: the visible box stays 34px. Without this the 44px rule for `.btn` wins and the
   "quiet" treatment disappears — see the specificity note above. The hit area is already 44px via
   the ::after, so nothing is lost by opting out of the blanket min-height here. */
#akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .btn-blue-tonal {
  min-height: 34px;
}

#akashic-health-records-patient-portal-root .btn-blue-tonal:hover:not(:disabled) {
  background-color: rgb(var(--primary-rgb) / 0.16);
  border-color: transparent;
  color: var(--primary);
}

#akashic-health-records-patient-portal-root .btn-blue-tonal:active:not(:disabled) {
  background-color: rgb(var(--primary-rgb) / 0.24);
  border-color: transparent;
  color: var(--primary);
}

/* 🔀 CARD 272's OWN TONAL VARIANT WAS DELETED HERE, DELIBERATELY — card 271 landed one first.
   The patient home's standing utilities (Schedule appointment · Contact us) now wear the
   `.btn-blue-tonal` defined ABOVE, which is the design-system's version and the one to keep:
   it fills from `--blue-soft` rather than an alpha of `--primary`, and its 44px hit area is a
   centred fixed-height `::after` rather than a ±5px bleed, so it holds whatever the visible box
   becomes. The 34/44 split is guarded by `components/ui/__tests__/warmPaletteTokens.test.ts`.
   ⛔ Do not reintroduce a second tonal class. Two definitions of one variant is how a "quiet"
   button silently stops being quiet — the later rule in source order wins per property, and
   nothing errors. (The duplicate survived a clean rebase: git saw two additions in different
   places, not one collision.) */

/* GREEN BUTTONS (SUCCESS) */
#akashic-health-records-patient-portal-root .btn-green {
  background-color: var(--success);
  border-color: var(--success);
  color: var(--primary-foreground);
  /* 🔻 THE STROKE THAT LETS THE LIGHT SAGE CARRY A WHITE LABEL. Spencer, 2026-09-09: sage fill, white
     text, and the darker sage drawn around the letters.
     ⚖️ `text-shadow` RATHER THAN `-webkit-text-stroke`, and the reason is what happens at small
     sizes. A real stroke centres on the glyph outline, so half of it is painted INSIDE the letter and
     the white gets thinner - `paint-order: stroke fill` fixes that by drawing the fill last, but
     paint-order on HTML text is not supported everywhere, and where it is missing the label silently
     thins instead of failing. A shadow halo never touches the glyph, is supported everywhere, and at
     this weight is indistinguishable from a stroke.
     📌 Three offsets, not one: two at zero offset build an even ring, and the third at 1px down
     thickens the underside where a light fill loses the letter first. ⛔ Do not raise the blur - past
     1px it stops being an edge and starts being a smudge behind the text. */
  text-shadow:
    0 0 1px var(--success-active),
    0 0 1px var(--success-active),
    0 1px 1px var(--success-active);
}

#akashic-health-records-patient-portal-root .btn-green:hover:not(:disabled) {
  background-color: var(--success-hover);
  border-color: var(--success-hover);
  color: var(--primary-foreground);
}

#akashic-health-records-patient-portal-root .btn-green:active:not(:disabled) {
  background-color: var(--success-active);
  border-color: var(--success-active);
  color: var(--primary-foreground);
}

/* THE HALO HAS TO BE RESTATED FOR THE INTERACTION STATES, AND THIS IS A SPECIFICITY ACCIDENT RATHER
   THAN A SECOND OPINION. Section 3A above sets `text-shadow: none` on the button primitive to keep a
   WordPress theme from drawing its own; its base rule scores (1,1) and `.btn-green` above scores (1,1)
   too, so the halo wins at rest on source order - which is the file already saying the halo is meant to
   survive 3A. But 3A ALSO states `[data-slot="button"]:hover`, `:focus` and `:active`, and each of
   those scores (1,2). They outrank `.btn-green`, so on a shadcn <Button> carrying `btn btn-green` the
   stroke Spencer ruled in on 2026-09-09 vanished the moment the control was hovered or focused.
   Measured on the receptionist's Book affirmative 2026-09-13: halo at rest, `none` on hover, `none` on
   focus.
   FOCUS IS THE STATE THIS COSTS MOST. Hover at least darkens the fill to --success-hover (3.67:1);
   focus does not darken at all, so it was the ruled 3.19:1 with the one thing mitigating it removed,
   in the state a keyboard reader sits in. `:active` matters least - --success-active is 4.62:1 and
   clears AA unaided - and is restated anyway so the four states cannot drift apart.
   `:not(:disabled)` is not decoration: it takes these to (1,3) so they beat 3A on SPECIFICITY rather
   than on source order, and it matches the shape of the `:hover`/`:active` rules already above.
   DO NOT fix this by editing section 3A. 3A stops theme bleed on every button in the product; the
   narrow rule belongs with the one variant that needs a stroke.
   Do not remove this as duplication of the base rule - the base rule does not apply in these states */
#akashic-health-records-patient-portal-root .btn-green:hover:not(:disabled),
#akashic-health-records-patient-portal-root .btn-green:focus:not(:disabled),
#akashic-health-records-patient-portal-root .btn-green:active:not(:disabled) {
  text-shadow:
    0 0 1px var(--success-active),
    0 0 1px var(--success-active),
    0 1px 1px var(--success-active);
}

/* GREEN GHOST BUTTONS (BORDER ONLY) */
#akashic-health-records-patient-portal-root .btn-green-ghost {
  background-color: transparent;
  border-color: var(--success);
  color: var(--success);
}

#akashic-health-records-patient-portal-root .btn-green-ghost:hover:not(:disabled) {
  background-color: rgba(22, 163, 74, 0.08);
  color: var(--success);
}

#akashic-health-records-patient-portal-root .btn-green-ghost:active:not(:disabled) {
  background-color: rgba(22, 163, 74, 0.14);
  color: var(--success);
}

/* RED BUTTONS (DESTRUCTIVE) */
#akashic-health-records-patient-portal-root .btn-red {
  background-color: var(--danger);
  border-color: var(--danger);
  color: var(--primary-foreground);
}

#akashic-health-records-patient-portal-root .btn-red:hover:not(:disabled) {
  background-color: var(--danger-hover);
  border-color: var(--danger-hover);
  color: var(--primary-foreground);
}

#akashic-health-records-patient-portal-root .btn-red:active:not(:disabled) {
  background-color: var(--danger-active);
  border-color: var(--danger-active);
  color: var(--primary-foreground);
}

/* RED GHOST BUTTONS (BORDER ONLY) */
#akashic-health-records-patient-portal-root .btn-red-ghost,
#akashic-health-records-patient-portal-root .components-button.btn-red-ghost {
  background-color: transparent;
  border: 1px solid var(--danger);
  color: var(--danger);
}

#akashic-health-records-patient-portal-root .btn-red-ghost:hover:not(:disabled),
#akashic-health-records-patient-portal-root .components-button.btn-red-ghost:hover:not(:disabled) {
  background-color: rgba(220, 38, 38, 0.08);
  color: var(--danger);
}

#akashic-health-records-patient-portal-root .btn-red-ghost:active:not(:disabled),
#akashic-health-records-patient-portal-root .components-button.btn-red-ghost:active:not(:disabled) {
  background-color: rgba(220, 38, 38, 0.14);
  color: var(--danger);
}

/* AMBER BUTTONS - THE FOURTH OF THE EIGHT, AND THE APP HAD NONE.
 *
 * The standard sheet defines amber and this file did not, so every amber control in the product was
 * hand-rolled: the practice switcher wrote the ramp out by hand with a comment saying `btn-amber`
 * "does not exist", and the shared portal-departure card then did the same. That works, looks right,
 * and is exactly how a settled treatment drifts - the next one is a third hand-roll by somebody who
 * never saw the first two. It has already manufactured work in the other direction, when a deck review
 * found a compliant amber control, checked it against a standard the app could not express, and was one
 * step from "fixing" it.
 *
 * WHAT AMBER MEANS, and it was never an open question - only an unread one. The standard's own section
 * says `btn-amber` is "a state or a non-primary act", and the app already ships it that way on Mark as
 * Uninsured. Three shapes were parked waiting for a ruling that already existed:
 *
 *   the SAFE half of a destructive confirm   Keep it, Stay Logged In
 *   PROCEEDING PAST A WARNING                Reply anyway
 *   either half of an EITHER/OR where both outcomes are expensive - and both halves take the SAME
 *   variant, because a colour difference there is the product recommending one, and on "Not me /
 *   This is me" it has no business recommending either.
 *
 * ⛔ Red would put the SAFE choice in the danger colour and blue would make backing out look like the
 * primary act. Amber is neither, which is the whole reason it exists.
 *
 * TINTED RATHER THAN SATURATED, unlike blue, green and red: a fill with dark amber ink and a border to
 * hold its edge, matching `mockups/_standard.css` value for value. The three tokens it needs are new -
 * `--warning` is the ink for text and icons and is too dark against a tint at button size.
 */
#akashic-health-records-patient-portal-root .btn-amber {
  background-color: var(--amber-fill);
  border-color: var(--amber-line);
  color: var(--amber-ink);
}

#akashic-health-records-patient-portal-root .btn-amber:hover:not(:disabled) {
  background-color: var(--amber-fill-hover);
  border-color: var(--amber-line);
  color: var(--amber-ink);
}

#akashic-health-records-patient-portal-root .btn-amber:active:not(:disabled) {
  background-color: var(--amber-fill-active);
  border-color: var(--amber-line);
  color: var(--amber-ink);
}

#akashic-health-records-patient-portal-root .btn-amber-sm {
  background-color: var(--amber-fill);
  border-color: var(--amber-line);
  color: var(--amber-ink);
}

#akashic-health-records-patient-portal-root .btn-amber-sm:hover:not(:disabled) {
  background-color: var(--amber-fill-hover);
  border-color: var(--amber-line);
  color: var(--amber-ink);
}

/* THE AMBER GHOSTS TAKE `--warning` FOR THEIR INK, NOT `--amber-ink`, and the standard sheet says why
 * in the same words: with no fill behind it the darker ink reads as muddy. */
#akashic-health-records-patient-portal-root .btn-amber-ghost,
#akashic-health-records-patient-portal-root .components-button.btn-amber-ghost {
  background-color: transparent;
  border: 1px solid var(--amber-line);
  color: var(--warning);
}

#akashic-health-records-patient-portal-root .btn-amber-ghost:hover:not(:disabled),
#akashic-health-records-patient-portal-root .components-button.btn-amber-ghost:hover:not(:disabled) {
  background-color: var(--amber-soft);
  color: var(--warning);
}

#akashic-health-records-patient-portal-root .btn-amber-ghost:active:not(:disabled),
#akashic-health-records-patient-portal-root .components-button.btn-amber-ghost:active:not(:disabled) {
  background-color: var(--amber-fill);
  color: var(--warning);
}

/* The small amber ghost: a state or a non-primary act on a row or toolbar. */
#akashic-health-records-patient-portal-root .btn-amber-ghost-sm {
  background-color: transparent;
  border-color: var(--amber-line);
  color: var(--warning);
}
#akashic-health-records-patient-portal-root .btn-amber-ghost-sm:hover:not(:disabled) {
  background-color: var(--amber-soft);
  color: var(--warning);
}
#akashic-health-records-patient-portal-root .btn-amber-ghost-sm:active:not(:disabled) {
  background-color: var(--amber-fill);
  color: var(--warning);
}
/* GRAY BUTTONS (NEUTRAL) */


/* GRAY GHOST BUTTONS (BORDER ONLY) */


/* =========================================================
   BUSY STATE (.btn-busy)  —  card 132, the WordPress <Button isBusy> replacement
   =========================================================
   WordPress's Button has an `isBusy` prop (256 call sites here) that paints an animated
   diagonal-stripe wash while an action is in flight. There is no Radix or Tailwind equivalent, so
   per Spencer's ruling it lives here as ONE reusable class rather than being restated at every call
   site — the point being that refining the look later is a single CSS edit.

   Usage:  className={`btn btn-blue ${saving ? 'btn-busy' : ''}`}  disabled={saving}
   `isBusy` does NOT disable the button in WordPress, so this class does not either — pair it with
   `disabled` where the action must not re-fire (which is what nearly every call site does).
   Colour-agnostic on purpose: a translucent white wash reads correctly on blue, green, red and gray
   without a per-variant rule. */
#akashic-health-records-patient-portal-root .btn-busy {
  background-image: linear-gradient(
    -45deg,
    rgba(255, 255, 255, 0.25) 25%,
    transparent 25%,
    transparent 50%,
    rgba(255, 255, 255, 0.25) 50%,
    rgba(255, 255, 255, 0.25) 75%,
    transparent 75%,
    transparent
  );
  background-size: 1rem 1rem;
  animation: ak-btn-busy 1s linear infinite;
  cursor: progress;
}

/* Ghost variants sit on a light background, where a white wash is invisible — darken instead. */
#akashic-health-records-patient-portal-root .btn-blue-ghost.btn-busy,
#akashic-health-records-patient-portal-root .btn-green-ghost.btn-busy,
#akashic-health-records-patient-portal-root .btn-red-ghost.btn-busy {
  background-image: linear-gradient(
    -45deg,
    rgba(0, 0, 0, 0.08) 25%,
    transparent 25%,
    transparent 50%,
    rgba(0, 0, 0, 0.08) 50%,
    rgba(0, 0, 0, 0.08) 75%,
    transparent 75%,
    transparent
  );
}

@keyframes ak-btn-busy {
  from { background-position: 0 0; }
  to { background-position: 1rem 0; }
}

/* Respect a reduced-motion preference: keep the stripes, drop the animation. */
@media (prefers-reduced-motion: reduce) {
  #akashic-health-records-patient-portal-root .btn-busy {
    animation: none;
  }
}

/* =========================================================
   SMALL BUTTON VARIANTS (-sm)
   Same palette as each base variant, just a tighter font + padding for
   compact/inline actions (e.g. an inline field editor). Use `btn btn-<variant>-sm`.
   ========================================================= */
/* Two-class selectors (.btn.btn-*-sm) so the compact size beats `button.btn` (min-height:30px; padding:0 12px)
   at line ~2538, which is element+class specificity (1,1,1) and would otherwise win this tie. */
#akashic-health-records-patient-portal-root .btn.btn-blue-sm,
#akashic-health-records-patient-portal-root .btn.btn-blue-ghost-sm,
#akashic-health-records-patient-portal-root .btn.btn-green-sm,
#akashic-health-records-patient-portal-root .btn.btn-green-ghost-sm,
#akashic-health-records-patient-portal-root .btn.btn-red-sm,
#akashic-health-records-patient-portal-root .btn.btn-red-ghost-sm,
#akashic-health-records-patient-portal-root .btn.btn-amber-ghost-sm {
  height: auto;
  min-height: 26px;
  padding: 0 9px;
  font-size: 12.5px;
  gap: 7px;
}

/* Every download action wears the blue ghost and keeps its label on one line. */
#akashic-health-records-patient-portal-root [data-slot="button"]:not([data-nav-button]):has(> svg.lucide-download) {
  background-color: transparent;
  border: 1px solid var(--primary);
  color: var(--primary);
  white-space: nowrap;
  height: auto;
  min-height: 25px;
  padding: 0 9px;
  gap: 7px;
  border-radius: 2px;
  line-height: 1.55;
  font-weight: 500;
}
#akashic-health-records-patient-portal-root [data-slot="button"]:not([data-nav-button]):has(> svg.lucide-download):hover:not(:disabled) {
  background-color: rgb(var(--primary-rgb) / 0.08);
  color: var(--primary);
}

/* Blue */
#akashic-health-records-patient-portal-root .btn-blue-sm {
  background-color: var(--primary);
  border-color: var(--primary);
  color: var(--primary-foreground);
}
#akashic-health-records-patient-portal-root .btn-blue-sm:hover:not(:disabled) {
  background-color: rgb(var(--primary-rgb) / 0.9);
  border-color: rgb(var(--primary-rgb) / 0.9);
  color: var(--primary-foreground);
}
#akashic-health-records-patient-portal-root .btn-blue-sm:active:not(:disabled) {
  background-color: rgb(var(--primary-rgb) / 0.82);
  border-color: rgb(var(--primary-rgb) / 0.82);
  color: var(--primary-foreground);
}
#akashic-health-records-patient-portal-root .btn-blue-ghost-sm {
  background-color: transparent;
  border-color: var(--line);
  color: var(--primary);
}
#akashic-health-records-patient-portal-root .btn-blue-ghost-sm:hover:not(:disabled) {
  background-color: rgb(var(--primary-rgb) / 0.08);
  color: var(--primary);
}
#akashic-health-records-patient-portal-root .btn-blue-ghost-sm:active:not(:disabled) {
  background-color: rgb(var(--primary-rgb) / 0.14);
  color: var(--primary);
}

/* Green */
#akashic-health-records-patient-portal-root .btn-green-sm {
  background-color: var(--success);
  border-color: var(--success);
  color: var(--primary-foreground);
  /* THE SAME HALO `.btn-green` CARRIES, AND FOR THE SAME REASON. White on sage is 3.19:1 whatever
     size the button is; the small variant was declared from the full-size one's fill, border and
     colour and stopped one line short of the mitigation. `.ahr-header-action--sage` says it outright -
     "the same call Spencer made for the green buttons, with the same mitigation, so the two cannot
     drift apart" - and these two had drifted. Copied verbatim rather than retuned: a smaller label
     needs the edge more, not less. */
  text-shadow:
    0 0 1px var(--success-active),
    0 0 1px var(--success-active),
    0 1px 1px var(--success-active);
}
#akashic-health-records-patient-portal-root .btn-green-sm:hover:not(:disabled) {
  background-color: var(--success-hover);
  border-color: var(--success-hover);
  color: var(--primary-foreground);
}
#akashic-health-records-patient-portal-root .btn-green-sm:active:not(:disabled) {
  background-color: var(--success-active);
  border-color: var(--success-active);
  color: var(--primary-foreground);
}

/* THE SAME RESTATEMENT FOR THE SMALL VARIANT, FOR THE REASON THE COMMENT ABOVE IT ALREADY GIVES:
   "the same mitigation, so the two cannot drift apart". These two have drifted once before. Only one
   shadcn <Button> in the tree carries `btn-green-sm` today, so this is the pair being kept honest
   rather than a second observed fault - said plainly rather than implied */
#akashic-health-records-patient-portal-root .btn-green-sm:hover:not(:disabled),
#akashic-health-records-patient-portal-root .btn-green-sm:focus:not(:disabled),
#akashic-health-records-patient-portal-root .btn-green-sm:active:not(:disabled) {
  text-shadow:
    0 0 1px var(--success-active),
    0 0 1px var(--success-active),
    0 1px 1px var(--success-active);
}
#akashic-health-records-patient-portal-root .btn-green-ghost-sm {
  background-color: transparent;
  border-color: var(--success);
  color: var(--success);
}
#akashic-health-records-patient-portal-root .btn-green-ghost-sm:hover:not(:disabled) {
  background-color: rgba(22, 163, 74, 0.08);
  color: var(--success);
}
#akashic-health-records-patient-portal-root .btn-green-ghost-sm:active:not(:disabled) {
  background-color: rgba(22, 163, 74, 0.14);
  color: var(--success);
}

/* Red */
#akashic-health-records-patient-portal-root .btn-red-sm {
  background-color: var(--danger);
  border-color: var(--danger);
  color: var(--primary-foreground);
}
#akashic-health-records-patient-portal-root .btn-red-sm:hover:not(:disabled) {
  background-color: var(--danger-hover);
  border-color: var(--danger-hover);
  color: var(--primary-foreground);
}
#akashic-health-records-patient-portal-root .btn-red-sm:active:not(:disabled) {
  background-color: var(--danger-active);
  border-color: var(--danger-active);
  color: var(--primary-foreground);
}
#akashic-health-records-patient-portal-root .btn-red-ghost-sm {
  background-color: transparent;
  border: 1px solid var(--danger);
  color: var(--danger);
}
#akashic-health-records-patient-portal-root .btn-red-ghost-sm:hover:not(:disabled) {
  background-color: rgba(220, 38, 38, 0.08);
  color: var(--danger);
}
#akashic-health-records-patient-portal-root .btn-red-ghost-sm:active:not(:disabled) {
  background-color: rgba(220, 38, 38, 0.14);
  color: var(--danger);
}

/* Gray */

/* STRIPPED BUTTONS (NO BACKGROUND OR BORDER - INLINE/MINIMAL ACTIONS) */
#akashic-health-records-patient-portal-root .btn-stripped {
  background-color: transparent;
  border-color: transparent;
  color: var(--foreground);
  padding: 0;
  min-height: auto;
  height: auto;
}

#akashic-health-records-patient-portal-root .btn-stripped:hover:not(:disabled) {
  color: var(--primary);
  background-color: transparent;
}

#akashic-health-records-patient-portal-root .btn-stripped:active:not(:disabled) {
  color: var(--primary);
}

/* =========================================================
   PRESSED / ACTIVE STATE — a button that is currently ON
   =========================================================
   Card 132, Spencer's ruling 2026-08-09 (option a). Every `.btn-*` above is a STATIC colour variant;
   none of them can say "this one is currently selected". That state is what WordPress's `isPressed`
   prop expressed, and it is load-bearing in two places: the DICOM viewer's tool selector
   (Window/Level · Length · Angle · Ellipse · Delete) and RolePermissionsPage's None/View/Manage.

   This reproduces WordPress's own treatment exactly — `.components-button.is-pressed` is
   `background: #1e1e1e; color: #fff` — via our tokens, so the conversion moves no pixels.
   `--foreground` is within a hair of #1e1e1e and, unlike a hardcoded hex, follows the dark-mode block.

   🔴 THIS IS THE INTERIM ANSWER, DELIBERATELY. Both of those controls are RADIO GROUPS wearing
   buttons — exactly one member is on, and choosing one turns the others off. The honest primitive is a
   Radix ToggleGroup, which would also bring arrow-key navigation. That is option (c), and Spencer
   scheduled it for the design/UX pass rather than smuggling a keyboard-behaviour change into a styling
   sweep. See akashic-docs/_CLAUDE/2026-08-09-ui-design-pass-backlog.md.

   ⚠️ SPECIFICITY, and it is not incidental. `.btn[aria-pressed="true"]` scores (1,2,0), which beats
   every colour variant above at (1,1,0) — that is what lets pressed override `btn-blue-ghost` and
   friends. But those variants' own `:hover:not(:disabled)` rules score (1,3,0) and would win back on
   hover, so the hover/active rules below carry the attribute AND the pseudo-classes to reach (1,4,0).
   Dropping either extra rule looks harmless and silently restores the variant colour on hover. */
/* THE ON SEGMENT IS THE APP'S OWN BLUE, not a near-black.

   It filled with `--foreground`, which is `--ink` #33302c - the body ink, used here as a
   background. That came in with the WordPress ButtonGroup reproduction and outlived it: the
   2026-09-08 pass retired WordPress' styling wholesale and this was missed because nothing on the
   screen it was written for had been looked at since.

   SPENCER, 2026-09-10, ON THE TEAMS FILTER: "Open closed looks bad, that needs to change."

   The screen already answers what selected looks like, two elements below the control: a chosen
   team card is `border-primary bg-blue-soft`. So one screen was saying selected in two languages,
   one of them a colour the palette does not contain at all - there is no black in this app, by
   ruling, because pure black reads dated against a warm ground.

   FILL RATHER THAN TINT, and that is the one real choice here. The tint (`--blue-soft` under
   `--primary` text) is what the card uses and would have matched it exactly, but that pair
   measures 4.45:1 and this text is 13px at weight 500 - normal text, so its floor is 4.5. The
   fill is white on `--primary` at 5.33:1. A shipped sub-floor pairing existing elsewhere
   (`.btn-blue-tonal`) is not a licence to put another one on twenty more surfaces.

   WHAT ELSE MOVES: every `aria-pressed` control in the app, around twenty files - the record
   stream filters, the permission matrices, the viewer toolbars. That is the point of one named
   rule and the reason this is not fixed locally on the Teams tab. */
#akashic-health-records-patient-portal-root .btn[aria-pressed="true"] {
  background-color: var(--primary);
  border-color: var(--primary);
  color: var(--primary-foreground);
}

#akashic-health-records-patient-portal-root .btn[aria-pressed="true"]:hover:not(:disabled) {
  background-color: var(--primary);
  border-color: var(--primary);
  color: var(--primary-foreground);
}

#akashic-health-records-patient-portal-root .btn[aria-pressed="true"]:active:not(:disabled) {
  background-color: var(--primary);
  border-color: var(--primary);
  color: var(--primary-foreground);
}

/* No min-width, so the patient touch floor still applies. */
#akashic-health-records-patient-portal-root .btn.btn-icon {
  width: 30px;
  padding: 0;
  justify-content: center;
}
#akashic-health-records-patient-portal-root .btn.btn-icon svg {
  width: 16px;
  height: 16px;
}

#akashic-health-records-patient-portal-root .back-link {
  display: inline-flex;
  align-items: center;
  gap: 6px;
  margin-right: auto;
  padding: 0;
  border: 0;
  background: none;
  box-shadow: none;
  color: var(--primary);
  font-size: var(--ak-font-13);
  font-weight: 500;
  cursor: pointer;
}
#akashic-health-records-patient-portal-root .back-link svg {
  width: 16px;
  height: 16px;
  flex: none;
}

/* SEGMENTED CONTROL — buttons joined into one control, as WordPress's ButtonGroup did.
   Card 132: `.components-button-group` produced the joined look entirely through
   `.components-button` descendants (border-radius: 0 on the middle segments, a -1px overlap so
   adjacent borders collapse into one, and rounding only on the first/last child). A native `.btn`
   inherits none of that, so without this a three-state picker renders as three loose buttons.
   Used with `.btn[aria-pressed="true"]` above to mark which segment is on. */
#akashic-health-records-patient-portal-root .btn-segmented {
  display: inline-flex;
}

#akashic-health-records-patient-portal-root .btn-segmented > .btn {
  border-radius: 0;
}

#akashic-health-records-patient-portal-root .btn-segmented > .btn + .btn {
  margin-left: -1px;
}

#akashic-health-records-patient-portal-root .btn-segmented > .btn:first-child {
  border-top-left-radius: var(--ak-control-radius);
  border-bottom-left-radius: var(--ak-control-radius);
}

#akashic-health-records-patient-portal-root .btn-segmented > .btn:last-child {
  border-top-right-radius: var(--ak-control-radius);
  border-bottom-right-radius: var(--ak-control-radius);
}

/* The selected segment must paint its shared border too, or the -1px overlap leaves the neighbour's
   lighter border drawn on top of it. */
#akashic-health-records-patient-portal-root .btn-segmented > .btn[aria-pressed="true"] {
  position: relative;
  z-index: 1;
}

/* =========================================================
   WP-CARD — card 132's reproduction of @wordpress/components' Card family
   =========================================================
   Spencer's ruling 2026-08-10 (option a): reproduce WordPress's card geometry rather than adopt
   shadcn's `ui/card`, which is a different component — 12px corners vs 7px, a 24px gap between header
   and body that does not exist today, no header divider, and a drop shadow on top of the <Elevation>
   these cards already carry. See components/ui/wp-card.tsx for the side-by-side.

   Values read out of @wordpress/components' own source — build/card/styles.js, the per-section
   hook.js files under build/card, and build/utils/config-values.js — not matched by eye.
   (Written in words rather than with a glob: a star-slash inside a comment CLOSES it, and in a
   stylesheet that silently spills the rest of the comment into live CSS.)
     radiusLarge 8px, and WP's own radius is that minus one because it draws its border as a
     box-shadow, which renders as an OUTER radius; surfaceBorderColor and colorDivider are both
     rgba(0,0,0,0.1); surfaceColor is #fff; padding comes from the `size` prop, default medium.
   ⚠️ THOSE ARE WORDPRESS'S NUMBERS, KEPT AS THE RECORD OF WHAT WAS REPRODUCED. They are no longer
     what this file draws - see the design-pass note on the rule itself below.

   ⚠️ These are RULES, not inline styles, on purpose: the first/last-of-type corner clipping and the
   "a header stops drawing its divider when it is the last child" behaviour are pseudo-class selectors.
   Computing them in JS would be a different behaviour wearing the same name. */
/* 🔻 2026-09-08 - THE CARD TAKES THE SETTLED SHAPE. This block reproduced WordPress's card
   geometry on purpose, and the note above says the look was deferred "to the design pass".
   This is that pass. Spencer: "do NOT use any wordpress styles or components" and "our sole
   focus here is just getting the ui/design/css to a place that is usable for a real user."

   Measured in the approved decks: square, a 1px #e5e0d8 hairline, white, no drop shadow. The
   app already declares that exact colour as --line, so only the geometry was out of step.

   ⚠️ STILL A RING RATHER THAN A `border`, and deliberately. A real border adds 1px per side to
   the box on all 471 card sites and would reflow every one of them; a 1px ring is visually the
   same line at zero layout cost. The corner radius is one custom property so the whole family -
   card, and the first/last child clipping below - moves together. */
/* =========================================================
   THE LIST CARD - one row of a list of things, anywhere in the patient portal.

   🗣️ Spencer, 2026-09-11: *"The cards in Teams and in Practices don't match the rest of the card
   styles. I want you to match the card styles used in the 'ITEMS NEED ATTENTION' section of the
   dashboard home."* So that section is no longer a section's own styling - it is the standard, and
   this is it, in one declaration that every such list reads.

   📏 MEASURED OFF THE APPROVED DECK at scale 1, so these are real pixels rather than frame-scaled
   ones (patient-portal.html, the queue card):
     gap between cards   4px
     padding             8px 12px (mockup .lcard)
     border              NONE - 0px, and this is the part that matters
     background          white
     lift                --ak-card-lift

   ⚠️ THE CARD HAS NO BORDER, and the gap depends on that. Its edge is the offset shadow alone,
   which is why 4px is enough: a BORDERED card needs air around it or two hairlines read as one
   thick rule, which is why every list that drew a border had opened its gap to 8 or 12px to cope.
   Take the border off and the deck's own spacing works. Doing one without the other is what makes a
   spacing fix look wrong.

   ⛔ Do not add `border: 1px` back to make a card 'clearer'. On the paper ground the lift is what
   separates it, and a card that has both reads as heavier than everything around it.
   ========================================================= */
#akashic-health-records-patient-portal-root .ahr-list-stack,
#akashic-health-records-patient-portal-root .ahr-queue-list,
#akashic-health-records-patient-portal-root .ak-card-list {
  display: flex;
  flex-direction: column;
  gap: var(--ak-list-gap);
}

#akashic-health-records-patient-portal-root .ahr-list-card,
#akashic-health-records-patient-portal-root .ak-card,
#akashic-health-records-patient-portal-root .ahr-queue-list > *,
#akashic-health-records-patient-portal-root [data-slot="card"],
#akashic-health-records-patient-portal-root .wp-card {
  border: 0;
  border-radius: var(--ak-card-radius);
  background: var(--surface);
  color: var(--ink);
  box-shadow: var(--ak-card-lift);
}

#akashic-health-records-patient-portal-root .ahr-list-card,
#akashic-health-records-patient-portal-root .ahr-queue-list > *,
#akashic-health-records-patient-portal-root .ak-card:not(.ak-card--panel) {
  padding: var(--ak-card-list-pad);
}

/* THE SELECTED ROW. The queue has no selected state - nothing there is a destination you stay in -
   so this belongs to the lists that do. A tint rather than a border, for the reason above: adding an
   edge to one card in a borderless list makes the selection look like damage rather than emphasis.
   ⚠️ It has to be a RULE. `bg-blue-soft` is a utility at (0,1,0) and the card rule above sets
   `background` from an id-scoped selector, so the utility would lose silently and the row would look
   unselected with the source saying otherwise. */
/* THE LIST CARD'S TITLE. 13px, the heading weight token, the strong ink - measured off the
   approved deck, and pointed at the token rather than a literal 400 because the weight scale has
   moved once already and every hardcoded weight sailed straight past it.
   🗣️ Spencer, 2026-09-09: *"Card item headings should be 400 weight, 500 is too much."* */
#akashic-health-records-patient-portal-root .ahr-list-card-title,
#akashic-health-records-patient-portal-root .ahr-queue-item-title,
#akashic-health-records-patient-portal-root .ak-card__title {
  margin: 0;
  font-size: var(--ak-font-13);
  font-weight: var(--ak-heading-weight);
  color: var(--ink-strong);
}

#akashic-health-records-patient-portal-root .ak-card__title--lead {
  font-size: var(--ak-font-15);
}

/* THE LINE UNDER IT - who it is with, where it is.

   ⚠️ `--ink-muted`, NOT `--faint`, and that was measured rather than chosen. Faint is
   about 2.9:1 on white, and the palette says in as many words that it is for LARGE text and UI
   borders only, never body copy. A practice's address and telephone number are the two things on
   this card somebody reads back to another person down a phone line; they cannot be the palest
   text on the screen.

   ⇒ The queue card gets away with faint because the words that matter in ITS line are lifted out
   of it by their own span. A line that is entirely supporting facts has nothing to lift, so it
   takes the readable step for the whole line instead. */
#akashic-health-records-patient-portal-root .ahr-list-card-meta,
#akashic-health-records-patient-portal-root .ak-card__meta {
  margin-top: 6px;
  display: flex;
  align-items: center;
  gap: 5px;
  font-size: var(--ak-font-11-5);
  font-weight: var(--ak-heading-weight);
  color: var(--ink-muted);
}

#akashic-health-records-patient-portal-root .ahr-list-card--on,
#akashic-health-records-patient-portal-root .ak-card--on {
  background: var(--blue-soft);
}

#akashic-health-records-patient-portal-root .ahr-list-card:hover,
#akashic-health-records-patient-portal-root .ak-card:where(:not(.ak-card--panel)):hover {
  background: var(--line-soft);
}

#akashic-health-records-patient-portal-root .ahr-list-card--on:hover,
#akashic-health-records-patient-portal-root .ak-card--on:hover {
  background: var(--blue-soft);
}

/* A CARD THAT SCANS BY ITS LEFT EDGE (task rows): 3px of state, still no other border. Open is
   amber, done is sage, and an ended row takes no edge and recedes to the sunken ground. */
#akashic-health-records-patient-portal-root .ahr-list-card.ahr-list-card--edge,
#akashic-health-records-patient-portal-root .ak-card--edge {
  border-left: 3px solid transparent;
}

/* A card that heads a page section with a muted rule down its leading edge (the setup guide). */
#akashic-health-records-patient-portal-root .ak-card--rule {
  border-left: 4px solid var(--ink-muted);
}

#akashic-health-records-patient-portal-root .ahr-list-card.ahr-list-card--open,
#akashic-health-records-patient-portal-root .ak-card--open {
  border-left-color: var(--warning);
}

#akashic-health-records-patient-portal-root .ahr-list-card.ahr-list-card--done,
#akashic-health-records-patient-portal-root .ak-card--done {
  border-left-color: var(--success);
}

#akashic-health-records-patient-portal-root .ahr-list-card.ahr-list-card--ended,
#akashic-health-records-patient-portal-root .ahr-list-card.ahr-list-card--ended:hover,
#akashic-health-records-patient-portal-root .ak-card--ended,
#akashic-health-records-patient-portal-root .ak-card--ended:hover {
  background: var(--sunken);
}

/* THE ROW HEAD: the title wraps in its own column and the status stays at the top right, so a long
   title never pushes the status onto a line of its own. */
#akashic-health-records-patient-portal-root .ahr-list-card-head {
  display: grid;
  grid-template-columns: minmax(0, 1fr) auto;
  align-items: start;
  gap: 8px;
}

/* STATUS IS PLAIN ITALIC WORDS, never a pill. The words carry the state; the colour only repeats it. */
#akashic-health-records-patient-portal-root .ahr-row-status,
#akashic-health-records-patient-portal-root .ak-card__status {
  font-size: 12px;
  font-style: italic;
  font-weight: 400;
  white-space: nowrap;
  color: var(--ink-muted);
}

#akashic-health-records-patient-portal-root .ahr-row-status--attention {
  color: var(--warning);
}

#akashic-health-records-patient-portal-root .ahr-row-status--done {
  color: var(--success-active);
}

#akashic-health-records-patient-portal-root .ahr-row-status--ended {
  color: var(--ink);
}

#akashic-health-records-patient-portal-root .ahr-row-status--danger {
  color: var(--danger);
}

/* THE DUE LINE AND PRIORITY SHARE A ROW: due at the left, priority at the right, wrapping only when
   the row runs out of room. Priority is separate from status and only an urgent one is drawn. */
#akashic-health-records-patient-portal-root .ahr-row-deadline {
  display: flex;
  flex-wrap: wrap;
  align-items: baseline;
  gap: 2px 10px;
  margin-top: 4px;
}

#akashic-health-records-patient-portal-root .ahr-row-priority {
  margin-left: auto;
  font-size: 11px;
  font-style: italic;
  font-weight: 600;
  white-space: nowrap;
  color: var(--danger);
}

/* =========================================================
   THE MESSENGER INBOX ROW (staff messages). Rows, not cards: a divider under each, a 3px rail on the
   left that turns primary for the open conversation, a round avatar, and plain words for "Awaiting
   reply" rather than a pill. The unread count keeps the one count style.
   ========================================================= */
#akashic-health-records-patient-portal-root .ahr-mm-row {
  display: flex;
  align-items: center;
  gap: 11px;
  padding: 10px 11px;
  border-bottom: 1px solid var(--line-soft);
  border-left: 3px solid transparent;
  cursor: pointer;
}

#akashic-health-records-patient-portal-root .ahr-mm-row:hover {
  background: var(--line-soft);
}

#akashic-health-records-patient-portal-root .ahr-mm-row.ahr-mm-row--on {
  border-left-color: var(--primary);
  background: var(--blue-soft);
}

#akashic-health-records-patient-portal-root .ahr-mm-avatar {
  display: grid;
  place-items: center;
  flex: none;
  width: 36px;
  height: 36px;
  border-radius: 50%;
  overflow: hidden;
  background: var(--blue-soft);
  color: var(--primary);
  font-size: 12px;
  font-weight: 500;
}

#akashic-health-records-patient-portal-root .ahr-mm-avatar img {
  width: 100%;
  height: 100%;
  object-fit: cover;
}

#akashic-health-records-patient-portal-root .ahr-mm-name {
  margin: 0;
  font-size: 13px;
  font-weight: 500;
  color: var(--ink-strong);
}

#akashic-health-records-patient-portal-root .ahr-mm-role {
  margin: 0;
  font-size: 12px;
  color: var(--ink-muted);
}

#akashic-health-records-patient-portal-root .ahr-mm-preview {
  margin: 2px 0 0;
  overflow: hidden;
  font-size: 13px;
  color: var(--ink);
  text-overflow: ellipsis;
  white-space: nowrap;
}

#akashic-health-records-patient-portal-root .ahr-mm-time {
  margin: 0;
  font-size: 11px;
  color: var(--ink-muted);
  white-space: nowrap;
}

#akashic-health-records-patient-portal-root .ahr-mm-awaiting {
  display: flex;
  align-items: center;
  gap: 4px;
  margin-top: 6px;
  font-size: 11px;
  color: var(--warning);
}

#akashic-health-records-patient-portal-root button.ahr-mm-dismiss {
  display: inline-flex;
  padding: 2px;
  border: 0;
  background: transparent;
  color: var(--ink-muted);
}

#akashic-health-records-patient-portal-root button.ahr-mm-dismiss:hover:not(:disabled) {
  color: var(--ink-strong);
}

/* ONLY "Due by:" IS AMBER; the date after it is regular ink. */
#akashic-health-records-patient-portal-root .ahr-due-line {
  font-size: 11px;
  font-weight: 400;
  color: var(--ink);
}

#akashic-health-records-patient-portal-root .ahr-due-line .ahr-due-label {
  font-weight: 600;
  color: var(--warning);
}

/* The legacy wp-card draws the shared card above; it keeps only its corner variable. */
#akashic-health-records-patient-portal-root .wp-card {
  --wp-card-radius: 0px;
  outline: none;
}

#akashic-health-records-patient-portal-root .wp-card--rounded {
  border-radius: var(--wp-card-radius);
}

#akashic-health-records-patient-portal-root .wp-card--borderless {
  box-shadow: none;
}

/* Every direct section takes the card's corners so content clips instead of overflowing them. */
#akashic-health-records-patient-portal-root .wp-card--rounded > .wp-card__header:first-of-type,
#akashic-health-records-patient-portal-root .wp-card--rounded > .wp-card__body:first-of-type,
#akashic-health-records-patient-portal-root .wp-card--rounded > .wp-card__footer:first-of-type,
#akashic-health-records-patient-portal-root .wp-card--rounded > .wp-card__media:first-of-type {
  border-top-left-radius: var(--wp-card-radius);
  border-top-right-radius: var(--wp-card-radius);
}

#akashic-health-records-patient-portal-root .wp-card--rounded > .wp-card__header:last-of-type,
#akashic-health-records-patient-portal-root .wp-card--rounded > .wp-card__body:last-of-type,
#akashic-health-records-patient-portal-root .wp-card--rounded > .wp-card__footer:last-of-type,
#akashic-health-records-patient-portal-root .wp-card--rounded > .wp-card__media:last-of-type {
  border-bottom-left-radius: var(--wp-card-radius);
  border-bottom-right-radius: var(--wp-card-radius);
}

#akashic-health-records-patient-portal-root .wp-card__body {
  box-sizing: border-box;
  height: auto;
  max-height: 100%;
}

/* 🚨 The divider line under a card header. shadcn's CardHeader has none, which is why adopting it
   wholesale would have silently removed this from ~65 headers. WP drops it when the header is the
   only/last section, so a header-only card does not draw a rule against nothing. */
/* 🔻 2026-09-08 - var(--line), matching the card's own ring. The ring moved to the settled
   warm hairline in this pass and this divider stayed on WordPress's neutral rgba(0,0,0,.1), so a
   card drew a warm outline around a cool grey rule. */
#akashic-health-records-patient-portal-root .wp-card__header {
  box-sizing: border-box;
  border-bottom: 1px solid var(--line);
}

#akashic-health-records-patient-portal-root .wp-card__header:last-child,
#akashic-health-records-patient-portal-root .wp-card__header--borderless {
  border-bottom: none;
}

#akashic-health-records-patient-portal-root .wp-card__footer {
  box-sizing: border-box;
  border-top: 1px solid var(--line);
}

#akashic-health-records-patient-portal-root .wp-card__footer:first-of-type {
  border-top: none;
}

#akashic-health-records-patient-portal-root .wp-card__divider {
  box-sizing: border-box;
  display: block;
  width: 100%;
  border: 0;
  border-top: 1px solid var(--line);
  margin: 0;
}

#akashic-health-records-patient-portal-root .wp-card__media {
  box-sizing: border-box;
  overflow: hidden;
}

#akashic-health-records-patient-portal-root .wp-card__media > img,
#akashic-health-records-patient-portal-root .wp-card__media > iframe {
  display: block;
  height: auto;
  max-width: 100%;
  width: 100%;
}

#akashic-health-records-patient-portal-root .wp-card--shady {
  background-color: var(--sunken);
}

/* Padding by size. WP's `space()` grid: medium is `space(4) space(6)` = 16px 24px — the default, and
   what all but four of our 471 sites use. The size class is applied to the CARD and inherited by its
   sections unless a section overrides it, matching WP's context behaviour. */
#akashic-health-records-patient-portal-root .wp-card--medium > .wp-card__header,
#akashic-health-records-patient-portal-root .wp-card--medium > .wp-card__body,
#akashic-health-records-patient-portal-root .wp-card--medium > .wp-card__footer,
#akashic-health-records-patient-portal-root .wp-card__header.wp-card--medium,
#akashic-health-records-patient-portal-root .wp-card__body.wp-card--medium,
#akashic-health-records-patient-portal-root .wp-card__footer.wp-card--medium {
  padding: 16px 24px;
}

#akashic-health-records-patient-portal-root .wp-card--small > .wp-card__header,
#akashic-health-records-patient-portal-root .wp-card--small > .wp-card__body,
#akashic-health-records-patient-portal-root .wp-card--small > .wp-card__footer,
#akashic-health-records-patient-portal-root .wp-card__header.wp-card--small,
#akashic-health-records-patient-portal-root .wp-card__body.wp-card--small,
#akashic-health-records-patient-portal-root .wp-card__footer.wp-card--small {
  padding: 16px;
}

#akashic-health-records-patient-portal-root .wp-card--large > .wp-card__header,
#akashic-health-records-patient-portal-root .wp-card--large > .wp-card__body,
#akashic-health-records-patient-portal-root .wp-card--large > .wp-card__footer,
#akashic-health-records-patient-portal-root .wp-card__header.wp-card--large,
#akashic-health-records-patient-portal-root .wp-card__body.wp-card--large,
#akashic-health-records-patient-portal-root .wp-card__footer.wp-card--large {
  padding: 24px 32px;
}

#akashic-health-records-patient-portal-root .wp-card--xSmall > .wp-card__header,
#akashic-health-records-patient-portal-root .wp-card--xSmall > .wp-card__body,
#akashic-health-records-patient-portal-root .wp-card--xSmall > .wp-card__footer,
#akashic-health-records-patient-portal-root .wp-card__header.wp-card--xSmall,
#akashic-health-records-patient-portal-root .wp-card__body.wp-card--xSmall,
#akashic-health-records-patient-portal-root .wp-card__footer.wp-card--xSmall {
  padding: 8px;
}

/* CHIP */
#akashic-health-records-patient-portal-root .chip {
  display: inline-flex;
  align-items: center;
  gap: 0.375rem;
  border: 1px solid var(--border);
  border-radius: var(--radius-sm);
  background-color: #fff;
  padding: 0.25rem 0.5rem;
  font-size: var(--ak-font-sm);
  line-height: 1;
  color: var(--foreground);
}

#akashic-health-records-patient-portal-root .chip-label {
  line-height: 1.2;
}

#akashic-health-records-patient-portal-root .chip-remove {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  width: 1.125rem;
  height: 1.125rem;
  padding: 0;
  border: 0;
  border-radius: 9999px;
  background: transparent;
  color: var(--muted-foreground);
  font-size: var(--ak-font-md);
  line-height: 1;
  cursor: pointer;
  transition: background-color 0.2s ease, color 0.2s ease;
}

#akashic-health-records-patient-portal-root .chip-remove:hover:not(:disabled) {
  background-color: rgba(0, 0, 0, 0.06);
  color: var(--foreground);
}

#akashic-health-records-patient-portal-root .chip-remove:focus-visible {
  outline: 2px solid var(--ring);
  outline-offset: 2px;
}

#akashic-health-records-patient-portal-root .chip-remove:disabled {
  opacity: 0.5;
  cursor: default;
}
/* Delete icon button */
#akashic-health-records-patient-portal-root .btn-icon-delete {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  width: 1.5rem;
  height: 1.5rem;
  border-radius: 9999px;
  background-color: var(--line-soft);
  border: 1px solid transparent;
  color: var(--danger);
  cursor: pointer;
  transition:
    background-color 0.2s ease,
    border-color 0.2s ease,
    color 0.2s ease,
    transform 0.05s ease;
}

#akashic-health-records-patient-portal-root .btn-icon-delete:hover:not(:disabled) {
  background-color: var(--line-soft);
  color: var(--danger);
}

#akashic-health-records-patient-portal-root .btn-icon-delete:active:not(:disabled) {
  transform: translateY(1px);
}

#akashic-health-records-patient-portal-root .btn-icon-delete:disabled {
  opacity: 0.5;
  cursor: not-allowed;
}

#akashic-health-records-patient-portal-root .btn-icon-delete svg {
  width: 16px;
  height: 16px;
}
/* Legacy time-slot support during transition */
#akashic-health-records-patient-portal-root [data-slot="button"][data-kind="time-slot"] {
  background-color: var(--green-soft);
  color: var(--success);
  border: 1px solid transparent;
  border-radius: 0.3rem;
  transition:
    background-color 0.2s ease,
    color 0.2s ease,
    border-color 0.2s ease;
}

#akashic-health-records-patient-portal-root [data-slot="button"][data-kind="time-slot"]:hover:not([data-selected="true"]):not([aria-pressed="true"]):not(:disabled) {
  background-color: var(--green-soft);
  color: var(--success);
  border-color: transparent;
}

#akashic-health-records-patient-portal-root [data-slot="button"][data-kind="time-slot"][data-selected="true"],
#akashic-health-records-patient-portal-root [data-slot="button"][data-kind="time-slot"][aria-pressed="true"] {
  background-color: var(--success);
  border-color: var(--success);
  color: var(--primary-foreground);
}

#akashic-health-records-patient-portal-root [data-slot="button"][data-kind="time-slot"][data-selected="true"]:hover,
#akashic-health-records-patient-portal-root [data-slot="button"][data-kind="time-slot"][aria-pressed="true"]:hover {
  background-color: var(--success-hover);
  border-color: var(--success-hover);
  color: var(--primary-foreground);
}

/* =========================================================
   NAV NORMALIZATION
   Scoped to dashboard sidebar / nested nav only
   ========================================================= */

#akashic-health-records-patient-portal-root nav,
#akashic-health-records-patient-portal-root nav ul,
#akashic-health-records-patient-portal-root nav li,
#akashic-health-records-patient-portal-root nav .dashboard-nav-item,
#akashic-health-records-patient-portal-root nav .dashboard-nav-item > div {
  min-width: 0;
  max-width: 100%;
}

#akashic-health-records-patient-portal-root nav button[data-slot="button"] {
  display: flex;
  align-items: center;
  justify-content: space-between;
  gap: 0.5rem;
  width: 100%;
  min-width: 0;
  max-width: 100%;
  height: auto;
  min-height: 1.5rem;
  padding: 0.45rem 0.75rem;
  margin: 0;
  border: 1px solid transparent;
  border-radius: 0;
  background: transparent;
  box-shadow: none;
  font: inherit;
  line-height: 1.2;
  text-align: left;
  color: inherit;
  cursor: pointer;
  appearance: none;
  -webkit-appearance: none;
  transition:
    background-color 0.15s ease,
    border-color 0.15s ease,
    color 0.15s ease;
}

#akashic-health-records-patient-portal-root nav .dashboard-nav-item .dashboard-nav-item button[data-slot="button"] {
  min-height: 2rem;
  height: auto;
  padding-top: 0.45rem;
  padding-bottom: 0.45rem;
}

#akashic-health-records-patient-portal-root nav button[data-slot="button"] > * {
  min-width: 0;
}

#akashic-health-records-patient-portal-root nav button[data-slot="button"] > div:first-child,
#akashic-health-records-patient-portal-root nav button[data-slot="button"] > span:first-child {
  display: flex;
  align-items: center;
  gap: 0.625rem;
  flex: 1 1 auto;
  min-width: 0;
}

#akashic-health-records-patient-portal-root nav button[data-slot="button"] span,
#akashic-health-records-patient-portal-root nav button[data-slot="button"] p {
  min-width: 0;
  max-width: 100%;
  white-space: normal;
  overflow-wrap: break-word;
  word-break: normal;
  line-height: 1.25;
}

#akashic-health-records-patient-portal-root nav button[data-slot="button"] div {
  min-width: 0;
  max-width: 100%;
}

/* 🎯 THE SIZE HALF IS SOFTENED SO A UTILITY CAN WIN; THE REST IS NOT.
   The old rule scored (1,1,3) and set all five properties, so `size-5` on a nav icon did nothing and
   every one of the 58 icons in the sidebar carried `!w-5 !h-5` instead. The `!` worked and hid the
   cause, which is the trap: an override left at the call site is a lie about why it is there.
   ⭐ SPLIT RATHER THAN WRAPPED WHOLE. `:where()` drops specificity for EVERYBODY, not only for the
   utility you were fighting — so only `width`/`height` are softened. `flex-shrink`, `color` and
   `vertical-align` are not being overridden by anything and keep their specificity, which means this
   change cannot move them.
   ⚠️ The element stays OUTSIDE the `:where()` deliberately. That leaves (0,0,1) rather than (0,0,0):
   a utility at (0,1,0) still wins, but a host theme's bare `svg { }` no longer does. The plugin mounts
   inside somebody else's WordPress theme, and the id was buying that isolation in the first place. */
:where(#akashic-health-records-patient-portal-root nav button[data-slot="button"]) svg {
  width: 1rem;
  height: 1rem;
}

#akashic-health-records-patient-portal-root nav button[data-slot="button"] svg {
  flex-shrink: 0;
  color: inherit;
  vertical-align: middle;
}

/* Sidebar navigation states, taken from the navigation decks.
   The navigation stays quiet so the page remains the focus - but the row you are ON has to read as
   the strongest thing on the rail, and it did not.

   WHAT WAS WRONG, measured against the decks rather than judged. A selected row is drawn --sunken
   with --ink-strong at weight 500. This painted it --line - the BORDER token used as a surface -
   with --ink and no weight change, while HOVER painted --sunken. So hover wore the colour the
   drawing reserves for selection, and the two states sat one step apart on the ramp.
   And hovering the SELECTED row painted it --sunken, LIGHTER than its own resting --line: pointing
   at the row you were already on made it look less selected, and identical to a hovered one.

   HOVER IS A CHOICE HERE, NOT A READING. The decks draw no hover at all, because a static mockup
   cannot. It goes one step lighter than selection and never onto it. The warm ramp holds nothing
   between --surface and --sunken worth using as a fill, so the separation is carried by ink and
   weight, which is also how the patient rail below does it. */
#akashic-health-records-patient-portal-root nav button[data-slot="button"]:hover:not([data-active="true"]),
#akashic-health-records-patient-portal-root nav .dashboard-nav-item:not([data-active="true"]) > button[data-slot="button"]:hover {
  background-color: var(--line-soft);
  border-color: transparent;
  color: var(--ink);
}

#akashic-health-records-patient-portal-root nav button[data-slot="button"]:active,
#akashic-health-records-patient-portal-root nav button[data-slot="button"][data-active="true"],
#akashic-health-records-patient-portal-root nav .dashboard-nav-item[data-active="true"] > button[data-slot="button"] {
  background-color: var(--sunken);
  border-color: transparent;
  color: var(--ink-strong);
  font-weight: 500;
}

/* A hovered SELECTED row does not change. It is already the strongest state on the rail, so there
   is nothing a hover can add - and everything it could change would weaken it. */
#akashic-health-records-patient-portal-root nav .dashboard-nav-item[data-active="true"] > button[data-slot="button"]:hover {
  background-color: var(--sunken);
  border-color: transparent;
  color: var(--ink-strong);
  font-weight: 500;
}

#akashic-health-records-patient-portal-root nav .dashboard-nav-item--logout button[data-slot="button"] {
  color: rgba(220, 38, 38, 1);
}

#akashic-health-records-patient-portal-root nav .dashboard-nav-item--logout button[data-slot="button"]:hover {
  background-color: var(--sunken);
  border-color: transparent;
  color: rgba(220, 38, 38, 1);
}

/* =========================================================
   THE PATIENT DRAWER — navigation deck, skin s5, approved 2026-08-28
   Dark and square, and a drawer at every width. Scoped to `.ak-patient-nav`
   so the staff rail above is untouched: the rules there are (1,1,1) and
   these are (1,2,1), so they win without an override at the call site.
   ========================================================= */
#akashic-health-records-patient-portal-root .ak-patient-nav {
  background-color: var(--patient-nav);
  border-right: 0;
  border-radius: 0;
  color: var(--patient-nav-foreground);
}

#akashic-health-records-patient-portal-root .ak-patient-nav button[data-slot="button"] {
  min-height: 46px;
  padding: 0 14px;
  gap: 12px;
  border-radius: 0;
  border-color: transparent;
  color: var(--patient-nav-foreground);
}

#akashic-health-records-patient-portal-root .ak-patient-nav button[data-slot="button"]:hover:not([data-active="true"]),
#akashic-health-records-patient-portal-root .ak-patient-nav .dashboard-nav-item:not([data-active="true"]) > button[data-slot="button"]:hover {
  background-color: var(--patient-nav-selected);
  border-color: transparent;
  color: var(--patient-nav-selected-foreground);
}

#akashic-health-records-patient-portal-root .ak-patient-nav button[data-slot="button"][data-active="true"],
#akashic-health-records-patient-portal-root .ak-patient-nav .dashboard-nav-item[data-active="true"] > button[data-slot="button"],
#akashic-health-records-patient-portal-root .ak-patient-nav .dashboard-nav-item[data-active="true"] > button[data-slot="button"]:hover {
  background-color: var(--patient-nav-selected);
  border-color: transparent;
  color: var(--patient-nav-selected-foreground);
  font-weight: 500;
  /* the drawer mockup's current-page bar */
  box-shadow: inset 3px 0 0 var(--primary);
}

/* A child row is quieter and indented, and the indent is the only thing saying it is a child. */
#akashic-health-records-patient-portal-root .ak-patient-nav .dashboard-nav-item .dashboard-nav-item button[data-slot="button"] {
  min-height: 40px;
  padding-left: 44px;
  font-size: var(--ak-font-14);
  color: var(--patient-nav-child-foreground);
}

/* Sign out is amber here, not red: it is the only warm row in a dark menu and reads as an exit
   rather than a destruction. */
#akashic-health-records-patient-portal-root .ak-patient-nav .dashboard-nav-item--logout button[data-slot="button"],
#akashic-health-records-patient-portal-root .ak-patient-nav .dashboard-nav-item--logout button[data-slot="button"]:hover {
  color: var(--patient-nav-accent);
}

#akashic-health-records-patient-portal-root .ak-patient-nav .dashboard-nav-item--logout button[data-slot="button"]:hover {
  background-color: var(--patient-nav-selected);
}
#akashic-health-records-patient-portal-root button[role="combobox"],
#akashic-health-records-patient-portal-root [role="combobox"]:not(:where(.ak-field-shell) *) {
  background-color: #fff;
  background-image: none;
  color: inherit;
}
/* Common-element recipes; local skins require a recorded exception. */

/* Page title and its subtitle. */
#akashic-health-records-patient-portal-root .ak-page-title__sub {
  margin: 0 0 14px;
  font-size: var(--ak-font-13);
  font-weight: var(--ak-body-weight);
  color: var(--ink-muted);
}

/* A section head: heading, an optional plain count, an optional door link at the right. */
#akashic-health-records-patient-portal-root .ak-section-head {
  display: flex;
  align-items: center;
  gap: 8px;
  margin-bottom: 4px;
}
#akashic-health-records-patient-portal-root .ak-section-title {
  margin: 0;
  font-size: var(--ak-font-lg);
  font-weight: var(--ak-heading-weight);
  letter-spacing: 0.01em;
  color: var(--ink-strong);
}
#akashic-health-records-patient-portal-root h2.ak-section-title {
  font-weight: 500;
}
#akashic-health-records-patient-portal-root h3.ak-section-title {
  font-size: var(--ak-font-15);
  font-weight: 400;
}
#akashic-health-records-patient-portal-root .ak-section-title--attention {
  color: var(--warning);
}
#akashic-health-records-patient-portal-root .ak-section-title--done {
  color: var(--success-active);
}
#akashic-health-records-patient-portal-root .ak-section-title--danger {
  color: var(--danger);
}
#akashic-health-records-patient-portal-root .ak-section-head__count {
  font-size: var(--ak-font-13);
  font-weight: 500;
  color: var(--ink-muted);
}
#akashic-health-records-patient-portal-root .ak-section-head__door {
  margin-left: auto;
  font-size: var(--ak-font-11);
  font-weight: 500;
  color: var(--primary);
}

/* The caption that heads a list on its own. */
#akashic-health-records-patient-portal-root .ak-caption--md {
  font-size: var(--ak-font-13);
}

/* A panel card keeps the deck padding; a cancelled item recedes. */
#akashic-health-records-patient-portal-root .ak-card--panel {
  padding: var(--ak-card-pad);
}
#akashic-health-records-patient-portal-root .ak-card__header.border-b {
  padding-bottom: 12px;
}
#akashic-health-records-patient-portal-root .ak-card__footer.border-t {
  padding-top: 12px;
}
#akashic-health-records-patient-portal-root .ak-card__description {
  color: var(--ink-muted);
  font-size: var(--ak-font-13);
}
#akashic-health-records-patient-portal-root .ak-card--muted,
#akashic-health-records-patient-portal-root .ak-card--muted:hover {
  background: var(--sunken);
  color: var(--ink);
}

/* A list row that is not a card: hairlines between rows, no box. */
#akashic-health-records-patient-portal-root .ak-row {
  display: flex;
  align-items: center;
  gap: 10px;
  min-height: 36px;
  padding: 6px 10px;
  border: 0;
  border-radius: 0;
  box-shadow: none;
}
#akashic-health-records-patient-portal-root .ak-row + .ak-row {
  border-top: 1px solid var(--line-soft);
}
#akashic-health-records-patient-portal-root .ak-row__name {
  min-width: 0;
  overflow: hidden;
  text-overflow: ellipsis;
  white-space: nowrap;
  font-size: var(--ak-font-12-5);
  font-weight: 500;
  color: var(--ink-strong);
}
#akashic-health-records-patient-portal-root .ak-row--unread .ak-row__name {
  font-weight: 600;
}
#akashic-health-records-patient-portal-root .ak-row__detail {
  min-width: 0;
  overflow: hidden;
  text-overflow: ellipsis;
  white-space: nowrap;
  font-size: var(--ak-font-11-5);
  color: var(--ink-muted);
}
#akashic-health-records-patient-portal-root .ak-row__time {
  flex: none;
  font-size: var(--ak-font-12);
  font-weight: 500;
  color: var(--ink);
  font-variant-numeric: tabular-nums;
}
#akashic-health-records-patient-portal-root .ak-row__state {
  margin-left: auto;
  flex: none;
  font-size: var(--ak-font-11);
  font-weight: 500;
  text-align: right;
  color: var(--ink-muted);
}
#akashic-health-records-patient-portal-root .ak-row__state--warn {
  color: var(--warning);
}
#akashic-health-records-patient-portal-root .ak-row__state--bad {
  color: var(--danger);
}
#akashic-health-records-patient-portal-root .ak-row__state--good {
  color: var(--success);
}
#akashic-health-records-patient-portal-root .ak-row__age {
  margin-left: auto;
  flex: none;
  font-size: var(--ak-font-11);
  font-weight: 500;
  color: var(--ink-muted);
  font-variant-numeric: tabular-nums;
}

/* Organization mark sizes; the base is .ahr-org-mark above. Always round. */
#akashic-health-records-patient-portal-root .ak-org-mark--sm {
  width: var(--ak-mark-sm);
  height: var(--ak-mark-sm);
  font-size: var(--ak-font-10-5);
}
#akashic-health-records-patient-portal-root .ak-org-mark--lg {
  width: 38px;
  height: 38px;
  font-size: var(--ak-font-13);
}
#akashic-health-records-patient-portal-root .ak-org-line {
  display: flex;
  flex-wrap: wrap;
  align-items: center;
  gap: 2px 5px;
  font-size: var(--ak-font-12);
  color: var(--ink-muted);
}
#akashic-health-records-patient-portal-root .ak-org-line__name {
  font-weight: 500;
  color: var(--ink-strong);
}
#akashic-health-records-patient-portal-root .ak-org-line__sep {
  color: var(--faint);
}

/* A person: photo cover, initials only when there is no photo. The base is .ahr-person-avatar above. */
#akashic-health-records-patient-portal-root .ak-avatar {
  position: relative;
  display: inline-grid;
  place-items: center;
  overflow: visible;
  background: var(--blue-soft);
  color: var(--primary);
  font-size: var(--ak-font-13);
  font-weight: 500;
  line-height: 1;
}
#akashic-health-records-patient-portal-root .ak-avatar img,
#akashic-health-records-patient-portal-root .ak-avatar__fallback {
  width: 100%;
  height: 100%;
  border-radius: inherit;
  overflow: hidden;
  object-fit: cover;
  display: block;
}

#akashic-health-records-patient-portal-root .ak-avatar__fallback {
  display: grid;
  place-items: center;
}
#akashic-health-records-patient-portal-root .ak-avatar--sm {
  width: var(--ak-avatar-sm);
  height: var(--ak-avatar-sm);
  font-size: var(--ak-font-9);
}
#akashic-health-records-patient-portal-root .ak-avatar--header {
  width: 30px;
  height: 30px;
  font-size: var(--ak-font-11-5);
}
#akashic-health-records-patient-portal-root .ak-avatar--lg {
  width: 38px;
  height: 38px;
}
#akashic-health-records-patient-portal-root .ak-avatar--desk {
  background: var(--sunken);
  color: var(--ink-muted);
}
#akashic-health-records-patient-portal-root .ak-avatar__presence {
  position: absolute;
  right: -2px;
  bottom: -2px;
  width: 12px;
  height: 12px;
  border-radius: 50%;
  background: var(--success);
  border: 2px solid var(--surface);
  display: grid;
  place-items: center;
  color: var(--primary-foreground);
  z-index: 1;
}
#akashic-health-records-patient-portal-root .ak-avatar__presence svg {
  width: 8px;
  height: 8px;
}

/* Native, WordPress and Radix controls share one geometry and state palette. */
#akashic-health-records-patient-portal-root input[type="checkbox"],
#akashic-health-records-patient-portal-root input[type="radio"],
#akashic-health-records-patient-portal-root input.components-checkbox-control__input,
#akashic-health-records-patient-portal-root input.components-radio-control__input,
#akashic-health-records-patient-portal-root .ak-checkbox,
#akashic-health-records-patient-portal-root [data-slot="checkbox"] {
  box-sizing: border-box;
  -webkit-appearance: none;
  appearance: none;
  display: inline-grid;
  place-content: center;
  width: 16px;
  height: 16px;
  min-width: 16px;
  max-width: 16px;
  min-height: 16px;
  padding: 0;
  margin: 0;
  flex: none;
  border: 1px solid var(--line);
  border-radius: var(--ak-control-radius);
  background: var(--surface);
  color: var(--primary-foreground);
  box-shadow: none;
  cursor: pointer;
}
#akashic-health-records-patient-portal-root input[type="radio"] {
  border-radius: 50%;
}
#akashic-health-records-patient-portal-root input[type="checkbox"]:checked,
#akashic-health-records-patient-portal-root input[type="checkbox"]:indeterminate,
#akashic-health-records-patient-portal-root input[type="radio"]:checked,
#akashic-health-records-patient-portal-root .ak-checkbox[data-state="checked"],
#akashic-health-records-patient-portal-root .ak-checkbox[data-state="indeterminate"],
#akashic-health-records-patient-portal-root [data-slot="checkbox"][data-state="checked"],
#akashic-health-records-patient-portal-root [data-slot="checkbox"][data-state="indeterminate"] {
  border-color: var(--primary);
  background-color: var(--primary);
  color: var(--primary-foreground);
  background-repeat: no-repeat;
  background-position: center;
}
#akashic-health-records-patient-portal-root input[type="checkbox"]:checked {
  background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24' fill='none' stroke='%23fff' stroke-width='3' stroke-linecap='round' stroke-linejoin='round'%3E%3Cpath d='M20 6 9 17l-5-5'/%3E%3C/svg%3E");
  background-size: 12px;
}
#akashic-health-records-patient-portal-root input[type="checkbox"]:indeterminate {
  background-image: linear-gradient(var(--primary-foreground), var(--primary-foreground));
  background-size: 8px 2px;
}
#akashic-health-records-patient-portal-root input[type="radio"]:checked {
  background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 8 8'%3E%3Ccircle cx='4' cy='4' r='3' fill='%23fff'/%3E%3C/svg%3E");
  background-size: 8px;
}
#akashic-health-records-patient-portal-root input[type="checkbox"]:disabled,
#akashic-health-records-patient-portal-root input[type="radio"]:disabled,
#akashic-health-records-patient-portal-root .ak-checkbox:disabled,
#akashic-health-records-patient-portal-root [data-slot="checkbox"]:disabled {
  opacity: 0.5;
  cursor: not-allowed;
}
#akashic-health-records-patient-portal-root input[type="checkbox"]:focus-visible,
#akashic-health-records-patient-portal-root input[type="radio"]:focus-visible,
#akashic-health-records-patient-portal-root .ak-checkbox:focus-visible,
#akashic-health-records-patient-portal-root [data-slot="checkbox"]:focus-visible {
  outline: 2px solid var(--primary);
  outline-offset: 2px;
}
#akashic-health-records-patient-portal-root [data-slot="checkbox-indicator"],
#akashic-health-records-patient-portal-root .ak-checkbox__indicator {
  display: grid;
  place-content: center;
}
#akashic-health-records-patient-portal-root [data-slot="checkbox-indicator"] svg,
#akashic-health-records-patient-portal-root .ak-checkbox__indicator svg {
  width: 12px;
  height: 12px;
}
#akashic-health-records-patient-portal-root [data-state="indeterminate"] .ak-checkbox__check,
#akashic-health-records-patient-portal-root [data-slot="checkbox"]:not([data-state="indeterminate"]) .ak-checkbox__mixed {
  display: none;
}
@media (forced-colors: active) {
  #akashic-health-records-patient-portal-root input[type="checkbox"],
  #akashic-health-records-patient-portal-root input[type="radio"] {
    appearance: auto;
    background-image: none;
  }
  #akashic-health-records-patient-portal-root [data-slot="checkbox"][data-state="checked"],
  #akashic-health-records-patient-portal-root [data-slot="checkbox"][data-state="indeterminate"] {
    background: Highlight;
    color: HighlightText;
    border-color: Highlight;
    forced-color-adjust: none;
  }
}

/* A left-nav total is plain amber text, never a badge. */
#akashic-health-records-patient-portal-root .ak-nav-count {
  margin-left: auto;
  font-size: var(--ak-font-13);
  font-weight: 500;
  color: var(--warning);
  background: none;
  border-radius: 0;
  padding: 0;
}

/* A status pill and its tones. */
#akashic-health-records-patient-portal-root .ak-pill {
  display: inline-flex;
  align-items: center;
  flex: none;
  padding: 3px 11px;
  border: 1px solid var(--line);
  border-radius: 999px;
  background: var(--sunken);
  color: var(--ink-muted);
  font-size: var(--ak-font-11-5);
  font-weight: 500;
  line-height: 1.2;
  white-space: nowrap;
}
#akashic-health-records-patient-portal-root .ak-pill--ok {
  background: var(--green-soft);
  color: var(--sage-ink);
  border-color: var(--green-line);
}
#akashic-health-records-patient-portal-root .ak-pill--warn,
#akashic-health-records-patient-portal-root .ak-pill--new {
  background: var(--amber-soft);
  color: var(--warning);
  border-color: var(--amber-line);
}
#akashic-health-records-patient-portal-root .ak-pill--bad {
  background: var(--red-soft);
  color: var(--danger);
  border-color: var(--red-line);
}
#akashic-health-records-patient-portal-root .ak-pill--info {
  background: var(--blue-soft);
  color: var(--primary);
  border-color: var(--blue-line);
}
#akashic-health-records-patient-portal-root .ak-pill--square {
  border-radius: 6px;
  padding: 2px 9px;
}

/* State dots. */
#akashic-health-records-patient-portal-root .ak-dot {
  display: inline-block;
  flex: none;
  width: 8px;
  height: 8px;
  border-radius: 50%;
  background: var(--line);
}
#akashic-health-records-patient-portal-root .ak-dot--sm {
  width: 7px;
  height: 7px;
}
#akashic-health-records-patient-portal-root .ak-dot--on {
  background: var(--success);
}

/* A notice: an explanation is amber; error and success carry their own tints. */
#akashic-health-records-patient-portal-root .ak-notice {
  display: flex;
  align-items: flex-start;
  gap: 8px;
  padding: 8px 12px;
  border: 1px solid var(--amber-line);
  border-radius: 8px;
  background: var(--amber-soft);
  color: var(--amber-ink);
  font-size: var(--ak-font-13);
  line-height: 1.5;
}
#akashic-health-records-patient-portal-root .ak-notice b,
#akashic-health-records-patient-portal-root .ak-notice strong {
  color: inherit;
}
#akashic-health-records-patient-portal-root .ak-notice a {
  color: var(--amber-link);
}
#akashic-health-records-patient-portal-root .ak-notice--error {
  border-color: var(--red-line);
  background: var(--red-soft);
  color: var(--danger);
}
#akashic-health-records-patient-portal-root .ak-notice--error a {
  color: var(--danger);
}
#akashic-health-records-patient-portal-root .ak-notice--success {
  border-color: var(--green-line);
  background: var(--green-soft);
  color: var(--sage-ink);
}
#akashic-health-records-patient-portal-root .ak-notice--success a {
  color: var(--sage-ink);
}
/* The light tint glares on the dark call surface; the deck darkens it there. */
#akashic-health-records-patient-portal-root .ahr-call .ak-notice--success {
  border-color: #2f6b46;
  background: #1d2a24;
  color: #c8e6d4;
  font-size: 12.5px;
  font-weight: 400;
}
#akashic-health-records-patient-portal-root .ahr-call .ak-notice--success a {
  color: #c8e6d4;
}
#akashic-health-records-patient-portal-root .ak-notice--sm {
  padding: 7px 11px;
  font-size: var(--ak-font-12);
}
#akashic-health-records-patient-portal-root .ak-notice[data-slot="alert"] {
  display: grid;
  grid-template-columns: 0 minmax(0, 1fr);
  column-gap: 0;
  row-gap: 2px;
}
#akashic-health-records-patient-portal-root .ak-notice[data-slot="alert"]:has(> svg) {
  grid-template-columns: 16px minmax(0, 1fr);
  column-gap: 8px;
}
#akashic-health-records-patient-portal-root .ak-notice[data-slot="alert"].ak-notice--dismissible {
  grid-template-columns: minmax(0, 1fr) auto;
  column-gap: 8px;
  align-items: center;
}
#akashic-health-records-patient-portal-root .ak-notice--dismissible > .ak-notice__description {
  grid-column: 1;
}
#akashic-health-records-patient-portal-root .ak-notice__dismiss {
  display: grid;
  place-items: center;
  grid-column: 2;
  grid-row: 1;
  width: 24px;
  height: 24px;
  padding: 0;
  color: inherit;
  background: transparent;
  border: 0;
  cursor: pointer;
}
/* flex: none, or a long line in the flex notice squeezes the icon to a dot at phone width. */
#akashic-health-records-patient-portal-root .ak-notice > svg {
  flex: none;
  width: 16px;
  height: 16px;
  color: inherit;
}
#akashic-health-records-patient-portal-root .ak-notice__title,
#akashic-health-records-patient-portal-root .ak-notice__description {
  grid-column: 2;
  min-width: 0;
  color: inherit;
  font-size: inherit;
}
#akashic-health-records-patient-portal-root .ak-notice__title {
  font-weight: 500;
}
#akashic-health-records-patient-portal-root .ak-notice__description p {
  color: inherit;
  font-size: inherit;
}

/* A toast: surface, hairline, a state rule at the left. */
#akashic-health-records-patient-portal-root .ak-toast {
  width: 264px;
  padding: 8px 10px;
  border: 1px solid var(--line);
  border-left: 3px solid var(--primary);
  border-radius: 8px;
  background: var(--surface);
  box-shadow: 0 8px 22px rgba(0, 0, 0, 0.13);
}
#akashic-health-records-patient-portal-root .ak-toast--error {
  border-left-color: var(--danger);
}
#akashic-health-records-patient-portal-root .ak-toast--success {
  border-left-color: var(--success);
}
#akashic-health-records-patient-portal-root .ak-toast--warn {
  border-left-color: var(--warning);
}
#akashic-health-records-patient-portal-root .ak-toast__title {
  display: block;
  font-size: var(--ak-font-12);
  color: var(--ink-strong);
}
#akashic-health-records-patient-portal-root .ak-toast__body {
  font-size: var(--ak-font-11-5);
  color: var(--ink-muted);
}
#akashic-health-records-patient-portal-root .ak-toast__actions {
  display: flex;
  gap: 6px;
  margin-top: 6px;
}

/* Tabs and segmented controls share text and focus, not selection geometry. */
#akashic-health-records-patient-portal-root .ak-tabs-root {
  display: flex;
  flex-direction: column;
  gap: 8px;
}
#akashic-health-records-patient-portal-root .ak-tabs-root[data-orientation="vertical"] {
  flex-direction: row;
}
#akashic-health-records-patient-portal-root .ak-tabs {
  display: inline-flex;
  align-items: center;
  width: fit-content;
  max-width: 100%;
  gap: 0;
  padding: 0;
}
#akashic-health-records-patient-portal-root .ak-tabs--segmented {
  background: var(--sunken);
  border-radius: var(--ak-control-radius);
  padding: 3px;
}
#akashic-health-records-patient-portal-root .ak-tabs[data-orientation="vertical"] {
  flex-direction: column;
}
#akashic-health-records-patient-portal-root [data-slot="tabs-trigger"],
#akashic-health-records-patient-portal-root .ak-tab {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  gap: 6px;
  min-height: 24px;
  padding: 4px 8px;
  border: 0;
  background: transparent;
  font-size: var(--ak-font-13);
  font-weight: 500;
  color: var(--ink-muted);
  border-radius: 0;
  box-shadow: none;
  white-space: nowrap;
}
#akashic-health-records-patient-portal-root .ak-tabs--line [data-slot="tabs-trigger"],
#akashic-health-records-patient-portal-root .ak-tabs--line .ak-tab {
  padding: 8px 12px;
}
#akashic-health-records-patient-portal-root [data-slot="tabs-trigger"][data-state="active"],
#akashic-health-records-patient-portal-root .ak-tab[data-state="active"],
#akashic-health-records-patient-portal-root .ak-tab[aria-selected="true"],
#akashic-health-records-patient-portal-root .ak-tab--on {
  color: var(--primary);
  box-shadow: inset 0 -2px 0 var(--primary);
}
#akashic-health-records-patient-portal-root .ak-tabs--segmented [data-state="active"] {
  background: var(--surface);
  border-radius: var(--ak-control-radius);
  color: var(--ink-strong);
  box-shadow: none;
}
#akashic-health-records-patient-portal-root .ak-tabs[data-orientation="vertical"] .ak-tab {
  width: 100%;
  justify-content: flex-start;
}
#akashic-health-records-patient-portal-root .ak-tabs--line[data-orientation="vertical"] [data-state="active"] {
  box-shadow: inset -2px 0 0 var(--primary);
}
#akashic-health-records-patient-portal-root .ak-tab:focus-visible,
#akashic-health-records-patient-portal-root .ak-tabs__content:focus-visible {
  outline: 2px solid var(--primary);
  outline-offset: 2px;
}
#akashic-health-records-patient-portal-root .ak-tab:disabled {
  opacity: 0.5;
  cursor: not-allowed;
}
#akashic-health-records-patient-portal-root .ak-tab svg {
  width: 16px;
  height: 16px;
  flex: none;
}
#akashic-health-records-patient-portal-root .ak-tabs__content {
  flex: 1;
  min-width: 0;
}

/* A table: caption headers, hairline rows, tabular numbers. */
#akashic-health-records-patient-portal-root .ak-table {
  width: 100%;
  border-collapse: collapse;
}
#akashic-health-records-patient-portal-root .ak-table th {
  padding: 6px 10px;
  border-bottom: 1px solid var(--line);
  text-align: left;
  font-size: var(--ak-font-11);
  font-weight: 500;
  letter-spacing: 0.07em;
  text-transform: uppercase;
  color: var(--ink-muted);
}
#akashic-health-records-patient-portal-root .ak-table td {
  padding: 6px 10px;
  border-top: 1px solid var(--line-soft);
  font-size: var(--ak-font-12-5);
  color: var(--ink);
}
#akashic-health-records-patient-portal-root .ak-table tbody tr:first-child td {
  border-top: 0;
}
#akashic-health-records-patient-portal-root .ak-table .ak-table__num {
  text-align: right;
  font-variant-numeric: tabular-nums;
}
#akashic-health-records-patient-portal-root .ak-table tbody tr:hover {
  background: var(--line-soft);
}
#akashic-health-records-patient-portal-root .ak-table tbody tr.ak-table__row--on {
  background: var(--blue-soft);
}

/* An empty state. */
#akashic-health-records-patient-portal-root .ak-empty {
  padding: 24px 16px;
  text-align: center;
  font-size: var(--ak-font-13);
  color: var(--ink-muted);
}
#akashic-health-records-patient-portal-root .ak-empty__title {
  display: block;
  margin-bottom: 4px;
  font-size: var(--ak-font-15);
  font-weight: var(--ak-heading-weight);
  color: var(--ink-strong);
}
#akashic-health-records-patient-portal-root .ak-empty__description {
  color: var(--ink-muted);
  font-size: inherit;
}
#akashic-health-records-patient-portal-root .ak-empty--boxed {
  padding: 14px;
  border: 1px dashed var(--line);
  border-radius: 8px;
  font-size: var(--ak-font-12-5);
}
#akashic-health-records-patient-portal-root .ak-empty--compact {
  padding: 16px 12px;
}

/* A divider and a row chevron. */
#akashic-health-records-patient-portal-root .ak-body {
  font-size: var(--ak-font-15);
  font-weight: var(--ak-body-weight);
  line-height: var(--ak-line-base);
  color: var(--ink);
}
#akashic-health-records-patient-portal-root .ak-label {
  font-size: var(--ak-font-15);
  font-weight: var(--ak-label-weight);
  color: var(--ink);
}
#akashic-health-records-patient-portal-root .ak-field-help,
#akashic-health-records-patient-portal-root .ak-field-error {
  font-size: var(--ak-font-12);
  color: var(--ink-muted);
  margin-top: 4px;
}
#akashic-health-records-patient-portal-root .ak-field-error {
  color: var(--danger);
}
#akashic-health-records-patient-portal-root .ak-link {
  color: var(--primary);
  text-underline-offset: 3px;
}
#akashic-health-records-patient-portal-root .ak-field[aria-invalid="true"] {
  border-color: var(--danger);
}
/* The :not() chain matches the text-input base rule, which would otherwise out-rank this one. */
#akashic-health-records-patient-portal-root .ak-field:disabled,
#akashic-health-records-patient-portal-root input[type="text"].ak-field:not(.components-form-token-field__input):not(.components-input-control__input):not(.components-search-control__input):not(.components-combobox-control__input):disabled {
  background: var(--sunken);
  cursor: not-allowed;
}

/* Shared composition hooks; domain screens supply data and behavior. */
#akashic-health-records-patient-portal-root .ak-scrim {
  position: fixed;
  inset: 0;
  background: var(--scrim);
}
#akashic-health-records-patient-portal-root .ak-dialog,
#akashic-health-records-patient-portal-root .ak-panel {
  display: flex;
  flex-direction: column;
  min-height: 0;
  background: var(--surface);
  color: var(--ink);
  box-shadow: var(--panel-lift);
}
#akashic-health-records-patient-portal-root .ak-dialog {
  width: min(600px, calc(100vw - 32px));
  max-height: calc(100dvh - 32px);
  border-radius: var(--panel-radius);
}
#akashic-health-records-patient-portal-root .ak-panel {
  width: min(600px, 100vw);
  height: 100dvh;
}
#akashic-health-records-patient-portal-root .ak-overlay__header,
#akashic-health-records-patient-portal-root .ak-overlay__body,
#akashic-health-records-patient-portal-root .ak-overlay__footer {
  padding: 20px 24px;
}
#akashic-health-records-patient-portal-root .ak-overlay__body {
  min-height: 0;
  overflow-y: auto;
}
#akashic-health-records-patient-portal-root .ak-overlay__footer {
  display: flex;
  flex: none;
  justify-content: flex-end;
  gap: 8px;
  border-top: 1px solid var(--line);
}
/* A sheet header sits on a hairline; its description is 12.5px muted text. */
#akashic-health-records-patient-portal-root .ak-panel .ak-overlay__header {
  border-bottom: 1px solid var(--line);
}
#akashic-health-records-patient-portal-root .ak-overlay__description {
  font-size: 12.5px;
  color: var(--ink-muted);
}
@media (max-width: 639px) {
  #akashic-health-records-patient-portal-root .ak-overlay__header,
  #akashic-health-records-patient-portal-root .ak-overlay__body,
  #akashic-health-records-patient-portal-root .ak-overlay__footer {
    padding: 16px;
  }
}
#akashic-health-records-patient-portal-root .ak-nav {
  display: flex;
  flex-direction: column;
  gap: var(--ak-list-gap);
}
#akashic-health-records-patient-portal-root .ak-nav__item {
  display: flex;
  align-items: center;
  gap: 8px;
  min-height: 36px;
  padding: 0 14px;
  margin: 0 8px;
  border: 0;
  border-radius: var(--ak-control-radius);
  background: transparent;
  color: var(--ink-muted);
  font-size: var(--ak-font-15);
  text-align: start;
}
#akashic-health-records-patient-portal-root .ak-nav__item[aria-current="page"] {
  background: var(--sunken);
  color: var(--ink-strong);
  font-weight: 500;
}
#akashic-health-records-patient-portal-root .ak-nav__item--child {
  padding-left: 44px;
}
#akashic-health-records-patient-portal-root .ak-nav__item--exit {
  color: var(--danger);
}
#akashic-health-records-patient-portal-root .ak-tabs-mobile {
  display: none;
}
@media (max-width: 639px) {
  #akashic-health-records-patient-portal-root .ak-tabs-responsive > .ak-tabs {
    display: none;
  }
  #akashic-health-records-patient-portal-root .ak-tabs-responsive > .ak-tabs-mobile {
    display: block;
  }
}
#akashic-health-records-patient-portal-root .ak-toolbar,
#akashic-health-records-patient-portal-root .ak-pagination,
#akashic-health-records-patient-portal-root .ak-attachment,
#akashic-health-records-patient-portal-root .ak-legend {
  display: flex;
  flex-wrap: wrap;
  align-items: center;
  gap: 8px;
}
/* A toolbar field sits on the button line: 30px high with 13px text. */
#akashic-health-records-patient-portal-root .ak-toolbar {
  --ak-field-height: 30px;
  --ak-field-font-size: 13px;
  --ak-field-padding-x: 10px;
}
#akashic-health-records-patient-portal-root .ak-pagination {
  justify-content: flex-end;
  margin-top: 14px;
}
#akashic-health-records-patient-portal-root .ak-pagination__summary {
  margin-right: auto;
  color: var(--ink-muted);
  font-size: var(--ak-font-12);
}
#akashic-health-records-patient-portal-root .ak-pagination [aria-current="page"] {
  background: var(--blue-soft);
  color: var(--primary);
}
#akashic-health-records-patient-portal-root .ak-table-wrap {
  max-width: 100%;
  overflow-x: auto;
}
#akashic-health-records-patient-portal-root .ak-metric__value {
  display: block;
  font-size: var(--ak-font-24);
  font-weight: var(--ak-heading-weight);
  font-variant-numeric: tabular-nums;
  color: var(--ink-strong);
}
#akashic-health-records-patient-portal-root .ak-metric__value--bad {
  color: var(--danger);
}
/* A comparison under a metric is muted; a caller that states a good or bad change colours it. */
#akashic-health-records-patient-portal-root .ak-metric__delta {
  color: var(--ink-muted);
}
#akashic-health-records-patient-portal-root .ak-metric__label,
#akashic-health-records-patient-portal-root .ak-legend {
  font-size: var(--ak-font-12);
  color: var(--ink-muted);
}
/* Facts are a plain label over its value, as every deck draws them; a read-only field readout keeps its ground. */
#akashic-health-records-patient-portal-root .ak-facts {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(min(180px, 100%), 1fr));
  gap: 8px 12px;
  margin: 0;
}
#akashic-health-records-patient-portal-root .ak-facts__item {
  min-width: 0;
  overflow-wrap: anywhere;
}
#akashic-health-records-patient-portal-root .ak-facts--fields .ak-facts__item {
  padding: 8px;
  background: var(--sunken);
}
#akashic-health-records-patient-portal-root .ak-facts dt {
  font-size: var(--ak-font-12);
  color: var(--ink-muted);
}
#akashic-health-records-patient-portal-root .ak-facts dd {
  margin: 2px 0 0;
}
#akashic-health-records-patient-portal-root .ak-switch {
  position: relative;
  display: inline-flex;
  flex: none;
  width: var(--ak-switch-width);
  height: var(--ak-switch-height);
  min-width: var(--ak-switch-width);
  min-height: var(--ak-switch-height);
  padding: 2px;
  border: 0;
  border-radius: 999px;
  background: var(--line);
}
#akashic-health-records-patient-portal-root .ak-switch[aria-checked="true"],
#akashic-health-records-patient-portal-root .ak-switch[data-state="checked"] {
  background: var(--primary);
}
#akashic-health-records-patient-portal-root .ak-switch__thumb {
  display: block;
  width: var(--ak-switch-thumb);
  height: var(--ak-switch-thumb);
  border-radius: 50%;
  background: var(--surface);
}
#akashic-health-records-patient-portal-root .ak-switch[aria-checked="true"] .ak-switch__thumb,
#akashic-health-records-patient-portal-root .ak-switch[data-state="checked"] .ak-switch__thumb {
  transform: translateX(calc(var(--ak-switch-width) - var(--ak-switch-thumb) - 4px));
}
#akashic-health-records-patient-portal-root .ak-progress {
  overflow: hidden;
  height: var(--ak-progress-height);
  border-radius: var(--ak-control-radius);
  background: var(--sunken);
}
#akashic-health-records-patient-portal-root .ak-progress__fill {
  display: block;
  height: 100%;
  width: var(--ak-progress-value, 0%);
  background: var(--primary);
}
#akashic-health-records-patient-portal-root .ak-steps {
  display: grid;
  gap: 6px;
  padding: 0;
  list-style: none;
}
#akashic-health-records-patient-portal-root .ak-step {
  display: flex;
  align-items: baseline;
  gap: 8px;
  color: var(--ink-muted);
  font-size: var(--ak-font-13);
}
#akashic-health-records-patient-portal-root .ak-step[aria-current="step"] {
  color: var(--primary);
  font-weight: 500;
}
#akashic-health-records-patient-portal-root .ak-step[data-state="complete"] {
  color: var(--sage-ink);
}
#akashic-health-records-patient-portal-root .ak-upload {
  padding: var(--ak-card-pad);
  border: 1px dashed var(--line);
  border-radius: var(--ak-control-radius);
  color: var(--ink-muted);
  background: var(--surface);
}
#akashic-health-records-patient-portal-root .ak-upload[data-drag-active="true"] {
  border-color: var(--primary);
  background: var(--blue-soft);
}
#akashic-health-records-patient-portal-root .ak-upload[aria-invalid="true"] {
  border-color: var(--danger);
}
#akashic-health-records-patient-portal-root .ak-attachment__name {
  min-width: 0;
  overflow-wrap: anywhere;
  font-size: var(--ak-font-13);
}
#akashic-health-records-patient-portal-root .ak-disclosure__trigger {
  display: flex;
  align-items: center;
  gap: 8px;
  width: 100%;
  padding: 8px 0;
  border: 0;
  background: transparent;
  color: var(--ink-strong);
  font-size: var(--ak-font-13);
  text-align: start;
}
#akashic-health-records-patient-portal-root .ak-disclosure__content {
  padding: 8px 0;
}
#akashic-health-records-patient-portal-root .ak-menu,
#akashic-health-records-patient-portal-root .ak-tooltip {
  padding: 4px;
  border: 1px solid var(--line);
  border-radius: var(--ak-popup-radius);
  background: var(--surface);
  color: var(--ink);
  box-shadow: var(--ak-card-lift);
}
#akashic-health-records-patient-portal-root .ak-menu__item {
  display: flex;
  align-items: center;
  gap: 8px;
  padding: 6px 10px;
  min-height: 30px;
  width: 100%;
  border: 0;
  background: transparent;
  color: var(--ink);
  font-size: var(--ak-font-13);
  text-align: start;
}
#akashic-health-records-patient-portal-root .ak-menu__item:hover,
#akashic-health-records-patient-portal-root .ak-menu__item[data-highlighted] {
  background: var(--line-soft);
}
#akashic-health-records-patient-portal-root .ak-menu__item[aria-checked="true"] {
  background: var(--blue-soft);
  color: var(--primary);
}
#akashic-health-records-patient-portal-root .ak-menu__item--danger {
  color: var(--danger);
}
#akashic-health-records-patient-portal-root .ak-tooltip {
  max-width: min(280px, calc(100vw - 24px));
  padding: 6px 10px;
  font-size: var(--ak-font-12);
}
#akashic-health-records-patient-portal-root .ak-status-line {
  display: flex;
  align-items: center;
  gap: 6px;
  font-size: var(--ak-font-12);
  color: var(--ink-muted);
}
#akashic-health-records-patient-portal-root .ak-status-line--error {
  color: var(--danger);
}
#akashic-health-records-patient-portal-root .ak-status-line--success {
  color: var(--sage-ink);
}
#akashic-health-records-patient-portal-root .ak-spinner {
  width: 16px;
  height: 16px;
  border: 2px solid var(--line);
  border-top-color: var(--primary);
  border-radius: 50%;
  animation: ak-common-spin 0.8s linear infinite;
}
@keyframes ak-common-spin { to { transform: rotate(360deg); } }
@media (prefers-reduced-motion: reduce) {
  #akashic-health-records-patient-portal-root .ak-spinner { animation: none; }
}
#akashic-health-records-patient-portal-root .ak-switch:focus-visible,
#akashic-health-records-patient-portal-root .ak-field:focus-visible,
#akashic-health-records-patient-portal-root .ak-menu__item:focus-visible,
#akashic-health-records-patient-portal-root .ak-nav__item:focus-visible,
#akashic-health-records-patient-portal-root .ak-disclosure__trigger:focus-visible,
#akashic-health-records-patient-portal-root .ak-upload:focus-within,
#akashic-health-records-patient-portal-root .ak-link:focus-visible {
  outline: 2px solid var(--primary);
  outline-offset: 2px;
}
#akashic-health-records-patient-portal-root .ak-switch:disabled,
#akashic-health-records-patient-portal-root .ak-menu__item:disabled,
#akashic-health-records-patient-portal-root .ak-menu__item[aria-disabled="true"] {
  opacity: 0.5;
  cursor: not-allowed;
}
#akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .ak-menu__item {
  min-height: 44px;
}
#akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .ak-nav__item {
  min-height: 44px;
}

/* A divider and a row chevron. */
#akashic-health-records-patient-portal-root .ak-rule,
#akashic-health-records-patient-portal-root hr {
  height: 0;
  margin: 8px 0;
  border: 0;
  border-top: 1px solid var(--line-soft);
}
#akashic-health-records-patient-portal-root .ak-chev {
  flex: none;
  width: 15px;
  height: 15px;
  margin-left: auto;
  color: var(--faint);
  transition: transform 150ms ease;
}
#akashic-health-records-patient-portal-root [aria-expanded="true"] > .ak-chev,
#akashic-health-records-patient-portal-root [open] > summary .ak-chev {
  transform: rotate(180deg);
}

/* =========================================================
   4. OVERLAY / PORTAL LAYER
   All floating UI should portal into this container
   ========================================================= */

#akashic-overlay-root {
  position: relative;
  /* Topmost layer: must sit above host WordPress theme chrome (sticky headers/menus) and the WP admin bar
     (z-index 99999). Only portalled modals/sheets live here, so an always-on-top value is correct. */
  z-index: 2147483647;
}

#akashic-health-records-patient-portal-root [data-slot="dialog-content"],
#akashic-health-records-patient-portal-root [data-slot="dialog-overlay"],
#akashic-health-records-patient-portal-root [data-slot="dialog-close"],
#akashic-health-records-patient-portal-root [data-slot="sheet-content"] {
  font-family: inherit;
}

#akashic-health-records-patient-portal-root [data-slot="dialog-content"] {
  box-sizing: border-box;
  max-height: calc(100vh - 2rem);
  overflow-x: auto;
  overflow-y: auto;
}

/* Only for a dialog whose caller names no width. ui/dialog marks one that names a w-* or max-w-* class
   data-width="declared", and this rule must not match it: at 1,1,0 it outranks every utility class, so it
   would replace the width the caller asked for. :where keeps the specificity this rule has always had. */
#akashic-health-records-patient-portal-root [data-slot="dialog-content"]:where(:not([data-width="declared"])) {
  width: max-content;
  min-width: min(32rem, calc(100vw - 2rem));
  /* Content-sized up to the shared 600px dialog (.ak-dialog), not to the viewport: a long sentence otherwise
     stretches a form dialog across the page. */
  max-width: min(600px, calc(100vw - 2rem));
}

/* A dialog footer stays in view while the body scrolls, so a phone sheet shows its actions at first open, and
   it reads as the ruled band .ak-overlay__footer draws. The band and its rule are painted out to the dialog
   edges rather than laid out there, so they hold whatever padding the caller gives the dialog at any width; the
   dialog clips the paint to itself. A caller that binds .ak-overlay__footer owns its footer and is left alone. */
#akashic-health-records-patient-portal-root [data-slot="dialog-content"] [data-slot="dialog-footer"]:not(.ak-overlay__footer) {
  position: sticky;
  bottom: 0;
  z-index: 1;
  padding-top: 16px;
  background: var(--surface);
  box-shadow: 0 0 0 100vmax var(--surface);
  clip-path: inset(0 -100vmax -100vmax);
  border-top: 1px solid transparent;
  border-image: linear-gradient(var(--line), var(--line)) 1 0 0 / 1px 0 0 / 0 100vmax;
}

#akashic-health-records-patient-portal-root [data-slot="dialog-content"] > * {
  box-sizing: border-box;
  max-width: 100%;
  min-width: 0;
}
#akashic-health-records-patient-portal-root [data-slot="dialog-content"] :is(p, span, label, div) {
  overflow-wrap: anywhere;
}
/* A dialog header laid out as a row sets its title beside controls such as Print. With the rule above
   the title could shrink to a character a line on a phone; the row wraps, so the controls drop below it.
   Where the dialog draws its own close button in the corner, the row also keeps its controls clear of it. */
#akashic-health-records-patient-portal-root [data-slot="dialog-content"] [data-slot="dialog-header"].flex-row {
  flex-wrap: wrap;
}
#akashic-health-records-patient-portal-root [data-slot="dialog-content"][data-close-button="true"] [data-slot="dialog-header"].flex-row {
  padding-right: 3rem;
}

/* A patient's dialog on a phone is the deck's .ovsheet: it rises from the bottom edge, grows to fit and
   scrolls inside at its ceiling. ui/dialog marks it; wider screens keep the centred modal. The overlay
   root in the selector outranks each overlay's own sizing rule, so every patient overlay takes the shape. */
#akashic-health-records-patient-portal-root #akashic-overlay-root [data-slot="dialog-content"][data-presentation="sheet"] {
  top: auto;
  right: 0;
  bottom: 0;
  left: 0;
  width: 100%;
  min-width: 0;
  max-width: 100%;
  max-height: 88svh;
  /* The grab bar is painted in a clear top border and the home indicator gets a clear bottom one, so both
     add to whatever padding the overlay draws and neither scrolls away with its content. */
  border: 0 solid transparent;
  border-top-width: 12px;
  border-bottom-width: env(safe-area-inset-bottom, 0px);
  border-radius: var(--sheet-radius) var(--sheet-radius) 0 0;
  background-image: linear-gradient(var(--line), var(--line));
  background-origin: border-box;
  background-position: center 8px;
  background-repeat: no-repeat;
  background-size: 36px 4px;
  box-shadow: var(--sheet-lift);
  transform: none;
  overscroll-behavior: contain;
  --tw-enter-scale: 1;
  --tw-enter-translate-y: 100%;
  --tw-exit-scale: 1;
  --tw-exit-translate-y: 100%;
}
/* The deck's body padding, for an overlay that names none of its own. */
:where(#akashic-health-records-patient-portal-root [data-slot="dialog-content"][data-presentation="sheet"]) {
  padding: 10px 14px 16px;
}
/* The deck's sheet heading sits at the left with the close beside it, not centred over the body. */
#akashic-health-records-patient-portal-root [data-presentation="sheet"] [data-slot="dialog-header"] {
  text-align: left;
}
#akashic-health-records-patient-portal-root [data-presentation="sheet"] [data-slot="dialog-title"] {
  padding-left: 0;
}

/* A shared panel keeps its own surface; this later rule would otherwise outrank .ak-panel. */
#akashic-health-records-patient-portal-root [data-slot="sheet-content"]:not(.ak-panel) {
  background-color: var(--background);
  color: var(--foreground);
}

#akashic-health-records-patient-portal-root [data-slot="card"].ak-card-flat,
#akashic-health-records-patient-portal-root .ak-card--flat {
  box-shadow: none;
}

/* THE DEFAULT EDGE, AND A CALL SITE IS ALLOWED TO DISAGREE WITH IT.

   `border-color` used to sit in the rule above, at (1,1,0), where it beat every `border-*` utility a
   call site handed the Card - so the one card asking a patient to decide something drew the same edge as
   the card listing what they had already decided. Six call sites were passing a colour into a slot that
   overwrote it, and each read correct at exactly the place anybody would look.

   `:where(...)` CONTRIBUTES NOTHING TO SPECIFICITY, so this whole selector weighs (0,0,0) and any
   call-site border wins. It still beats Tailwind's `*` preflight, which is also (0,0,0) and is emitted
   far above this, so a card that asks for no border keeps exactly what it has today. That is the reason
   for `:where` over `:not([class*="border-"])`: the narrower change in behaviour.

   ONLY THE BORDER MOVED. Background and text stay at their old weight on purpose - dropping those to
   zero as well would hand every `bg-*` utility a card it could not previously reach, which is a wider
   change than the one asked for and nobody has measured it.

   `.ak-card-plain` below is unaffected: it is (1,2,0) and still wins, including over a call-site
   utility, which is what a card that draws no surface of its own needs. */
:where(#akashic-health-records-patient-portal-root [data-slot="card"]) {
  border-color: var(--border);
}

/* The section label the patient portal uses above a card or a list.
   Small, uppercase and tracked - a signpost, not a destination, which is why it is quieter than the
   things beneath it. The approved decks use it at EVERY width, so it is not a mobile treatment.
   A count or sentence sitting inside it opts out with `.ak-caption__note`. */
#akashic-health-records-patient-portal-root .ak-caption {
  display: flex;
  align-items: baseline;
  gap: 8px;
  margin: 0 0 6px;
  font-size: 11px;
  font-weight: 500;
  letter-spacing: 0.07em;
  text-transform: uppercase;
  color: var(--ink-muted);
}

#akashic-health-records-patient-portal-root .ak-caption__note {
  font-size: var(--ak-font-12);
  font-weight: var(--ak-body-weight);
  letter-spacing: normal;
  text-transform: none;
  color: var(--muted-foreground);
}

/* A card that only groups - it draws no surface of its own because its children draw theirs.
   Needed because the rule above is (1,0,1) and `bg-transparent` at (0,1,0) cannot reach it, so
   without this the call site is pushed into an `!` override. The second selector outranks the shell's
   square-card rule, which gives every `.rounded` the lift - on a plain card that drew a shadow along
   the right and bottom edge of a page that has no card at all. */
#akashic-health-records-patient-portal-root [data-slot="card"].ak-card-plain,
#akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .ak-shell [data-slot="card"].ak-card-plain {
  background-color: transparent;
  border-color: transparent;
  box-shadow: none;
}

#akashic-health-records-patient-portal-root [data-slot="sheet-content"] p,
#akashic-health-records-patient-portal-root [data-slot="sheet-content"] h1,
#akashic-health-records-patient-portal-root [data-slot="sheet-content"] h2,
#akashic-health-records-patient-portal-root [data-slot="sheet-content"] h3,
#akashic-health-records-patient-portal-root [data-slot="sheet-content"] h4 {
  margin: 0;
}

/* =========================================================
   BASE CONTROL LAYOUT NORMALIZATION
   Force WordPress base-control wrappers and their direct children
   to fill the same width so token fields and selects align cleanly
   ========================================================= */
#akashic-health-records-patient-portal-root .components-base-control,
#akashic-health-records-patient-portal-root .components-base-control__field {
  width: 100%;
  min-width: 0;
  max-width: none;
}

#akashic-health-records-patient-portal-root .components-base-control__field {
  display: grid;
  grid-template-columns: minmax(0, 1fr);
  align-items: start;
}

#akashic-health-records-patient-portal-root .components-base-control__field > * {
  width: 100%;
  min-width: 0;
  max-width: none;
}

#akashic-health-records-patient-portal-root .components-form-token-field,
#akashic-health-records-patient-portal-root .components-form-token-field__input-container,
#akashic-health-records-patient-portal-root .components-input-control,
#akashic-health-records-patient-portal-root .components-input-control__container {
  width: 100%;
  min-width: 0;
  max-width: none;
}

/* Unified select normalization
   Applies one consistent visual system to:
   - native <select> controls
   - Radix/shadcn select triggers and portaled content
*/
#akashic-health-records-patient-portal-root select,
#akashic-health-records-patient-portal-root [data-slot="select-trigger"],
#akashic-health-records-patient-portal-root button[role="combobox"],
#akashic-health-records-patient-portal-root [role="combobox"]:not(:where(.ak-field-shell) *) {
  box-sizing: border-box;
  min-width: 0;
  max-width: none;
  min-height: var(--ak-field-height);
  margin: 0;
  border: 1px solid var(--line);
  border-radius: var(--ak-field-radius);
  background-color: var(--surface);
  color: var(--ink);
  font-size: var(--ak-field-font-size);
  line-height: var(--ak-field-line-height);
  box-shadow: none;
}

/* Native selects */
#akashic-health-records-patient-portal-root select {
  -webkit-appearance: none;
  appearance: none;
  padding: 0 2.5rem 0 var(--ak-field-padding-x);
  background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='16' height='16' viewBox='0 0 24 24' fill='none' stroke='%236b7280' stroke-width='2' stroke-linecap='round' stroke-linejoin='round'%3E%3Cpath d='m6 9 6 6 6-6'/%3E%3C/svg%3E");
  background-repeat: no-repeat;
  background-position: right 0.75rem center;
  background-size: 1rem;
}

/* WordPress SelectControl already renders its own chevron suffix. */
#akashic-health-records-patient-portal-root .components-select-control__input {
  background-image: none;
}

/* Radix/shadcn select path: trigger owns the visible shell, wrapper stays neutral */
#akashic-health-records-patient-portal-root .components-input-control__container {
  display: flex;
  align-items: center;
  gap: 0;
  width: 100%;
  min-width: 0;
  max-width: none;
  padding: 0;
  border: 0;
  background: transparent;
  box-shadow: none;
}

/* =========================================================
   WORDPRESS INPUTCONTROL — TEXT INPUT ONLY
   Give the visible shell only to text-style InputControl wrappers,
   not to select/combobox wrappers that already own their shell
   ========================================================= */

#akashic-health-records-patient-portal-root .components-input-control__container {
  display: flex;
  align-items: center;
  gap: 0;
  width: 100%;
  min-width: 0;
  max-width: none;
  padding: 0;
  border: 0;
  background: transparent;
  box-shadow: none;
}

/* Text-like InputControl path gets the shell */
#akashic-health-records-patient-portal-root .components-input-control__container:has(> .components-input-control__input) {
  min-height: var(--ak-field-height);
  border: 1px solid var(--line);
  border-radius: var(--ak-field-radius);
  background-color: var(--surface);
}

/* Inner input fills the shell and owns padding */
#akashic-health-records-patient-portal-root .components-input-control__input,
#akashic-health-records-patient-portal-root .components-text-control__input {
  box-sizing: border-box;
  width: 100%;
  min-width: 0;
  max-width: none;
  height: calc(var(--ak-field-height) - 2px);
  margin: 0;
  padding: 0 var(--ak-field-padding-x);
  border: 0;
  border-radius: inherit;
  background: transparent;
  color: inherit;
  font: inherit;
  line-height: var(--ak-field-line-height);
  box-shadow: none;
  outline: none;
}

/* Focus only for text-like InputControl */
#akashic-health-records-patient-portal-root .components-input-control__container:has(> .components-input-control__input):focus-within {
  border-color: var(--primary);
  box-shadow: 0 0 0 3px rgb(var(--primary-rgb) / 0.15);
}

/* Backdrop stays inert */
#akashic-health-records-patient-portal-root .components-input-control__backdrop {
  border: 0;
  background: transparent;
  box-shadow: none;
}

/* Autofill hardening for text-style inputs inside contained shells */
#akashic-health-records-patient-portal-root .components-input-control__input:-webkit-autofill,
#akashic-health-records-patient-portal-root .components-input-control__input:-webkit-autofill:hover,
#akashic-health-records-patient-portal-root .components-input-control__input:-webkit-autofill:focus,
#akashic-health-records-patient-portal-root input[type="email"]:-webkit-autofill,
#akashic-health-records-patient-portal-root input[type="email"]:-webkit-autofill:hover,
#akashic-health-records-patient-portal-root input[type="email"]:-webkit-autofill:focus {
  -webkit-text-fill-color: var(--ink);
  -webkit-box-shadow: inset 0 0 0 1000px var(--surface);
  box-shadow: inset 0 0 0 1000px var(--surface);
  border-radius: inherit;
}

#akashic-health-records-patient-portal-root [data-slot="select-trigger"],
#akashic-health-records-patient-portal-root button[role="combobox"],
#akashic-health-records-patient-portal-root [role="combobox"]:not(:where(.ak-field-shell) *) {
  display: inline-flex;
  align-items: center;
  justify-content: space-between;
  gap: 0.75rem;
  min-width: 0;
  max-width: none;
  margin: 0;
  /* No vertical padding: the field height alone sizes it, so a select and a text field always match. */
  padding: 0 var(--ak-field-padding-x);
  text-align: left;
  background-image: none;
  height: auto;
}

/* THE DEFAULT WIDTH FOR A SELECT, AND THE ONE DECLARATION IN THIS FILE A UTILITY IS ALLOWED TO BEAT.

   It is split out of the two resets above and wrapped in `:where()`, which makes the whole selector
   count as zero specificity. So an unstyled select still fills its field -- the behaviour every form in
   the product relies on -- while any `w-*` on the element wins, which is what a caller writing `w-20`
   plainly meant.

   WHY IT HAD TO CHANGE. The resets are ID-scoped, so `width: 100%` outranked any Tailwind `w-*` and
   there was no way to win from a className. Measured on the running app: the address editor's state
   picker carried `w-20` and computed to 428px, squeezing the City and ZIP beside it in the same flex row
   to 25px each -- a row nobody could type a city into. That class could never have applied, on any
   screen, since it was written.

   `:where()` rather than raising the utility's specificity, because the fix has to work for a class
   nobody has written yet. And the whole selector rather than only the id: an attribute selector like
   `[data-slot="select-trigger"]` already ties with a single class, and a tie is decided by source
   order -- which this file wins. A tie is not an override.

   VERIFIED AGAINST THE REAL BUILT STYLESHEET before shipping, by reproducing this edit in the live
   CSSOM and measuring a trigger three ways:

       no width utility   371px   the field width -- the default still does its job
       w-20               80px    5rem, so the utility wins
       restored           371px

   THE NEXT TRAP, AND IT IS NOT THIS RULE. `SelectTrigger` puts `w-full` on itself. Two utilities tie
   on specificity, so source order decides and Tailwind emits `w-full` after `w-20` -- meaning a caller
   who adds `w-20` and leaves `w-full` in place still gets 100%, now losing to a sibling utility rather
   than to this reset. It reads exactly like this bug and is a different one.
   => When you set an explicit width on a trigger, REMOVE `w-full` as well. */
:where(#akashic-health-records-patient-portal-root select),
:where(#akashic-health-records-patient-portal-root [data-slot="select-trigger"]),
:where(#akashic-health-records-patient-portal-root button[role="combobox"]),
:where(#akashic-health-records-patient-portal-root [role="combobox"]) {
  width: 100%;
}

/* The narrow fix that came first, kept because it still does something the rule above does not: it also
   releases the trigger from `flex: 1 1 auto`, so a fixed-width picker stops absorbing the row's spare
   space. One marker class, set by one component. */
#akashic-health-records-patient-portal-root [data-slot="select-trigger"].ak-select-fixed-w {
  width: var(--ak-select-fixed-w, auto);
  flex: 0 0 auto;
}

#akashic-health-records-patient-portal-root [data-slot="select-trigger"] > span,
#akashic-health-records-patient-portal-root button[role="combobox"] > span,
#akashic-health-records-patient-portal-root [role="combobox"] > span {
  min-width: 0;
  flex: 1 1 auto;
  overflow: hidden;
}

#akashic-health-records-patient-portal-root [data-slot="select-trigger"] svg,
#akashic-health-records-patient-portal-root button[role="combobox"] svg,
#akashic-health-records-patient-portal-root [role="combobox"] svg {
  flex-shrink: 0;
  width: 1rem;
  height: 1rem;
  color: var(--ink-muted);
}

#akashic-health-records-patient-portal-root select:hover,
#akashic-health-records-patient-portal-root [data-slot="select-trigger"]:hover,
#akashic-health-records-patient-portal-root button[role="combobox"]:hover,
#akashic-health-records-patient-portal-root [role="combobox"]:not(:where(.ak-field-shell) *):hover {
  background-color: var(--surface);
  color: var(--ink);
  border-color: var(--faint);
}

#akashic-health-records-patient-portal-root select:focus,
#akashic-health-records-patient-portal-root select:focus-visible,
#akashic-health-records-patient-portal-root [data-slot="select-trigger"]:focus,
#akashic-health-records-patient-portal-root [data-slot="select-trigger"]:focus-visible,
#akashic-health-records-patient-portal-root [data-slot="select-trigger"][data-state="open"],
#akashic-health-records-patient-portal-root button[role="combobox"]:focus,
#akashic-health-records-patient-portal-root button[role="combobox"]:focus-visible,
#akashic-health-records-patient-portal-root button[role="combobox"][data-state="open"],
#akashic-health-records-patient-portal-root [role="combobox"]:not(:where(.ak-field-shell) *):focus,
#akashic-health-records-patient-portal-root [role="combobox"]:not(:where(.ak-field-shell) *):focus-visible,
#akashic-health-records-patient-portal-root [role="combobox"]:not(:where(.ak-field-shell) *)[data-state="open"] {
  background-color: var(--surface);
  color: var(--ink);
  border-color: var(--primary);
  box-shadow: 0 0 0 3px rgb(var(--primary-rgb) / 0.15);
  outline: none;
}

#akashic-health-records-patient-portal-root select:disabled,
#akashic-health-records-patient-portal-root [data-slot="select-trigger"]:disabled,
#akashic-health-records-patient-portal-root button[role="combobox"]:disabled,
#akashic-health-records-patient-portal-root [role="combobox"]:disabled,
#akashic-health-records-patient-portal-root [aria-disabled="true"][data-slot="select-trigger"],
#akashic-health-records-patient-portal-root [aria-disabled="true"][role="combobox"] {
  background-color: var(--sunken);
  color: var(--faint);
  cursor: not-allowed;
}

#akashic-health-records-patient-portal-root option {
  color: var(--ink);
  background: var(--surface);
}

/* Also keyed on the overlay root, so an open list keeps its ground and stacking wherever the overlay mounts.
   The fallbacks hold where the app tokens do not reach. */
#akashic-health-records-patient-portal-root [data-slot="select-content"],
#akashic-overlay-root [data-slot="select-content"] {
  border: 1px solid var(--line, #e2ddd5);
  border-radius: var(--ak-field-radius, 8px);
  background: var(--surface, #ffffff);
  color: var(--ink, #1f1d1a);
  box-shadow: 0 10px 30px rgba(0, 0, 0, 0.12);
  overflow: hidden;
  z-index: 10000;
}

#akashic-health-records-patient-portal-root [data-slot="select-viewport"] {
  padding: 0.25rem;
}

#akashic-health-records-patient-portal-root [data-slot="select-item"] {
  min-height: 40px;
  padding: 8px 12px;
  border-radius: 6px;
  display: flex;
  align-items: center;
  font-size: var(--ak-field-font-size);
  line-height: var(--ak-field-line-height);
  color: var(--ink);
  background: transparent;
  cursor: pointer;
}

/* BOTH OF THESE WERE LOSING A SPECIFICITY TIE AND NEITHER HUE WAS REACHING THE SCREEN.
   `SelectItem` carries shadcn's own `focus:bg-accent focus:text-accent-foreground` utilities in its
   className. Under the mount id those emit `#…root .focus\:bg-accent:focus`, which scores (1,2,0) —
   exactly what `#…root [data-slot="select-item"][data-highlighted]` scores — and Tailwind's
   utilities are emitted after this block, so the LATER rule won. `--accent` is `--line-soft`, so
   every highlighted row rendered a warm putty fill instead of the blue tint declared here.

   MEASURED on the workspace switcher, four rows, pointer on row 2:
       Practitioner  checked      rgba(47, 111, 165, 0.12)   cool blue
       Receptionist  highlighted  rgb(240, 237, 231)         warm putty
   Two rows filled at once in two different hues, adjacent, in a four-row menu — and the warm one is
   the tint the sidebar rail eight pixels away reserves for HOVER on a nav row.

   The remedy is the house one: a NAMED rule at a weight the utility cannot beat, not a `!`. Scoping
   each to its own popover raises them to (1,3,0) and (1,4,0), which also describes the real
   containment rather than inventing a hook.

   AND THE CHECKED ROW IS RAISED HIGHER THAN THE HIGHLIGHT ON PURPOSE. Radix highlights the checked
   item the moment the menu opens, so the two states land on one row constantly. The sidebar ruling
   above settled this exact question for the nav rail — "a hovered SELECTED row does not change. It
   is already the strongest state" — and the same answer applies here: without the second selector a
   highlighted checked row would drop from 12% to 8% and pointing at the row you are already on would
   make it look less chosen. */
#akashic-health-records-patient-portal-root [data-slot="select-content"] [data-slot="select-item"]:hover,
#akashic-health-records-patient-portal-root [data-slot="select-content"] [data-slot="select-item"][data-highlighted] {
  background: rgb(var(--primary-rgb) / 0.08);
  color: var(--ink);
  outline: none;
}

#akashic-health-records-patient-portal-root [data-slot="select-content"] [data-slot="select-item"][data-state="checked"],
#akashic-health-records-patient-portal-root [data-slot="select-content"] [data-slot="select-item"][data-state="checked"][data-highlighted] {
  background: rgb(var(--primary-rgb) / 0.12);
  color: var(--ink);
}

#akashic-health-records-patient-portal-root [data-slot="select-label"] {
  padding: 0.5rem 0.75rem 0.25rem;
  font-size: var(--ak-font-xs);
  font-weight: 600;
  color: var(--ink-muted);
}

#akashic-health-records-patient-portal-root [data-slot="select-separator"] {
  height: 1px;
  margin: 0.25rem 0;
  background: var(--line-soft);
}

/* Sheet flyout practitioner summary row only */
#akashic-health-records-patient-portal-root
[data-slot="sheet-content"]
[data-slot="card-content"]
> .flex.gap-2.justify-between.border-b.pb-2
> .flex.flex-1.gap-2 {
  align-items: center;
  min-width: 0;
}

#akashic-health-records-patient-portal-root
[data-slot="sheet-content"]
[data-slot="card-content"]
> .flex.gap-2.justify-between.border-b.pb-2
> .flex.flex-1.gap-2
img {
  width: 3.25rem;
  height: 3.25rem;
  min-width: 3.25rem;
  max-width: 3.25rem;
  object-fit: cover;
  flex-shrink: 0;
  border-radius: 0.5rem;
}

#akashic-health-records-patient-portal-root
[data-slot="sheet-content"]
[data-slot="card-content"]
> .flex.gap-2.justify-between.border-b.pb-2
> .flex.flex-1.gap-2
> div {
  min-width: 0;
  flex: 1;
}

/* =========================================================
   TOKEN FIELD SUGGESTION DROPDOWN NORMALIZATION
   Style WordPress FormTokenField suggestion menus the same way
   as the rest of the app's dropdowns
   ========================================================= */
#akashic-health-records-patient-portal-root .components-form-token-field__suggestions-container {
  width: 100%;
  min-width: 0;
  max-width: none;
  margin-top: 0.25rem;
}

#akashic-health-records-patient-portal-root .components-form-token-field__suggestions-list {
  margin: 0;
  padding: 0.25rem;
  list-style: none;
  border: 1px solid var(--line);
  border-radius: 0.5rem;
  background: var(--surface);
  color: var(--ink);
  box-shadow: 0 10px 30px rgba(0, 0, 0, 0.12);
  overflow: hidden;
}

#akashic-health-records-patient-portal-root .components-form-token-field__suggestion {
  display: flex;
  align-items: center;
  width: 100%;
  min-width: 0;
  min-height: 40px;
  margin: 0;
  padding: 8px 12px;
  border: 0;
  border-radius: 0.375rem;
  background: transparent;
  color: var(--ink);
  font-size: var(--ak-field-font-size);
  line-height: var(--ak-field-line-height);
  text-align: left;
  white-space: nowrap;
  cursor: pointer;
}

#akashic-health-records-patient-portal-root .components-form-token-field__suggestion:hover,
#akashic-health-records-patient-portal-root .components-form-token-field__suggestion.is-selected,
#akashic-health-records-patient-portal-root .components-form-token-field__suggestion[aria-selected="true"] {
  background: rgb(var(--primary-rgb) / 0.08);
  color: var(--ink);
}

#akashic-health-records-patient-portal-root .components-form-token-field__suggestion.is-selected,
#akashic-health-records-patient-portal-root .components-form-token-field__suggestion[aria-selected="true"] {
  background: rgb(var(--primary-rgb) / 0.12);
}

#akashic-health-records-patient-portal-root .components-form-token-field__suggestion[aria-disabled="true"] {
  opacity: 0.5;
  cursor: not-allowed;
}

/* =========================================================
   5. COMPONENT HARDENING
   Protect specific components from theme/plugin bleed
   ========================================================= */

#akashic-health-records-patient-portal-root .components-button.is-primary {
  background: var(--wp-admin-theme-color);
  border-color: var(--wp-admin-theme-color);
  color: oklch(1 0 0);
  text-decoration: none;
  text-shadow: none;
}

#akashic-health-records-patient-portal-root .components-button.is-primary:hover:not(:disabled):not([aria-disabled="true"]) {
  background: var(--wp-admin-theme-color-darker-10);
  border-color: var(--wp-admin-theme-color-darker-10);
  color: oklch(1 0 0);
}

#akashic-health-records-patient-portal-root .components-button.is-secondary {
  color: var(--wp-admin-theme-color);
  border-color: var(--wp-admin-theme-color);
}

#akashic-health-records-patient-portal-root .components-button.is-secondary:hover:not(:disabled):not([aria-disabled="true"]) {
  color: var(--wp-admin-theme-color-darker-10);
  border-color: var(--wp-admin-theme-color-darker-10);
}

/* WordPress Button disabled state.
   Our component hardening colors otherwise mask WordPress's native disabled styling. */
#akashic-health-records-patient-portal-root .components-button:disabled,
#akashic-health-records-patient-portal-root .components-button[aria-disabled="true"] {
  cursor: not-allowed;
  opacity: 0.55;
  pointer-events: none;
  box-shadow: none;
}

#akashic-health-records-patient-portal-root .components-button.is-primary:disabled,
#akashic-health-records-patient-portal-root .components-button.is-primary[aria-disabled="true"] {
  background: var(--sunken);
  border-color: var(--line);
  color: var(--faint);
}

/* Theme color compatibility */
#akashic-health-records-patient-portal-root .bg-blue-600,
#akashic-health-records-patient-portal-root .bg-blue-500 {
  background-color: var(--primary);
}

#akashic-health-records-patient-portal-root .border-blue-600,
#akashic-health-records-patient-portal-root .border-blue-500 {
  border-color: var(--primary);
}

/* Legacy data-kind support during transition to semantic button classes */
#akashic-health-records-patient-portal-root [data-slot="button"][data-kind="primary-action"] {
  display: inline-flex;
  align-items: center;
  justify-content: center;
  min-height: 2.25rem;
  padding: 0.5rem 1rem;
  border: 1px solid var(--primary);
  border-radius: 0.3rem;
  background-color: var(--primary);
  color: var(--primary-foreground);
  font-size: var(--ak-font-sm);
  font-weight: 500;
  line-height: 1;
  white-space: nowrap;
  transition:
    background-color 0.2s ease,
    border-color 0.2s ease,
    color 0.2s ease,
    opacity 0.2s ease,
    transform 0.15s ease;
}

#akashic-health-records-patient-portal-root [data-slot="button"][data-kind="primary-action"]:hover:not(:disabled) {
  background-color: rgb(var(--primary-rgb) / 0.9);
  border-color: rgb(var(--primary-rgb) / 0.9);
  color: var(--primary-foreground);
}

#akashic-health-records-patient-portal-root [data-slot="button"][data-kind="primary-action"]:active:not(:disabled) {
  background-color: rgb(var(--primary-rgb) / 0.82);
  border-color: rgb(var(--primary-rgb) / 0.82);
  color: var(--primary-foreground);
}

/* =========================================================
   6. WORDPRESS / GUTENBERG OVERRIDES
   Keep WP-specific fixes isolated in one section
   ========================================================= */

#akashic-health-records-patient-portal-root .wrap {
  margin: 0;
  padding: 0;
}

#akashic-health-records-patient-portal-root .wp-heading-inline {
  display: inline-block;
  margin-right: 5px;
}

#akashic-health-records-patient-portal-root .page-title-action {
  margin-left: 4px;
  padding: 4px 8px;
}

#akashic-health-records-patient-portal-root .notice {
  background: oklch(1 0 0);
  border-left: 4px solid #ddd;
  box-shadow: 0 1px 1px rgba(0, 0, 0, 0.04);
  margin: 5px 0 15px;
  padding: 1px 12px;
}

#akashic-health-records-patient-portal-root .notice-error {
  border-left-color: var(--danger);
}

#akashic-health-records-patient-portal-root .notice-warning {
  border-left-color: var(--warning);
}

#akashic-health-records-patient-portal-root .notice-success {
  border-left-color: var(--success);
}

#akashic-health-records-patient-portal-root .notice-info {
  border-left-color: var(--primary);
}

#akashic-health-records-patient-portal-root .wp-unit-control .components-unit-control__unit-label,
#akashic-health-records-patient-portal-root .wp-unit-control .components-unit-control__select {
  min-width: 48px;
  max-width: 100px;
}

#akashic-health-records-patient-portal-root .wp-guide {
  width: 800px;
}

#akashic-health-records-patient-portal-root .wp-progress-bar {
  width: 100%;
  height: 2px;
}

#akashic-health-records-patient-portal-root .wp-search-control {
  width: 100%;
}

#akashic-health-records-patient-portal-root .wp-tab-panel {
  height: 100%;
  max-height: 100%;
  border: none;
}

#akashic-health-records-patient-portal-root .components-tab-panel__tab-content {
  height: calc(100% - 48px);
}

#akashic-health-records-patient-portal-root .components-modal__header + div {
  height: 100%;
}

/* WP styles overwrite */
/* Unscoped on purpose: WP Modal portals into document.body, outside the plugin root.
   Stops wheel/touch scroll chaining to the page behind when modal content hits its end. */
.components-modal__content {
  overscroll-behavior: contain;
}

#akashic-health-records-patient-portal-root a:where(:not(.wp-element-button)) {
  text-decoration: none;
}

#akashic-health-records-patient-portal-root .is-layout-constrained
> :where(:not(.alignleft):not(.alignright):not(.alignfull)) {
  max-width: 100%;
  margin-left: auto;
  margin-right: auto;
}

/* =========================================================
   7. UTILITIES / HELPERS
   Scoped helper classes used across the app
   ========================================================= */

/* =========================================================
   THE SCROLLBAR, AND IT IS NOT AN OPT-IN.

   🗣️ Spencer, 2026-09-08: "Scroll bar doesn't match mockup."

   🔍 Why it did not: `.thin-scrollbar` below is a HELPER CLASS, so a scroll area only got
   the treatment if somebody remembered to ask for it. The deck asks for nothing - it styles
   `.screen *`, every scrollable descendant of the frame - so in the drawing every scrollbar
   matches and in the build only the handful that opted in did. A default that has to be
   requested is not a default.

   📏 The values are the deck's, measured off mockups/_standard.css rather than approximated:
     width / height   7px          (the helper below was 6)
     track            transparent
     thumb            rgba(33,31,28,.16), 4px radius
     thumb inset      a 2px transparent border with `background-clip: content-box`, which is what
                      makes the thumb float in the gutter instead of filling it edge to edge
     hover            rgba(33,31,28,.3)
     buttons          none - the little arrow caps are removed outright

   ⚠️ Firefox takes `scrollbar-width`/`scrollbar-color` and ignores the pseudo-elements;
   WebKit is the reverse. Both are declared because neither alone covers the browsers a patient
   actually arrives on.
   ========================================================= */
#akashic-health-records-patient-portal-root,
#akashic-health-records-patient-portal-root * {
  scrollbar-width: thin;
  scrollbar-color: rgba(33, 31, 28, 0.16) transparent;
}

/* 🔻 THE ONE RULE THAT DELIBERATELY LEAVES THE MOUNT, and it is fenced with `:has()`.
   🗣️ Spencer: "scrollbar still seems the same to me, is that something we can't style?"
   🔍 We could not, from inside. Nothing in the mount scrolls on the patient home - the page
   itself does - so every rule above was styling scrollbars that do not exist on that screen.
   ⚠️ `html:has(#…root)` - HTML, not BODY. The viewport's scrollbar is taken from the root
   element; a rule on `body` styles a scrollbar that only exists if BODY itself scrolls, which it
   does not here. Measured: `document.scrollingElement` is `html`. The `:has()` still narrows this
   to pages that actually host the portal. Without the
   `:has()` this would restyle every page of the practice's website, which is the theme bleed the
   containment rules at the top of this file exist to stop. */
html:has(#akashic-health-records-patient-portal-root) {
  scrollbar-width: thin;
  scrollbar-color: rgba(33, 31, 28, 0.16) transparent;
}

html:has(#akashic-health-records-patient-portal-root)::-webkit-scrollbar {
  width: 7px;
  height: 7px;
}

html:has(#akashic-health-records-patient-portal-root)::-webkit-scrollbar-track {
  background: transparent;
}

html:has(#akashic-health-records-patient-portal-root)::-webkit-scrollbar-thumb {
  background: rgba(33, 31, 28, 0.16);
  border-radius: 4px;
  border: 2px solid transparent;
  background-clip: content-box;
}

#akashic-health-records-patient-portal-root ::-webkit-scrollbar {
  width: 7px;
  height: 7px;
}

#akashic-health-records-patient-portal-root ::-webkit-scrollbar-track {
  background: transparent;
}

#akashic-health-records-patient-portal-root ::-webkit-scrollbar-thumb {
  background: rgba(33, 31, 28, 0.16);
  border-radius: 4px;
  border: 2px solid transparent;
  background-clip: content-box;
}

#akashic-health-records-patient-portal-root ::-webkit-scrollbar-thumb:hover {
  background: rgba(33, 31, 28, 0.3);
  background-clip: content-box;
}

#akashic-health-records-patient-portal-root ::-webkit-scrollbar-button {
  display: none;
  width: 0;
  height: 0;
}

#akashic-health-records-patient-portal-root ::-webkit-scrollbar-corner {
  background: transparent;
}

/* ♻️ `.thin-scrollbar` STAYS, and is now a no-op on the portal rather than a lie: it is on
   ~40 elements across the app and removing it would be a large diff for no visible change. It
   still carries the treatment on any surface the rule above does not reach. */
#akashic-health-records-patient-portal-root .thin-scrollbar::-webkit-scrollbar {
  width: 7px;
}

#akashic-health-records-patient-portal-root .thin-scrollbar::-webkit-scrollbar-thumb {
  background-color: var(--line);
  border-radius: 9999px;
}

#akashic-health-records-patient-portal-root .thin-scrollbar::-webkit-scrollbar-track {
  background: transparent;
}

#akashic-health-records-patient-portal-root .thin-scrollbar {
  scrollbar-width: thin;
  scrollbar-color: var(--line) transparent;
}

#akashic-health-records-patient-portal-root .scrollbar-hidden {
  scrollbar-width: none;
  -ms-overflow-style: none;
}

#akashic-health-records-patient-portal-root .scrollbar-hidden::-webkit-scrollbar {
  display: none;
}

#akashic-health-records-patient-portal-root .cursor {
  cursor: pointer;
}

#akashic-health-records-patient-portal-root .code-input input {
  font-size: 10px;
}

#akashic-health-records-patient-portal-root .w-13 {
  width: 3.25rem;
}

#akashic-health-records-patient-portal-root .h-13 {
  height: 3.25rem;
}

#akashic-health-records-patient-portal-root .w-15 {
  width: 3.75rem;
}

#akashic-health-records-patient-portal-root .h-15 {
  height: 3.75rem;
}

#akashic-health-records-patient-portal-root .w-17 {
  width: 4.25rem;
}

#akashic-health-records-patient-portal-root .h-17 {
  height: 4.25rem;
}

#akashic-health-records-patient-portal-root .w-25 {
  width: 6.25rem;
}

#akashic-health-records-patient-portal-root .h-22 {
  height: 5.5rem;
}

#akashic-health-records-patient-portal-root .w-30 {
  width: 7.5rem;
}

#akashic-health-records-patient-portal-root .h-30 {
  height: 7.5rem;
}

/* =========================================================
   8. TAILWIND THEME MAPPING
   Preserve existing shadcn/tailwind token mappings
   ========================================================= */

/* 🚨 EVERYTHING IN THIS BLOCK IS INERT UNDER THE TAILWIND THIS PROJECT BUILDS, AND IT IS KEPT ONLY AS A
   v4 MIGRATION MARKER. `@theme` is a Tailwind **v4** directive; the installed version is **3.4.19**, so
   PostCSS passes this whole block through as an unknown at-rule and the browser ignores it. None of these
   `--color-*` / `--text-*` / `--radius-*` aliases ever registered, and v3 never generated a utility from
   one of them.
   ⭐ It looked like it worked because the shadcn names (`bg-muted`, `border-border`, `text-foreground`, …)
   are ALSO hand-written into the `@layer utilities` block further down — so the half with a fallback
   rendered and the half without it was silently a no-op.
   ▶️ THE LIVE REGISTRATION IS `tailwind.config.js` → `theme.extend.colors` / `theme.extend.fontSize`.
   ⛔ Adding a name HERE does nothing. Add it there, or it will compile to nothing with no error anywhere.
   📌 Left in place rather than deleted so the eventual v4 upgrade has the mapping already written; the
   `--radius-*` entries below are inert for the same reason, which is why `rounded-lg` still resolves to
   Tailwind's own default rather than to `--radius`. */
@theme inline {
  /* Card 281 — the ruled type scale, registered as real Tailwind sizes so a step can be USED.
     🚨 Same mechanism the colour ramp documents further down and for the same reason: a raw CSS
     variable is not a Tailwind size, so without these lines `text-step-11-5` compiles to NOTHING and
     the element silently renders at its inherited size — indistinguishable from a deliberate choice.
     ⛔ These are the ONLY twelve, plus the two display steps. A further name here is a scale
     change and belongs to Spencer.
     📌 Named for the VALUE on purpose. The t-shirt names (`--ak-font-xs/sm/...`) already carry the
     ramp's MEANING; giving the same eight numbers a second set of semantic names would be two
     vocabularies for one scale, which is the collision card 271 spent a commit untangling. */
  --text-step-9: var(--ak-font-9);
  --text-step-10: var(--ak-font-10);
  --text-step-10-5: var(--ak-font-10-5);
  --text-step-11: var(--ak-font-11);
  --text-step-11-5: var(--ak-font-11-5);
  --text-step-12: var(--ak-font-12);
  --text-step-12-5: var(--ak-font-12-5);
  --text-step-13: var(--ak-font-13);
  --text-step-14: var(--ak-font-14);
  --text-step-15: var(--ak-font-15);
  --text-step-17: var(--ak-font-17);
  --text-step-18: var(--ak-font-18);
  --text-step-24: var(--ak-font-24);
  --text-step-42: var(--ak-font-42);

  --radius-sm: calc(var(--radius) - 4px);
  --radius-md: calc(var(--radius) - 2px);
  --radius-lg: var(--radius);
  --radius-xl: calc(var(--radius) + 4px);
  --radius-2xl: calc(var(--radius) + 8px);
  --radius-3xl: calc(var(--radius) + 12px);
  --radius-4xl: calc(var(--radius) + 16px);

  --color-background: var(--background);
  --color-foreground: var(--foreground);
  --color-card: var(--card);
  --color-card-foreground: var(--card-foreground);
  --color-popover: var(--popover);
  --color-popover-foreground: var(--popover-foreground);
  --color-primary: var(--primary);
  --color-primary-foreground: var(--primary-foreground);
  --color-secondary: var(--secondary);
  --color-secondary-foreground: var(--secondary-foreground);
  --color-muted: var(--muted);
  --color-muted-foreground: var(--muted-foreground);
  --color-accent: var(--accent);
  --color-accent-foreground: var(--accent-foreground);
  --color-destructive: var(--destructive);
  /* Card 132 (WP→Radix sweep) — registers `text-success`/`bg-success` as real Tailwind utilities.
     `--success` already existed above (and backs `btn btn-green`), but a raw CSS variable is NOT a
     Tailwind color: without this line `text-success` compiles to nothing and a success banner renders
     colourless, indistinguishable from a neutral one — silently. `--color-destructive` right above is
     what makes the existing `text-destructive` work; success simply never got the same treatment
     because nothing had needed it until <Notice status="success"> had to be replaced. */
  --color-success: var(--success);
  /* Card 132 — same reason as `--color-success` directly above, for the other two <Notice> statuses.
     A raw CSS variable is NOT a Tailwind color: without these lines `text-warning` / `text-info`
     compile to NOTHING and the banner renders colourless — indistinguishable from a neutral one, with
     no error anywhere. That is the exact silent failure the success comment describes, and `warning`
     and `info` are 135 of the 461 Notice call sites, so getting it wrong would be the majority of the
     "info" ones reading as plain text. */
  --color-warning: var(--warning);
  --color-info: var(--info);
  /* Card 271 — registers the warm ramp as real Tailwind colours, which is what card 241 repoints
     call sites AT. Same reason as `--color-success` above: a raw CSS variable is NOT a Tailwind
     colour, so without these lines `bg-paper` / `text-ink-muted` compile to NOTHING and a repointed
     surface renders colourless with no error anywhere.
     ⛔ There is deliberately no `--color-muted` alias for the ramp's text tone: `muted` is already
     taken by the shadcn SURFACE token and a second meaning under one name is the collision this
     card exists to avoid. The text tone is `ink-muted` and only `ink-muted`. */
  --color-paper: var(--paper);
  --color-surface: var(--surface);
  --color-sunken: var(--sunken);
  --color-line: var(--line);
  --color-line-soft: var(--line-soft);
  --color-ink: var(--ink);
  --color-ink-strong: var(--ink-strong);
  --color-ink-muted: var(--ink-muted);
  --color-faint: var(--faint);
  --color-blue-soft: var(--blue-soft);
  --color-green-soft: var(--green-soft);
  --color-amber-soft: var(--amber-soft);
  --color-red-soft: var(--red-soft);
  --color-input: var(--input);
  --color-border: var(--border);
  --color-ring: var(--ring);
  --color-chart-1: var(--chart-1);
  --color-chart-2: var(--chart-2);
  --color-chart-3: var(--chart-3);
  --color-chart-4: var(--chart-4);
  --color-chart-5: var(--chart-5);
  --color-sidebar: var(--sidebar);
  --color-sidebar-foreground: var(--sidebar-foreground);
  --color-sidebar-primary: var(--sidebar-primary);
  --color-sidebar-primary-foreground: var(--sidebar-primary-foreground);
  --color-sidebar-accent: var(--sidebar-accent);
  --color-sidebar-accent-foreground: var(--sidebar-accent-foreground);
  --color-sidebar-border: var(--sidebar-border);
  --color-sidebar-ring: var(--sidebar-ring);
}

/* =========================================================
   9. TAILWIND LAYER SCOPING
   Never style body or global * in a WP plugin app
   ========================================================= */

@layer base {
  #akashic-health-records-patient-portal-root {
    @apply bg-white text-gray-900;
  }
}

@layer utilities {
  /* Backgrounds */
  #akashic-health-records-patient-portal-root .bg-primary {
    background-color: var(--primary);
  }

  #akashic-health-records-patient-portal-root .bg-primary-foreground {
    background-color: var(--primary-foreground);
  }

  #akashic-health-records-patient-portal-root .bg-secondary {
    background-color: var(--secondary);
  }

  #akashic-health-records-patient-portal-root .bg-secondary-foreground {
    background-color: var(--secondary-foreground);
  }

  #akashic-health-records-patient-portal-root .bg-muted {
    background-color: var(--muted);
  }

  #akashic-health-records-patient-portal-root .bg-muted-foreground {
    background-color: var(--muted-foreground);
  }

  #akashic-health-records-patient-portal-root .bg-accent {
    background-color: var(--accent);
  }

  #akashic-health-records-patient-portal-root .bg-accent-foreground {
    background-color: var(--accent-foreground);
  }

  #akashic-health-records-patient-portal-root .bg-destructive {
    background-color: var(--destructive);
  }

  #akashic-health-records-patient-portal-root .bg-border {
    background-color: var(--border);
  }

  #akashic-health-records-patient-portal-root .bg-input {
    background-color: var(--input);
  }

  #akashic-health-records-patient-portal-root .bg-ring {
    background-color: var(--ring);
  }

  #akashic-health-records-patient-portal-root .bg-card {
    background-color: var(--card);
  }

  #akashic-health-records-patient-portal-root .bg-background {
    background-color: var(--background);
  }

  #akashic-health-records-patient-portal-root .bg-popover {
    background-color: var(--popover);
  }

  /* Text colors */
  #akashic-health-records-patient-portal-root .text-foreground {
    color: var(--foreground);
  }

  #akashic-health-records-patient-portal-root .text-card-foreground {
    color: var(--card-foreground);
  }

  #akashic-health-records-patient-portal-root .text-popover-foreground {
    color: var(--popover-foreground);
  }

  #akashic-health-records-patient-portal-root .text-primary {
    color: var(--primary);
  }

  #akashic-health-records-patient-portal-root .text-primary-foreground {
    color: var(--primary-foreground);
  }

  #akashic-health-records-patient-portal-root .text-secondary {
    color: var(--secondary);
  }

  #akashic-health-records-patient-portal-root .text-secondary-foreground {
    color: var(--secondary-foreground);
  }

  #akashic-health-records-patient-portal-root .text-muted {
    color: var(--muted);
  }

  #akashic-health-records-patient-portal-root .text-muted-foreground {
    color: var(--muted-foreground);
  }

  #akashic-health-records-patient-portal-root .text-accent {
    color: var(--accent);
  }

  #akashic-health-records-patient-portal-root .text-accent-foreground {
    color: var(--accent-foreground);
  }

  #akashic-health-records-patient-portal-root .text-destructive {
    color: var(--destructive);
  }

  /* 🚨 AMBER AND SAGE BELONG IN THIS BLOCK TOO, and their absence is why neither has been
     reliably visible.

     `.text-warning` and `.text-success` ARE emitted - verified in the built stylesheet, not
     assumed - but they are emitted bare, at (0,1,0). This mount colours its own elements:
     `#…root p` is (1,0,1) and beats them. So the same class works on a `<b>` or a `<span>` the
     mount does not colour, and silently renders as body ink on a `<p>` that it does. Two call
     sites of one class, one right and one wrong, with nothing reporting anything.

     ⚖️ THE SIBLINGS ABOVE ARE THE PROOF THIS IS THE MECHANISM, not a theory: `text-primary`,
     `text-secondary` and `text-destructive` are all restated here at (1,1,0) for exactly this
     reason, and all three work everywhere. These two were left out of that block when the
     palette gained them, so they inherited the problem the block exists to solve.

     ⇒ It also retires the `!text-warning` in the help widget, whose own note calls the bang
     load-bearing. It was - against the bare utility. It is not any more, and an `!important`
     that has stopped being necessary is the next person's false lead.

     Reached by: the upcoming-appointments row, where `text-warning` on a `<p>` rendered as
     ordinary ink. Also reaches the attention alert, the status glyphs, the part-paid mark on an
     invoice, and the unread counts on the home page.

     ⛔ ONLY AMBER, AND `text-success` IS DELIBERATELY LEFT OUT. Amber is #b45309 at 4.77:1 on this
     ground - it clears the floor for normal text, so activating it makes about a dozen call sites
     start saying what they were written to say. Sage does not: `--success` under white measures
     3.19:1 and as text on its own tint 3.81:1, both under 4.5, which is recorded in DESIGN.md as
     the reason the green BUTTON needs a stroked white label. Scoping `.text-success` here would
     therefore turn several labels that are accidentally legible body ink today into a colour that
     fails - a regression wearing the costume of a fix.
     ⇒ Sage-as-text needs a deeper token first, the way every `--cat-*` text value is deeper than
     the button token of the same colour. Until that exists, `text-success` stays inert rather than
     wrong. */
  #akashic-health-records-patient-portal-root .text-warning {
    color: var(--warning);
  }

  /* Keep amber notice copy above the normalized body-text colour. */
  #akashic-health-records-patient-portal-root .text-amber-ink {
    color: var(--amber-ink);
  }

  #akashic-health-records-patient-portal-root .text-border {
    color: var(--border);
  }

  #akashic-health-records-patient-portal-root .text-input {
    color: var(--input);
  }

  #akashic-health-records-patient-portal-root .text-ring {
    color: var(--ring);
  }

  /* Borders */
  #akashic-health-records-patient-portal-root .border-primary {
    border-color: var(--primary);
  }

  #akashic-health-records-patient-portal-root .border-primary-foreground {
    border-color: var(--primary-foreground);
  }

  #akashic-health-records-patient-portal-root .border-secondary {
    border-color: var(--secondary);
  }

  #akashic-health-records-patient-portal-root .border-secondary-foreground {
    border-color: var(--secondary-foreground);
  }

  #akashic-health-records-patient-portal-root .border-muted {
    border-color: var(--muted);
  }

  #akashic-health-records-patient-portal-root .border-muted-foreground {
    border-color: var(--muted-foreground);
  }

  #akashic-health-records-patient-portal-root .border-accent {
    border-color: var(--accent);
  }

  #akashic-health-records-patient-portal-root .border-accent-foreground {
    border-color: var(--accent-foreground);
  }

  #akashic-health-records-patient-portal-root .border-destructive {
    border-color: var(--destructive);
  }

  /* 🚨 THE LEFT-RAIL COLOURS, added by card 305 R2 — and the reason they were missing is worth keeping.
     Every shadcn token above is written for the ALL-SIDES form (`.border-destructive`) only, because
     Tailwind never generates these: the config registers the warm ramp under `colors`, but `destructive`
     and `secondary` are hand-written here instead. So `border-l-destructive` and `border-l-secondary`
     compiled to NOTHING, and both patient-home banners drew their rail in the neutral `--border` they
     inherited from `border-border` — the accent that tells the two states apart was never on screen.
     ⛔ This changes no token VALUE and adds no name. It makes two existing tokens reachable on one side,
     which is the same thing the block above does for four sides. A new colour is card 271's decision;
     this is not one. */
  #akashic-health-records-patient-portal-root .border-border {
    border-color: var(--border);
  }

  /* After .border-border, which ties on specificity and would otherwise repaint the rail neutral. */
  #akashic-health-records-patient-portal-root .border-l-destructive {
    border-left-color: var(--destructive);
  }

  #akashic-health-records-patient-portal-root .border-l-secondary {
    border-left-color: var(--secondary);
  }

  #akashic-health-records-patient-portal-root .border-input {
    border-color: var(--input);
  }

  #akashic-health-records-patient-portal-root .border-ring {
    border-color: var(--ring);
  }
}


/* =========================================================
   TOKEN FIELD (FORM TOKEN FIELD) — REFINED IMPLEMENTATION
   Match staging behavior while keeping Akashic containment
   ========================================================= */

#akashic-health-records-patient-portal-root .components-form-token-field {
  position: relative;
  width: 100%;
  min-width: 0;
}

#akashic-health-records-patient-portal-root .components-form-token-field__input-container {
  width: 100%;
  min-width: 0;
  padding: 0;
  border: 0;
  background: transparent;
  box-shadow: none;
}

#akashic-health-records-patient-portal-root .components-form-token-field__input-container > [data-wp-component="Flex"],
#akashic-health-records-patient-portal-root .components-form-token-field__input-container > .components-flex {
  display: flex;
  align-items: center;
  flex-wrap: wrap;
  gap: 4px;
  width: 100%;
  min-width: 0;
  min-height: var(--ak-field-height);
  padding: 7px var(--ak-field-padding-x);
  border: 1px solid var(--line);
  border-radius: var(--ak-field-radius);
  background: var(--surface);
  box-shadow: none;
}

/* Keep the actual input visually naked so the wrapper is the only shell */
#akashic-health-records-patient-portal-root .components-form-token-field__input,
#akashic-health-records-patient-portal-root .components-form-token-field__input:focus,
#akashic-health-records-patient-portal-root .components-form-token-field__input:focus-visible {
  box-sizing: border-box;
  flex: 1 1 8rem;
  width: auto;
  min-width: 6rem;
  min-height: 0;
  height: auto;
  margin: 0;
  padding: 0;
  border: 0;
  border-radius: 0;
  background: transparent;
  background-color: transparent;
  box-shadow: none;
  outline: none;
  appearance: none;
  -webkit-appearance: none;
}

/* Suggestions dropdown: attach visually to the field like staging */
#akashic-health-records-patient-portal-root .components-form-token-field__suggestions-container {
  position: absolute;
  top: calc(100% - 1px);
  left: 0;
  right: 0;
  z-index: 1000;
}

#akashic-health-records-patient-portal-root .components-form-token-field__suggestions-list {
  margin: 0;
  padding: 0;
  list-style: none;
  border: 1px solid var(--line);
  border-top: 0;
  border-radius: 0 0 var(--ak-field-radius) var(--ak-field-radius);
  background: var(--surface);
  box-shadow: none;
  max-height: 12rem;
  overflow-y: auto;
  overflow-x: hidden;
}

#akashic-health-records-patient-portal-root .components-form-token-field__suggestion {
  padding: 0.5rem 0.75rem;
  cursor: pointer;
}

#akashic-health-records-patient-portal-root .components-form-token-field__suggestion:hover,
#akashic-health-records-patient-portal-root .components-form-token-field__suggestion.is-selected,
#akashic-health-records-patient-portal-root .components-form-token-field__suggestion[aria-selected="true"] {
  background: var(--primary);
  color: var(--primary-foreground);
}


/* =========================================================
   TOKEN FIELD — FINAL TUNING
   Remove inherited rounded option corners and ensure long lists scroll
   ========================================================= */

#akashic-health-records-patient-portal-root .components-form-token-field__suggestions-list {
  max-height: 12rem;
  overflow-y: auto;
  overflow-x: hidden;
}

#akashic-health-records-patient-portal-root .components-form-token-field__suggestion,
#akashic-health-records-patient-portal-root .components-form-token-field__suggestion:hover,
#akashic-health-records-patient-portal-root .components-form-token-field__suggestion.is-selected,
#akashic-health-records-patient-portal-root .components-form-token-field__suggestion[aria-selected="true"] {
  display: block;
  width: 100%;
  margin: 0;
  border-radius: 0;
  font-size: var(--ak-field-font-size);
  line-height: var(--ak-field-line-height);
}

#akashic-health-records-patient-portal-root .components-form-token-field__suggestions-list::-webkit-scrollbar {
  width: 8px;
}

#akashic-health-records-patient-portal-root .components-form-token-field__suggestions-list::-webkit-scrollbar-thumb {
  background-color: var(--line);
  border-radius: 9999px;
}

#akashic-health-records-patient-portal-root .components-form-token-field__suggestions-list::-webkit-scrollbar-track {
  background: transparent;
}

#akashic-health-records-patient-portal-root .components-form-token-field__suggestions-list {
  scrollbar-width: thin;
  scrollbar-color: var(--line) transparent;
}


/* =========================================================
   TOKEN FIELD OPEN-STATE CORNER FIX
   Flatten bottom corners only when suggestions are actually present
   ========================================================= */
#akashic-health-records-patient-portal-root .components-form-token-field:has(.components-form-token-field__suggestions-list) .components-form-token-field__input-container > [data-wp-component="Flex"],
#akashic-health-records-patient-portal-root .components-form-token-field:has(.components-form-token-field__suggestions-list) .components-form-token-field__input-container > .components-flex {
  border-bottom-left-radius: 0;
  border-bottom-right-radius: 0;
}


/* =========================================================
   FORM LABEL CONSISTENCY PATCH
   Align utility-class labels with WP/Gutenberg labels
   ========================================================= */
#akashic-health-records-patient-portal-root label.text-sm,
#akashic-health-records-patient-portal-root .components-base-control__field > label.text-sm,
#akashic-health-records-patient-portal-root .flex.flex-col > label.text-sm {
  font-size: var(--ak-font-base);
  font-weight: var(--ak-label-weight);
  line-height: 18px;
  color: var(--ink);
}


/* =========================================================
   SELECT VALUE CONTENT WRAP PATCH
   Allow avatar/text practitioner values to wrap inside the trigger
   instead of overrunning the control shell
   ========================================================= */
#akashic-health-records-patient-portal-root [data-slot="select-value"] {
  display: flex;
  align-items: center;
  min-width: 0;
  flex: 1 1 auto;
}

#akashic-health-records-patient-portal-root [data-slot="select-value"] > div,
#akashic-health-records-patient-portal-root [data-slot="select-value"] .text-start {
  display: flex;
  align-items: center;
  gap: 0.5rem;
  min-width: 0;
  width: 100%;
}

#akashic-health-records-patient-portal-root [data-slot="select-value"] [data-slot="avatar"] {
  flex-shrink: 0;
}

#akashic-health-records-patient-portal-root [data-slot="select-value"] [data-slot="avatar"] img {
  display: block;
}

#akashic-health-records-patient-portal-root [data-slot="select-value"] .whitespace-normal,
#akashic-health-records-patient-portal-root [data-slot="select-value"] .break-words {
  display: block;
  min-width: 0;
  flex: 1 1 auto;
  white-space: normal;
  overflow-wrap: anywhere;
  word-break: break-word;
  line-height: 1.2;
}

/* Default single-value selects can still truncate cleanly */
#akashic-health-records-patient-portal-root [data-slot="select-value"]:not(:has([data-slot="avatar"])) {
  white-space: nowrap;
  text-overflow: ellipsis;
  overflow: hidden;
}


/* =========================================================
   BUTTON PADDING HARDENING
   Preserve horizontal/vertical padding against theme/plugin resets
   ========================================================= */
#akashic-health-records-patient-portal-root .btn,
#akashic-health-records-patient-portal-root [data-slot="button"].btn,
#akashic-health-records-patient-portal-root button.btn,
#akashic-health-records-patient-portal-root [data-slot="dialog-trigger"].btn,
#akashic-health-records-patient-portal-root [data-slot="sheet-trigger"].btn {
  padding-top: 0;
  padding-right: 12px;
  padding-bottom: 0;
  padding-left: 12px;
}

#akashic-health-records-patient-portal-root .btn svg,
#akashic-health-records-patient-portal-root [data-slot="button"].btn svg,
#akashic-health-records-patient-portal-root button.btn svg {
  flex-shrink: 0;
}

/* 🔴 `:not(.hidden)` IS THE WHOLE FIX FOR A HEADER THAT RAN OFF THE PHONE.
   This rule is (1,1,3) and `.hidden` is (0,1,0), so a label that asked to disappear below a breakpoint
   was told to stay — and `hidden sm:inline` on the patient header's two quick buttons had therefore
   NEVER worked. 📏 Measured on the deployed build at 390px: the document scrolled to 440px, "Contact
   front desk" ran off the right edge, and the phone number behind it was unreadable.
   ⭐ It is the same trap the `color` rule at the top of this file already documents — an ID-scoped
   element rule quietly beating a utility — seen on a second property.
   ⛔ NARROWED RATHER THAN MOVED. Reordering or de-scoping this rule would change layout for every
   `.btn` in the product; excusing it from an explicit `hidden` changes nothing that was not already
   asking to be hidden. */
#akashic-health-records-patient-portal-root [data-slot="button"].btn > svg + span:not(.hidden),
#akashic-health-records-patient-portal-root [data-slot="button"].btn > svg + div:not(.hidden),
#akashic-health-records-patient-portal-root button.btn > svg + span:not(.hidden),
#akashic-health-records-patient-portal-root button.btn > svg + div:not(.hidden) {
  display: inline-block;
}


/* =========================================================
   BUTTON UTILITY CONSISTENCY PATCH
   Normalize Tailwind utility-driven button sizing across installs
   ========================================================= */
/* 🔻 2026-09-08 - 2px, matching the button system above. This block restates radius,
   height, padding, size and weight 2600 lines below the rule that already sets them, so it
   WINS ON SOURCE ORDER and the settled corner never reached the screen: the base rule said
   2px and every button still drew at 6px. Measured on the sign-in screen.
   ⚠️ The duplication is the real defect and it is left standing on purpose - collapsing two
   competing definitions of a button is a change to every button in the app, and this pass is
   for what a user can see. Whichever survives, the corner has to be the same in both. */
#akashic-health-records-patient-portal-root .btn,
#akashic-health-records-patient-portal-root [data-slot="button"].btn,
#akashic-health-records-patient-portal-root button.btn {
  /* 🚨 `min-height` IS DELIBERATELY NOT RESTATED HERE. It used to say 36px, and that one
     declaration silently switched off the patient portal's 44px touch floor for every component
     <Button> in the app.
     ⚖️ The mechanism is a TIE, not a defeat: this selector list scores (1,2,0) and so does
     `#…root[data-akashic-mount="frontend"] .btn` up at the touch-floor block, so the winner is
     decided by SOURCE ORDER - and this block sits 2,700 lines later. Nothing was overridden loudly
     enough to notice; the floor simply never applied.
     🔬 Measured 2026-09-09 in the booking modal, on touch: `Book` (a plain `button.btn`, which this
     list also matches but which carries no `data-slot`) came out 44px tall next to `Clear All` (a
     `[data-slot="button"].btn`) at 36px - two buttons side by side in one footer, disagreeing by 8px
     because one of them matched a rule the other did not. Spencer read it as the green button being
     too big; it was the only one obeying the ruling.
     ⛔ Do not add a height back to this block. Heights belong to the three rules that already own
     them and read as a ladder: `.btn` 30px (the base), `[data-akashic-mount="frontend"]` 44px (a
     finger), and that same mount under `@media (pointer: fine)` 32px (a mouse). */
  padding: 0 12px;
  border-radius: 2px;
  font-size: var(--ak-font-sm);
  font-weight: 500;
  line-height: 1;
  gap: 7px;
  white-space: nowrap;
}

#akashic-health-records-patient-portal-root .btn.px-4,
#akashic-health-records-patient-portal-root [data-slot="button"].btn.px-4,
#akashic-health-records-patient-portal-root button.btn.px-4 {
  padding-left: 16px;
  padding-right: 16px;
}

#akashic-health-records-patient-portal-root .btn.py-2,
#akashic-health-records-patient-portal-root [data-slot="button"].btn.py-2,
#akashic-health-records-patient-portal-root button.btn.py-2 {
  padding-top: 8px;
  padding-bottom: 8px;
}
/* 🚨 `p-0` MEANT NOTHING ON A BUTTON, AND THE FAILURE LOOKED LIKE A DRAWING BUG. Tailwind emits
   `.p-0` at (0,1,0); the rule above is (1,0,2), so the id wins and the padding stays 8px 16px no
   matter what the source says. On a 36px square icon button - `h-9 w-9 p-0`, the shape the chat
   header and the attachment remove both use - 16px of horizontal padding leaves a FOUR PIXEL
   content box for a 16px glyph, so the icon is squeezed out of its aspect ratio rather than
   centred in the square the author asked for.

   ⭐ THE TELL IS THAT NOTHING ERRORS. The class is written, spelled correctly, and compiled - it
   simply loses, silently, which reads exactly like the icon component being wrong. Every other
   utility in this block is here for the same reason; `p-0` was the one nobody had hit yet.

   ⚠️ Both sides, not the shorthand: `padding: 0` would also reset any padding a more specific rule
   below has deliberately given one of these buttons. */
#akashic-health-records-patient-portal-root .btn.p-0,
#akashic-health-records-patient-portal-root [data-slot="button"].btn.p-0,
#akashic-health-records-patient-portal-root button.btn.p-0 {
  padding-left: 0;
  padding-right: 0;
  padding-top: 0;
  padding-bottom: 0;
}

#akashic-health-records-patient-portal-root .btn.text-sm,
#akashic-health-records-patient-portal-root [data-slot="button"].btn.text-sm,
#akashic-health-records-patient-portal-root button.btn.text-sm {
  font-size: var(--ak-font-sm);
  line-height: 1;
}

/* A button carrying Tailwind's `rounded-md` is still a button, and the standard's corner does
   not depend on which utility happens to be on it. 6px here was Tailwind's value, not ours. */
#akashic-health-records-patient-portal-root .btn.rounded-md,
#akashic-health-records-patient-portal-root [data-slot="button"].btn.rounded-md,
#akashic-health-records-patient-portal-root button.btn.rounded-md {
  border-radius: 2px;
}

#akashic-health-records-patient-portal-root .btn.gap-2,
#akashic-health-records-patient-portal-root [data-slot="button"].btn.gap-2,
#akashic-health-records-patient-portal-root button.btn.gap-2 {
  gap: 8px;
}

#akashic-health-records-patient-portal-root .btn svg,
#akashic-health-records-patient-portal-root [data-slot="button"].btn svg,
#akashic-health-records-patient-portal-root button.btn svg {
  width: 16px;
  height: 16px;
  flex-shrink: 0;
}

/* ICON-ONLY OVERLAY BUTTONS — a glyph sitting ON an image, not beside a label.
   Card 132, Spencer's ruling 2026-08-09. The rule directly above pins every icon inside a button to
   16px, which is correct for a button whose icon sits next to text. These are a different animal:
   PhotoAttachment's add / change / remove controls are 40px white discs floating on the photo itself,
   so at 16px the glyph fills ~40% of the disc instead of ~80% — a small mark adrift in a white circle.

   32px is TODAY'S size — it is exactly the `iconSize={32}` the WordPress Buttons carried — chosen so
   this conversion stays a machinery change and nothing moves visually. The NUMBER is deliberately open
   for the design/UX tightening pass; this class is the one place to change it.

   ⚠️ THE SELECTOR'S SPECIFICITY IS LOAD-BEARING — do not "simplify" it to `.btn-icon-overlay svg`.
   `.btn.btn-icon-overlay` scores (1,2,1), which beats BOTH `.btn svg` (1,1,1) and `button.btn svg`
   (1,1,2) above. That means it wins on SPECIFICITY rather than on source order, and stays correct if
   these blocks are ever moved or reordered. (`.btn-icon-close`'s own svg rule further up in this file
   is the same idiom but relies on order — harmless only because it happens to set the same 16px it
   would otherwise inherit. Do not copy that one.) */
#akashic-health-records-patient-portal-root .btn.btn-icon-overlay svg {
  width: 32px;
  height: 32px;
}

/* `.btn` sets no colour of its own, so without this the glyph would inherit from whatever the photo
   overlay happens to sit in. WordPress painted these `#1e1e1e` via `.components-button`; `--foreground`
   is within a hair of that and is ours, so it also follows the dark-mode block. */
#akashic-health-records-patient-portal-root .btn.btn-icon-overlay {
  color: var(--foreground);
}


/* =========================================================
   LOGIN PAGE — POWERED BY BRANDING
   ========================================================= */
#akashic-health-records-patient-portal-root .login-poweredby {
  display: flex;
  flex-direction: column;
  align-items: center;
  gap: 4px;
  margin-top: 16px;
}

#akashic-health-records-patient-portal-root .login-poweredby .components-text {
  font-size: 11px;
  color: #999;
  letter-spacing: 0.05em;
  text-transform: uppercase;
}

#akashic-health-records-patient-portal-root .login-poweredby img {
  height: 28px !important;
  width: auto;
  opacity: 0.6;
}

/* Formal invoice printout (Feature A): on screen the block is hidden; when printing, hide the entire
   app and show only the invoice. Scoped by @media print so it never affects normal rendering. */
.printable-invoice { display: none; }

/* THE INACTIVE TAB PANEL IS HIDDEN ON SCREEN, and this rule exists because `forceMount` removed the
   hiding Radix used to do for us. It is scoped to a print region: a tabbed surface anywhere else in
   the app is untouched, because keeping every panel mounted is a licence the RECORD asked for so it
   could print whole, not a change to how tabs work. */
#akashic-health-records-patient-portal-root
  [data-print-region="true"] [data-slot="tabs-content"][data-state="inactive"] {
  display: none;
}

@media print {
  /* Hide everything, then reveal only the printable invoice. */
  body * { visibility: hidden; }
  .printable-invoice, .printable-invoice * { visibility: visible; }
  .printable-invoice {
    display: block;
    position: absolute;
    left: 0;
    top: 0;
    width: 100%;
    padding: 24px;
    color: #000;
    background: #fff;
    font-size: 12pt;
  }
  .printable-invoice .pi-header { display: flex; align-items: center; gap: 16px; border-bottom: 2px solid #000; padding-bottom: 12px; margin-bottom: 16px; }
  .printable-invoice .pi-logo { max-height: 64px; max-width: 180px; object-fit: contain; }
  .printable-invoice .pi-org-name { font-size: 16pt; font-weight: 700; }
  .printable-invoice .pi-meta { display: flex; justify-content: space-between; margin-bottom: 16px; }
  .printable-invoice .pi-title { font-size: 14pt; font-weight: 700; }
  .printable-invoice .pi-label { font-weight: 700; }
  .printable-invoice .pi-billto { text-align: right; }
  .printable-invoice .pi-lines { width: 100%; border-collapse: collapse; margin-bottom: 16px; }
  .printable-invoice .pi-lines th { text-align: left; border-bottom: 1px solid #000; padding: 6px 8px; }
  .printable-invoice .pi-lines td { padding: 6px 8px; border-bottom: 1px solid #ccc; }
  .printable-invoice .pi-lines th:nth-child(n+2), .printable-invoice .pi-lines td:nth-child(n+2) { text-align: right; white-space: nowrap; }
  .printable-invoice .pi-lines tr { break-inside: avoid; }
  .printable-invoice .pi-totals { margin-left: auto; width: 240px; }
  .printable-invoice .pi-totals > div { display: flex; justify-content: space-between; padding: 3px 0; }
  .printable-invoice .pi-payments { margin-top: 20px; break-inside: avoid; }
  .printable-invoice .pi-payments p { margin: 6px 0 12px; }
  .printable-invoice .pi-total { border-top: 2px solid #000; margin-top: 4px; padding-top: 6px !important; font-weight: 700; font-size: 13pt; }
  @page { margin: 12mm; }
}

/* =========================================================
   PATIENT HOME — TABLET, LAPTOP AND DESKTOP. Card 280, design spec §7b.
   =========================================================

   🚨 CONTAINER QUERIES, NOT VIEWPORT QUERIES, and that is correctness rather than taste: this app is a
   MOUNT INSIDE SOMEONE ELSE'S PAGE, so the width it gets is its CONTAINER'S, not the window's. A
   viewport query is right on a standalone client and WRONG inside a WordPress theme with a sidebar —
   the window says 1440 while the app has 900.

   🚨 THIS BLOCK MUST STAY BELOW THE BASE RULES IT OVERRIDES. A container query adds NO SPECIFICITY, so
   a plain rule declared later in the sheet silently beats it and the wide layouts render at phone
   padding. That defect cost the design session a debugging round: it looked like a bad calc() and it
   was the cascade. It is why this sits at the end of the file.

   📏 THE BREAKPOINTS ARE CONTAINER WIDTHS, DELIBERATELY NOT THE SPEC'S VIEWPORT NUMBERS (834 / 1280) —
   the container is narrower than the window by whatever chrome the host page spends. They are derived
   from the content instead, which is the only thing that survives being embedded:
     · 700  — enough room that a full-width column would exceed the readable measure ⇒ cap and centre.
     · 1000 — the summary can give four items ~250px each. ⛔ BELOW this it stays 2 × 2: four across
              inside a 620px column gives each item ~150px, NARROWER THAN THE PHONE'S 176, which wraps
              the labels again and reintroduces on the wide layout the exact defect the phone fixed.
     · 1060 — 620 (queue) + 30 (gap) + 380 (reference) = 1030, plus padding. Below it the reference
              column stacks under the queue rather than squeezing both.

   🔑 THE GOVERNING RULE, and it is Spencer's: PATIENT MEANS FEWER THINGS, BIGGER, MORE AIR. Extra width
   buys air and placement, NEVER density. ⛔ Do not let a later consistency pass make the patient portal
   as dense as the staff one — the two audiences were separated on purpose.
   ========================================================= */
#akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .ak-home {
  container-type: inline-size;
  container-name: akhome;
}

/* The deck's 12px row gap plus the title's own 10px before the list. */
#akashic-health-records-patient-portal-root .ak-home__welcome {
  margin-block-end: calc(0.75rem + 10px);
}

#akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .ak-home__columns {
  display: flex;
  flex-direction: column;
  gap: 0.75rem;
}

/* `min-width: 0` on both: a flex child defaults to min-content width, so a long unbroken string in a
   card would push the column wider than its cap and the page would scroll sideways. */
#akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .ak-home__queue,
#akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .ak-home__reference {
  min-width: 0;
}

#akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .ak-home__summary {
  display: grid;
  grid-template-columns: repeat(2, minmax(0, 1fr));
  gap: 6px;
}

/* A tablet keeps one full-width column. The deck dropped the 620 measure cap here for flat gutters:
   these are cards, not prose, and a centred 620 left a quarter of an 834px screen empty. */

/* =========================================================
   THE SECOND COLUMN ARRIVES AT 840, NOT 1060.

   Spencer, 2026-09-13: *"Why does the patient portal dashboard home page have such big side gutters
   on it again?"* Measured at the time: an 861px container, the queue capped at 620 and centred, and
   120px of nothing down each side.

   It was not the page-width cap coming back - that is still `none`. It was this ladder having a band
   in it where the layout RESERVES room for a column it is not yet showing. Below 700 there is no cap
   and no gutter; above 1060 the reference column fills the space. Between them the queue is capped
   and centred and the space is simply dead, which is the exact thing the page-width ruling forbids.

   ⛔ THE CAP IS NOT THE DEFECT AND MUST NOT BE REMOVED TO FIX THIS. 720px was measured at about 92
   characters, past the readable band, and that is why 620 exists. Widening the queue to fill 861
   would trade a gutter for an unreadable line.

   ⚖️ SO THE COLUMN COMES IN EARLY INSTEAD, and the arithmetic is why it could not simply be moved:
   two columns at the 1060 band's own sizes need 620 + 30 + 380 = 1030, which is why that number is
   1060 rather than 900. To arrive at 840 the reference has to be narrower and the gap tighter, and
   both columns have to be allowed to give.

       840   bases 620 + 20 + 300 = 940, over by 100, both shrink    queue ~555   reference ~265
       861   over by 79                                             queue ~568   reference ~273
      1059   under by 119; the queue is at its cap so the slack
            all goes to the reference                               queue  620   reference ~419

   ⭐ Nothing is dead at any width in the band, which is the whole point. The queue narrows as the
   second column arrives - the ordinary trade when a column appears - and it never exceeds 620.

   📌 `justify-content: center` is deliberately NOT set here. Centring is what turns leftover space
   into two gutters; letting the columns take it turns the same space into content.
   ========================================================= */
@container akhome (min-width: 840px) {
  #akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .ak-home__columns {
    flex-direction: row;
    align-items: flex-start;
    gap: 1.25rem;
  }

  #akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .ak-home__queue {
    flex: 1 1 620px;
    max-width: 620px;
    margin-inline: 0;
  }

  #akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .ak-home__reference {
    flex: 1 1 300px;
    max-width: none;
    margin-inline: 0;
    position: sticky;
    top: 1rem;
  }
}

/* =========================================================
   THE SECOND COLUMN ARRIVES AT 840, NOT 1060.

   Spencer, 2026-09-13: *"Why does the patient portal dashboard home page have such big side gutters
   on it again?"* Measured at the time: an 861px container, the queue capped at 620 and centred, and
   120px of nothing down each side.

   It was not the page-width cap coming back - that is still `none`. It was this ladder having a band
   in it where the layout RESERVES room for a column it is not yet showing. Below 700 there is no cap
   and no gutter; above 1060 the reference column fills the space. Between them the queue is capped
   and centred and the space is simply dead, which is the exact thing the page-width ruling forbids.

   ⛔ THE CAP IS NOT THE DEFECT AND MUST NOT BE REMOVED TO FIX THIS. 720px was measured at about 92
   characters, past the readable band, and that is why 620 exists. Widening the queue to fill 861
   would trade a gutter for an unreadable line.

   ⚖️ SO THE COLUMN COMES IN EARLY INSTEAD, and the arithmetic is why it could not simply be moved:
   two columns at the 1060 band's own sizes need 620 + 30 + 380 = 1030, which is why that number is
   1060 rather than 900. To arrive at 840 the reference has to be narrower and the gap tighter, and
   both columns have to be allowed to give.

       840   bases 620 + 20 + 300 = 940, over by 100, both shrink    queue ~555   reference ~265
       861   over by 79                                             queue ~568   reference ~273
      1059   under by 119; the queue is at its cap so the slack
            all goes to the reference                               queue  620   reference ~419

   ⭐ Nothing is dead at any width in the band, which is the whole point. The queue narrows as the
   second column arrives - the ordinary trade when a column appears - and it never exceeds 620.

   📌 `justify-content: center` is deliberately NOT set here. Centring is what turns leftover space
   into two gutters; letting the columns take it turns the same space into content.
   ========================================================= */
@container akhome (min-width: 840px) {
  #akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .ak-home__columns {
    flex-direction: row;
    align-items: flex-start;
    gap: 1.25rem;
  }

  #akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .ak-home__queue {
    flex: 1 1 620px;
    max-width: 620px;
    margin-inline: 0;
  }

  #akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .ak-home__reference {
    flex: 1 1 300px;
    max-width: none;
    margin-inline: 0;
    position: sticky;
    top: 1rem;
  }
}

@container akhome (min-width: 1000px) {
  #akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .ak-home__summary {
    grid-template-columns: repeat(4, minmax(0, 1fr));
    gap: 8px;
  }
}

@container akhome (min-width: 1060px) {
  /* 🎯 THE SUMMARY BAND SHARES THE COLUMNS' EDGES, and until now it did not.
     🗣️ Spencer, 2026-08-22, on the patient home: *"It needs to be symmetric though. We have this big
     padding gap on the right side for some reason making it look off."*

     📏 The arithmetic, and it is why the number is 1030 rather than a round one: the queue is capped at
     620 (above), the reference column is 380, and the row's gap is 1.875rem = 30px. **620 + 30 + 380 =
     1030.** The columns already centre themselves in whatever is left; the band had NO cap at all, so it
     spanned the full container and its edges sat outside everything beneath it. On a 1440 laptop that is
     ~200px of band overhanging the content — read as a gap on one side rather than as a wide band.

     ⛔ THE CAP CANNOT GO ON `.ak-home` ITSELF, and that is the trap worth writing down: that element
     carries `container-type: inline-size` and IS the query container. Capping it to 1030 would mean this
     very query (`min-width: 1060px`) could never match again, the columns would never become a row, and
     the fix would silently undo the layout it exists to tidy.

     📌 Deliberately inside the 1060 block. Below it the columns are STACKED and full-width, so every row
     is already flush and a cap there would inset them for no reason.

     ⭐ APPLIED TO EVERY ROW, not just the band — `.ak-home`'s direct children are the banner, the summary
     and the columns, and the banner is uncapped for exactly the same reason the band was. Fixing only the
     one that was pointed at leaves the next row overhanging, and a rule that says *"every row of this
     page shares one content column"* is also the thing a later row inherits for free. */
  /* 🔻 2026-09-08 - 1440, NOT 1030, AND THE QUEUE TAKES THE SLACK.
     🗣️ Spencer, on the running portal: "issue #1 is the wide gutters on the sides."
     Measured at a 1500 viewport: the rows were 1030 in a 1468 container, so 219px of empty
     paper on each side - 29 percent of the window - and the reading column sat in the middle
     of it looking like a phone layout that had been left on a desktop.

     ✅ This is the approved deck's own rule, which had already answered this and which the
     build had not taken: the deck caps the PAGE at 1440 and lets the queue grow, and its note
     names this exact complaint - "1030px inside a 1280px laptop left 119px on each side
     unused". 1030 was never a page width; it was the sum of two capped columns
     (620 + 30 + 400) showing through as if it were one.

     ⚠️ WHAT THIS COSTS, because the file argued the other way and the argument is real: the
     rule below measured 720px at about 92 characters and called that past the readable band.
     At 1440 the queue runs to ~1030 and a task line runs about 130. Spencer was shown both
     that number and the narrower alternatives on 2026-09-08 and chose the width. Recorded so
     the next pass reads it as a decision rather than as drift to be tidied back. */
  #akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .ak-home > * {
    max-width: var(--ak-content-max);
    margin-inline: auto;
    width: 100%;
  }

  #akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .ak-home__columns {
    flex-direction: row;
    align-items: flex-start;
    justify-content: center;
    gap: 2rem;
  }
  /* GROWS. `flex: 0 1 620px` held it at 620 no matter how much room the row had, and the
     `max-width: 620px` set at the 700 breakpoint went on applying here - so the basis alone
     would not have released it and both have to be undone together. The reference column
     opposite keeps its fixed 380: only one of the two is a reading column. */
  #akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .ak-home__queue {
    flex: 1 1 auto;
    max-width: none;
    margin-inline: 0;
  }
  /* ⛔ REFERENCE, NEVER QUEUE — the appointment card and the door list. Things you act on one side,
     things you look at the other; the same rule the encounter workspace landed on. Sticky because a
     reference that scrolls away stops being reference. */
  #akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .ak-home__reference {
    flex: 0 0 380px;
    max-width: 380px;
    margin-inline: 0;
    position: sticky;
    top: 1rem;
  }
}


/* =========================================================
   THE PATIENT SHELL SHARES THE HOME'S CONTENT COLUMN, and until now only the home did.

   The rule above caps `.ak-home`'s own rows at 1030 and centres them, so the summary band and the two
   columns line up. Everything the dashboard shell renders ABOVE the routed page - the banner slot, the
   identity-verification card, the breadcrumb row - is a sibling of `.ak-home` rather than a child of
   it, so none of them were ever reached. Measured on a 1920 window: the banner ran 16 -> 1889 while the
   content beneath it started at 438. The right-hand end of the banner was ~420px outside the column,
   which is what put its primary action against the window edge with a scrollbar's width to spare.

   THE ROW THAT CLIPS IS THE ONE THAT IS ASKING A QUESTION. The invitation banner offers a decline and
   an accept; the accept is the last thing on the row, so it is the half that goes first. A choice with
   one option reachable is not a choice.

   `:not(.ak-home)` IS LOAD-BEARING, and it is the same trap the rule above records: `.ak-home` carries
   `container-type: inline-size` and IS the `akhome` query container. Capping it here would mean
   `@container akhome (min-width: 1060px)` could never match, the columns would never become a row, and
   this fix would silently undo the layout it is trying to line up with. Its children are already
   capped by their own rule, so the column is the same either way.

   THE WIDTH IS THE HOME'S OWN NUMBER, not a second one that happens to look right: 620 (queue) + 30
   (gap) + 380 (reference) = 1030. One content column on the patient portal means one number; a second
   would drift from the first the moment either moved.

   NO CONTAINER QUERY HERE, AND THAT IS DELIBERATE RATHER THAN AN OVERSIGHT. The rule above needs one
   because it changes LAYOUT - stacked columns become a row - and a layout that flips has to know the
   width it is flipping at. This one only ever caps: below 1030 the rows are already narrower than the
   cap and it does nothing, so there is no band where it needs turning off and no breakpoint to keep in
   step. `container-type: inline-size` was the first draft and it was the wrong tool: it applies layout
   containment, which makes the pane a containing block for every `position: fixed` descendant inside
   it. The drawer's scrim is a sibling and safe, but the pane holds every routed patient page and every
   component they render, and that is not a thing to change blind for a cap that does not need it.

   The one place the two rules disagree is a container between 1030 and 1060 wide, where the home's own
   rows are up to 30px wider than the shell's because their cap has not switched on yet. Thirty pixels
   in a thirty-pixel band, against a containment change across the whole portal.
   ========================================================= */
/* 1440 for the same reason and, more importantly, the SAME NUMBER: this rule exists so the
   shell's banners and breadcrumb line up with the home's rows, and leaving it at 1030 while the
   home moved to 1440 would have reintroduced the overhang it was written to remove - only
   inverted, with the shell now narrower than the page under it. */
/* One gutter for the band and the page under it: 14px on a phone, 20px wherever there is room. */
#akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .ak-shell {
  padding: 14px 14px 32px;
}
#akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] header[data-akashic-frame] {
  padding-inline: 14px;
}
@media (min-width: 640px) {
  #akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .ak-shell {
    padding: 14px 20px 40px;
  }
  #akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] header[data-akashic-frame] {
    padding-inline: 20px;
  }
}

#akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .ak-shell > *:not(.ak-home) {
  max-width: var(--ak-content-max);
  margin-inline: auto;
}

/* THE FRAME'S OWN ROWS SIT IN THE CONTENT COLUMN. The band spans the window; what is printed
   inside it does not. Without this the logo and the phone number are the only things on the page
   that ignore the column, and on a wide monitor they are the first and last things read. */
#akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .ak-frame-row {
  max-width: var(--ak-content-max);
  margin-inline: auto;
  width: 100%;
}

/* The front desk's search, Book and Register in the staff header: search takes the width. */
.ak-frame-desk-actions {
  margin-left: auto;
  display: flex;
  flex: 1 1 auto;
  align-items: center;
  gap: 8px;
  min-width: 0;
  max-width: 760px;
}

.ak-frame-desk-actions .ak-frame-desk-action {
  flex: none;
  height: 32px;
  padding: 0 11px;
}

/* =========================================================
   THE PATIENT PORTAL'S CARDS ARE SQUARE, ALL OF THEM.

   🗣️ Spencer, walking the running home page 2026-09-08: "Card styles".

   Two card systems draw on one screen. `.wp-card` took the settled square shape
   earlier today; the sixteen surfaces built from Tailwind utilities - the summary
   tiles, every queue row, the reference panels - carry `rounded-lg` and stayed at
   8px. One page, two corner radii, which reads as carelessness rather than as
   either decision.

   ⚠️ Scoped to the portal shell rather than written as a global `.rounded-lg`
   override: the utility is also on things that are not cards, and squaring an
   avatar or a menu is not what this says. Anything inside the shell that must stay
   round should carry `rounded-full`, which this does not touch.
   ========================================================= */
#akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .ak-shell .rounded-lg,
#akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .ak-shell .rounded {
  border-radius: 0;
  box-shadow: var(--ak-card-lift);
}

/* ⚠️ THE FOUR SUMMARY TILES KEEP THEIR CORNERS, and it is the one deliberate exception.
   🗣️ Spencer, 2026-09-08: "I kind of liked having the 4 top cards with rounded corners to
   separate them from the rest of the content since those should take eye focus more than the rest."
   The deck agrees on the number - `.strip-item` is `border-radius: 8px` there while every card
   below it is square - so the corner is doing the same job in both: these four are a different
   KIND of thing from the queue under them, and the shape is what says so before the words do. */
#akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .ak-home__summary .rounded-lg {
  border-radius: 8px;
  box-shadow: none;
}

#akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .ak-home__reference > nav {
  margin-top: 16px;
}

/* The door list keeps its rounded frame and heavier dividers: it is one list, not a stack of cards. */
#akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .ak-home__reference .ak-doors {
  border-radius: 8px;
  box-shadow: none;
}

/* 🔻 THE NEXT APPOINTMENT IS DASHED, ON PAPER. Spencer: "I liked the dashed border you have
   for the next appointment card in the mockup." The deck draws it as
   `background: var(--paper); border-style: dashed` - the one card on the page that is not a thing
   to act on but a thing to look at, and the dash is what separates reference from queue without
   another colour. */
#akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .ak-home__reference .ak-next-appointment {
  padding: 14px;
  border-style: dashed;
  background: var(--paper);
  /* THE LIFT STAYS. Measured on the deck 2026-09-08: the next-appointment card is dashed AND
     carries the same 2px offset shadow every other card does - the dash separates reference from
     work, the shadow is what makes it a card at all. Taking the shadow off flattened it into the
     page. */
  box-shadow: var(--ak-card-lift);
}

/* 🚨 THE AMBER NOTICE WAS DRAWING WHITE. The proofing banner carries `border-amber-300
   bg-amber-50`, and an id-scoped rule on the Card slot beat both, so the one banner on the page
   that is supposed to catch the eye rendered as an ordinary card. The utilities are given the
   specificity they were written expecting rather than being replaced. */
#akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] [data-testid="proofing-banner"] {
  background: var(--amber-soft, #fdf0e3);
  border-color: var(--amber-line, #e8c9a0);
}

/* =========================================================
   44px IS A FINGER, NOT A DESIGN.

   🗣️ Spencer, same walk: "Accept button too big."

   The frontend mount sets every button to a 44px minimum, which is the touch
   target and is right on the surface a patient uses on a phone. On a pointer
   device it is simply a large button - a 13px label in a 44px box - and in a
   notice banner it reads as shouting.

   ⛔ The rule is NOT removed, it is asked a better question. `pointer: fine` is
   true for a mouse or a trackpad and false for a touchscreen, so a phone keeps its
   44px and a laptop gets a button in proportion to its own text. A hit area is an
   accessibility requirement; it just is not a requirement about mice.
   ========================================================= */
@media (pointer: fine) {
  #akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] .btn,
  #akashic-health-records-patient-portal-root[data-akashic-mount="frontend"] [data-slot="button"] {
    min-height: 32px;
  }
}

/* =========================================================
   CLINICIAN OVERVIEW — the widths this workspace was designed for. Card 334 slice 5.

   🚨 CONTAINER QUERIES, NEVER VIEWPORT. We are a mount inside the practice's own page: the window can
   report 1440 while this column has 900. The patient home above had to fix precisely this, and the
   design doc says so in capitals.

   📐 THE THREE BANDS, and where each number comes from:
     · ≥ 1180 — the desktop the surface was built at; the queue keeps its 358px.
     · ≥  769 — the design's LANDSCAPE TABLET frame. The queue narrows to 296px; below that the task
                count cannot share a line with the room chip, which is why the row stacks it.
     ·   ≤768 — the design's PORTRAIT frame. Two columns are given up: the queue becomes the 64px rail
                that already exists for the open-visit state, and DAY opens it over the top.

   ⚠️ THE PORTRAIT FRAME AND ITS OWN STATED REASON NO LONGER AGREE, AND THIS BUILDS THE FRAME.
   §6 rejects two columns at 768 because they leave the patient "~390px, narrower than the phone
   layout" — but that arithmetic is against the OLD 358px queue (768 − 358 − 16 = 394). The same frame
   narrows the queue to 296, which would leave the patient 456. The drawn frame is what Spencer
   approved, so the drawn frame is what is built; the arithmetic is on the card for him to overturn if
   he wants the columns held. ⛔ Nothing was drawn between 768 and 1024, so no midpoint is invented
   here — 769 is simply "not the portrait frame".

   🔑 The rail rule is DELIBERATELY not a container query. It changes BEHAVIOUR (an overlay, not a
   column), which CSS cannot express, so the page measures the container and sets the class. Both
   thresholds read the same box — the content rect — so they cannot land on different numbers.

   🚨 CARD 408 — THE CONTAINER MUST CARRY NO PADDING, AND THIS IS THE RULE THE NUMBERS ABOVE DEPEND ON.
   A container query measures the CONTENT box. `.ak-clinday` used to carry `max-w-[1180px] p-4 md:p-6`
   on the SAME element, so the query saw 1180 - 48 = 1132 and the 1180 band could NEVER fire at any
   window size — measured at a 2200px viewport, where the grid still computed `296px 820px`. The 358px
   layout was unreachable code, and every other band engaged 48px early, which is what put the portrait
   rail on a tablet the design says should hold two columns.
   ⇒ The padding now lives on a child. ⛔ Never put padding, a border, or anything else that shrinks
   the content box back on this element, and ⛔ never "fix" a band by adding 48 to it — that hard-codes
   today's padding into a rule that will not error when the padding changes.
   📌 `max-width` is fine here and is deliberately kept: with no padding it does not shrink the content
   box, so what the query reads IS the frame width these three numbers were drawn against.
   ========================================================= */
.ak-clinday {
  container-type: inline-size;
  container-name: akclinday;
}

.ak-clinday__columns {
  display: grid;
  grid-template-columns: minmax(0, 1fr);
  gap: 1rem;
  align-items: start;
}

@container akclinday (min-width: 769px) {
  .ak-clinday__columns {
    grid-template-columns: 296px minmax(0, 1fr);
  }
}

@container akclinday (min-width: 1180px) {
  .ak-clinday__columns {
    grid-template-columns: 358px minmax(0, 1fr);
  }
}

/* TWO class names, so this beats the container rules above on specificity rather than by shouting.
   The rail wins at every width: it is set either because a visit is open and the queue was hidden, or
   because the container is too narrow to hold two columns at all. */
.ak-clinday__columns.ak-clinday__columns--railed {
  grid-template-columns: 64px minmax(0, 1fr);
}

/* The queue opened OVER the panel at portrait width, rather than beside it — there is no room beside it,
   which is the whole reason the rail exists there. It takes the WHOLE width because that is the only
   width there is, and the queue's own "Hide queue" control closes it, so there is no state a
   practitioner can be stranded in. */
.ak-clinday__dayoverlay {
  position: absolute;
  z-index: 20;
  top: 0;
  left: 0;
  right: 0;
  max-height: 100%;
  overflow-y: auto;
  border-radius: 0.75rem;
}

/* The overview's day as count cards and its empty panel, as drawn in the approved practitioner deck.
   A card is a heading and a number; it is tinted only while its sheet is open. */
#akashic-health-records-patient-portal-root .ak-clinday__counts {
  display: flex;
  flex-direction: column;
  gap: 8px;
  margin: 0 0 1rem;
  padding: 0;
  list-style: none;
}

#akashic-health-records-patient-portal-root .ak-clinday__count {
  display: flex;
  align-items: center;
  justify-content: space-between;
  gap: 8px;
  width: 100%;
  min-height: 44px;
  padding: 10px;
  text-align: left;
  background: var(--surface);
  border: 0;
  border-radius: var(--ak-card-radius);
  box-shadow: var(--ak-card-lift);
  cursor: pointer;
}

#akashic-health-records-patient-portal-root .ak-clinday__count:hover {
  background: var(--sunken);
}

#akashic-health-records-patient-portal-root .ak-clinday__count[aria-expanded="true"] {
  background: var(--amber-soft);
}

#akashic-health-records-patient-portal-root .ak-clinday__count-label {
  min-width: 0;
  font-size: var(--ak-font-11);
  font-weight: 500;
  letter-spacing: 0.05em;
  text-transform: uppercase;
  color: var(--ink-muted);
}

#akashic-health-records-patient-portal-root .ak-clinday__count-value {
  flex: none;
  font-size: var(--ak-font-15);
  font-weight: 600;
  line-height: 1;
  font-variant-numeric: tabular-nums;
  color: var(--ink-strong);
}

#akashic-health-records-patient-portal-root .ak-clinday__count[aria-expanded="true"] .ak-clinday__count-value {
  color: var(--amber-ink);
}

#akashic-health-records-patient-portal-root .ak-clinday__sheet {
  width: 100%;
  max-width: 420px;
  gap: 6px;
  padding: 16px 0;
  overflow-y: auto;
  background: var(--surface);
  border-left: 1px solid var(--line);
}

#akashic-health-records-patient-portal-root .ak-clinday__sheet .ak-clinday__sheettitle {
  margin: 0 18px 8px;
  font-size: var(--ak-font-17);
  font-weight: 500;
  color: var(--ink-strong);
}

/* A size container, so the icon is a fraction of the card rather than a pixel size. */
#akashic-health-records-patient-portal-root .ak-clinday__emptypanel {
  container-type: size;
  display: flex;
  align-items: center;
  justify-content: center;
  height: 520px;
  background: var(--surface);
  border: 0;
  border-radius: var(--ak-card-radius);
  box-shadow: var(--ak-card-lift);
}

#akashic-health-records-patient-portal-root .ak-clinday__emptystate {
  display: flex;
  flex-direction: column;
  align-items: center;
  justify-content: center;
  gap: 20px;
  max-width: 520px;
  padding: 24px;
  text-align: center;
}

#akashic-health-records-patient-portal-root .ak-clinday__emptymsg {
  margin: 0;
  font-size: var(--ak-font-18);
  font-weight: 500;
  line-height: 1.5;
  text-wrap: balance;
  color: var(--ink-strong);
}

#akashic-health-records-patient-portal-root .ak-clinday__emptylink {
  padding: 0;
  font: inherit;
  font-weight: 500;
  white-space: nowrap;
  color: var(--primary);
  text-decoration: underline;
  text-underline-offset: 2px;
  background: none;
  border: 0;
  cursor: pointer;
}

#akashic-health-records-patient-portal-root .ak-clinday__emptyicon {
  display: flex;
  align-items: center;
  justify-content: center;
  gap: 16px;
  color: var(--faint);
}

#akashic-health-records-patient-portal-root .ak-clinday__emptyicon svg {
  display: block;
  width: min(62cqw, 62cqh);
  height: auto;
}

#akashic-health-records-patient-portal-root .ak-clinday__emptyicon--duo svg {
  width: min(42cqw, 42cqh);
}

@container akclinday (max-width: 768px) {
  #akashic-health-records-patient-portal-root .ak-clinday__emptypanel {
    height: 400px;
  }

  #akashic-health-records-patient-portal-root .ak-clinday__emptyicon svg {
    width: min(60cqw, 60cqh);
  }

  #akashic-health-records-patient-portal-root .ak-clinday__emptyicon--duo svg {
    width: min(40cqw, 40cqh);
  }
}

/* THE WORDPRESS ADMIN BAR SAT ON TOP OF THE PORTAL'S NAVIGATION BUTTON.

   A practice owner signed in to their own WordPress site gets the admin bar fixed across the top of
   every page on that site, this one included. WordPress normally makes room for it with a forced
   top margin on `html` - that rule is present and enabled here, and the computed margin is still
   0px, so nothing offsets the document and the bar overlaps our header. Measured:
   `document.elementFromPoint` at the button's centre returns a WordPress `ab-item` link, and
   Playwright refuses the click for the same reason. The button is visible, is not disabled, and does
   nothing - which is the most expensive kind of broken, because there is nothing to read.

   IT IS THE PERSON MOST LIKELY TO BE SHOWN THIS PRODUCT. The WordPress administrator on a practice's
   site is the practice owner - the one who installed the plugin - and for them the entire sidebar is
   unreachable: Patients, Appointments, Schedules, Messages, Log Out.

   THE BAR IS NOT HIDDEN AND MUST NOT BE. It belongs to WordPress, on a site the practice owns.

   THE HEIGHT COMES FROM WORDPRESS, NOT FROM US. `--wp-admin--admin-bar--height` is theirs, and their
   own stylesheet redefines it at the mobile breakpoint - 32px above 782px, 46px at or below. Reading
   it is what makes one rule correct at both widths; two hardcoded numbers and a media query of our own
   would be a second copy of a value they already maintain, and it would be wrong the day they change
   it. The fallback covers a WordPress old enough not to publish the variable.

   PADDING, NOT MARGIN: the frame is `min-h-screen`, and with border-box the padding sits inside that
   100vh rather than adding to it, so the page does not gain a scrollbar it did not have. */
body.admin-bar:not(.wp-admin) [data-akashic-portal-frame] {
  padding-top: var(--wp-admin--admin-bar--height, 32px);
}


/* The patient home's "N items need attention" heading, taken from the approved patient-portal deck
   (mockups/patient-portal/_shared.css, the q-head rule).

   SCOPED, NOT ADDED TO THE PALETTE. This is a SECTION colour belonging to one heading, and the palette
   above is the cross-workspace one the design pass is explicitly not to touch. Keeping it here mirrors
   the deck's own structure, which declares this variable on the heading for the same reason, and keeps a
   deep red out of the token layer where somebody would later reach for it as a general danger colour.
   It is NOT --danger (#dc2626): that is the button red, and this is quieter on purpose.

   The dark value follows this file's dormant .dark convention, recorded because the deck records it - a
   ramp that exists in only one theme is how a later consistency pass reintroduces the wrong one. */
.patient-queue-head {
  --sec-attn: #b3261e;
}

.dark .patient-queue-head {
  --sec-attn: #9a4537;
}

.patient-queue-head h3 {
  color: var(--sec-attn);
}

/* Shared page titles retain the mount scope to override WordPress theme headings. */
#akashic-health-records-patient-portal-root .ahr-view-title,
#akashic-health-records-patient-portal-root .ak-page-title {
  margin: 0 0 10px;
  /* WordPress .wrap h1 pads the heading. */
  padding: 0;
  font-size: var(--ak-font-20);
  letter-spacing: 0.01em;
  font-weight: 600;
  color: var(--sage);
}

/* Page-body rhythm (reviews/2026-09-27-page-body-rhythm.md): an opt-in single-column stack, 12px between
   blocks, as the decks' page body draws it. Put it on a page or section's block group, never on a
   title and its subtitle, and card and list interiors keep their own spacing. */
#akashic-health-records-patient-portal-root .ak-page-body {
  display: grid;
  grid-template-columns: minmax(0, 1fr);
  align-content: start;
  row-gap: 12px;
  min-width: 0;
}

/* The breadcrumb as every deck draws it: 13px, the trail in primary blue, the current page in the
   heading ink, and a faint separator 6px either side. */
#akashic-health-records-patient-portal-root [data-slot="breadcrumb-list"] {
  gap: 6px;
}

/* The assistant keeps its 44px target but overhangs the row, so the row is the crumb's height and
   the title sits where the deck puts it. */
#akashic-health-records-patient-portal-root [data-akashic-crumb-actions] {
  margin-block: -8px;
}

#akashic-health-records-patient-portal-root [data-slot="breadcrumb-link"] {
  color: var(--primary);
}

#akashic-health-records-patient-portal-root [data-slot="breadcrumb-page"] {
  color: var(--ink-strong);
}

#akashic-health-records-patient-portal-root [data-slot="breadcrumb-separator"] {
  color: var(--faint);
}

#akashic-health-records-patient-portal-root [data-slot="breadcrumb-separator"] > svg {
  width: 12px;
  height: 12px;
}

/* ── A record, rendered as a record ──────────────────────────────────────────────────────────────
   The same shape the approved task-modal drawing uses for a patient's submitted answers: the
   question is a label and the answer is the content. Text, never inputs - which is what makes it
   selectable, copyable and printable, none of which a disabled form is. */
#akashic-health-records-patient-portal-root .ak-readback {
  display: grid;
  gap: 0;
  margin: 0;
}

#akashic-health-records-patient-portal-root .ak-readback-row {
  display: grid;
  gap: 1px;
  padding: 8px 0;
  border-bottom: 1px solid var(--line-soft);
}

#akashic-health-records-patient-portal-root .ak-readback-row:last-child {
  border-bottom: 0;
}

#akashic-health-records-patient-portal-root .ak-readback-label {
  margin: 0;
  font-size: var(--ak-font-12-5, 12.5px);
  line-height: 1.4;
  color: var(--ink-muted);
}

#akashic-health-records-patient-portal-root .ak-readback-value {
  margin: 0;
  font-size: var(--ak-font-14);
  line-height: 1.4;
  color: var(--ink-strong);
}

/* NOTHING RECORDED IS NOT THE SAME AS NOTHING RENDERED. A row that simply stopped after its label
   reads as a value that failed to load, and on a clinical record those are different claims. */
#akashic-health-records-patient-portal-root .ak-readback-value--empty {
  color: var(--faint);
  font-style: italic;
}

/* ── Printing one region of a page we do not own ────────────────────────────────────────────────
   GUARDED ON THE REGION EXISTING, and that guard is load-bearing rather than tidy. This plugin
   mounts inside thousands of other people's WordPress sites, so an unconditional `body *` print rule
   would break printing of the practice's OWN pages wherever the portal happens to be mounted. The
   :has() means these rules exist only on a page that actually carries a printable record.

   VISIBILITY RATHER THAN DISPLAY, deliberately: `display: none` on an ancestor takes the region down
   with it, and visibility lets a nested region stay visible inside a hidden parent. */
@media print {
  body:has(#akashic-health-records-patient-portal-root [data-print-region="true"]) * {
    visibility: hidden;
  }

  body:has(#akashic-health-records-patient-portal-root [data-print-region="true"])
    #akashic-health-records-patient-portal-root [data-print-region="true"],
  body:has(#akashic-health-records-patient-portal-root [data-print-region="true"])
    #akashic-health-records-patient-portal-root [data-print-region="true"] * {
    visibility: visible;
  }

  /* A region that is a centred, scrolling dialog on screen prints as one clipped screen unless it
     flows: no centring shift, no height cap, no scroll box. */
  body:has(#akashic-health-records-patient-portal-root [data-print-region="true"])
    #akashic-health-records-patient-portal-root [data-print-region="true"] {
    position: absolute;
    left: 0;
    top: 0;
    width: 100%;
    max-width: none;
    height: auto;
    max-height: none;
    overflow: visible;
    translate: none;
    transform: none;
  }

  /* The dialog layer sits below the page's hidden content, so a region anchored to it starts a page
     late; the page is its anchor on paper. */
  body:has(#akashic-health-records-patient-portal-root [data-print-region="true"]) #akashic-overlay-root {
    position: static;
  }

  /* The control that started the print does not belong on the paper, and neither does anything else
     marked as screen furniture. */
  #akashic-health-records-patient-portal-root [data-print-hidden="true"] {
    display: none !important;
  }

  /* A TAB YOU WERE NOT LOOKING AT STILL BELONGS ON THE PAPER, because a printed record that
     silently omits half of itself cannot be told apart from a record that had nothing in that half.
     The tab strip goes the other way - a row of controls nobody can press is not information.

     KEYED ON data-state, NOT [hidden]. `forceMount` means Radix keeps the panel mounted and leaves
     visibility to us: it sets no `hidden` attribute, so a rule matching one matched nothing and the
     inactive panel simply rendered - both tabs stacked on screen, and the paper unchanged. */
  #akashic-health-records-patient-portal-root [data-print-region="true"]
    [data-slot="tabs-content"][data-state="inactive"] {
    display: block !important;
    visibility: visible !important;
  }

  /* Paper is not a screen: the lift, the tints and the reversed fills all cost ink and give nothing
     back, and a link whose href a reader cannot see is better plain. */
  #akashic-health-records-patient-portal-root [data-print-region="true"] * {
    box-shadow: none !important;
    text-shadow: none !important;
  }

  #akashic-health-records-patient-portal-root .ak-readback-row {
    break-inside: avoid;
  }
}