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.

A CLI command that emits a deterministic static rune gallery: every rune across its variant matrix, on one page, rendered through the HTML adapter. This is the AI-iteration surface and the deterministic subject the harness (WORK-409) photographs.

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.