/**
 * The `sdocs://visual-testing-guide` resource: how to look at one component
 * without photographing an entire application.
 *
 * Kept as prose rather than data on purpose — the advice is identical for
 * every stage, so repeating it inside each resolve_visual_target result would
 * spend tokens to say the same thing N times, which is the exact cost this
 * guidance exists to avoid.
 */
export declare const VISUAL_TESTING_GUIDE = "# Inspecting sdocs previews with a browser\n\nsdocs renders every stage \u2014 each `[component]` preview, each `[example]`, each\n`[LAYOUT]` \u2014 as its own standalone page. Open that page and you photograph one\ncomponent. Open the Explorer instead and you photograph a documentation app that\nhappens to contain it.\n\nThe difference is not small. Measured on a real 42x36px component:\n\n| What you capture | Pixels | Image tokens |\n|---|---|---|\n| The Explorer page | 1934x1162 | ~1970 |\n| The stage only | 1934x64 | ~108 |\n| The component | 42x36 | ~2 |\n\n## The ladder\n\nWork down it and stop at the first rung that answers the question.\n\n1. **Read, don't photograph.** `getComputedStyle` reports padding, color, font\n   size, and border radius exactly; a screenshot only lets you guess at them.\n   Most \"is the spacing wrong?\" questions are answered here, for free.\n2. **Screenshot one element** when you need to see it \u2014 the button, not the page.\n3. **Screenshot the stage** (`#sdocs-preview`) when the relationship *between*\n   elements is the point, or when the component paints outside its own box.\n4. **Screenshot the Explorer** only when the documentation UI itself is the bug.\n5. **Full-page screenshots** only when explicitly asked for.\n\nBefore any of it, run `check_docs`. A stage that fails to compile renders an\nerror panel, and no amount of looking at that picture will explain the bug.\n\n## The procedure\n\n```js\n// 1. Resolve the stage. Names, routes, and stage ids all work; you never\n//    reproduce the slug rules yourself.\nconst target = await mcp.resolve_visual_target({ target: 'Button / Sizes' });\n\n// 2. Open the preview-only route. previewRoute is relative \u2014 join it to\n//    whatever origin the dev server actually reported (the port is not fixed).\nawait page.goto(origin + target.resolved.previewRoute);\n\n// 3. Wait for the marker. It is set after mount, after webfonts settle, and\n//    after images decode \u2014 screenshotting earlier catches a half-drawn stage.\nawait page.locator(target.resolved.readySelector).waitFor();\n\n// 4. Locate the smallest relevant element and measure it.\nconst button = page.getByRole('button', { name: 'Small' });\nconst box = await button.boundingBox();   // runtime truth; nothing predicts this\n\n// 5. Capture it.\nawait button.screenshot({ path: 'small-button.png', scale: 'css' });\n```\n\nRuntime size is never reported by the MCP server, because it can't be: it\ndepends on the viewport, responsive CSS, loaded fonts, and the component's own\ncontent. `boundingBox()` owns that answer, and a locator screenshot crops to it\nautomatically.\n\n## Shadows, glows, and focus rings\n\n`boundingBox()` returns the **border box**. A component's visible extent is\noften larger \u2014 `box-shadow`, `filter: drop-shadow`, an `outline` with an offset,\na focus ring. Cropping to the border box cuts exactly the pixels a design review\nis looking at.\n\nTwo ways to keep the halo:\n\n**Capture the stage.** `stageLayout.padding` from `resolve_visual_target` is the\nauthor's own answer to \"how much room does this need?\". A stage with padding\nalready holds the shadow, so `#sdocs-preview` is a safe target.\n\n**Or grow the crop.** Every stage page exposes a helper that measures how far an\nelement actually paints, read from computed styles rather than assumed:\n\n```js\nconst rect = await page.evaluate(() =>\n  window.__sdocs.captureRect('.my-button', { padding: 8 })\n);\n// { x, y, width, height, clipped, bleeds }\nawait page.screenshot({ clip: rect, scale: 'css' });\n```\n\n- `bleeds: true` \u2014 the component paints outside its box; a tight element\n  screenshot would have clipped it.\n- `clipped: true` \u2014 the halo runs past the edge of the viewport, so the crop is\n  cut short. Widen the viewport, or give the stage more `padding`, before\n  trusting the image.\n\n`window.__sdocs.inkBleed(selector)` returns the per-side overflow on its own\n(`{ left, right, top, bottom }`) when you want the numbers rather than a picture.\n\n## What a stage page gives you\n\n| Thing | Where |\n|---|---|\n| Ready marker | `<html data-sdocs-stage-ready>` |\n| Failed stage | `<html data-sdocs-stage-error=\"render \\| script \\| timeout\">` |\n| Stage identity | `window.__sdocs.stage` \u2192 `{ id, kind, name, component }` |\n| Capture rect | `window.__sdocs.captureRect(selector?, { padding })` |\n| Ink overflow | `window.__sdocs.inkBleed(selector?)` |\n| The stage element | `#sdocs-preview` |\n\nA stage always ends up marked ready, even when it fails \u2014 a client waiting on\nthe marker gets an answer instead of a timeout. Check `data-sdocs-stage-error`\nbefore trusting what you see.\n\n## Variants\n\n`?axis-<id>=<value>` sets `data-<id>` on the stage document \u2014 one parameter per\ncustomization axis the project declares under `axes` (theme, density, palette,\nwhatever it defines). Combine them freely:\n`?axis-scheme=dark&axis-density=compact` photographs one component in one exact\ncombination, no Explorer involved. `list_docs` reports the project's axes and\ntheir values; a value the config doesn't list simply has no CSS behind it.\n\n`?theme=dark` sets `data-sdocs-theme`, for CSS keyed off that attribute. Themes\ndriven by `prefers-color-scheme` are the browser's to emulate\n(`page.emulateMedia({ colorScheme: 'dark' })`) \u2014 sdocs does not fake the media\nquery. `?css=<name>` picks between the stylesheets a project configures under\n`css`, which is a whole-file swap rather than a composable dimension.\n\n## Editing\n\nThe dev server hot-reloads a stage page in place. Resolve once, open once, then\nedit the component and re-measure \u2014 no re-navigation, no re-resolution.\n`resolve_visual_target` reports `source.component` (the `.svelte` file) and\n`source.doc` with a line, so what you see leads straight to what you edit.\n";