Close the loop on the use case that motivated SPEC-107: the same content rune reading as a contained card and as a full-width hero, by composing the axes — no rune fork.
Tracking started Jun 14 — check back for trends.
recipe (and playlist) at their card default and as a hero: elevation="flush" width="full" prominence="display" — large title, no surface chrome, edge-to-edge.recipe renders as a bordered card by default and as a full-bleed, large-title hero via elevation="flush" width="full" prominence="display", verified in the gallery (light + dark) with no leaked markdown.packages/runes/fixtures/ · plugins/learning (recipe) · plugins/media (playlist).Completed: 2026-06-15
Branch: claude/v023-elevation-migration-demo
runes/surfaces.md (new ## Card vs hero section, the #card-vs-hero anchor referenced from the axes intro): the same recipe as a bordered card by default, then as a full-bleed hero via elevation="flush" width="full" prominence="display" — two {% preview source=true %} blocks, same content, no rune fork. Noted the pattern generalises to any page-section-header rune (playlist/howto/section) and cross-linked cover mode.runes/learning/recipe.md → ## Card vs hero), contrasting it with cover mode (hero stacks a display title above edge-to-edge media; cover overlays the title on the image).refrakt inspect <rune> --elevation=flush --width=full --prominence=display): all three axes emit on the rune root — data-elevation="flush", data-width="full", data-prominence="display" — with no leaked markdown ({% absent from output).data-elevation="flat" and neither data-width nor data-prominence.prominence never reached the engine — without it the hero's title would not have scaled. The demonstration is the regression test for that wiring.width="full" inside a {% preview %} renders full-width-of-preview rather than true page bleed (the preview container has no article grid); the real edge-to-edge bleed shows on an actual page. Worth a glance in a browser run.