/*
 * GENERATED FILE — DO NOT EDIT.
 *
 * Source:    sites/shared/theme/theme-dark.css
 * Regenerate: python3 scripts/sync-shared.py   (from sites/)
 *
 * This copy exists only because HQ embeds its frontend with go:embed, which
 * cannot reference files outside its module. Edit the source; changes made
 * here are overwritten and will fail `sync-shared.py --check`.
 */

/* ============================================================================
 * theme-dark — a proof, not a theme
 * ============================================================================
 *
 * Everything here applies only under `:root[data-theme="dark"]`, which nothing
 * sets unless a reader presses the switch. Delete this file and the switch still
 * works; it just stops repainting anything.
 *
 * It exists to make one question answerable by looking instead of arguing:
 * BRAND.html says "not dark on customer-facing surfaces", and this is what the
 * other side of that rule would cost.
 *
 * ---- What trying it actually taught -----------------------------------------
 *
 * A TOKEN SWAP DOES NOT PRODUCE A DARK THEME. It produces a photographic
 * negative, and the reason is in the names.
 *
 * `--ink` is a colour ("#1b2844", a blue-black) doing a job (every text, every
 * border, every drop shadow). Redefine it to a near-white and the job still gets
 * done — but `--on-ink`, which means "text drawn ON an ink fill", now has to be
 * DARK, and the sidenav, whose ground is `var(--ink)`, turns into a white column
 * in a dark page. The palette is not theme-neutral, and it is not sloppy: it was
 * written for one theme and says so honestly.
 *
 * A real dark mode wants ROLE names — surface, surface-raised, foreground,
 * border — so that "the darkest surface" is a thing the palette can express
 * twice. That is the actual size of the job, and it is a rename across every
 * component rather than a second colour list.
 *
 * Below, the sidenav is re-grounded through the five names it publishes for
 * exactly this purpose rather than by fighting `--ink`. That seam existing is
 * why this file is short.
 * ========================================================================== */

:root[data-theme="dark"] {
  /* The desk, and the cards on it. Two steps apart, so a panel still reads as
     sitting ON something rather than as a patch of the same field. */
  --bg: #14181f;
  --panel: #1e242e;

  /* The foreground. Named --ink because that is the token every component
     reaches for; it is no longer ink, which is the naming problem above. */
  --ink: #e8ecf3;
  --ink-subtle: #e8ecf34d;
  --muted: #9aa6bd;

  /* Text on an --ink FILL. Since --ink is now light, this has to be dark — the
     one place the inversion is unavoidable rather than merely awkward. */
  --on-ink: #14181f;
  --on-ink-muted: #46506a;
  --ink-raised: #cfd6e4;

  /* A ROLE the light palette never needed a name for, and the first piece of the
     vocabulary this file argues for at the top.
     On the light side, "a panel that stands out from the page" is drawn by
     FILLING IT WITH INK — the table spine, the search mark, a selected row. That
     works because ink is the darkest thing available and the page is white.
     Invert the palette and the same instruction paints the brightest thing
     available onto a dark page, which is not emphasis, it is a floodlight: the
     spine of a reference table became a white slab with the prose whispering
     beside it.
     So the dark side needs a surface that is a STEP from the page rather than
     the opposite of it. Everything that used an ink fill for emphasis points
     here instead.

     One step above --panel and no more. The emphasis on this side comes from
     the surface being DIFFERENT, not from it being bright — a spine only has to
     separate from the cell beside it, and the border already draws the edge. */
  --surface-raised: #242c38;

  /* The triad is never reassigned — it is the ABC mapping and it is
     load-bearing. Orange, purple and green all clear 4.5:1 on #14181f, so they
     carry over untouched. */
}

/* The column would otherwise follow --ink and turn white. It publishes five
   names precisely so a host can stand it on a different ground, which is the
   same seam `subnav` uses to sit on a light one. */
:root[data-theme="dark"] .sidenav {
  --sidenav-ground: #10141a;
  --sidenav-fg: #c3cbdb;
  --sidenav-fg-muted: #7c88a3;
  --sidenav-fg-strong: #ffffff;
  --sidenav-raised: #1d2532;
}

/* The shelf is --panel, which is now dark, so its underline needs to read
   against it rather than against white. */
:root[data-theme="dark"] .topbar {
  border-bottom: 0;
}

/* ---- Everything that used an ink FILL to mean "emphasis" -------------------
 * Each of these is a light-side instruction that inverts into a floodlight, and
 * each takes the raised surface instead. The text goes back to --ink, because on
 * a dark fill the label is the light one again — the double inversion that makes
 * this palette awkward to reason about and is exactly why the role name exists.
 *
 * Contrast is not the reason for any of them: the ink-filled versions measure
 * 13:1. They are too LOUD, which is a different fault and needs a different fix.
 */
:root[data-theme="dark"] .searchbar-mark {
  background: var(--surface-raised);
  color: var(--ink);
}

/* ---- THE LONG RULES ACROSS THE MARKETING PAGE -----------------------------
 *
 * Same fault as the windows and the buttons, on the lines that divide the page
 * rather than on anything that holds content: written as --ink they are the
 * darkest thing on a white page and a bright white wire here.
 *
 * A full-width 2px rule is the worst case for it, too. A button's edge is a few
 * hundred pixels of outline; these run the width of the viewport, so at --ink
 * they are the brightest object on the screen and they are not even content.
 *
 * The navbar's rule only exists once the page has scrolled — at the top the
 * header is part of the hero and draws nothing — so this is scoped the same way
 * rather than painting an edge the light theme does not have. The extra
 * [data-scrolled] also settles the specificity against global.css's own rule
 * without depending on which file loads last.
 *
 * The terminal's fill is a literal and stays one; only its OUTLINE moves. It is
 * a dark panel on a dark page here, where on a white page it was a dark panel on
 * white — the fill needs no help separating itself, the outline was doing work
 * it no longer has to do. `.band.ink .term` already reached this conclusion for
 * the one section whose ground matched it, at 18%; this is the same idea for
 * every other section, at the 30% everything else in this palette uses. */
:root[data-theme="dark"][data-scrolled] .navbar { border-bottom-color: var(--ink-subtle); }
:root[data-theme="dark"] .term { border-color: var(--ink-subtle); }
:root[data-theme="dark"] .reslinks { border-top-color: var(--ink-subtle); }

/* THE FOOTER'S TOP EDGE GOES, both sites'. It is the only one of these that is
   drawn twice: the footer opens with .footer-accent, the ABC triad in three
   equal thirds, and a 2px rule immediately above that is a second division of
   the same seam. On a white page the two read as one object because the ink line
   caps the colours; on a dark one it is a white wire above a triad that already
   separates the footer perfectly well on its own.
   TRANSPARENT, not `none` — the same reasoning global.css gives for the navbar's:
   the border keeps its 2px in both themes, so switching palette cannot move the
   bottom of the document by two pixels. */
:root[data-theme="dark"] .site-footer { border-top-color: transparent; }

/* THE BAR'S OWN EDGES, quieted to match everything else in this palette. The
   fill above was already corrected; the 2px outline around the mark and the
   field was not, so the control kept a bright white rectangle on each half while
   its own keyboard hint sat between them at --ink-subtle. The component had the
   right value in it all along — `.searchbar-key` states it directly — and only
   the two loud parts were reading --ink.
   The FOCUS ring is deliberately untouched: it is --brand-2 on both halves and
   the one thing here that should shout.
   The input's border, not its outline. `:focus` draws a purple outline inset by
   2px, which is a separate property and survives this. */
:root[data-theme="dark"] .searchbar-mark,
:root[data-theme="dark"] .searchbar input {
  border-color: var(--ink-subtle);
}

