v0.21.0 — Registry-driven composition and sandbox integration

SPEC-092 Layer 1 — the small first strike that proves the registry-authoring loop. Core registers every page as a page entity but copies only a fixed frontmatter subset (config.ts register hook). Merge the rest of the page's frontmatter onto the page entity's data so any field is queryable by the field-match grammar (which already normalises arrays).

SPEC-092 Layers 2 + 3 — let a page declare a registry type so collection/ aggregate can query it by domain (collection type="rune"), not just type:page.

The generated rune catalogue (WORK-386) needs every /runes/<name> page to carry category, plugin, and status frontmatter. Hand-editing ~100+ pages is a slog and drifts — so backfill it with a script.

The SPEC-092 showcase: the docs site's own rune catalogue, generated from the registry — the page about the runes built from the runes. The dogfood payoff of frontmatter-declared entities, and open-world (a third-party plugin's documented runes join with no change to refrakt).

Frontmatter-driven catalogues can drift from code — add a defineRune without a doc page and it silently vanishes from the generated catalogue. Turn that into a build signal. Fast-follow to the catalogue work.

SPEC-093 core — the build-time data channel from the registry into a sandbox. The registry's third render target (HTML via collection, SVG via aggregate, arbitrary client-side here). Independent of the SPEC-092 track: flat/tree shapes work over the page/pageTree data that exists today.

The second data-bound showcase — and a dogfood: the plan's own relationship graph. SPEC-072 edges are already live and populated (the plan plugin calls relate() for spec↔work↔decision↔milestone), so this needs no SPEC-092 work.

A generic, content-agnostic section rune: the shared page-section header (eyebrow → headline → blurb → image) followed by an arbitrary body. It exists so a preamble-less grid primitive like bento can be introduced with a title and intro — the role the feature "runes that work together" block plays on the site index today. Unblocks WORK-350 (the bento capstone), which replaces that feature section with a section + bento.

hero grammatically accepts media-position="cover" but has never been styled or tested for it (SPEC-101 §1–§3, §6). The engine side (scrim, foreground flip, posture demotion) already fires for hero — and hero emits the anatomy cover.css keys on — so this item is the hero-side delta: config variant parity with card, a band-appropriate height authority, padding rerouting, and an overlay legibility pass.

cover.css stretches only img/video to fill the media well; any other guest — a sandbox above all — sits at its own height. CSS alone can't fix the sandbox case: the custom element (packages/behaviors/src/elements/sandbox.ts) sets an inline iframe height (fixed px, or live auto-resize via rf-sandbox-resize postMessage when data-height="auto"), which fights a host-owned height. This item makes any guest fill a cover well, with sandbox height="fill" as the mechanism for the live case (SPEC-101 §4). Benefits every cover host (card, bento-cell, hero alike).

A cover-backdrop sandbox is inert (SPEC-090 posture demotion) and above the fold, so the WORK-381 activation affordances contradict it: visible is a no-op there and click's poster + "Run" control is a dead end on a pointer-events: none surface. Eager is the background mode; a non-eager sandbox under cover should warn at build time (SPEC-101 §5).

The showcase scene for the animated hero background (SPEC-101 §7): the brand metaphor, literally. A slowly rotating prism; a thin stream of markdown glyph particles (#, *, >, {%) enters one face as a faint ishi-tinted beam (stone grey — undifferentiated input); fanned spectrum streams leave the other in the Niwaki syntax roles — wakaba (keyword green), sakura (function pink), matsu (pine — link/constant), momiji (string peach, punchy string-expression orange as an accent). Markdown in, structured meaning out, in the exact colours this site renders syntax in.

The capstone of SPEC-101: document hero-cover and ship the animated prism background as a live, authored example. There is currently no docs example of media-position="cover" on hero at all.

Long-standing leak in the density dimension, surfaced by the SPEC-101 hero-cover docs: sections.css scaled titles with a descendant selector ([data-density="compact"] [data-section="title"] { font-size: 1.25rem }), which punches through nested densities — a full-density hero inside a compact preview renders its headline at 1.25rem, wildly unrepresentative of the real rune. The existing "nested density scoping" resets in density.css covered descriptions and meta ranks but never the title, and a value-based reset can't work for titles (each rune sets its own size).