/* The CLI references hang their examples inside list items, so capping the
   list capped the block: the article widened and the commands did not. A
   container holding a block is not prose and takes the column. */

.vs-docs-article :is(ul, ol, li, dd):has(:is(.highlight, table.docutils)) {
  max-width: none;
}

/* Generated CLI references are lookup surfaces, not prose. The generator
   supplies this boundary so their dense hierarchy and parameter matrices do
   not leak into ordinary documentation tables. */
.vs-cli-reference > ul {
  columns: 2;
  column-gap: var(--space-8);
  padding: var(--space-4) var(--space-5);
  border-block: var(--border-hairline) solid var(--color-rule);
}

.vs-cli-reference > ul li {
  break-inside: avoid;
  font-family: var(--font-mono);
  font-size: var(--text-mono);
}

.vs-cli-reference h2:not(:first-of-type) {
  margin-top: var(--space-12);
  padding-top: var(--space-6);
  border-top: var(--border-hairline) solid var(--color-rule);
  font-family: var(--font-mono);
  font-weight: var(--weight-emphasis);
  font-variant-numeric: tabular-nums;
}

.vs-cli-reference h3 {
  margin-top: var(--space-6);
  font-family: var(--font-label);
  color: var(--color-ink-secondary);
  font-size: var(--text-label);
  font-weight: var(--text-label-weight);
  line-height: var(--text-label-line-height);
  letter-spacing: var(--ms-label-tracking);
}

.vs-cli-reference table.docutils {
  display: block;
  max-width: 100%;
  overflow-x: auto;
  font-size: var(--doc-table);
  font-variant-numeric: tabular-nums;
  scrollbar-color: var(--color-rule-strong) var(--color-paper-sunken);
}

.vs-cli-reference table.docutils th:nth-child(-n + 4),
.vs-cli-reference table.docutils td:nth-child(-n + 4) {
  white-space: nowrap;
}

.vs-cli-reference table.docutils th:first-child,
.vs-cli-reference table.docutils td:first-child {
  font-family: var(--font-mono);
}

@media (max-width: 48rem) {
  .vs-cli-reference > ul {
    columns: 1;
  }
}

/* ---- code -------------------------------------------------------------- */

/* The light syntax colours are Sphinx's own pygments.css, unscoped, which is
   also what a reader with scripting off gets. The dark half is generated by the
   build extension under [data-theme="dark"], so code follows the same control
   as the rest of the page rather than the operating system's preference. */

/* Sunken, not the page's own colour. A code block set in --color-mat was a
   hairline around nothing while the ground was flat; now that the ground
   carries a grid, the same rule punches an opaque rectangle through it and the
   block reads as a hole rather than as material. It is inlaid stock: cut into
   the mat, so it takes the sunken ground.

   This was briefly moved to --color-paper to give the blocks that are neither
   a command nor output a ground of their own. That token resolves to the same
   primitive as --color-mat, so the change restored the exact defect described
   above, on a ground that now carries a grid for it to punch through. The
   palette has no fourth value with room to be told apart: raised, mat and
   sunken sit inside 1.3:1 of each other, and anything mixed between them
   separates by 1.1. So there are two grounds, and the third distinction is
   carried where there is room for it - the edge and the ink. */

/* `div` earns its place here. Sphinx emits pygments-dark.css, and the theme
   links it after this file; its `[data-theme="dark"] .highlight` carries the
   same specificity as this rule did, so source order handed it the ground and
   every block without a role rule of its own - the config blocks, the document
   excerpts - was painted in that stylesheet's blue-black beside the warm blacks
   the rest of the page is built from. Naming the element outranks it without
   reaching the weight of the role rules below, which still override this. */

.vs-docs-article div.highlight {
  background: var(--color-paper-sunken);
  border: var(--border-hairline) solid var(--color-rule);
  border-radius: var(--radius-cut);
  margin: 0 0 var(--space-5);
  overflow-x: auto;
}

/* A command or config block gives its wrapper a full border (below), which
   traps this margin inside the box instead of letting it separate the block
   from what follows - the inner highlight rendered a blank inset at the
   bottom of the block and a 0px gap to the next paragraph. The margin
   belongs on the wrapper for those roles; this cancels the one above so it
   is never paid twice. */

.vs-docs-article :is(div.vs-block-command, div.vs-block-config, div.vs-block-output, div.vs-block-synopsis) {
  margin: 0 0 var(--space-5);
}

.vs-docs-article :is(div.vs-block-command, div.vs-block-config, div.vs-block-output, div.vs-block-synopsis) .highlight {
  margin: 0;
}