/* THE RESULTS PANEL, and its shadow with it. This one was left loud on the
   argument that a dropdown has to separate itself from the page behind it — and
   the argument is right, but it is the FILL that does that job here: --panel
   against --bg is a lighter slab on a darker page, which is exactly the
   separation a floating panel needs. The 2px outline and the hard 4px offset
   under it were doing it a second time, in the brightest value the palette has,
   over a panel that is already only 60px tall in places.
   Border and shadow together, for the reason the buttons gave: they are the same
   line seen twice, and a quiet outline over a hard white underside reads as a
   mistake.
   The GROUP HEADER's rule is the same fault one level in — a full-width white
   wire under "PAGES", inside a panel whose own edge is now quieter than it.
   The row dividers are NOT here and want nothing: they are `--bg` on `--panel`,
   a pair that already follows the palette, so inverted they stay a step darker
   than the rows they divide instead of a step brighter. */
:root[data-theme="dark"] .searchbar-results {
  border-color: var(--ink-subtle);
  box-shadow: 4px 4px 0 var(--ink-subtle);
}

/* THE BAR'S OWN LIFT, at the weight of the panel it opens. Focus raises the mark
   and the field onto the results panel's layer with the same 4px diagonal the
   panel carries, and the two are read as one object at that moment — so a hard
   white shadow under the bar above a softened one under the panel would be the
   seam showing.
   Softened, not removed, and that is the difference between this and the focus
   RING. The ring is --brand-2 and stays exactly as loud as it is: it is the
   thing that says where the keyboard is. The shadow is not state, it is depth —
   the same 4px both halves get, saying they came forward together. */
:root[data-theme="dark"] .searchbar:focus-within .searchbar-mark,
:root[data-theme="dark"] .searchbar:focus-within .searchbar-field {
  box-shadow: 4px 4px 0 var(--ink-subtle);
}
:root[data-theme="dark"] .searchbar-result-group {
  border-bottom-color: var(--ink-subtle);
}

/* The reference table's Γ — the header bar and the spine down the first column.
   The largest ink fill on a docs page, so the largest floodlight. */
:root[data-theme="dark"] .docs-content .reference-table th,
:root[data-theme="dark"] .docs-content .reference-table td:first-child {
  background: var(--surface-raised);
  color: var(--ink);
}
/* The rest of the ink-filled emphasis on a docs page: the list title, the
   callout's claim line, the rack's header, the copy button. Same instruction,
   same floodlight, same fix. */
:root[data-theme="dark"] .docs-content h3.docs-list-title,
:root[data-theme="dark"] .docs-content .callout .co-claim,
:root[data-theme="dark"] .docs-content .tbl-rack .rk-head,
:root[data-theme="dark"] .docs-content .cb-copy {
  background: var(--surface-raised);
  color: var(--ink);
}

/* The chip's right edge, which separated it from the bar it sits on. That edge
   was --ink because the bar was --ink: a dark line at the end of a dark bar,
   invisible except where the coloured square met it. The rule above re-grounds
   the bar and leaves the edge behind, so what was a seam became a bright white
   post standing between the flavour square and the claim.
   It takes the bar's fill, like every other internal rule corrected in this
   file — the chip is already a different colour from the bar on every side, so
   the division was never the line's to make. */
:root[data-theme="dark"] .docs-content .callout .co-chip {
  border-right-color: var(--surface-raised);
}

/* The prev/next card fills on HOVER, which on the light side is a card going
   solid under the pointer and here would be a panel flashing near-white. A
   transient state is the one you least want shouting. */
:root[data-theme="dark"] .docs-footer-link:hover {
  background-color: var(--surface-raised);
  color: var(--ink);
}

/* ---- The marketing page's ink fills ----------------------------------------
 * Same rule as the documentation's: an ink fill meant "emphasis" on a white
 * page, and inverted it means "floodlight" on a dark one. Contrast is not the
 * problem with any of these — they measure 13:1 — brightness is.
 */

/* The strip above the navbar. Full width, so it is the largest ink fill on the
   site and the first thing above the fold. */
