/* ============================================================================
   docs.css — the Documentation page
   ============================================================================

   Loaded by the twenty-three documents in public/docs/. Nothing else on the
   site links to these class names, and the .dx- prefix is here so that stays
   true by accident as well as on purpose — a rule in this file cannot collide
   with .pa- (product articles), .pr- (products index) or the shared chrome in
   site.css.

   WHY THIS PAGE IS SHAPED THE WAY IT IS

   The brief was "laid out like Polymarket's docs, in the RMS theme". What that
   layout actually is, underneath the styling, is three columns that answer
   three different questions at the same time:

     left   — where am I in the whole product?     (persistent, never scrolls away)
     centre — what am I reading?                    (the only column that owns the page)
     right  — where am I inside this one page?      (jump targets for the section)

   The reason it works for documentation specifically is that a reader arriving
   from a search engine lands in the middle of the middle column with no idea
   what surrounds them. The left column is the recovery: it shows the whole map
   with their position marked, so a deep link is never a dead end. That is worth
   240px of permanent screen space, and it is why the left column is sticky
   rather than something you scroll back up to find.

   A PAGE PER TOPIC

   This was one document with twenty-three sections, and the note that used to
   sit here argued for keeping it that way. The split happened anyway, and the
   reason the old argument lost is worth recording so it is not re-litigated.

   The case for one file was find-in-page and cheap maintenance. The case
   against it was that the two navigation columns were describing the same
   thing. The left column said "you are in Authentication" and the right column
   said "you are at Refresh rotation" — both were positions inside one
   document, so the left column was doing a job the right column already did
   better, and neither answered "where am I in the product". Split into a page
   per section, each column gets its own question back:

     left   — which topic, out of all of them?   (unchanged as you scroll)
     centre — the topic                           (one section, start to end)
     right  — where in this topic?                (this page's h3s)

   What the split cost, and how each cost is paid:

     - find-in-page now searches one topic instead of the whole guide. The
       sidebar is the replacement and it is a better one for a reference, where
       a reader is looking for a named endpoint rather than a phrase.
     - the chrome is copied twenty-three times. Header, drawer, sidebar and
       footer are identical in every file and there is no build step to keep
       them that way. This is the real ongoing cost. If it starts to hurt, the
       fix is a partial-assembly script, not a return to one file.
     - reading in order needs the pager at the foot of each page, because the
       next topic is no longer the next thing on screen. See .dx-pager below.

   IDS ARE THE CONTRACT. Every id survived the split unchanged, and index.html
   carries a redirect map from the old "/docs/#authentication" form to the new
   page. External links and support replies point at ids; they are the one part
   of this file's structure that is not ours to renumber.

   WHAT THE THEME CONTRIBUTES

   Nothing here invents a colour, a font or a spacing value. Everything is a
   token from site.css :root. Documentation is the surface where a house style
   is most tempted to drift — it is "just text", it is written in a hurry, and
   it is usually somebody else's template. Drift here is the reader's first
   evidence that the product is assembled from parts.

   The one place this page speaks a second language is the plan chips, which
   use the same three hues as the pricing grid and the product articles: Basic
   cyan, Premium amber, Unlimited violet. A reader who has learned that key
   anywhere else on the site should not have to relearn it here, and a docs
   section for a feature they cannot use yet should say so in the colour they
   already associate with the plan that unlocks it.
   ============================================================================ */


/* ── the page frame ──────────────────────────────────────────────────────────

   .dx-shell is wider than the site's .shell (1240px). Three columns at the
   site width would leave the prose column around 600px, which is fine for
   reading and bad for the tables — a device-form field reference has four
   columns and wraps into unreadable stacks below about 680px.

   1560px is not a round number chosen for looks: it is 240 (nav) + 200 (toc) +
   two 56px gutters + a 900px content column, which is the widest the prose can
   get before .dx-doc's own max-width takes over and starts leaving the line
   length alone. Past that the columns just drift apart on a large monitor. */
.dx-shell{ width:100%; max-width:1560px; margin-inline:auto; padding-inline:var(--gut); }

/* The top offset clears the sticky .nav bar, which this page keeps. The product
   articles dropped their bar and had to drop this offset with it; docs are the
   opposite case — a reader here is mid-task and much more likely to want to get
   back to Pricing or Get Started without hunting for the footer. */
