v0.44.0 — Hero, cta and testimonial compose

ADR-046 decides that an eyebrow is a paragraph directly before the headline, never a heading. The docs still teach the heading form. The guide's only example of it uses hero, which renders it wrongly (BUG-047), and nineteen rune pages say "a short paragraph or heading" in the same boilerplate sentence.The native page-section runes keep their grammar until each one is composed (ADR-046, decision 4), so some of them still accept the heading form. The docs stop recommending it anyway: it is not the direction, and documenting less than a rune accepts is safe where documenting more is not.

The native hero and feature host a media guest with guestFit: 'bleed', a config field. A config field cannot differ between compositions that place the same section, and hero needs bleed where a card-like composition needs clip (SPEC-160 D7).

A blocks entry renders through bar (a row) or definition-list (a label/value grid). Neither draws a byline, a lead value with secondary values beneath, which testimonial and cast each hand-roll in their CSS (SPEC-161 D6).

ADR-042 makes a composed rune's config its definition's: a theme cannot know which definition it faces, so an override of a composed rune's blocks or metaFields is a guess that silently resolves to nothing. Nothing enforces this yet. mergeThemeConfig and mergeRuneConfig (packages/transform/src/merge.ts) guard the identity fields on every rune, and nothing else, so a theme's runes: entry keyed to a composed rune's type name applies.v0.44.0 adds the first composed runes a theme could try to override (hero, cta, testimonial), so the guard lands with them.

A second site, staging, renders site/content with the project runes in site/staged-runes/ preferred over the plugin runes they replace (SPEC-181 D1). It uses only existing configuration: runes.dir and runes.prefer (__project__).

The composed hero, cta and testimonial move out of the test fixtures into site/staged-runes/. This makes the review of WORK-665, WORK-666 and WORK-668 possible: the runes' reference pages, the homepage and every other page that uses them, rendered with the compositions on the staging site.

Every conversion of a plugin rune into a composition is staged until it goes live, and goes live on its own (SPEC-181 D5, D6). Writing that down is not enough to make it happen, so this item also adds a test that fails when a conversion skips staging.

The composed hero takes align="start | center | end", which is section's vocabulary. The plugin hero takes left | center | right. The staging site renders the same content as main, so align="left" on the homepage and on the hero reference page would be invalid there (SPEC-181 D7). The plugin hero learns the new values first, and the content moves to them.

The composed testimonial (WORK-668) takes author and role attributes and reports a **Name** — Role paragraph as content-unmatched. The plugin testimonial takes no author attribute. So WORK-668 built refrakt marketing migrate-testimonial but did not apply it: the rewritten content would not have rendered through the plugin.The staging site renders the same content as main (SPEC-181 D7). The plugin testimonial therefore learns the attributes first, and the codemod is then applied.

The content model reads structured values out of a list item (itemModel) and a heading (headingExtract), but not out of a paragraph, and what it extracts can only reach an emitted child or $each (SPEC-182). This item adds both missing pieces, reusing the list-item vocabulary.

The staged testimonial reads **Name** — Role through WORK-686's paragraph item model, and keeps author and role as the alternative form (SPEC-182 D6). The content migration and the codemod that pointed the other way are reversed before v0.44.0 is released (D7).