:root[data-theme="dark"] .announce-bar {
  background: var(--surface-raised);
  color: var(--ink);
}
/* The badge on that strip is the INVERSE variant — panel fill, ink label — and it
   still reads, one step darker than the bar with its own light border. */

/* The plain badge, as the footer wears it. */
:root[data-theme="dark"] .alpha-tag:not(.inverse) {
  background: var(--surface-raised);
  color: var(--ink);
  border-color: var(--ink);
}

/* The two big dark slabs on the marketing page: the hero terminal and the
   expanded stat panel.
   Both are theme-invariant inside — literal dark grounds with their own light
   text — but their EDGE is drawn against the page, so it follows --ink and in
   this palette --ink is near-white. A 2px white rule around a 400px slab is the
   loudest line on the page, and it is drawing a box rather than an edge.
   --ink-subtle is the same token the light side already uses for "ink, softened"
   and here resolves to light at 30% — the same reading `.band.ink .term` reaches
   for with its own rgba(255,255,255,0.18) when it sits on ink. */
:root[data-theme="dark"] .hero-term,
:root[data-theme="dark"] .hero-stats .stat-detail {
  border-color: var(--ink-subtle);
}

/* The stat row's selected and hovered card. An ink fill for emphasis, so it
   takes the raised surface like every other one — including the pseudo-elements
   that bleed its ground out to the screen edge on the first and last card, or a
   selected edge card would stop halfway. */
:root[data-theme="dark"] .hero-stats .stat.active,
:root[data-theme="dark"] .hero-stats .stat:hover {
  background: var(--surface-raised);
  color: var(--ink);
}
:root[data-theme="dark"] .hero-stats .stat.active .big,
:root[data-theme="dark"] .hero-stats .stat:hover .big,
:root[data-theme="dark"] .hero-stats .stat.active .tt-hint,
:root[data-theme="dark"] .hero-stats .stat:hover .tt-hint { color: var(--ink); }
:root[data-theme="dark"] .hero-stats .stat.active .label,
:root[data-theme="dark"] .hero-stats .stat:hover .label { color: var(--muted); }

/* EVERY PRESSABLE THING'S EDGE, in one line.
   --toy-edge is the colour of a button's 2px border and the hard shadow under
   it, named in brand.css and used by `.btn`, `.btn-raised`, `.navbar-cta`,
   `.btn-rev` and every latchbox key. In the light palette it is --ink and this
   file is what makes it anything else.
   The terminal already reads this way, and the reason generalises: --ink is the
   darkest thing on a white page and the near-white one here, so an instruction
   that draws a crisp edge in one theme outlines every button in bright white in
   the other. Softening it to --ink-subtle keeps the affordance — the shadow is
   still there, still hard, still directly below — and stops it shouting.
   Because border and shadow both read the one token they cannot fall out of step:
   a muted outline over a hard white underside would read as a mistake. */
:root[data-theme="dark"] {
  --toy-edge: var(--ink-subtle);

  /* A WELL IS QUIETER THAN THE KEYS IN IT. --toy-edge is the edge of a thing you
     press; this is the edge of the housing those things sit in, and it is one
     step further back — 18% against the keys' 30%.
     The order matters more than either number. A frame drawn as strongly as what
     it frames reads as a fifth box competing with the four inside it; drawn
     quieter, it reads as the recess they are seated in, which is what it is.
     18% is not a new idea either: `.band.ink .term` already reaches for exactly
     rgba(255,255,255,0.18) when it needs an edge that sits back on a dark
     ground. */
  --toy-well-edge: rgba(232, 236, 243, 0.18);
}

/* The well only. Its keys keep --toy-edge, set above and untouched here. */
:root[data-theme="dark"] .latchbox {
  border-color: var(--toy-well-edge);
}

/* The pressed latch is the exception, and only for its BORDER. Its fill is the
   full --ink, so an edge softer than the fill draws a grey halo around a white
   slab. Down, the key wants no visible outline at all — which is what an edge
   matching its own fill gives it. The shadow is already gone by then. */