.dx-wrap{ padding:calc(64px + clamp(28px,3.5vw,44px)) 0 clamp(70px,9vw,110px); }

.dx-grid{
  display:grid;
  grid-template-columns:240px minmax(0,1fr) 200px;
  gap:clamp(32px,4vw,56px);
  align-items:start;
}


/* ── masthead ────────────────────────────────────────────────────────────────
   Spans all three columns so the title is measured against the page rather
   than against the prose column, which would leave it looking indented. */
.dx-head{ grid-column:1 / -1; margin:0 0 clamp(30px,4vw,44px); }
.dx-head h1{
  font-family:var(--display); font-variation-settings:"wdth" 108,"wght" 760;
  font-size:clamp(34px,4.6vw,54px); line-height:1.02; letter-spacing:-.02em;
  margin:0 0 14px; color:var(--bone);
}
.dx-head p{
  margin:0; max-width:62ch; font-size:clamp(15px,1.5vw,17px);
  line-height:1.65; color:var(--ash);
}
.dx-head .eyebrow{ margin-bottom:18px; }


/* ── left column: the map ────────────────────────────────────────────────────

   position:sticky with its own overflow. The height is the viewport minus the
   nav bar minus a breath, so on a short screen the sidebar scrolls internally
   instead of the page having to scroll to reach the bottom of the map. Without
   the max-height a long nav simply runs past the fold and the last few groups
   become unreachable while the sidebar is pinned.

   overscroll-behavior:contain stops a scroll that bottoms out inside the
   sidebar from grabbing the page and throwing the reader somewhere else — the
   single most irritating behaviour a sticky sidebar can have. */
.dx-nav{
  position:sticky; top:96px;
  max-height:calc(100vh - 120px);
  overflow-y:auto; overscroll-behavior:contain;
  padding-right:8px;
  scrollbar-width:thin; scrollbar-color:var(--edge) transparent;
}
.dx-nav::-webkit-scrollbar{ width:6px; }
.dx-nav::-webkit-scrollbar-thumb{ background:var(--edge); }

.dx-nav-group + .dx-nav-group{ margin-top:26px; }
.dx-nav-group h4{
  font-family:var(--mono); font-size:10px; letter-spacing:.2em; text-transform:uppercase;
  color:var(--ash-dim); margin:0 0 10px; font-weight:400;
}
.dx-nav ul{ list-style:none; margin:0; padding:0; display:grid; gap:2px; }

/* The 1px left border is the active indicator's track. It is always present
   and always --edge, so when a link becomes current the colour changes but
   nothing moves — a border that appears on activation shifts every label 11px
   to the right and makes the whole column twitch as you scroll. */
.dx-nav a{
  display:block; padding:5px 0 5px 11px;
  border-left:1px solid var(--edge);
  font-size:13.5px; line-height:1.45; color:var(--ash);
  text-decoration:none; transition:color .16s ease, border-color .16s ease;
}
.dx-nav a:hover{ color:var(--bone); border-left-color:var(--ash-dim); }
/* "page", not "true". The left column navigates between documents now rather
   than within one, so the current entry is the current *page* — which is the
   value assistive technology looks for, and the one that stops a screen reader
   announcing the link as somewhere else the reader could go. */
.dx-nav a[aria-current="page"]{
  color:var(--arc); border-left-color:var(--arc);
}


/* ── right column: the section's own contents ────────────────────────────────
   Same sticky treatment, no internal scroll — a single section never has
   enough headings to need one, and a scrollbar on a six-item list looks broken. */
.dx-toc{ position:sticky; top:96px; }
.dx-toc h4{
  font-family:var(--mono); font-size:10px; letter-spacing:.2em; text-transform:uppercase;
  color:var(--ash-dim); margin:0 0 10px; font-weight:400;
}
.dx-toc ul{ list-style:none; margin:0; padding:0; display:grid; gap:7px; }
.dx-toc a{
  font-size:12.5px; line-height:1.45; color:var(--ash-dim);
  text-decoration:none; transition:color .16s ease;
}
.dx-toc a:hover{ color:var(--bone); }
.dx-toc a[aria-current="true"]{ color:var(--bone); }


