Each of the three runes is individually assessed: is the missing role an oversight, or is the slot deliberately not a semantic section?
Corrections are applied only where the role genuinely belongs; a decision not to add one is recorded with its reasoning
Each correction has a test asserting the new data-section and, for a body role, that reading/dropcap now land on it
The rendered-output change for each rune is enumerated in the resolution — this is not output-neutral
refrakt contracts is regenerated; the unavailable entries for the affected runes disappear, and nothing else in the contract moves
A changeset records the visible change for theme authors
npm run build, the full repo suite, and refrakt contracts --check pass

Approach

Adding a role adds data-section, which Lumina styles directly in styles/dimensions/sections.css and styles/dimensions/density.css. Existing sites will render these runes differently without doing anything, so each addition needs its own justification — "the slot exists" is necessary but not sufficient.

Check the rendered result visually, not only in tests: a card body picking up the shared [data-section="body"] rules is the intended outcome, but it should be confirmed rather than assumed.

Blocked by

WORK-528

References

SPEC-125 — Phase 1, Direction 1
SPEC-108 — reading register and dropcap