V0.21.0
Name:v0.21.0Status:complete

v0.21.0 — Registry-driven composition and sandbox integration

A minor release turning the entity registry into something you can author over and visualize — making content queryable by frontmatter, and letting sandboxes be fed registry data to drive arbitrary client-side renderings (3D sitemaps, relationship graphs). The thread that runs through it: the registry's render targets grow from HTML and SVG to bring-your-own-renderer.

Milestone burndown: 0 open work items remaining; peak 0, started Jun 1101Jun 11Jun 15
Open work items Ideal burndown
Progress 13/13 work items
Related 22

Work Items

Done 13
WORK-381 main
Sandbox lazy/poster activation
sandbox is eager today: the iframe is created and its dependencies load on page render (it has a height knob but no deferral). That's fine for a small demo, but a heavy sandbox — a three.js scene (WORK-382), a large framework demo — on a perf-sensitive page like the site index costs a chunk of load time we deliberately avoided (WORK-350 and WORK-380 both limited live iframes "to keep the landing page fast").Add a deferred-activation capability so a heavy sandbox can headline a page without the load-time hit — useful for any heavy sandbox, not just three.js.
medium moderate
5/5 criteria
WORK-383 main
Frontmatter indexing on the page entity
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).
high simple
3/3 criteria
WORK-384 main
Typed page entities
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.
medium moderate
4/4 criteria
WORK-388 main
Data-bound sandbox core
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.
high complex
4/4 criteria
WORK-389 main
3D sitemap showcase
The launch showcase for the data-bound sandbox — and the simplest, since the data already exists: the core pageTree. A data-shape="tree" sandbox renders the site as a navigable 3D map (three.js tree/force layout); nodes link to their URLs.
medium moderate
4/4 criteria
WORK-390 main
Plan relationship-graph showcase
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.
medium moderate
3/3 criteria
WORK-396 main
Generic section rune (eyebrow/headline/blurb preamble + body)
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.
medium moderate
6/6 criteria
WORK-398 main
Hero as a cover host
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.
high moderate
6/6 criteria
WORK-399 main
Cover guest fill and sandbox fill height mode
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).
high moderate
5/5 criteria
WORK-400 main
Build warning for non-eager sandbox in a cover media zone
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).
low simple
3/3 criteria
WORK-401 main
Prism scene — the niwaki-refraction hero backdrop
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.
medium moderate
5/5 criteria
WORK-402 main
Docs — hero cover reference and animated prism background showcase
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.
medium simple
5/5 criteria
WORK-403 main
Nested-density title sizing — full-density runes in compact hosts
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).
medium simple
3/3 criteria