/* ── centre column: prose ────────────────────────────────────────────────────

   scroll-margin-top is the nav bar plus a breath. Every sidebar click and every
   inbound deep link lands via a fragment, so this one value decides where
   essentially every arrival on this page comes to rest. site.css sets
   scroll-padding-top:80px globally, which handles the smooth-scroll case; this
   covers scrollIntoView and the initial load, which do not read it. */
.dx-doc{ max-width:900px; min-width:0; }
.dx-sec{ scroll-margin-top:96px; margin:0 0 clamp(44px,5.5vw,68px); }

/* The .is-group rules that used to live here drew a divider above the first
   section of each sidebar group. A page holds one section now, so the group
   boundary is a page boundary and there is nothing left to divide. */


/* ── the pager ───────────────────────────────────────────────────────────────

   Previous / Next at the foot of every page. This is the piece that a split
   reference cannot do without: on one long page the next topic was the next
   thing on screen, and a reader who wanted the whole guide simply kept
   scrolling. Cutting the page into twenty-three removes that, and without a
   pager the only way onward is to go back to the sidebar and work out which
   entry you had just finished — the reader has to hold the running order in
   their head to read in order.

   Both slots are always rendered. On the first and last pages one of them is
   an empty span rather than an omitted element, so the surviving link stays on
   its own side instead of sliding across the grid — Next on the first page
   should be on the right, where every other page has trained the reader to
   look for it. */
.dx-pager{
  display:grid; grid-template-columns:1fr 1fr; gap:16px;
  margin-top:clamp(48px,6vw,72px);
  padding-top:clamp(28px,3.5vw,40px);
  border-top:1px solid var(--edge);
}
.dx-pager-a{
  display:flex; flex-direction:column; gap:6px;
  padding:16px 18px;
  border:1px solid var(--edge); border-radius:2px;
  text-decoration:none; background:var(--graphite);
  transition:border-color .16s ease, background .16s ease;
}
.dx-pager-a.is-next{ text-align:right; }
/* Placeholder for the missing side. Invisible and not focusable, but it still
   occupies its grid cell. */
.dx-pager-a.is-empty{ border:0; background:none; pointer-events:none; }
.dx-pager-a:hover{ border-color:var(--ash-dim); background:var(--graphite-hi,var(--graphite)); }
.dx-pager-k{
  font-family:var(--mono); font-size:10px; letter-spacing:.2em;
  text-transform:uppercase; color:var(--ash-dim);
}
.dx-pager-a b{
  font-size:15px; line-height:1.35; color:var(--bone); font-weight:600;
}
.dx-pager-a:hover b{ color:var(--arc); }

@media (max-width:640px){
  .dx-pager{ grid-template-columns:1fr; }
  /* The empty slot has nothing to align against once the columns collapse, and
     an invisible box between the divider and the footer just adds a gap. */
  .dx-pager-a.is-empty{ display:none; }
  .dx-pager-a.is-next{ text-align:left; }
}

.dx-doc h2{
  font-family:var(--display); font-variation-settings:"wdth" 106,"wght" 720;
  font-size:clamp(24px,2.8vw,32px); line-height:1.12; letter-spacing:-.015em;
  margin:0 0 16px; color:var(--bone);
}
.dx-doc h3{
  font-family:var(--display); font-variation-settings:"wdth" 104,"wght" 660;
  font-size:clamp(17px,1.9vw,20px); line-height:1.25;
  margin:32px 0 12px; color:var(--bone);
}
.dx-doc h3:first-of-type{ margin-top:24px; }
.dx-doc p{ margin:0 0 14px; font-size:15px; line-height:1.72; color:var(--ash); }
.dx-doc p:last-child{ margin-bottom:0; }
.dx-doc strong{ color:var(--bone); font-weight:600; }
.dx-doc a:not(.btn):not(.dx-anchor){
  color:var(--arc); text-decoration:none;
  border-bottom:1px solid color-mix(in srgb, var(--arc) 34%, var(--void));
  transition:border-color .16s ease;
}
.dx-doc a:not(.btn):not(.dx-anchor):hover{ border-bottom-color:var(--arc); }