.vs-docs-article .highlight pre {
  margin: 0;
  padding: var(--space-4) var(--space-5);
  background: none;
  font-family: var(--font-mono);
  font-size: var(--doc-code);
  line-height: var(--doc-code-line-height);
  tab-size: 2;
}

/* Inline code sits inside a reading line, so it takes no border and only
   enough ground to separate it from the prose. */

.vs-docs-article code.literal,
.vs-docs-article p > code,
.vs-docs-article li > code,
.vs-docs-article td > code {
  padding: 0.1em 0.3em;
  background: var(--color-paper-sunken);
  border-radius: var(--radius-cut);
  font-family: var(--font-mono);

  /* Nine tenths of the line it sits in, but never under the floor.

     `0.9em` is a ratio, so it compounds with the context rather than resolving
     against the body. In a reading line that is right: 14.4px inside 16px prose
     keeps a mono face from out-sizing the text around it. In any of the site's
     13px contexts it is 11.7px, under the floor `--text-caption` declares for
     anything a visitor has to read, and those contexts hold the text that can
     least afford it - environment variable names and flags in table cells, and
     the commit hashes in the provenance notices, where one misread character is
     unrecoverable.

     This was first fixed by naming the contexts, which was the wrong shape: it
     caught tables and figcaptions and missed the notices, and it only worked on
     figcaptions because the code there happens to carry no class. `max()` states
     the rule itself instead - take the ratio, stop at the floor - so it holds in
     every 13px context on the site and in any added later. */
  font-size: max(0.9em, var(--text-caption));
  color: var(--color-ink);
}

/* Sphinx's own stylesheet forbids these from wrapping. `basic.css` carries
   `span.pre { white-space: nowrap; hyphens: none; }`, and every inline code
   token on the site is one of those spans - the tokens themselves hold no
   spaces, because Sphinx splits on them and emits one span per word.

   That is fine until a token is longer than the column. A hundred and
   thirty-six distinct inline tokens here run to twenty-eight characters or
   more, the longest sixty-nine:
   `vaultspec_rag.indexer._preprocess_schema.load_preprocess_invocation()`,
   and environment variable names like
   `VAULTSPEC_RAG_STORAGE_AUTOPRUNE_ARCHIVE_RETENTION_DAYS` in a list item
   on the configuration page. Forbidden to wrap and sitting in a paragraph
   rather than a block, they have no scroll container to fall into: they push
   the article column, and with it the page, wider than a narrow viewport. It
   is the one hole in this site's rule that anything wide gets its own
   scrollbar, because this is neither a block nor a table.

   `anywhere` rather than `break-word` because only `anywhere` reduces the
   element's min-content width, which is the measurement the parent uses when
   it decides how wide it has to be. `break-word` would let the glyphs wrap and
   still leave the column sized for the longest token.

   These spans never occur inside a code block - measured at zero of the
   eighteen hundred on the harness reference - so nothing here reaches a
   command line, which must keep scrolling sideways rather than break. */

.vs-docs-article code.literal span.pre,
.vs-docs-article p > code span.pre,
.vs-docs-article li > code span.pre,
.vs-docs-article td > code span.pre {
  white-space: normal;
  overflow-wrap: anywhere;
}

.vs-docs-article a code.literal {
  color: inherit;
}

/* Code retains its console voice inside titles without a prose-sized chip. */
.vs-docs-article :is(h1, h2, h3, h4, h5) code.literal {
  padding: 0;
  background: none;
  font-size: inherit;
  font-weight: var(--weight-emphasis);
}

/* Outrank both Pygments palettes, which request a bold cut we do not ship. */
.vs-docs-article div.highlight :is(
  .k, .kc, .kd, .kn, .kr, .o, .ow, .cp, .cs, .ges, .gh, .gp, .gs, .gu,
  .nc, .no, .nd, .ne, .nf, .ni, .nl, .nn, .nt, .fm, .se
) {
  font-weight: var(--weight-emphasis);
}

/* ---- captured output --------------------------------------------------- */

/* A `text` block on these pages is output a command printed, not something to
   type. It is drawn as a quieter recess than a command block so the eye can
   tell a line it should enter from a line it should expect back, without a
   label on either. The distinction is also load-bearing for the command gate,
   which reads only untagged and shell-tagged blocks as invocations. */

.vs-docs-article .highlight-text {
  --vs-output-edge: color-mix(in srgb, var(--color-rule) 60%, transparent);
}

.vs-docs-article .highlight-text .highlight {
  background: var(--color-paper-sunken);
  border-color: var(--vs-output-edge);
  border-left-width: var(--border-accent-edge);
  border-left-color: var(--color-edge);
}

