Users author composed runes only

Consequences

The CSS problem for rune authors disappears. This is the largest consequence and the reason this decision is worth making early. A declared rune with no styles renders unstyled, which SPEC-143 identifies as the sharpest authoring barrier — and which dragged in a style fence, sanitisation of untrusted CSS, a scope assertion over author selectors, and the question of what a skin file contains. A composed rune ships no CSS at all (SPEC-145 D2). None of that applies to a rune author any more.

ADR-035 is unaffected: skin files target theme authors, a different audience with a different job. The scope of the skin format does not change; only the claim that rune authors would use one goes away.

Revisited, and wrong: ADR-035 is now rejected. That paragraph assumed the remaining audience — a leaf theme styling a few self-contained runes — survives this decision. It does not. After composition a theme styles tokens, primitives and dimensions, all cross-cutting by construction, which is ADR-035's own package row rather than its skin row; and a capability package shipping CSS for a rune it owns is likewise a package. ADR-035's rejected third alternative — "user runes reference existing BEM blocks instead of shipping CSS" — is precisely what this decision chose, so its premise is gone rather than narrowed. Its full reasoning is preserved in place.

The hosted validation surface barely grows. A user rune becomes frontmatter plus a Markdoc template. Markdoc is already parsed and already safe. What remains is the schema.org claims question (SPEC-143's open question) and itemModel's regex (ADR-036's one exception) — both already recorded, neither made worse by this.

SPEC-143 is unchanged in substance and clearer in purpose. Its job was always removing ~135 imperative transforms from this repo; every acceptance criterion is a first-party migration. Its role becomes "the internal emit path, and the foundation the shared declaration rests on", which is more defensible than being one of two options a user picks between.

A user's composed rune keeps its arrangement across a theme change. Appearance follows the theme, because the primitives are themed; arrangement does not, because it is in the template. That is a reasonable contract for someone who wrote a template, and it belongs in the authoring documentation rather than being discovered.

A composed rune is a poor basis for a redistributable rune package. Anyone wanting @acme/wine-runes to work under any theme is constrained by a baked arrangement — and is writing a plugin anyway, so the constraint bites only if they try to avoid that.

Qualified: the observation survives, the conclusion does not. A baked arrangement is still a real constraint, but ADR-039 rule 4 names a pack — compositions plus curated knowledge, no code — as one of three legitimate package kinds, and SPEC-153 D1 makes a plugin-shipped composition byte-identical to a user-authored one. So a redistributable package of composed runes is not a misuse; it is the expected shape wherever the value being distributed is a curated schema mapping or a format rather than cross-theme portability. @refrakt-md/media is the worked case (SPEC-155 D6): two compositions, no code for them, and a five-row schema.org table nothing validates.

D5's mutual exclusion still holds, and gains a second job: it is now also the line between the internal and user-facing paths, so a user definition carrying a slot declaration instead of a template is rejected rather than quietly accepted.

runes.local is not an exception to this, and the reason should be stated rather than assumed. It takes a JS module path and registers a rune with a hand-written transform, which reads like the declared path offered to users. Its documentation scopes it otherwise — "Referencing Your Package → During Development (Local Files)" — so its audience is a plugin author's inner loop before publishing, which is the code path this decision assigns the declared emit path to. Nothing in the mechanism enforces that scope, and a composed rune cannot travel through it at all, since a .rune.md is not a module. SPEC-153 D7 records the scope explicitly.