The three entity runes are assessed together; the decision and its reasoning apply consistently across them, or the divergence is explained
The three *Section child runes are assessed together on the same terms
Corrections are applied only where the role genuinely belongs
Each correction has a test asserting the new data-section and, for a body role, that reading/dropcap land on it
The rendered-output change for each rune is enumerated in the resolution
refrakt contracts is regenerated; the affected unavailable entries disappear and nothing else moves
A changeset records the visible change for theme authors
npm run build, the full repo suite, and refrakt contracts --check pass

Approach

Worth a specific look: the *Section child runes are sections of an entity rune, so "does this have a page-section header" is a different question for them than for a top-level rune. prominence scales a page-section header — on a child section that may be the wrong axis entirely, in which case the honest answer is to leave the role off and let the contract keep recording it as unavailable.

Realm also has a media section already (plugins/storytelling styles [data-section="media"] in realm.css), so it is the one entity rune where a new body role interacts with existing role-based CSS. Check that pairing visually.

Blocked by

WORK-528

References

SPEC-125 — Phase 1, Direction 1
SPEC-107 — prominence