.vs-docs-article .highlight-text pre {
  color: var(--color-ink-muted);
}

/* ---- light syntax colours ---------------------------------------------- */

/* Sphinx's stock light Pygments palette was chosen against white. This theme
   paints code blocks on the sunken ground, which is darker, and five of its
   colour families land under WCAG AA there: the operator grey at 4.30:1, the
   string blue at 3.89:1, the number green at 3.69:1, the comment teal at
   3.34:1, and the variable purple at 2.73:1. Three hundred text nodes across
   the rendered tree, none of them visible to a gate that only measured the
   marketing page.

   Each replacement is the same hue and saturation darkened until it clears
   4.5:1 against `--color-paper-sunken`, so the highlighting still reads as the
   same scheme rather than being re-picked. The dark half needs none of this:
   it is generated from the token layer already.

   Scoped with :not([data-theme="dark"]) rather than [data-theme="light"] so a
   reader with scripting off, who gets no attribute at all, is covered too. */

/* Scoped away from high-contrast as well as dark. `:not([data-theme="dark"])`
   matched it, so the light syntax palette painted on a near-black ground:
   `#606060` on `#050403` is about 3.2:1, under AA for code at this size. That
   theme is authored in the token layer and not reachable from the toggle, which
   is exactly why nothing caught it. */

:root:not([data-theme="dark"]):not([data-theme="high-contrast"]) .vs-docs-article .highlight .o {
  color: #606060;
}

:root:not([data-theme="dark"]):not([data-theme="high-contrast"]) .vs-docs-article .highlight :is(.s, .na, .sa, .sb, .sc, .dl, .sd, .s2, .se, .sh, .s1) {
  color: #39638d;
}

:root:not([data-theme="dark"]):not([data-theme="high-contrast"]) .vs-docs-article .highlight :is(.m, .mb, .mf, .mh, .mi, .mo, .il) {
  color: #1b6d44;
}

:root:not([data-theme="dark"]):not([data-theme="high-contrast"]) .vs-docs-article .highlight :is(.c, .ch, .cm, .cpf, .c1, .cs) {
  color: #346774;
}

:root:not([data-theme="dark"]):not([data-theme="high-contrast"]) .vs-docs-article .highlight :is(.nv, .vc, .vg, .vi, .vm) {
  color: #952fb3;
}

/* ---- derived block roles ----------------------------------------------- */

/* The authored pages say which blocks are captured output by fencing them
   `text`. The vendored pages cannot, so a build extension derives the same
   distinction from what each block contains and marks it with a class. Both
   routes land on the same two appearances, which is the point: a reader moving
   between an authored guide and an upstream page should not have to relearn
   what a recessed block means. */

/* The left mark moved off `--color-rule-strong` for the reason the synopsis
   rule below already gives: on the sunken ground it measured 1.55:1 in light
   and 2.19:1 in dark, under the 3:1 this system holds non-text marks to. That
   diagnosis was written here and then applied to one block; these are the other
   two it was always about - the captured-output family and the recording's
   transcript. `--color-edge` measures 3.00:1 and 3.94:1 on this ground. The
   light figure meets the floor exactly, which is the whole margin there is, and
   still beats a mark a reader has to hunt for. It stays outside the accent, so
   the grammar that says a green edge means you can take the block is
   untouched. */

.vs-docs-article .vs-block-output .highlight,
.vs-docs-article div.vs-block-output {
  background: var(--color-paper-sunken);
  border-color: color-mix(in srgb, var(--color-rule) 60%, transparent);
  border-left-width: var(--border-accent-edge);
  border-left-color: var(--color-edge);
}

.vs-docs-article .vs-block-output pre {
  color: var(--color-ink-muted);
}

/* A command block is left on the raised ground the theme already gives code,
   and marked only by an accent edge. Two recesses of different depth read as a
   hierarchy nobody meant; one recess and one edge reads as two kinds of thing. */

/* Two grounds and an edge: a command is raised, everything else is sunken, and
   what a sunken block is comes from its left edge and its ink. The first attempt at this put output
   on `--color-mat` and called it "a quieter recess" in a comment; measured
   against the command ground it was the lighter of the two, so the words
   described an effect the stylesheet did not produce and the distinction rested
   entirely on one accent hue and a text tint. It now rests on elevation as
   well, which survives a colour-blind reader and a bad panel. */

.vs-docs-article div.vs-block-command {
  background: var(--color-paper-raised);
  border-left: var(--border-accent-edge) solid var(--color-accent);
  border-radius: var(--radius-cut);
}