.dx-doc ul, .dx-doc ol{ margin:0 0 16px; padding-left:20px; }
.dx-doc li{ font-size:15px; line-height:1.72; color:var(--ash); margin-bottom:7px; }
.dx-doc li::marker{ color:var(--ash-dim); }
.dx-doc li > strong:first-child{ color:var(--bone); }

/* Inline code. Not a pill — square, like everything else that is not a .btn.
   The background is mixed into --graphite rather than laid over the page with
   alpha, because these sit inside table cells and callouts that are already a
   different colour and a translucent chip would show whatever is underneath. */
.dx-doc code{
  font-family:var(--mono); font-size:.86em;
  background:var(--graphite); border:1px solid var(--edge);
  padding:1px 5px; color:var(--bone);
}


/* ── the anchor affordance ───────────────────────────────────────────────────
   A "#" that appears on hover and copies nothing — it is a real link to the
   heading's own id, so right-click-copy and plain clicking both work, and the
   URL bar updates. Support replies live or die on being able to send somebody
   a link to one paragraph.

   It is positioned in the heading's left margin on wide screens so it never
   reflows the text, and it is hidden below that width because there is no
   margin to put it in and no hover to reveal it. */
.dx-h{ position:relative; }
.dx-anchor{
  position:absolute; left:-24px; top:0;
  color:var(--ash-dim); text-decoration:none;
  opacity:0; transition:opacity .16s ease, color .16s ease;
  font-family:var(--mono); font-weight:400;
}
.dx-h:hover .dx-anchor{ opacity:1; }
.dx-anchor:hover{ color:var(--arc); }
.dx-anchor:focus-visible{ opacity:1; }


/* ── callouts ────────────────────────────────────────────────────────────────
   Two only. A documentation page that offers note / tip / info / warning /
   danger / caution ends up using them decoratively, and once a reader has
   scrolled past four coloured boxes that said nothing urgent they stop reading
   the fifth, which is the one about de-energising the equipment.

   .dx-note  — you would not have guessed this, and it will save you time.
   .dx-warn  — doing this wrong produces a wrong document.

   The left border does the identifying. No icons: an icon set is a second
   vocabulary to learn and the first word of each callout already says which
   kind it is. */
.dx-call{
  border:1px solid var(--edge); border-left:2px solid var(--ash-dim);
  background:var(--graphite);
  padding:clamp(14px,1.8vw,18px) clamp(16px,2vw,22px);
  margin:0 0 18px;
}
.dx-call p{ margin:0 0 10px; font-size:14px; }
.dx-call p:last-child{ margin-bottom:0; }
.dx-call b{
  display:block; font-family:var(--mono); font-size:10px;
  letter-spacing:.18em; text-transform:uppercase; margin-bottom:8px; font-weight:400;
}
.dx-note{ border-left-color:var(--plasma); }
.dx-note b{ color:var(--plasma); }
.dx-warn{ border-left-color:var(--arc); }
.dx-warn b{ color:var(--arc); }


/* ── code blocks ─────────────────────────────────────────────────────────────

   These hold real, runnable requests and real response bodies. That is the
   whole point of the page: a reader who wants to be told what a feature is has
   the marketing site, and a reader who wants to be walked through the UI has
   the app itself. What neither of those can give them is the exact bytes to put
   on the wire, so that is what lives here.

   HIGHLIGHTING IS HAND-APPLIED, AND THAT IS DELIBERATE

   There is no highlighter library and no build step. Every span in every block
   below was written by hand into the HTML. That sounds like a maintenance
   burden and it is a small one, but the alternative is worse in three ways:
   a highlighter is 40-200KB of JavaScript on a page whose entire premise is
   that it must work when things are broken; it re-tokenises on load, so the
   code flashes unstyled first; and it would be the only thing on this site that
   needs a bundler.

   The palette is five classes and no more. A highlighter would give us twenty,
   and twenty colours on a dark background is a stained-glass window that the
   eye stops parsing. These five each answer a question the reader is actually
   asking:

     .c  comment / prose annotation      — "this line is me talking, not code"
     .k  keyword, field name, JSON key   — "this is structure"
     .v  value you should look at        — "this is the interesting part"
     .s  string literal                  — "these characters are data"
     .m  method verb or numeric literal  — "GET/POST, 200, 403"

   A token that does not clearly belong to one of the five is left unstyled in
   --bone. Unstyled is a legitimate answer; guessing is not. */
.dx-code{
  border:1px solid var(--edge); background:var(--graphite);
  margin:0 0 18px;
}
.dx-code pre{
  margin:0; padding:clamp(14px,1.8vw,18px) clamp(16px,2vw,20px);
  font-family:var(--mono); font-size:12.5px; line-height:1.75;
  color:var(--bone); white-space:pre; overflow-x:auto;
}
.dx-code .c{ color:var(--ash-dim); }        /* a comment or an annotation */
.dx-code .k{ color:var(--plasma); }         /* a key, a field name */
.dx-code .v{ color:var(--arc); }            /* a value worth looking at */
.dx-code .s{ color:#8FBF9F; }               /* a string literal */
.dx-code .m{ color:var(--ion); }            /* an HTTP verb or a number */

/* The label bar names the file or the shape ("Response 200", "curl"). It is
   optional: a block with nothing worth naming does not get one, rather than
   getting one that says "code". */
.dx-code-bar{
  display:flex; align-items:center; justify-content:space-between; gap:12px;
  padding:8px clamp(16px,2vw,20px); border-bottom:1px solid var(--edge);
  font-family:var(--mono); font-size:10px; letter-spacing:.16em;
  text-transform:uppercase; color:var(--ash-dim);
}

/* Copy button. Progressive enhancement in the strictest sense: it is not in
   the HTML at all, it is created by docs.js, and only when the browser
   actually has navigator.clipboard. A button that is present but does nothing
   is worse than no button, because the reader believes the copy happened and
   pastes whatever was in the clipboard before. */
.dx-copy{
  border:1px solid var(--edge); background:var(--steel); color:var(--ash);
  padding:3px 9px; cursor:pointer;
  font-family:var(--mono); font-size:9.5px; letter-spacing:.16em;
  text-transform:uppercase;
  transition:color .16s ease, border-color .16s ease;
}
.dx-copy:hover{ color:var(--bone); border-color:var(--ash-dim); }
.dx-copy[data-done]{ color:var(--arc); border-color:var(--arc-dim); }


/* ── language tabs ───────────────────────────────────────────────────────────

   Every request on this page is shown as curl, TypeScript and Python. Three,
   not one, because the three readers of an API reference arrive with different
   questions: curl answers "what is actually on the wire", and the two languages
   answer "what do I paste into my file".

   WHY THE MARKUP IS RADIOS AND NOT BUTTONS

   The tab strip is a set of <input type="radio"> with <label>s, one group per
   block. That gives keyboard arrow-key navigation, focus, and the selected
   state for free and correct, from the platform, rather than from a roving
   tabindex implementation that would be the most bug-prone thing on the page.

   It also means the tabs work with JavaScript disabled or broken. docs.js adds
   exactly one behaviour on top: choosing a language in one block chooses it in
   every block, and remembers the choice. That is a real improvement — without
   it a reader picks Python nine times on the way down the page — but it is an
   improvement to something that already works, which is the rule for
   everything on this page.

   The panels are shown by the :checked sibling selector, so the CSS is the
   source of truth for which one is visible and no script can leave the block
   with nothing showing.

   WHY THE THREE ELEMENT TYPES ARE INTERLEAVED AND THEN RE-ORDERED

   Markup order inside .dx-tabs is input, label, panel, input, label, panel —
   the label immediately after its input, and the panel immediately after its
   label. That is forced by the selectors: `input:checked + label` and
   `input:checked + label + .dx-tabpanel` are adjacent-sibling combinators, so
   they only work if the three really are adjacent. The obvious alternative —
   a <div class="dx-tabbar"> holding all the labels — puts the labels one level
   down and breaks both.

   Visually the labels still need to sit in one row above the panels, so the
   container is a wrapping flexbox and `order` does the arranging: labels take
   order:1, panels order:2, and every panel is width:100% so it forces its own
   line. The result is a tab strip that is a row on screen and a correct
   sibling chain in the DOM, with no JavaScript deciding either. */
.dx-tabs{
  display:flex; flex-wrap:wrap;
  border:1px solid var(--edge); background:var(--graphite); margin:0 0 18px;
}
.dx-tabs > input{ position:absolute; opacity:0; pointer-events:none; }
.dx-tabs > label{
  order:1; padding:9px 16px; cursor:pointer; white-space:nowrap;
  font-family:var(--mono); font-size:10px; letter-spacing:.16em;
  text-transform:uppercase; color:var(--ash-dim);
  border-bottom:1px solid var(--edge);
  transition:color .16s ease, border-color .16s ease;
}
.dx-tabs > label:hover{ color:var(--ash); }
/* The focus ring is on the label, not the visually-hidden input, so tabbing
   into the group shows where you are. */
.dx-tabs > input:focus-visible + label{ outline:1px solid var(--plasma); outline-offset:-3px; }
.dx-tabs > input:checked + label{ color:var(--arc); border-bottom-color:var(--arc); }
/* Carries the strip's rule across whatever width the labels did not use. It is
   a flex item on the label row (order:1) that grows to fill it — the only way
   to draw that line, since with flex-wrap there is no element wrapping the
   label row that could own a border. */
.dx-tabs::after{ content:""; order:1; flex:1 1 0; border-bottom:1px solid var(--edge); }
.dx-tabpanel{ order:2; width:100%; display:none; min-width:0; }
.dx-tabs > input:checked + label + .dx-tabpanel{ display:block; }
/* A code block inside a tab panel has already been framed by .dx-tabs, so it
   drops its own border and bottom margin. Without this every tabbed example
   would have a double rule down both sides. */
.dx-tabpanel .dx-code{ border:0; margin:0; background:transparent; }


/* ── endpoint signature ──────────────────────────────────────────────────────

   The one-line "GET /db/projects" header that opens each endpoint. It is a
   heading in every sense except the markup — it is a <div>, because the h3s on
   this page are what the right-hand contents column is built from, and a
   reference section with eleven endpoints would push eleven near-identical
   lines into a column that is meant to be scannable.

   The method verb is coloured by safety, which is the only property of an HTTP
   verb a reader needs at a glance: green reads, amber writes, violet mutations
   in place, red destroys. */
.dx-ep{
  display:flex; align-items:center; gap:12px; flex-wrap:wrap;
  border:1px solid var(--edge); background:var(--steel);
  padding:10px 14px; margin:0 0 14px;
  font-family:var(--mono); font-size:13px;
}
.dx-ep .verb{
  font-size:10px; letter-spacing:.16em; padding:3px 8px;
  border:1px solid currentColor; flex:none;
}
.dx-ep[data-verb="GET"]    .verb{ color:#8FBF9F; }
.dx-ep[data-verb="POST"]   .verb{ color:var(--arc); }
.dx-ep[data-verb="PUT"]    .verb,
.dx-ep[data-verb="PATCH"]  .verb{ color:var(--ion); }
.dx-ep[data-verb="DELETE"] .verb{ color:#D9705A; }
.dx-ep .path{ color:var(--bone); word-break:break-all; }
/* Path parameters are dimmed inside the path so {pid} reads as a slot rather
   than as a literal segment someone might type. */
.dx-ep .path em{ color:var(--plasma); font-style:normal; }
/* Pushed to the far end: "requires Unlimited", "no auth". */
.dx-ep .note{
  margin-left:auto; font-size:10px; letter-spacing:.14em;
  text-transform:uppercase; color:var(--ash-dim);
}


/* ── section subtitle ────────────────────────────────────────────────────────
   One line under an h2 saying what the section covers, in the sidebar's voice
   rather than the prose's. It is the same sentence that would be the page
   description if this were twenty-eight pages instead of one, which is where
   the convention comes from. */
.dx-sub{
  margin:-6px 0 20px; font-size:14.5px; line-height:1.6;
  color:var(--ash-dim); max-width:62ch;
}


/* ── next-steps cards ────────────────────────────────────────────────────────
   Closes a group with two or three onward links. Not decoration: a single-page
   reference has no "next page" button, so without these the end of a group is
   a reader sitting at the bottom of a section with the sidebar as their only
   way forward. Two columns, because three across 900px gives titles that wrap
   mid-word. */
.dx-cards{
  display:grid; grid-template-columns:repeat(auto-fit,minmax(240px,1fr));
  gap:14px; margin:22px 0 0;
}
.dx-card{
  display:block; border:1px solid var(--edge); background:var(--graphite);
  padding:16px 18px; text-decoration:none;
  transition:border-color .16s ease, background .16s ease;
}
/* Overrides the underline that .dx-doc puts on every other link in the column:
   the whole card is the target, so a rule under the title would be a second,
   smaller-looking target inside it. */
.dx-doc a.dx-card{ border-bottom:1px solid var(--edge); }
.dx-doc a.dx-card:hover{
  border-color:var(--ash-dim); background:var(--steel);
}
.dx-card b{
  display:block; font-family:var(--display); font-size:14.5px;
  font-weight:600; color:var(--bone); margin-bottom:5px;
}
.dx-card span{ display:block; font-size:13px; line-height:1.6; color:var(--ash-dim); }


/* ── field-reference tables ──────────────────────────────────────────────────
   The densest thing on the page and the reason the content column is 900px.
   Header row is mono and uppercase so it reads as a label rather than as a
   first row of data. */
.dx-tw{ overflow-x:auto; margin:0 0 18px; }
.dx-table{ width:100%; border-collapse:collapse; min-width:520px; }
.dx-table th{
  text-align:left; font-family:var(--mono); font-size:10px;
  letter-spacing:.16em; text-transform:uppercase; color:var(--ash-dim);
  font-weight:400; padding:0 16px 9px 0; border-bottom:1px solid var(--edge);
}
.dx-table td{
  padding:11px 16px 11px 0; border-bottom:1px solid var(--steel);
  font-size:13.5px; line-height:1.6; color:var(--ash); vertical-align:top;
}
.dx-table tr:last-child td{ border-bottom:0; }
.dx-table td:first-child{ color:var(--bone); white-space:nowrap; }
.dx-table td code{ white-space:nowrap; }


/* ── numbered procedure ──────────────────────────────────────────────────────
   Counter rather than <ol> markers because the number needs to be mono, sized
   independently of the text, and aligned to the first line of a step that may
   run to three lines. ::marker cannot be positioned. */
.dx-steps{ list-style:none; margin:0 0 18px; padding:0; counter-reset:dxs; }
.dx-steps > li{
  counter-increment:dxs; position:relative;
  padding-left:36px; margin-bottom:16px;
  font-size:15px; line-height:1.72; color:var(--ash);
}
.dx-steps > li::before{
  content:counter(dxs,decimal-leading-zero);
  position:absolute; left:0; top:1px;
  font-family:var(--mono); font-size:11px; letter-spacing:.08em;
  color:var(--arc);
}
.dx-steps > li:last-child{ margin-bottom:0; }


/* ── plan chips ──────────────────────────────────────────────────────────────
   The site's colour key, restated. Square, mono, and carrying a small filled
   square in the tier's hue — identical in construction to the chips on the
   product articles' fact column so the two never look like different systems. */
.dx-plan{
  display:inline-flex; align-items:center; gap:7px;
  border:1px solid var(--edge); background:var(--graphite);
  padding:4px 10px; margin:0 6px 10px 0;
  font-family:var(--mono); font-size:10px; letter-spacing:.16em;
  text-transform:uppercase; color:var(--ash); vertical-align:middle;
}
.dx-plan::before{ content:""; width:6px; height:6px; background:var(--pc,var(--ash)); flex:none; }
.dx-plan[data-tier="basic"]    { --pc:var(--plasma); color:var(--plasma); border-color:color-mix(in srgb, var(--plasma) 30%, var(--edge)); }
.dx-plan[data-tier="premium"]  { --pc:var(--arc);    color:var(--arc);    border-color:color-mix(in srgb, var(--arc) 30%, var(--edge)); }
.dx-plan[data-tier="unlimited"]{ --pc:var(--ion);    color:var(--ion);    border-color:color-mix(in srgb, var(--ion) 30%, var(--edge)); }

/* Sits directly under an h2/h3 to say which plan the feature needs. The
   negative top margin pulls it up against the heading it belongs to, because
   at default flow spacing it reads as belonging to the paragraph below. */
.dx-planrow{ margin:-6px 0 16px; }


/* ── in-app location breadcrumb ──────────────────────────────────────────────
   "Where this lives in the app." Almost every support question is really this
   question, so it gets a consistent object rather than being written into the
   prose differently every time. The › separators are content, not borders,
   because the whole string should survive being copy-pasted into a reply. */
.dx-where{
  display:block; font-family:var(--mono); font-size:11px; letter-spacing:.06em;
  color:var(--ash-dim); margin:0 0 16px;
}
.dx-where b{ color:var(--bone); font-weight:400; }


/* ── mobile ──────────────────────────────────────────────────────────────────

   Below 1100px the right column goes first. It is the least valuable of the
   three on a narrow screen: it duplicates headings the reader is about to
   scroll past anyway, and unlike the left column it cannot take them anywhere
   they could not already get to.

   Below 900px the left column stops being a column. It does NOT become a
   drawer — the page already has one drawer behind the burger, and a second
   panel that opens from a different edge with a different set of links is two
   navigations for the reader to hold at once. It becomes a plain disclosure at
   the top of the page, marked up as <details> so the open/closed state costs
   no JavaScript.

   It should start closed here — twenty-nine links between the title and the
   first paragraph is a wall — but `open` is a boolean attribute and CSS cannot
   set it per breakpoint. The markup ships `open` because that is the state
   desktop needs, and js/docs.js clears it below this width. So the closed
   default is a scripted behaviour, not a styled one: with JavaScript off, a
   narrow reader gets the list expanded. Verbose, still completely usable, and
   the right direction to fail in. */
@media (max-width:1100px){
  .dx-grid{ grid-template-columns:240px minmax(0,1fr); }
  .dx-toc{ display:none; }
}

@media (max-width:900px){
  .dx-grid{ grid-template-columns:minmax(0,1fr); gap:0; }

  .dx-nav{
    position:static; max-height:none; overflow:visible;
    border:1px solid var(--edge); background:var(--graphite);
    margin:0 0 clamp(30px,4vw,40px); padding:0;
  }
  /* The <details> chrome. On wide screens the same element is a bare column,
     so every one of these has to be neutralised above rather than added here —
     which is why the summary is display:none by default further down. */
  .dx-nav > summary{
    display:flex; align-items:center; justify-content:space-between;
    padding:14px 18px; cursor:pointer; list-style:none;
    font-family:var(--mono); font-size:11px; letter-spacing:.16em;
    text-transform:uppercase; color:var(--bone);
  }
  .dx-nav > summary::-webkit-details-marker{ display:none; }
  .dx-nav > summary::after{ content:"+"; color:var(--ash-dim); font-size:14px; }
  .dx-nav[open] > summary::after{ content:"−"; }
  .dx-nav[open] > summary{ border-bottom:1px solid var(--edge); }
  .dx-nav-inner{ padding:18px; }
  .dx-nav-group{ break-inside:avoid; }
  .dx-nav-inner{ columns:2; column-gap:24px; }
  .dx-nav-group + .dx-nav-group{ margin-top:20px; }
}

/* The disclosure summary only exists as a control on narrow screens. On wide
   screens <details> is forced open by the markup's `open` attribute and this
   hides the toggle, so the same element serves both layouts without a
   duplicate copy of twenty-eight links in the HTML. */
@media (min-width:901px){
  .dx-nav > summary{ display:none; }

  /* Above this width the disclosure state is not just irrelevant, it is
     dangerous. The summary is hidden here, so if the element were ever closed
     on a wide screen the reader would get an empty 240px column and no control
     anywhere on the page to reopen it.

     That is a reachable state, not a hypothetical one: a reader collapses the
     panel on a phone, rotates to landscape or casts to a larger display, and
     the `open` attribute is still false. Leaving it to js/docs.js to notice the
     breakpoint change is exactly the sort of thing that works until the script
     is slow, blocked, or the media-query event does not fire.

     So the column is forced visible by CSS and the attribute is overruled. The
     `display:block` on the content is the part that actually matters — a
     closed <details> hides its non-summary children — and the one on the
     element itself stops the collapsed details from contributing zero height
     to the grid row. */
  .dx-nav{ display:block; }
  .dx-nav:not([open]) > .dx-nav-inner{ display:block; }
}

@media (max-width:640px){
  .dx-nav-inner{ columns:1; }
  .dx-anchor{ display:none; }
  .dx-doc h3{ margin-top:26px; }
}