Writing a guide page

Voyager runs on several AI sites and gains more. A page describes a feature once, with the site differences carried by data, so a new site needs no prose edit. docs/guide/folders.md is the reference page.

Shape

1. One page per feature, never per platform. Open with one or two plain sentences on what it does for the person.
2. Right after the intro, <SiteSupport feature="<id>" :labels="{ … }" /> (docs/.vitepress/theme/components/SiteSupport.vue). Its rows and ticks come from shipped code through docs/.vitepress/siteSupport.ts: the feature's own row from the plugin table (pluginsPage.ts featureRows), then the capability rows in FEATURE_CAPABILITIES. The page only supplies row labels; an unlabelled row shows its id.
3. A capability that differs by site gets a row in FEATURE_CAPABILITIES, derived from code data (plugin manifests, catalog/sites/<site>/site.json, popup allowlists). Trace where it is wired before adding one. When no data can say it, add a footer row by hand, :only="[{ id: 'move-menu', sites: ['gemini', 'claude'] }]" with its label in :labels (**…** bolds a UI label), and say so in your report. Nothing else is hand-ticked.
4. Sections by operation (filing, nesting, import/export, …), not by platform. Short sentences, no marketing filler, no em-dash asides. An operation is a lead sentence, then 3 to 5 bullets that each open with a bold trigger word and stay within two lines; longer asides go in <GuideNote>.
5. Every claim is checked against code before it is written. Quote UI labels from src/locales/<lang>/messages.json exactly. Drop or fix anything stale rather than carrying it over.
6. Zh (docs/guide/) and en are written natively. The other 8 locales are translated naturally from en with the same structure, links to their own locale's pages, and the same images.

Layout blocks