@writedocs/generator 0.1.0

package/src/components/Hint.astro

@@ -0,0 +1,99 @@
+---
+// Inline, text-level component - unlike every other built-in here
+// (Callout, Card, Accordion, ...), which are all block-level and get
+// their own line, a Hint sits mid-sentence: `word <Hint tip="...">this
+// bit</Hint> continues`. That's why this renders a <span>, not a <div>,
+// and why its own trigger area is exactly its slotted text - no icon,
+// no padding box drawing attention to itself the way a Callout does.
+//
+// tip is a plain string prop (not a slot) deliberately - the tooltip
+// bubble itself needs to be one line of plain text CSS can center/
+// position predictably; a second <slot> would let an author put
+// arbitrary markup (another Hint, a link, a whole paragraph) in there,
+// which the hover-bubble layout below was never built to hold.
+interface Props {
+  tip: string;
+}
+const { tip } = Astro.props as Props;
+---
+
+<span class="wd-hint" tabindex="0">
+  <span class="wd-hint-trigger"><slot /></span>
+  <span class="wd-hint-tooltip" role="tooltip">{tip}</span>
+</span>
+<style>
+  .wd-hint {
+    position: relative;
+    /* display: inline, not inline-block - this needs to be able to wrap
+       across a line break exactly like the plain text around it would
+       (it's often a whole sentence, not one short word), which
+       inline-block would prevent by forcing the whole span to stay on
+       one line or break as a single rigid box. */
+    display: inline;
+    /* tabindex above + :focus-visible below make this reachable and
+       revealable by keyboard, not just a mouse hover - the underline
+       and cursor: help both double as the visual cue that there's a
+       hint here at all, since nothing about plain underlined text
+       otherwise signals "hover me" the way an icon or button would. */
+    cursor: help;
+    border-bottom: 1px solid var(--wd-text);
+  }
+  .wd-hint-tooltip {
+    position: absolute;
+    bottom: calc(100% + 0.55rem);
+    left: 50%;
+    transform: translateX(-50%) translateY(4px);
+    /* Fixed dark-on-light regardless of [data-theme] - deliberately not
+       var(--wd-text)/var(--wd-background) (which flip a Hint's own
+       tooltip to light-on-dark in dark mode) since the bubble needs to
+       read as "a label floating above the page", the same fixed
+       look in both themes, not as page content that itself follows the
+       theme - the same reasoning Card.astro's method badges already
+       settled on for their own always-colored, never-theme-flipping
+       backgrounds. */
+    background: #18181b;
+    color: #fff;
+    padding: 0.45rem 0.75rem;
+    border-radius: 0.4rem;
+    font-size: 0.75rem;
+    font-weight: 700;
+    line-height: 1.3;
+    /* No white-space: nowrap - a long tip (a UUID example, a full
+       sentence) needs to actually wrap onto a second line within
+       max-width; nowrap combined with max-width caps the *box* but
+       leaves overflow: visible's default behavior letting the text
+       itself spill out past the painted background/border-radius
+       instead of wrapping inside it - exactly the "text sticking out
+       past the dark bubble" bug a real screenshot caught. Wrapping
+       normally keeps the background sized to whatever it's actually
+       covering, at the cost of a short tip's box no longer perfectly
+       hugging one line's width (an intentional trade - a tip that's
+       readable matters more than one that's minimally-sized). */
+    max-width: 16rem;
+    width: max-content;
+    box-shadow: 0 4px 12px rgba(0, 0, 0, 0.18);
+    opacity: 0;
+    visibility: hidden;
+    pointer-events: none;
+    transition:
+      opacity 0.15s ease,
+      transform 0.15s ease,
+      visibility 0.15s;
+    z-index: 30;
+  }
+  .wd-hint-tooltip::after {
+    content: "";
+    position: absolute;
+    top: 100%;
+    left: 50%;
+    transform: translateX(-50%);
+    border: 5px solid transparent;
+    border-top-color: #18181b;
+  }
+  .wd-hint:hover .wd-hint-tooltip,
+  .wd-hint:focus-visible .wd-hint-tooltip {
+    opacity: 1;
+    visibility: visible;
+    transform: translateX(-50%) translateY(0);
+  }
+</style>