:root[data-theme="dark"] .latchbox-key[aria-checked="true"],
:root[data-theme="dark"] .latchbox-key[aria-pressed="true"] {
  border-color: var(--ink);
}

/* The chosen latch is NOT dimmed here, unlike the other emphasis fills above.
   It keeps the component's own inverted look — the --ink fill, which in this
   palette is the near-white one, with its contents in ink — because that is what
   a pressed key looks like everywhere else in this theme, the switch in the
   navbar included. A key that is down should read the same way whatever it
   happens to be labelling.
   So there is no rule here: hero.css states the pair in tokens that hold in both
   palettes, and this file has nothing to correct. */
:root[data-theme="dark"] .hero-stats .stat:hover::before,
:root[data-theme="dark"] .hero-stats .stat.active::before,
:root[data-theme="dark"] .hero-stats .stat:hover::after,
:root[data-theme="dark"] .hero-stats .stat.active::after {
  background: var(--surface-raised);
}

/* The secondary button's fill is a literal near-white, which is a colourway
   rather than a token and therefore does not follow anything. On a dark page it
   is a white slab beside an orange one; here it becomes a surface, and its label
   goes back to following the palette because this fill now does. */
:root[data-theme="dark"] .btn-rev {
  background: var(--surface-raised);
  color: var(--ink);
}

/* A code block's filename bar, and a file tree's folder bars — untagged only,
   for the same reason as the rack and the plate below. The tree's bar carries a
   dimmed NOTE as well as a name, and that note is already written per-case: a
   coloured bar dims with its own white, an ink one takes a blue-grey. Only the
   fill moves here, so both keep the note they were given. */
:root[data-theme="dark"] .docs-content .cb-plaque:not(.on-atomic):not(.on-backbone):not(.on-canvas) {
  --cb-hue: var(--surface-raised);
  --cb-on: var(--ink);
}
:root[data-theme="dark"] .docs-content .filetree:not([class*="on-"]) > li:not([class*="on-"]) {
  --ft-hue: var(--surface-raised);
  --ft-on: var(--ink);
}

/* ---- THE WINDOWS GET THE SAME QUIET EDGE THE BUTTONS DID -------------------
 *
 * A code block is a window onto a machine: a dark ground with a 2px outline, and
 * on a white page that outline is the darkest thing in the paragraph. Inverted,
 * --ink is the near-white one, so the same instruction drew a bright white box
 * around every code sample on the page — the identical fault --toy-edge was
 * introduced to fix for the buttons, one object class over.
 *
 * --ink-subtle, NOT --toy-edge, and the two are the same value here on purpose.
 * --toy-edge means "the edge of a thing you press", and its whole worth is that
 * a theme can move it without touching anything that is not a control. A window
 * is not pressable; borrowing the button token would make the next change to
 * button edges silently repaint every code block too. Same colour, different
 * fact, so it reads the token that states the fact.
 *
 * The bar and the body are one outline drawn by two elements — the bar carries
 * all four sides and the body the three below it — so they have to soften
 * together or the window grows a bright waistline where they meet.
 *
 * The plaque's TAGGED bar is deliberately not here: its fill is the triad, which
 * does not move between themes, and a 30% white line over amber is a pale amber
 * smear rather than a quiet edge. It takes its own fill's colour instead, so a
 * coloured title bar simply has no outline of its own — which is what a title
 * bar is. */
:root[data-theme="dark"] .docs-content pre,
:root[data-theme="dark"] .docs-content .cb-body,
:root[data-theme="dark"] .docs-content .cb-bar {
  border-color: var(--ink-subtle);
}
:root[data-theme="dark"] .docs-content .cb-plaque.on-atomic > .cb-bar,
:root[data-theme="dark"] .docs-content .cb-plaque.on-backbone > .cb-bar,
:root[data-theme="dark"] .docs-content .cb-plaque.on-canvas > .cb-bar {
  border-color: var(--cb-hue);
}

