docs/source/pcapkit/const/index.rst:16-26 describes _missing_ as universally minting, which docs/source/contributing/conventions/mint-criterion.rst contradicts. The landing page is the authority a reader of pcapkit.const meets first, so the wrong one is the one most likely to be believed.
The landing page says a value inside a registry's valid range "is minted into a new member on the fly -- via aenum.extend_enum", and that "the identity of a minted member is stable for the life of the process".
mint-criterion.rst:19-26 says the opposite for all but one registry: _unregistered_member "Returns a member-like object for the value without installing it. The registry does not grow, and a second lookup of the same value builds an equal but distinct object rather than handing back the first." It then states that exactly one _missing_ in the tree mints — CGAType's — while 114 unmint and six only range-check.
Measured on main: 111 files under pcapkit/const/ reference _unregistered_member, and 3 reference extend_enum at all. So "via aenum.extend_enum" is wrong for roughly 120 of the 121 registries that define _missing_, and "stable for the life of the process" is the direct inverse of the documented behaviour — a second lookup builds a distinct object.
This predates the #719 sweep and is not a regression. It surfaced because #1011 removed the same error from CONTRIBUTING.md, which points the reader at this very page — so the two now disagree in the opposite direction.
Worth noting it reads authoritatively: "minted", "extend_enum" and "stable for the life of the process" are specific enough that a sweeper is unlikely to doubt them without mint-criterion.rst open alongside. Belongs to the docs/source/pcapkit/** slice of #719, flagged here so the sweep does not have to notice it unaided.
docs/source/pcapkit/const/index.rst:16-26describes_missing_as universally minting, whichdocs/source/contributing/conventions/mint-criterion.rstcontradicts. The landing page is the authority a reader ofpcapkit.constmeets first, so the wrong one is the one most likely to be believed.The landing page says a value inside a registry's valid range "is minted into a new member on the fly -- via
aenum.extend_enum", and that "the identity of a minted member is stable for the life of the process".mint-criterion.rst:19-26says the opposite for all but one registry:_unregistered_member"Returns a member-like object for the value without installing it. The registry does not grow, and a second lookup of the same value builds an equal but distinct object rather than handing back the first." It then states that exactly one_missing_in the tree mints —CGAType's — while 114 unmint and six only range-check.Measured on
main: 111 files underpcapkit/const/reference_unregistered_member, and 3 referenceextend_enumat all. So "viaaenum.extend_enum" is wrong for roughly 120 of the 121 registries that define_missing_, and "stable for the life of the process" is the direct inverse of the documented behaviour — a second lookup builds a distinct object.This predates the #719 sweep and is not a regression. It surfaced because #1011 removed the same error from
CONTRIBUTING.md, which points the reader at this very page — so the two now disagree in the opposite direction.Worth noting it reads authoritatively: "minted", "extend_enum" and "stable for the life of the process" are specific enough that a sweeper is unlikely to doubt them without
mint-criterion.rstopen alongside. Belongs to thedocs/source/pcapkit/**slice of #719, flagged here so the sweep does not have to notice it unaided.