package/src/components/Icon.astro

@@ -0,0 +1,70 @@
+---
+// Renders either a real icon (via `icon`) or a custom image (via
+// `src`) inline with surrounding text - modeled on Mintlify's own Icon
+// (https://www.mintlify.com/docs/components/icons), which documents
+// exactly this "one of `icon` or `src`" split. `icon` reuses
+// AppIcon.astro - the same Lucide/Iconify/literal-text resolution
+// every other icon prop on this site already goes through (Card,
+// Badge, writedocs.json's own tab/dropdown/product icons) - so this
+// component's `icon` prop behaves identically to theirs, just laid out
+// for inline text flow instead of block/flex placement.
+//
+// The `src` branch is a second, independent code path (a plain <img>,
+// not AppIcon) since it isn't resolving an icon set at all - it's
+// dropping in an arbitrary image (a project-local file or an external
+// URL) and just needs to sit inline at a controlled height, the exact
+// behavior of the InlineImage React component this was modeled on
+// (display: inline, a `height` prop controlling size, no margin).
+import AppIcon from './AppIcon.astro';
+
+interface Props {
+  icon?: string;
+  src?: string;
+  alt?: string;
+  // Only meaningful for the `icon` branch - a pixel size (Mintlify's
+  // own `size` prop is a number, not a CSS length) and a CSS color,
+  // applied as an inline style since these are arbitrary per-instance
+  // values, not a fixed set of classes.
+  size?: number;
+  color?: string;
+  // Only meaningful for the `src` branch - a CSS length string (not a
+  // bare number, unlike `size` above), matching the InlineImage
+  // reference component's own `height` prop and its "1.6em" default.
+  height?: string;
+}
+const { icon, src, alt = '', size, color, height = '1.6em' } = Astro.props as Props;
+
+const iconStyle =
+  [size ? `width:${size}px` : null, size ? `height:${size}px` : null, color ? `color:${color}` : null]
+    .filter(Boolean)
+    .join(';') || undefined;
+---
+
+{
+  src ? (
+    <img src={src} alt={alt} class="wd-icon-image" style={`height:${height}`} />
+  ) : icon ? (
+    <AppIcon icon={icon} class="wd-icon-inline" style={iconStyle} />
+  ) : null
+}
+<style>
+  .wd-icon-image {
+    display: inline;
+    vertical-align: middle;
+    height: 1.6em;
+    margin: 0;
+  }
+  /* :global() is load-bearing, same reason as every other AppIcon
+     consumer's identical comment (Card.astro, Badge.astro): AppIcon
+     renders this span/svg, not Icon.astro, so it never carries this
+     component's own scope attribute. 1em default (overridden inline
+     via the `size` prop's style attribute when set) keeps an
+     unsized icon proportional to its surrounding text, the same way a
+     real glyph would be. */
+  :global(.wd-icon-inline) {
+    display: inline;
+    vertical-align: middle;
+    width: 1em;
+    height: 1em;
+  }
+</style>

package/src/components/Image.astro