/* A rack's row bars, and ONLY the untagged ones — same reasoning as the plate
   below. Set on the ITEM rather than on the bar, because the item is where the
   pillar classes live and the bar merely inherits: writing --rk-hue on the bar
   would win over the inherited pillar value and grey out Atomic, Backbone and
   Canvas along with the rest. */
:root[data-theme="dark"] .docs-content .tbl-rack .rk-item:not(.on-atomic):not(.on-backbone):not(.on-canvas) {
  --rk-hue: var(--surface-raised);
  --rk-on: var(--ink);
}

/* The plate, and ONLY where its hue is the default ink one. A plate tagged with
   a pillar sits on the triad, which does not move between themes and must not be
   dimmed to a surface — that would turn a colour that MEANS Atomic into grey.
   Hence the three :not()s: without them this selector outranks the pillar rules
   (0,4,2 against 0,3,2) and silently repaints all three. */
:root[data-theme="dark"] .docs-content ul:not([class]) > li:not(.on-atomic):not(.on-backbone):not(.on-canvas),
:root[data-theme="dark"] .docs-content ol:not([class]) > li:not(.on-atomic):not(.on-backbone):not(.on-canvas) {
  --np-hue: var(--surface-raised);
  --np-on: var(--ink);
}

/* ---- THE TABLE IS DRAWN BY ITS FILLS, NOT BY ITS RULES --------------------
 *
 * A reference table in this palette is an L of --surface-raised — the header row
 * and the key column — with the body in --panel beside it. Those two fills
 * already say everything the structure needs: which row is the header, which
 * column is the key, where one cell ends and the next begins.
 *
 * Every internal rule was therefore drawing a division that the fill had already
 * drawn, and drawing it in the loudest values available. Four of them:
 *
 *   the outer border          --ink, a bright white box round the whole table
 *   the header's underline    --ink, a second bright rule immediately inside it
 *   the spine's right edge    --ink, a bright white column down the middle
 *   the row dividers          each column given the OTHER column's surface
 *
 * That last one is why the rows looked spaced apart. The spine's divider was
 * --panel (the body's fill, darker than the spine) and the body's was
 * --surface-raised (the spine's fill, lighter than the body) — so every row
 * boundary was a 2px band of the wrong colour on both sides at once, reading as
 * a gap you could see the page through rather than as a line.
 *
 * Now each rule takes the fill it sits on and disappears into it. The 2px is
 * still spent — the cells keep their spacing and nothing reflows — it just stops
 * being visible. What is left is two fills and one quiet outline.
 *
 * THE LIGHT SIDE IS UNTOUCHED and is not the same drawing. There the body is
 * white and its --bg divider is a clean hairline that reads correctly, and the
 * spine's --muted is genuinely "a quiet edge ON a dark fill". Both are right for
 * a light page; neither survives inversion, which is the whole reason this block
 * exists. */
:root[data-theme="dark"] .docs-content .reference-table {
  border-color: var(--ink-subtle);
}
:root[data-theme="dark"] .docs-content .reference-table th {
  border-bottom-color: var(--surface-raised);
}
:root[data-theme="dark"] .docs-content .reference-table td:first-child {
  border-bottom-color: var(--surface-raised);
  border-right-color: var(--surface-raised);
}
:root[data-theme="dark"] .docs-content .reference-table td {
  border-bottom-color: var(--panel);
}

/* Code blocks are the brand's ONE sanctioned dark surface, so in a dark page
   they stop being an exception and start being invisible against the panel.
   Lifted a step rather than restyled — the highlighting is untouched. */
:root[data-theme="dark"] pre {
  background: #0f1319;
}

/* A hard ink shadow on a dark ground is a black hole: the shadow and the surface
   are the same darkness, so the toy affordance stops reading. The shadow follows
   --ink like everything else and is therefore light here, which keeps the
   gesture legible — the one place where "the shadow is ink" survives the swap
   because it was written as a token rather than as a hex. */