Represent scoped rune attributes as an object-valued bag

Decision

Adopt an object-valued attribute bag as the single representation for scoped and injected rune attributes, carried as attributes={...} on a tag and as an attributes object in config. Three sub-decisions ride on it.

1. Representation — one shape, three sites

The same { key: value } bag is the unit in all of:

• config scoped defaults (runeDefaults[].attributes, SPEC-122),
• the {% expand attributes={...} %} override (SPEC-123),
• the internal precedence-merge that combines them with inline attributes.

Because the shape is identical everywhere, one validator — "validate this attribute bag against rune schema R" — serves config-load validation (SPEC-122) and expand's build-time validation (SPEC-123). One tested code path, not two divergent ones. Keys are kebab-case rune attribute names (matching inline authoring); values are typed Markdoc literals.

Name is attributes, not variables. partial already uses variables= to mean Markdoc $vars — a different concept (template substitution, not rune attributes). Reusing that word would conflate the two. attributes= is self-documenting and reads as a deliberate parallel.

2. Precedence — and the schema-default trap

The merge order, most-authoritative first, is:

inline author attribute → most-specific scoped/injected bag → rune schema default.

An explicit inline attribute always wins; a bag never overrides what the author wrote by hand. For SPEC-122 the bag tiers are route-scoped (more specific) over rune-global; for SPEC-123 the single bag sits above the embedded entity's own authored attributes.

The trap: Markdoc SchemaAttribute carries its own default, applied during transform. By the time a rune's transform() sees attrs, an author-written value and a schema-filled default are indistinguishable — so a bag applied after schema defaults resolve cannot honour "inline author wins." Therefore bag values must be layered in before schema defaults take effect: for any attribute a bag governs, the schema default is suppressed (sentinel the omitted value) so the bag→schema-default order is real rather than always losing to the schema default. This is the one mechanism both specs must build on and is called out in each.

3. Validation posture — LSP-quiet, build/config-strict

The bag is opaque to the language server. getTagContext (packages/language-server/src/parser/document.ts) recognises only name="value" attribute positions; it does not descend into an object literal, so there is no completion, hover, or diagnostic for keys or values inside attributes={...}. For SPEC-123 this is unavoidable regardless — the target rune is only known once id resolves against the build-time registry, which the editor cannot do.

We recover correctness by moving validation to where the schema is resolvable:

• Config defaults validate at config-load (SPEC-122) — a bad key or enum value errors loudly at startup, naming the rune and attribute.
• Expand overrides validate at build time (SPEC-123) — the registry is resolved, so the bag is checked against the target entity's root rune schema. This catches semantic typos the parser accepts: mediaPosition: "left" parses fine as an object key but is not a real attribute, and only schema validation flags it.

The editor stays quiet; the build does not.

Scope

The bag is the vehicle for scoped defaults (config) and embed overrides (expand). It is deliberately not a universal per-rune escape hatch — we do not add attributes={...} to every rune as a second way to set inline attributes. That would create two authoring paths for the same value and muddy precedence and validation. expand earns the bag because embedding is inherently a re-skinning operation; ordinary runes set attributes inline.