@@ -0,0 +1,147 @@
+---
+// Block-level (own line, centered) - unlike Hint (inline/text-level),
+// this is meant to be dropped in on its own the way Callout/Card are.
+//
+// src/srcDark render as two separate <img> tags, both always in the
+// markup, CSS shows only the one matching the active [data-theme] - the
+// exact same dual light/dark-asset pattern base.css's own .wd-logo-light/
+// .wd-logo-dark rules already establish for TopBar/MobileMenu/SiteFooter's
+// logo (see that comment there) - base.css's own comment on those rules
+// spells out exactly why they get to write [data-theme='dark'] .wd-logo-x
+// completely unscoped: base.css is a *plain imported* .css file, never run
+// through Astro's scoped-CSS compiler at all, unlike this component's own
+// <style> block below. [data-theme] lives on <html>, set by BaseLayout's
+// anti-FOUC script - nowhere near this component's own template - so
+// inside a *scoped* <style> (this one) that ancestor selector has to be
+// wrapped in :global() or Astro's compiler appends this component's own
+// scope attribute onto it too, requiring <html> to carry that attribute,
+// which it never will. .wd-image-light/.wd-image-dark themselves don't
+// need :global() - unlike AppIcon-rendered markup (Card/Accordion's own
+// icon rules), both <img> tags here are rendered directly by *this*
+// component's own template, so they already carry its scope attribute
+// normally.
+interface Props {
+  src: string;
+  srcDark?: string;
+  // Width at full (unconstrained) viewport width - a raw CSS length or
+  // percentage string ("80%", "480px", "40rem", ...), passed straight
+  // through as a custom property with no parsing/validation, the same
+  // "trust the site author, this is their writedocs.json/content" latitude
+  // every other pass-through string prop here already gets (Card's
+  // icon, Callout's title, ...). Applied to the *figure* (see below),
+  // not the <img> tags directly - an earlier version set it on the img
+  // instead, which left the figure itself (and, when caption is set,
+  // its whole bordered card) always full-width regardless of `size`,
+  // so a size="70%" image ended up sitting inside a card twice as wide
+  // as it needed to be, with a large empty gap on both sides - caught
+  // via a real screenshot showing exactly that gap. max-width: 100%
+  // below is what actually makes this shrink on a narrower viewport
+  // instead of overflowing it, regardless of which form `size` takes -
+  // a percentage already scales with its container on its own, but a
+  // fixed px/rem value doesn't, and needs that separate cap to behave
+  // the same way.
+  size?: string;
+  alt?: string;
+  // Optional caption shown below the image. Set it and the whole thing
+  // gains the same bordered/rounded "card" background Frame's own
+  // caption case uses (border + background + padding, image inset
+  // inside it) - deliberately conditional on caption being set rather
+  // than always-on: without a caption this needs to render exactly as
+  // it always has (a plain image, no chrome), so an existing
+  // <Image src="..." /> with no caption keeps its current look with
+  // zero visual change - only opting a page into the card look actually
+  // opts it in.
+  caption?: string;
+  // Opts this image out of the site-wide click-to-zoom lightbox (see
+  // src/scripts/image-zoom.ts) - rendered as a bare `nozoom` attribute
+  // on both <img> tags, the same attribute a raw
+  // `<img nozoom src="..." />` written directly in MDX would carry, so
+  // one selector in image-zoom.ts handles both cases identically rather
+  // than needing to special-case this component.
+  noZoom?: boolean;
+}
+const { src, srcDark, size, alt = "", caption, noZoom } = Astro.props as Props;
+const sizeStyle = size ? `--wd-image-size:${size}` : undefined;
+---
+
+<figure
+  class:list={["wd-image-figure", caption && "wd-image-figure-framed", srcDark && "wd-image-has-dark"]}
+  style={sizeStyle}
+>
+  <img src={src} alt={alt} class="wd-image wd-image-light" nozoom={noZoom || undefined} />
+  {srcDark && <img src={srcDark} alt={alt} class="wd-image wd-image-dark" nozoom={noZoom || undefined} />}
+  {caption && <figcaption class="wd-image-caption">{caption}</figcaption>}
+</figure>
+<style>
+  /* width: var(--wd-image-size, 100%) here (not on the img - see the
+     `size` prop's own comment above) is what makes the *whole figure*,
+     card background and all, actually match the image's own size
+     instead of always spanning the full content column. margin: ...
+     auto only has anything to center once this has a definite width
+     smaller than its container - at the 100% default it's a no-op,
+     same as before this prop existed. */
+  .wd-image-figure {
+    width: var(--wd-image-size, 100%);
+    max-width: 100%;
+    margin: 1.25rem auto;
+  }
+  /* Same card language as Frame's own bordered case (border + rounded +
+     surface background + padding) - deliberately duplicated here rather
+     than shared, the same way Card/Callout/Accordion each carry their
+     own near-identical CSS rather than a shared base class; Astro's
+     scoped <style> blocks are per-component anyway, so there's no
+     lighter-weight way to share this without introducing a global
+     stylesheet dependency neither component otherwise needs. Padding
+     is what creates the "image inset within the card" look - the img's
+     own width: 100% below resolves against this padded content box,
+     not the figure's own outer edge.
+     box-shadow is a deliberate belt-and-suspenders addition on top of
+     the border - var(--wd-border)/var(--wd-surface) are both very
+     light, low-contrast tokens by default (see BaseLayout.astro's own
+     --wd-border/--wd-surface light-mode values), so on a page whose own
+     background is similarly pale (or, worse, uses the literal same
+     image asset as its background - confirmed as the actual root cause
+     of a real earlier "the card is invisible" report), the border alone
+     can end up nearly imperceptible even though it's genuinely being
+     applied. A soft shadow gives the card a second, independent visual
+     cue that doesn't depend on border/surface contrast against
+     whatever the page happens to look like. */
+  .wd-image-figure-framed {
+    border: 1px solid var(--wd-border);
+    border-radius: 0.75rem;
+    background: var(--wd-surface);
+    padding: 0.5rem;
+    box-shadow: 0 1px 3px rgba(0, 0, 0, 0.08);
+  }
+  .wd-image {
+    display: block;
+    width: 100%;
+    height: auto;
+    border-radius: 0.75rem;
+  }
+  .wd-image-dark {
+    display: none;
+  }
+  /* .wd-image-light only hides in dark mode when a dark variant is
+     actually there to replace it - .wd-image-has-dark only gets added
+     to the figure when srcDark is set (see the frontmatter above); with
+     no srcDark, there's no second <img> in the markup at all, so
+     unconditionally hiding the light one (an earlier version of this
+     rule had no such scoping) left dark mode with literally nothing to
+     show - a real user report caught exactly that: light-only Image
+     usages went blank in dark mode instead of just keeping the one
+     image they had, same as base.css's own dual-logo comment already
+     notes for a site that only configures one logo. */
+  :global([data-theme="dark"]) .wd-image-figure.wd-image-has-dark .wd-image-light {
+    display: none;
+  }
+  :global([data-theme="dark"]) .wd-image-dark {
+    display: block;
+  }
+  .wd-image-caption {
+    margin-top: 0.6rem;
+    text-align: center;
+    color: var(--wd-text-muted);
+    font-size: 0.75rem;
+  }
+</style>