.vs-docs-article div.vs-block-command .highlight {
  background: transparent;
  border: 0;
}

/* The copy control sits inside the command block it copies.
   It is quiet until the block is hovered or something inside it takes focus,
   because a page of commands would otherwise carry a row of buttons competing
   with the commands themselves. It is never hidden from the keyboard: focus
   inside the block reveals it, and it is named in the site's focus-ring rule so
   tabbing to it shows an outline rather than moving to something invisible. */

.vs-docs-article .vs-block-command,
/* A file you paste somewhere is neither a command nor a capture, so it keeps
   the middle ground - but it is still something to take, which is why it has a
   copy control at all. The control only appears on hover, so before this rule
   the block carried no standing sign that it was copyable, and sat on exactly
   the ground of a listing that is not. The accent edge is the mark the command
   block already uses for "you can take this"; the ground underneath says which
   of the two kinds of thing it is. */
.vs-docs-article .vs-block-config {
  position: relative;
  /* The surround is the channel that tells this block from a command, and
     clearing the inner element took it away: both then carried one accent edge
     on grounds 1.180:1 apart in light and 1.124:1 in dark, which is no
     distinction at all on the reference pages where twenty configs sit beside
     two commands. A file is a bounded thing and a typed line is not, so the
     border says which - present or absent, not a colour, so it survives
     monochrome and both themes. The accent edge stays: both are still things
     you take away, and the dashed rule keeps meaning what it means on the
     synopsis rather than being spent here.

     It was drawn in the same 60% mix the output block frames itself with, which
     measures 1.147:1 against the mat in light and 1.225:1 in dark - present in
     the markup and invisible on the screen, so the distinction was declared and
     not delivered. `--color-edge` is 3.30:1 and 3.75:1 on that ground, the same
     value this file already proved twice. The output block's own surround is
     left at the faint mix on purpose: it frames a block that its ground, its
     ink and its left edge already tell apart, and a mark that carries no
     distinction has no floor to clear. This one carries the whole
     distinction. */
  border: var(--border-hairline) solid var(--color-edge);
  border-left: var(--border-accent-edge) solid var(--color-accent);
  border-radius: var(--radius-cut);
}

/* The comment above said this block keeps the middle ground, and until this
   rule it did not: the ground is painted on the inner `.highlight`, and command
   and synopsis each clear theirs so the wrapper's own ground shows through.
   Config had no such rule, so it fell through to the sunken fill and rendered
   as an output block with a green stripe - identical ground, 1:1, on the one
   pair the accent edge is supposed to tell apart - and carried that block's
   hairline inside its own border as well. Clearing it puts the file on the mat,
   which is what leaves elevation saying what kind of thing a block is and the
   edge saying whether you can take it.

   That moved a collision rather than removing one. On the mat, config and
   synopsis now share a ground exactly, and output and synopsis sit 1.101:1
   apart in light and 1.051:1 in dark while wearing the same solid grey edge.
   Config is still told apart by its accent edge; output and synopsis were not
   told apart by anything, which the rule below fixes. */

.vs-docs-article div.vs-block-config .highlight {
  background: transparent;
  border: 0;
}

/* A synopsis is the shape of a command, not one you can run: `install
   [OPTIONS] [PATH]` is a template whose brackets are for the reader to
   replace. The grammar the rest of the page teaches is that the accent edge
   means "you can take this" and elevation says what kind of thing it is, so a
   synopsis must not wear the accent edge - and until now it wore nothing at
   all, which left it looking like an oversight rather than a decision. It sits
   on the flat middle ground with a structural rule down its edge: the same
   gesture as its neighbours, in the one colour on the page that never means
   "take this". Deliberately absent from the copy-control selector above, so it
   is the only monospaced kind on the page with no way to copy it whole. */

/* Dashed, because the palette has no fourth ground to spend and this one does
   not need one. The dashed line already means one thing in this system - marked
   out but not yet cut - and that is what a synopsis is: the shape of a command
   rather than a command. It separates synopsis from output without a colour, so
   it survives dark, where their grounds are 1.051:1 apart, and monochrome,
   where nothing else here would.

   The colour is the other half of that, and the first pass got it wrong. Left
   in `--color-rule-strong`, the one mark carrying the distinction measured
   1.71:1 against the mat in light and 2.08:1 in dark - under the 3:1 this
   system holds non-text marks to, so the line was correct in style and too
   faint to read it by. `--color-edge` measures 3.30:1 and 3.75:1 on the same
   two grounds, stays outside the accent so it still never says "take this",
   and is already the colour this site pairs with a dashed rule for exactly
   this meaning on its scored notices. */

