v0.22.0 — Theme platform foundations

Extend the SPEC-048 TokenContract with a real typographic system. Today the contract carries only font.sans / font.mono — no scale, leading, weight, or tracking — so typographic identity (the primary differentiator for editorial/magazine themes) is not themeable. This is the gate for the SPEC-094 Tier 1 foundations.

Replace Lumina's hardcoded typography with the WORK-404 tokens. Today there are ~351 hardcoded font-size declarations against 5 tokenized — so an editorial theme wanting a different scale must override hundreds of declarations across 90 files. Tokenizing here is also what shrinks the WORK-410 skeleton/skin spike's classification surface.

Make tokens.ts the single source for Lumina's token CSS. Today tokens/base.css and tokens/dark.css are hand-authored mirrors of luminaTokens, kept in lockstep by token-config-coverage.test.ts — the file header even notes "a future build script that regenerates this file." Wire generateThemeStylesheet into the build so the mirror and its coverage test retire and drift becomes impossible.

Extend the gallery generator (WORK-407) to a second subject class: layout fixtures — representative sample pages rendered through each LayoutConfig so page chrome (header, nav, sidebar, TOC, mobile panel, footer) is visually covered. Chrome carries as much of a theme's identity as runes, and the skeleton/skin extraction touches styles/layouts/*, so this is what lets the harness guarantee hold for chrome, not just content blocks.

A shared Playwright harness that photographs the generated gallery + layout fixtures and diffs them against a baseline. This closes the AI iteration loop and — critically — gives the v0.23.0 skeleton/skin extraction its "diff must be empty" proof. No screenshot testing exists in the repo today; this is greenfield.Baselines are ephemeral, not committed. Fixtures and theme CSS churn constantly, so committed golden PNGs would mean endless binary diffs and a re-baseline commit on nearly every PR — noise that trains everyone to ignore the check, plus repo bloat. Instead the baseline is whatever you compare against in the moment (__screenshots__/ is gitignored): capture-then- compare locally, or compare-against-base in CI.

The gating spike for the v0.23.0 wholesale extraction. The skeleton/skin cut is a per-declaration design call (structure and aesthetics are braided inside single rules), so settle it empirically on a small slice before committing to the public contract every future theme depends on.

The foundation of SPEC-102: pin down the fixture format and unify the four fragmented stores into one source the CLI, gallery, editor, and reference all read. The WORK-407 gallery exposed the cost of the status quo — getFixture reads only cli/lib/fixtures.ts (13 runes), ignores RUNE_EXAMPLES (24), and 25 runes fall back to a naive stub that renders wrong (<p> inside an inline badge span).

With the format + loader in place (WORK-411), author a good fixture for every rune so the gallery, editor, and inspect render the whole catalogue correctly. The WORK-407 gallery surfaced ~25 runes with no real fixture (rendering the broken stub) and several child runes shown standalone.

ai/src/modes/write.ts hardcodes an "Example structure" in its prompt. Replace it with the unified fixtures — drawing each rune's rich/canonical fixture (with its notes) as in-context few-shot exemplars. No training pipeline; retrieval into the prompt only.

Guard the corpus: parse the frontmatter fields (the format established in WORK-411 strips the block; this work consumes it), validate them against the schema, support <rune>.<scenario>.md scenarios, and ensure every fixture parses + transforms. plugin-validate reports role coverage instead of only warning "no fixture".

Document the fixture format, frontmatter fields, the role (coverage-vs-exemplar) split, and the <rune>.<scenario>.md convention under the plugin/theme authoring section.

The WORK-407 gallery renders the static pre-enhancement HTML, so custom-element / lifecycle runes render empty: diagram → <rf-diagram>, chart → <rf-chart>, nav → <rf-nav>, sandbox → <rf-sandbox>, map → ~nothing. Progressive-enhancement runes (accordion, details, tabs, …) render their no-JS fallback (all-expanded) rather than their real state. Including the behaviors client makes the lifecycle runes draw and the PE runes show their enhanced (representative) state.

The foundation for SPEC-106: recognise custom URL schemes in a Markdown image's src during the transform and resolve them to a renderable, before the generic <img> fallback. Custom schemes (placeholder:, icon:) already survive markdown-it's validateLink, so  arrives as an image node with src intact.

The inline icon shorthand discussed when the icon rune landed:  resolves to the named icon's inline SVG — the same source the {% icon %} rune uses.

 resolves to a generated, theme-tinted inline SVG placeholder sized to the named shape — deterministic, offline, screenshot-stable.

With the placeholder: resolver in place, swap the SPEC-102 fixtures' base64-PNG image blobs for clean  references, and confirm the image-consuming runes render the resolved SVG.

Document the image-src scheme sugar for content authors, and the data:svg caveat.