v0.41.0 — Composed runes you can ship

Found by WORK-625, the composed character. A {% hint %} an author wrote before the first section was matched by no preamble field and dropped, with no error and no warning. The composed definition works around it with a catch-all body preamble field. SPEC-145 records the finding beside the character worked example.D11 promises against this silent loss but checks the other direction. It requires that every declared field is placed by a slot. Nothing checks that every authored node is matched by a field. So content can still vanish between the author's file and the content model, by another route.This applies to any content model, not just compositions. A tree-owning rune with a narrow preamble loses unmatched content the same way, so the fix belongs in the content-model resolver, not in the composition layer. First measure how many shipped runes drop content today, so the change can be staged as a warning before an error if needed.

SPEC-145 D27 (c). validateSchemaTable (packages/runes/src/lib/schema-table.ts) checks two things: that by names a declared attribute, and that a fallback exists. It never compares rows keys with that attribute's matches. So a misspelt row (podcasts:) or a newly added enum value silently selects the fallback, and {% playlist type="podcast" %} would publish MusicAlbum.D15 already requires an exact two-way correspondence for template variants. The schema by gets the same check. It needs no composition, and it applies to every hand-written table today (playlist, track, organization and others).

SPEC-153 implementation note 3, the plugin side. In v0.40.0 a composed definition reached the pipeline only as a string passed to defineComposedRune. A plugin now declares runeDir (package-relative, resolved the way fileRoots resolves, D2). Every <rune>.md in it is loaded as a composed rune.Decisions:

SPEC-153 implementation note 4, the project side, and the step that opens composition to users. A project declares runes.dir in refrakt.config.json, following contentDir's shape, with a recommended default of runes (D4). The loader discovers every <rune>.md in it.Decisions:

SPEC-147 lists lore as the simplest storytelling rune. It has a title, a body, an Article schema row (title → headline, category → articleSection) and a registered entity. It follows the pattern WORK-624 and WORK-625 set:

SPEC-147: realm (Place) and faction (Organization) share character's shape, sections plus a preamble, and each has a -section child rune that composition removes. Their media split maps to {% mediatext %}. Both follow WORK-625's pattern:

Composition ships to users in this milestone, and SPEC-153 D9 makes the definition file the user-facing authoring surface. Today the only documentation is a PluginRune note in rune-authoring/authoring-overview.md. Add a page under site/content/extend/rune-authoring/ written from SPEC-145's "template vocabulary, in one place" table. The guide is the spine of that table rather than a summary of it.It covers:

WORK-631 added content-unmatched: validation reports an authored node that no content-model field matches, because the transform drops it. It shipped as a warning because the measurement found that four shipped runes drop real content today, all in the plan plugin. The plan site renders each entity through its rune ({% expand %}), so the loss reaches plan.refrakt.md.Measured over this repo's plan/ directory (907 files), as of WORK-631: