Found reviewing PR #517, which adds six enums to communitymech.yaml and is the first change to test this.
vocab/cultivation_terms.yaml states an invariant in its own header:
INVARIANT (enforced by tests/test_cultivation_vocab_sync.py): the keys under each enum here MUST exactly equal that enum's permissible-value keys […]
The enforcement is tests/test_cultivation_vocab_sync.py:16:
ENUMS = ("CultivationModeEnum", "CultivationSystemEnum")
A hardcoded 2-tuple, consumed by three loops, with no test asserting it is complete. A new cultivation enum is outside the invariant the moment it is written, and nothing anywhere goes red. The header reads as a property of the file; it is a property of two names someone typed once.
Verified, not assumed: grep -rln across tests/ finds test_cultivation_vocab_sync.py as the only file referencing CultivationModeEnum or cultivation_terms, and the only reference to ENUMS is its definition plus the three loops. Nothing else guards it.
#517 is the live case, and its answer is "correctly exempt." The six new enums are units and a retention-time kind — °C, 1/h, HRT. Those are not METPO candidates; if they map anywhere it is UO or UCUM. Leaving them out of vocab/ is right. But that reasoning exists only in this issue: the repo cannot distinguish "deliberately exempt" from "nobody noticed," which is the same shape as #471, where nine tests stayed green because they pinned a constant's value rather than its use.
Suggested fix, cheap and in the established style: a test that enumerates every enum in the schema and requires each to be either listed in ENUMS or named in an explicit _NOT_STAGED_FOR_METPO set carrying a one-line reason. A new enum then forces the author to say which it is, at the moment they add it, rather than in a later audit. That also gives the unit enums' exemption a written home.
Related: #471 (a constant whose use went unchecked), #514 (a slot whose convention lived in a description rather than a constraint).
Found reviewing PR #517, which adds six enums to
communitymech.yamland is the first change to test this.vocab/cultivation_terms.yamlstates an invariant in its own header:The enforcement is
tests/test_cultivation_vocab_sync.py:16:A hardcoded 2-tuple, consumed by three loops, with no test asserting it is complete. A new cultivation enum is outside the invariant the moment it is written, and nothing anywhere goes red. The header reads as a property of the file; it is a property of two names someone typed once.
Verified, not assumed:
grep -rlnacrosstests/findstest_cultivation_vocab_sync.pyas the only file referencingCultivationModeEnumorcultivation_terms, and the only reference toENUMSis its definition plus the three loops. Nothing else guards it.#517 is the live case, and its answer is "correctly exempt." The six new enums are units and a retention-time kind —
°C,1/h,HRT. Those are not METPO candidates; if they map anywhere it is UO or UCUM. Leaving them out ofvocab/is right. But that reasoning exists only in this issue: the repo cannot distinguish "deliberately exempt" from "nobody noticed," which is the same shape as #471, where nine tests stayed green because they pinned a constant's value rather than its use.Suggested fix, cheap and in the established style: a test that enumerates every enum in the schema and requires each to be either listed in
ENUMSor named in an explicit_NOT_STAGED_FOR_METPOset carrying a one-line reason. A new enum then forces the author to say which it is, at the moment they add it, rather than in a later audit. That also gives the unit enums' exemption a written home.Related: #471 (a constant whose use went unchecked), #514 (a slot whose convention lived in a description rather than a constraint).