package/src/components/Info.astro

@@ -0,0 +1,12 @@
+---
+// Shorthand for <Callout type="info">. See Callout.astro's own comment.
+import Callout from './Callout.astro';
+interface Props {
+  title?: string;
+  // See Callout.astro's own comment - set automatically by
+  // remarkCalloutAnchorIds, not meant to be passed by hand.
+  _titleId?: string;
+}
+const { title, _titleId } = Astro.props as Props;
+---
+<Callout type="info" title={title} _titleId={_titleId}><slot /></Callout>

package/src/components/Note.astro

@@ -0,0 +1,12 @@
+---
+// Shorthand for <Callout type="note">. See Callout.astro's own comment.
+import Callout from './Callout.astro';
+interface Props {
+  title?: string;
+  // See Callout.astro's own comment - set automatically by
+  // remarkCalloutAnchorIds, not meant to be passed by hand.
+  _titleId?: string;
+}
+const { title, _titleId } = Astro.props as Props;
+---
+<Callout type="note" title={title} _titleId={_titleId}><slot /></Callout>

package/src/components/Parameter.astro

@@ -0,0 +1,119 @@
+---
+// The name+type+description row used throughout API reference content -
+// modeled directly on Mintlify's own ParamField/ResponseField
+// (https://www.mintlify.com/docs/components/expandables), which this
+// was explicitly asked to match. Deliberately one component covering
+// both "this is a request parameter" and "this is a response field"
+// use cases (Mintlify itself ships two near-identical components for
+// that split) - nothing here actually depends on which direction the
+// data flows, so there was no real reason to duplicate it.
+//
+// Only `name` is required - `type` is optional (a parameter's shape is
+// sometimes obvious from context, or genuinely untyped), so its badge
+// only renders when passed.
+//
+// Nests naturally: a Parameter's own slot can contain plain description
+// text, an <Expandable> wrapping more Parameters for a nested object's
+// own properties, or both - see Expandable.astro's own comment for that
+// half of the pattern.
+interface Props {
+  name: string;
+  type?: string;
+  required?: boolean;
+  default?: string;
+}
+const { name, type, required = false, default: defaultValue } = Astro.props as Props;
+---
+
+<div class="wd-parameter">
+  <div class="wd-parameter-head">
+    <span class="wd-parameter-name">{name}</span>
+    {type && <span class="wd-parameter-type">{type}</span>}
+    {required && <span class="wd-parameter-required">required</span>}
+    {defaultValue && <span class="wd-parameter-default">default: {defaultValue}</span>}
+  </div>
+  <div class="wd-parameter-body">
+    <slot />
+  </div>
+</div>
+<style>
+  .wd-parameter {
+    padding: 0.9rem 0;
+  }
+  /* Divider between consecutive fields, not around the group as a
+     whole - a first-child Parameter (the common case: the very first
+     field in a list, or the only field passed to Expandable) shouldn't
+     render a line above itself with nothing there to separate it
+     from. */
+  .wd-parameter + .wd-parameter {
+    border-top: 1px solid var(--wd-border);
+  }
+  .wd-parameter-head {
+    display: flex;
+    align-items: center;
+    flex-wrap: wrap;
+    gap: 0.5rem;
+    margin-bottom: 0.4rem;
+  }
+  .wd-parameter-name {
+    font-family: monospace;
+    font-weight: 700;
+    color: var(--wd-primary);
+  }
+  /* border/background/border-radius match base.css's own global inline
+     <code> pill exactly (var(--wd-surface)/var(--wd-border)/0.35em) -
+     reusing those instead of inventing new chip colors is the actual
+     "apply the same styles as our api pages" part of the request: a
+     type name here should read as the same kind of chip a reader
+     already sees for inline `code` anywhere else in this site's
+     content. font-family: monospace is added on top (base.css's own
+     inline code doesn't force one, it inherits the body font) - every
+     other API-page element that reads as "code" (ApiPlayground's param
+     inputs, CodeGroup's tab labels, ApiReferencePanel's own field
+     labels) already sets it explicitly the same way, and the reference
+     screenshot this was built from clearly renders field names/types
+     in a monospace face too. */
+  .wd-parameter-type {
+    font-family: monospace;
+    font-size: 0.8rem;
+    background: var(--wd-surface);
+    border: 1px solid var(--wd-border);
+    border-radius: 0.35em;
+    padding: 0.1em 0.5em;
+    color: var(--wd-text-muted);
+  }
+  /* Same chip shape as .wd-parameter-type (border/radius/padding/
+     font-family), just recolored red - matches the reference
+     screenshot, where "required" reads as the same kind of badge as
+     the type chip next to it, not a plain-text label. */
+  .wd-parameter-required {
+    font-family: monospace;
+    font-size: 0.8rem;
+    font-weight: 600;
+    background: color-mix(in srgb, #dc2626 8%, var(--wd-surface));
+    border: 1px solid color-mix(in srgb, #dc2626 35%, var(--wd-border));
+    border-radius: 0.35em;
+    padding: 0.1em 0.5em;
+    color: #dc2626;
+  }
+  .wd-parameter-default {
+    font-size: 0.78rem;
+    color: var(--wd-text-muted);
+  }
+  .wd-parameter-body {
+    color: var(--wd-text-muted);
+  }
+  .wd-parameter-body :global(p:first-child) {
+    margin-top: 0;
+  }
+  .wd-parameter-body :global(p:last-child) {
+    margin-bottom: 0;
+  }
+  /* A nested <Expandable> (see its own comment) sits inside this same
+     body slot, right below the description text - a little breathing
+     room above it so it doesn't crowd directly against the last line
+     of description. */
+  .wd-parameter-body :global(.wd-expandable) {
+    margin-top: 0.75rem;
+  }
+</style>

package/src/components/RequestExample.astro

@@ -0,0 +1,33 @@
+---
+// Pins its code example(s) in the right sidebar - in place of the page's
+// normal table of contents - on desktop; falls back to a plain in-place
+// CodeGroup on narrower viewports where that sidebar column doesn't
+// render at all. Modeled on Mintlify's own RequestExample/
+// ResponseExample (https://www.mintlify.com/docs/components/examples):
+// "work similarly to CodeGroup... but display the code in the sidebar
+// instead of inline" - reuses CodeGroup.astro itself internally (tabs
+// by default, or its own `dropdown` prop for a <select> switcher
+// instead) rather than reimplementing that tab/dropdown-switching logic
+// a second time.
+//
+// The actual relocation into the sidebar is handled entirely by
+// src/scripts/example-panels.ts, mounted once from [...slug].astro - see
+// its own comment for why a client-side DOM move (rather than an
+// Astro-slot/build-time split) is what this needs: MDX compiles this
+// component's children into one single content flow, with no way for a
+// build-time render to place part of that flow into a *different*
+// column's own slot output.
+//
+// wd-example-panel is the marker class that script looks for; it's
+// otherwise a completely plain wrapper.
+import CodeGroup from './CodeGroup.astro';
+interface Props {
+  dropdown?: boolean;
+}
+const { dropdown = false } = Astro.props as Props;
+---
+<div class="wd-example-panel wd-request-example">
+  <CodeGroup dropdown={dropdown}>
+    <slot />
+  </CodeGroup>
+</div>

package/src/components/ResponseExample.astro

@@ -0,0 +1,19 @@
+---
+// See RequestExample.astro's own comment - identical in every respect
+// except the marker class (wd-response-example vs wd-request-example),
+// which src/scripts/example-panels.ts uses to always dock Response
+// panels below Request panels in the sidebar regardless of which order
+// they're written in a page's own MDX, matching Mintlify's own stated
+// behavior ("ResponseExample... pins code examples in the right sidebar
+// beneath any RequestExample content on the same page").
+import CodeGroup from './CodeGroup.astro';
+interface Props {
+  dropdown?: boolean;
+}
+const { dropdown = false } = Astro.props as Props;
+---
+<div class="wd-example-panel wd-response-example">
+  <CodeGroup dropdown={dropdown}>
+    <slot />
+  </CodeGroup>
+</div>

package/src/components/Searchbar.astro

@@ -0,0 +1,117 @@
+---
+// Wraps a GFM table (or any other block-level slot content, though a
+// table is the intended/primary use case) with a text input above it
+// that live-filters rows by their own text content - "let users filter
+// the content inside the wrapper" per the request that spawned this.
+//
+// A markdown table always lands as a *direct* child of .wd-article
+// (see [...slug].astro's own comment on this at its `<style is:global>`
+// block), which is what its own global table CSS rule
+// (`.wd-article > table`) deliberately targets - once wrapped in this
+// component's own .wd-searchbar-content div, that table is no longer a
+// direct child of .wd-article, so that rule's ">" combinator stops
+// matching it. Rather than loosening that combinator sitewide (it's
+// intentionally direct-child-only - see its own comment for why), the
+// exact same declarations are duplicated here, scoped to
+// .wd-searchbar-content instead, so a wrapped table still renders
+// identically to every unwrapped one.
+interface Props {
+  placeholder?: string;
+}
+const { placeholder = "Search..." } = Astro.props as Props;
+---
+
+<div class="wd-searchbar">
+  <input type="text" class="wd-searchbar-input" placeholder={placeholder} aria-label={placeholder} />
+  <div class="wd-searchbar-content">
+    <slot />
+  </div>
+  <p class="wd-searchbar-empty">No results found.</p>
+</div>
+<script>
+  // Filters by each <tbody> row's own full text content - simplest
+  // approach that works regardless of column count/order, and needs no
+  // knowledge of the table's shape. Only <tbody> rows are ever
+  // filtered (querySelector scopes to "table tbody tr"), so the
+  // header row is never a candidate for hiding.
+  function initSearchbars(root: ParentNode) {
+    root.querySelectorAll<HTMLElement>(".wd-searchbar").forEach((wrapper) => {
+      if (wrapper.dataset.wdInit) return;
+      wrapper.dataset.wdInit = "true";
+      const input = wrapper.querySelector<HTMLInputElement>(".wd-searchbar-input");
+      const empty = wrapper.querySelector<HTMLElement>(".wd-searchbar-empty");
+      const rows = Array.from(wrapper.querySelectorAll<HTMLTableRowElement>(".wd-searchbar-content table tbody tr"));
+      if (!input || rows.length === 0) return;
+      input.addEventListener("input", () => {
+        const query = input.value.trim().toLowerCase();
+        let visibleCount = 0;
+        rows.forEach((row) => {
+          const isMatch = !query || (row.textContent ?? "").toLowerCase().includes(query);
+          row.style.display = isMatch ? "" : "none";
+          if (isMatch) visibleCount++;
+        });
+        if (empty) empty.style.display = visibleCount === 0 ? "block" : "none";
+      });
+    });
+  }
+  initSearchbars(document);
+  document.addEventListener("astro:page-load", () => initSearchbars(document));
+</script>
+<style>
+  .wd-searchbar {
+    margin: 1.25rem 0;
+  }
+  .wd-searchbar-input {
+    box-sizing: border-box;
+    width: 100%;
+    border: 1px solid var(--wd-border);
+    border-radius: 0.6rem;
+    padding: 0.6rem 1rem;
+    margin-bottom: 1rem;
+    color: var(--wd-text);
+    background: var(--wd-background);
+    font-size: 0.9rem;
+    font-family: inherit;
+  }
+  .wd-searchbar-input::placeholder {
+    color: var(--wd-text-muted);
+  }
+  .wd-searchbar-input:focus {
+    outline: none;
+    border-color: var(--wd-primary);
+  }
+  /* Matches .wd-article > table's own global styling exactly (see this
+     file's own top comment for why it has to be duplicated here rather
+     than reused directly) - width/border-collapse/font-size on the
+     table itself, cell padding/border/alignment on th and td, and the
+     muted uppercase treatment on th. :global() throughout since slot
+     content (the author's own MDX table) never carries this
+     component's own scope attribute. */
+  .wd-searchbar-content :global(table) {
+    width: 100%;
+    border-collapse: collapse;
+    margin: 0;
+    font-size: 0.9rem;
+  }
+  .wd-searchbar-content :global(th),
+  .wd-searchbar-content :global(td) {
+    text-align: left;
+    padding: 0.55rem 0.75rem;
+    border-bottom: 1px solid var(--wd-border);
+    vertical-align: top;
+  }
+  .wd-searchbar-content :global(th) {
+    color: var(--wd-text-muted);
+    font-weight: 600;
+    font-size: 0.8rem;
+    text-transform: uppercase;
+    letter-spacing: 0.03em;
+  }
+  .wd-searchbar-empty {
+    display: none;
+    padding: 1.5rem 0;
+    text-align: center;
+    color: var(--wd-text-muted);
+    font-size: 0.9rem;
+  }
+</style>

package/src/components/Step.astro

@@ -0,0 +1,10 @@
+---
+interface Props {
+  title?: string;
+}
+const { title } = Astro.props as Props;
+---
+<div class="wd-step">
+  {title && <p class="wd-step-title"><strong>{title}</strong></p>}
+  <slot />
+</div>