ClassRegistry doesn't enforce Elemental's disallowed_elements/allowed_elements

[jsirish]

Summary

git grep -n 'disallowed_elements\|allowed_elements' src/ _config/ returns nothing — the module's
discovery_roots auto-discovery (and manual models: mapping) has no awareness of Elemental's own
per-page disallowed_elements/allowed_elements config (Page.disallowed_elements: [...] in a
project's _config/*.yml).

Confirmed on ~/Sites/mathedleadership: app/_config/essentials.yml disallows six element classes
(blog pagination/widgets, CTA, timeline, testimonials, stat counters) for CMS editors. Without a
project-level discovery_exclude mirroring that list by hand, the content API would happily create
those elements via a composition/batch write, producing content the CMS editor then can't manage
(the element type doesn't appear in their "add element" picker, but it now exists on the page).

Current workaround

Every consuming project's own content-api.yml has to manually mirror disallowed_elements into
ClassRegistry.discovery_exclude — see the comment in mathedleadership's
app/_config/content-api.yml. The two lists will silently drift the moment either config changes,
since nothing cross-references them.

Proposal

ClassRegistry's discovery pass could consult Elemental's own Page.allowed_elements/
disallowed_elements config (and per-page-type overrides, if Elemental supports them) when building
the discovered class set, at least as an additional automatic exclusion on top of
discovery_exclude — so a project's existing Elemental config is the source of truth rather than a
second list a maintainer has to remember to update in lockstep.

🤖 Generated with Claude Code