Problem
An abstract template.prompt + extends cannot hoist the required @payloadRef / @format (or @textRef) attributes, because the loader's required-attr check is own-only: it validates required attrs on the node's OWN layer, not the resolving/effective set. So an abstract template.prompt that omits these (intending concrete subtypes to supply them, or to inherit via extends) fails to load, even though meta verify reads the effective attrs correctly.
This forces every concrete template.prompt node to restate @payloadRef/@format per node — repetition the metamodel otherwise lets extends eliminate. A reference-impl consumer documents exactly this in its prompt metadata header as a forced workaround.
Why it's arguably wrong
It contradicts the ADR-0039 resolving-default spirit (resolving/effective accessors are the default; own-only reads drop inherited data). The required-attr check is one of the few remaining own-only reads that isn't a sanctioned metamodel-internal case, and here it blocks a legitimate extends composition.
Ask
Decide whether the loader's required-attr check should consult the resolving attr set (so an abstract can omit a required attr that concrete subtypes / extends provide), consistent with ADR-0039 — or document why own-only is intentional here and provide a sanctioned pattern for abstract prompt templates.
Problem
An abstract
template.prompt+extendscannot hoist the required@payloadRef/@format(or@textRef) attributes, because the loader's required-attr check is own-only: it validates required attrs on the node's OWN layer, not the resolving/effective set. So an abstracttemplate.promptthat omits these (intending concrete subtypes to supply them, or to inherit viaextends) fails to load, even thoughmeta verifyreads the effective attrs correctly.This forces every concrete
template.promptnode to restate@payloadRef/@formatper node — repetition the metamodel otherwise letsextendseliminate. A reference-impl consumer documents exactly this in its prompt metadata header as a forced workaround.Why it's arguably wrong
It contradicts the ADR-0039 resolving-default spirit (resolving/effective accessors are the default;
own-only reads drop inherited data). The required-attr check is one of the few remaining own-only reads that isn't a sanctioned metamodel-internal case, and here it blocks a legitimateextendscomposition.Ask
Decide whether the loader's required-attr check should consult the resolving attr set (so an abstract can omit a required attr that concrete subtypes /
extendsprovide), consistent with ADR-0039 — or document why own-only is intentional here and provide a sanctioned pattern for abstract prompt templates.