.vs-docs-article .vs-block-synopsis {
  border-left: var(--border-accent-edge) dashed var(--color-edge);
  border-radius: var(--radius-cut);
}

.vs-docs-article .vs-block-synopsis .highlight {
  background: transparent;
  border: 0;
}

/* A synopsis's brackets are notation, not operators. The dark palette draws
   operators in bold red, which on `[OPTIONS]` read as an error. */
.vs-docs-article .vs-block-synopsis .highlight .o {
  color: var(--color-ink-muted);
  font-weight: inherit;
}

/* Room for the control, so it never lands on the command.
   The button is absolutely positioned at the top right of the block while the
   <pre> reserved no space for it, so on a one-line block - which most command
   blocks are - it sat on the end of the line, and a long line scrolled beneath
   a fixed button. */

.vs-docs-article .vs-block-command pre,
.vs-docs-article .vs-block-config pre,
.vs-docs-article .vs-block-prompt pre {
  padding-right: var(--space-8);
}

/* A prompt is the third thing a reader takes away: words for their agent,
   where a command is a line for a shell and a config block a file for disk.
   The product is used this way more than any other, and its prompts were set
   as quotations - the one kind of thing to copy on the site with no plate and
   no control. It is raised and edged like a command, because it is typed, and
   set in the body face and allowed to wrap, because it is a sentence:
   monospace would say "shell" about something no shell should ever see. */

.vs-docs-article div.vs-block-prompt {
  position: relative;
  margin: 0 0 var(--space-3);
  background: var(--color-paper-raised);
  border-left: var(--border-accent-edge) solid var(--color-accent);
  border-radius: var(--radius-cut);
}

.vs-docs-article div.vs-block-prompt .highlight {
  margin: 0;
  background: transparent;
  border: 0;
}

.vs-docs-article .vs-block-prompt pre {
  font-family: var(--font-sans);
  font-size: var(--doc-body);
  line-height: var(--text-body-line-height);
  white-space: pre-wrap;
  overflow-wrap: anywhere;
  color: var(--color-ink);
}

.vs-docs-article .vs-copy {
  position: absolute;
  top: var(--space-2);
  right: var(--space-2);
  --control-font: var(--font-mono);
}

.vs-docs-article .vs-block-command:hover .vs-copy,
.vs-docs-article .vs-block-command:focus-within .vs-copy,
.vs-docs-article .vs-block-config:hover .vs-copy,
.vs-docs-article .vs-block-config:focus-within .vs-copy,
.vs-docs-article .vs-block-prompt:hover .vs-copy,
.vs-docs-article .vs-block-prompt:focus-within .vs-copy {
  --control-ground: var(--interaction-ground-hover);
  --control-edge: var(--interaction-edge);
}

/* The text of a terminal capture that ships as a picture. The four on this
   site are the only content images it has, and they are evidence: what the
   readiness report prints, what a search returns. Inside an `img` that text
   is not in the accessibility tree, so the transcript is emitted beside each
   one and folded away, closed by default because a reader who can see the
   picture already has it.

   Opened, it is output and is dressed as output: the same sunken ground and
   neutral edge every captured block gets, so the eye reads it as a record of
   a run rather than as something to type. Its ink is inherited rather than
   set: a closed disclosure is display:none to the contrast gate, which skips
   it, so a colour declared here would be the one text on the site nothing
   measures. The body ink is measured on thirteen pages. */

.vs-docs-article .vs-term-transcript {
  margin: var(--space-2) 0 0;
}

.vs-docs-article .vs-term-transcript summary {
  color: var(--color-ink-muted);
  font-size: var(--text-meta);
  line-height: var(--text-meta-line-height);
  cursor: pointer;
}

.vs-docs-article .vs-term-transcript summary:hover {
  color: var(--color-ink);
}

.vs-docs-article .vs-term-transcript summary:focus-visible {
  outline: var(--focus-ring-width) solid var(--focus-ring-color);
  outline-offset: var(--focus-ring-offset);
}

.vs-docs-article .vs-term-transcript pre {
  margin: var(--space-2) 0 0;
  border: var(--border-hairline) solid
    color-mix(in srgb, var(--color-rule) 60%, transparent);
  border-left: var(--border-accent-edge) solid var(--color-edge);
  border-radius: var(--radius-cut);
  background: var(--color-paper-sunken);
  padding: var(--space-3);
  overflow-x: auto;
  font-family: var(--font-mono);
  font-size: var(--doc-code);
  line-height: var(--doc-code-line-height);
}