From 525dc73509e1439e3bb99d4d74d684207e60e066 Mon Sep 17 00:00:00 2001
From: Jarry Shaw <jarryshaw@icloud.com>
Date: Sun, 25 Oct 2026 10:27:26 -0400
Subject: [PATCH] docs(tests): state const tests' behaviour without
 change-relative narrative (#1103)

Rewrites comments and docstrings under tests/const/ so they describe
behaviour and the defect each test guards against, not the change that
introduced it. Prose only; AST-identical once docstrings are stripped.
---
 .../test_const_apptype_lazy_1538_unit.py      |   2 +-
 ..._const_apptype_register_range_1792_unit.py |  19 +-
 tests/const/test_const_apptype_split_unit.py  | 527 ++++++------
 tests/const/test_const_enum_builtin_parity.py | 321 ++++----
 tests/const/test_const_enum_get.py            | 304 +++----
 tests/const/test_const_enum_lookup.py         |  32 +-
 tests/const/test_const_enum_no_mint.py        | 764 ++++++++----------
 tests/const/test_const_ethertype_862_unit.py  |  22 +-
 ...onst_ftp_command_get_key_type_1824_unit.py |   2 +-
 .../test_const_ftp_featcode_case_903_unit.py  |   6 +-
 ...st_const_ipv6_extension_header_925_unit.py |  68 +-
 tests/const/test_const_linktype_209_unit.py   |  44 +-
 ...st_const_method_case_sensitive_896_unit.py |  24 +-
 ...test_const_method_value_lookup_908_unit.py |  16 +-
 ...ster_validates_every_registry_1816_unit.py |   2 +-
 tests/const/test_const_registry_protocol.py   | 488 +++++------
 .../const/test_const_str_payload_870_unit.py  |  29 +-
 17 files changed, 1213 insertions(+), 1457 deletions(-)

diff --git a/tests/const/test_const_apptype_lazy_1538_unit.py b/tests/const/test_const_apptype_lazy_1538_unit.py
index 2b40365caf..12b08e2607 100644
--- a/tests/const/test_const_apptype_lazy_1538_unit.py
+++ b/tests/const/test_const_apptype_lazy_1538_unit.py
@@ -5,7 +5,7 @@
 :mod:`~pcapkit.const.reg.apptype.udp` are generated from IANA's registry and
 hold about 49,700 lines of members between them; ``python -X importtime -c
 'import pcapkit'`` put them at 104 ms and 102 ms of a 700 ms import. Nothing on
-any import path needs them, so :mod:`pcapkit.const.reg.apptype` now imports them
+any import path needs them, so :mod:`pcapkit.const.reg.apptype` imports them
 from a :pep:`562` ``__getattr__`` and from
 :attr:`AppType.__registries__ <pcapkit.const.reg.apptype.apptype.AppType.__registries__>`
 the first time either is read.
diff --git a/tests/const/test_const_apptype_register_range_1792_unit.py b/tests/const/test_const_apptype_register_range_1792_unit.py
index d75a3ab8de..c8b9df3bd0 100644
--- a/tests/const/test_const_apptype_register_range_1792_unit.py
+++ b/tests/const/test_const_apptype_register_range_1792_unit.py
@@ -1,15 +1,16 @@
 # -*- coding: utf-8 -*-
 """``AppType.register`` refuses a port that ``get`` refuses.
 
-GitHub issue #1792. :meth:`~pcapkit.const.reg.apptype.apptype.AppType.register`
-neither called nor overrode
-:meth:`~pcapkit.corekit.enum.EnumLookup._validate_value`, so ``TCP.register(70000,
-'x')`` minted a member, and ``AppType.get(70000, proto='tcp')`` then returned it
-although ``get`` raises :exc:`ValueError` for a port outside ``0``-``65535``
-(#758). ``AppType`` now overrides the hook with :meth:`_missing_`'s own check and
-``register`` calls it after its duplicate check, as the base ``register`` does.
-The override raises :exc:`~pcapkit.utilities.exceptions.EnumValueError`, as the
-registry-protocol convention asks of one, with the message ``get`` raises.
+GitHub issue #1792. Without the fix,
+:meth:`~pcapkit.const.reg.apptype.apptype.AppType.register` neither calls nor
+overrides :meth:`~pcapkit.corekit.enum.EnumLookup._validate_value`, so
+``TCP.register(70000, 'x')`` mints a member, and ``AppType.get(70000,
+proto='tcp')`` then returns it although ``get`` raises :exc:`ValueError` for a
+port outside ``0``-``65535`` (#758). ``AppType`` overrides the hook with
+:meth:`_missing_`'s own check and ``register`` calls it after its duplicate
+check, as the base ``register`` does. The override raises
+:exc:`~pcapkit.utilities.exceptions.EnumValueError`, as the registry-protocol
+convention asks of one, with the message ``get`` raises.
 
 Each test imports the registries after
 :func:`~tests._support.reimport_once_per_class`, whose ``restore`` puts the
diff --git a/tests/const/test_const_apptype_split_unit.py b/tests/const/test_const_apptype_split_unit.py
index 10117d2dc7..ac8f35bc4f 100644
--- a/tests/const/test_const_apptype_split_unit.py
+++ b/tests/const/test_const_apptype_split_unit.py
@@ -1,18 +1,18 @@
 # -*- coding: utf-8 -*-
 """The application layer registry as a per-transport package.
 
-GitHub issue #732. :file:`pcapkit/const/reg/apptype.py` was one
-:class:`~aenum.StrEnum` holding the members of every transport protocol,
-with a ``__members_proto__`` mapping that kept **one** member per
-``(transport, port)`` pair -- so of the three services IANA assigns to port 80,
-two were reachable only by attribute name and none of that was visible from a
-lookup. It is now :mod:`pcapkit.const.reg.apptype`: a memberless
+GitHub issue #732. :mod:`pcapkit.const.reg.apptype` is a memberless
 :class:`~pcapkit.const.reg.apptype.apptype.AppType` base and one registry per
 transport protocol, each keyed on port by a
-:class:`~pcapkit.corekit.multidict.MultiDict` that keeps every assignment.
-
-These properties carry the design and none of them held before, so each is
-asserted directly rather than left to the generic sweeps in
+:class:`~pcapkit.corekit.multidict.MultiDict` that keeps every assignment. The
+defect #732 reported was a single :class:`~aenum.StrEnum` holding the members
+of every transport protocol, with a ``__members_proto__`` mapping that kept
+**one** member per ``(transport, port)`` pair -- so of the three services IANA
+assigns to port 80, two were reachable only by attribute name and none of that
+was visible from a lookup.
+
+These properties carry the design, so each is asserted directly rather than
+left to the generic sweeps in
 :mod:`tests.const.test_const_enum_builtin_parity`:
 
 #. the base holds **no** members, which is not a tidiness preference --
@@ -23,7 +23,7 @@
 #. a colliding port keeps **every** service IANA assigned it, answering with one
    canonical member and keeping the rest reachable as named aliases;
 #. :func:`~aenum.extend_enum` on an occupied port *appends* rather than
-   displacing what was there, which is the silent data loss the old
+   displacing what was there, which is the silent data loss #732's
    ``__members_proto__`` assignment performed.
 
 """
@@ -86,9 +86,9 @@ def _declarations(path: 'str', name: 'str') -> 'tuple[tuple[str, int], ...]':
 def _declared(registry: 'type') -> 'list[tuple[str, int]]':
     """Every member ``registry``'s generated module declares, in source order.
 
-    GitHub issue #1820. The population checks in this file used to pin IANA's
-    per-registry member counts, so a vendor update that added or removed a port
-    turned them red with nothing wrong. They compare against this instead: the
+    GitHub issue #1820. The population checks in this file compare against
+    this rather than pin IANA's per-registry member counts, which a vendor
+    update that adds or removes a port turns red with nothing wrong: the
     ``(name, port)`` rows the generated class body declares, read with
     :mod:`ast` rather than off the live class, so the oracle does not depend on
     what the registry holds at run time. A vendor update moves both sides alike,
@@ -464,7 +464,7 @@ def test_register_alias_refuses_a_name_already_on_the_port(self) -> None:
         self.assertEqual(len(TCP.__registry__.getlist(80)), before)
 
     def test_extend_enum_appends_to_an_occupied_port(self) -> None:
-        """The old ``__members_proto__[proto][port] = obj`` displaced it silently."""
+        """Guards against #732's ``__members_proto__[proto][port] = obj`` displacing a member."""
         import aenum
 
         from pcapkit.const.reg.apptype import UDP, TransportProtocol
@@ -478,9 +478,9 @@ def test_extend_enum_appends_to_an_occupied_port(self) -> None:
         after = [member.svc for member in UDP.__registry__.getlist(80)]
         self.assertEqual(after, ['http', 'www', 'www-http', 'unit-test-80'])
 
-        # Appending must not displace the answer either: the old code overwrote
-        # the bucket, so a third-party registration silently became what every
-        # lookup of that port returned.
+        # Appending must not displace the answer either: #732's assignment
+        # overwrites the bucket, so a third-party registration silently becomes
+        # what every lookup of that port returns.
         self.assertEqual(UDP.get(80).svc, 'http')
         self.assertIn('unit-test-80', [member.svc for member in UDP.get_all(80)])
 
@@ -504,14 +504,13 @@ def test_every_registry_rejects_a_negative_value(self) -> None:
     def test_a_port_lookup_on_the_base_dispatches_by_transport(self) -> None:
         """Which is what keeps every ``AppType.get(port, proto=...)`` caller working.
 
-        9899 -- this test's own port before GitHub issue #860 step 2 PR 2 --
-        is not one SCTP declares, so ``SCTP.get(9899)`` now mints an
-        *unregistered* member on every call: equal, but no longer identical,
-        so ``assertIs`` against a second, independent call would be
+        A port SCTP does not declare, such as 9899, mints an *unregistered*
+        member on every call (GitHub issue #860 step 2 PR 2): equal, but not
+        identical, so ``assertIs`` against a second, independent call would be
         comparing two different objects that merely resolved the same way.
-        9 (``discard``) is a real, declared SCTP member, so identity is
-        still the right check there -- exactly as it remains for 80 on TCP
-        and UDP, both real declared members too.
+        9 (``discard``) is a real, declared SCTP member, so identity is the
+        right check there -- exactly as it is for 80 on TCP and UDP, both real
+        declared members too.
         """
         from pcapkit.const.reg.apptype import SCTP, TCP, UDP, AppType, TransportProtocol
 
@@ -528,11 +527,11 @@ def test_a_port_lookup_on_the_base_dispatches_by_transport(self) -> None:
     def test_a_service_name_is_not_a_port_lookup(self) -> None:
         """GitHub issue #734's junk-minting path is gone rather than fixed.
 
-        The old string branch tested ``key in __members_proto__``, which is keyed
+        The string branch #734 reported tested ``key in __members_proto__``, which is keyed
         by transport protocol, so a name never matched and
         ``AppType.get('ssh')`` returned a **new** member with port ``-1`` instead
         of the one at 22. Nothing in :mod:`pcapkit` resolves a service by name, so
-        it now raises; #734 was closed on that, with the name lookup removed
+        it raises; #734 was closed on that, with the name lookup removed
         rather than repaired.
         """
         from pcapkit.const.reg.apptype import TCP
@@ -563,16 +562,16 @@ def test_unassigned_rows_are_documented_rather_than_declared(self) -> None:
                 self.assertNotIn(-1, [member.port for member in cls])
 
     def test_a_real_port_with_no_transport_no_longer_resolves(self) -> None:
-        """The one deliberate behaviour change, pinned so it cannot happen twice.
+        """The one deliberate behaviour difference from #732's lookup, pinned.
 
         Some registry entries carry a real port with an **empty** transport
-        protocol column, and the old ``_missing_`` consulted them as a fallback
-        tier after the transport-specific lookup missed -- so ``get(51,
-        proto=tcp)`` answered ``reserved``, claiming a TCP assignment IANA never
+        protocol column. A ``_missing_`` that consults them as a fallback tier
+        after the transport-specific lookup misses answers ``get(51,
+        proto=tcp)`` with ``reserved``, claiming a TCP assignment IANA never
         made. They are documented on the base class instead, and the lookup
-        answers an unknown port, which is the honest answer -- since GitHub issue
-        #860 step 2 PR 2, an unregistered one rather than a permanent mint, so
-        there is nothing left for :meth:`_purge_member` to undo (it no-ops when
+        answers an unknown port, which is the honest answer -- an unregistered
+        one rather than a permanent mint (GitHub issue #860 step 2 PR 2), so
+        there is nothing for :meth:`_purge_member` to undo (it no-ops when
         the name it is asked to remove was never added, which is exactly what
         happens here; kept anyway as a harmless guard against a regression
         that reintroduced minting).
@@ -672,9 +671,9 @@ def test_every_transport_named_span_is_claimed_by_one_registry(self) -> None:
         spans that happen to collide: a branch minting a member for a named
         transport protocol is claimed by that registry, and one answering with
         ``cls.__transport__`` claims nothing, since IANA's unassigned and reserved
-        markers belong to whichever registry was asked. Such a branch answered
-        ``undefined`` until GitHub issue #2048, which made it answer with the
-        asking registry's own transport, so none answers ``undefined``.
+        markers belong to whichever registry was asked. Such a branch answers
+        with the asking registry's own transport, not ``undefined`` (GitHub
+        issue #2048).
 
         "Every branch" is checked against the same source parsed with :mod:`ast`:
         the pattern has to find one branch per ``_unregistered_member`` call in
@@ -688,16 +687,15 @@ def test_every_transport_named_span_is_claimed_by_one_registry(self) -> None:
         from pcapkit.const.reg.apptype import AppType
 
         source = inspect.getsource(AppType._missing_.__func__)  # type: ignore[attr-defined]
-        # NOTE: GitHub issue #768 changed the emitted form from
-        # ``TransportProtocol.get('tcp')`` to the attribute access
-        # ``TransportProtocol.tcp``, so the capture is a bare identifier now
-        # rather than a quoted literal. GitHub issue #860 step 2 PR 2 changed
-        # the call itself from ``extend_enum(cls, f'<name>_{value}', value,
-        # '<label>', TransportProtocol.X)`` to
-        # ``cls._unregistered_member(value, '<label>', TransportProtocol.X)``
-        # -- stopping the mint, but leaving every ``if``/``cls.__transport__``
-        # condition this test is actually about untouched, which is why only
-        # the call's own name changed here and not the shape of what follows.
+        # NOTE: the emitted form is the attribute access
+        # ``TransportProtocol.tcp`` (GitHub issue #768), not
+        # ``TransportProtocol.get('tcp')``, so the capture is a bare identifier
+        # rather than a quoted literal. The call is
+        # ``cls._unregistered_member(value, '<label>', TransportProtocol.X)``,
+        # not a minting ``extend_enum(cls, f'<name>_{value}', value,
+        # '<label>', TransportProtocol.X)`` (GitHub issue #860 step 2 PR 2);
+        # the ``if``/``cls.__transport__`` conditions this test is actually
+        # about have the same shape either way.
         branches = re.findall(r'\n        if (.+?):\n            #:.*?\n            '
                               r"return cls\._unregistered_member\(value, .+?, "
                               r'(?:TransportProtocol\.(\w+)|cls\.__transport__)\)',
@@ -729,53 +727,52 @@ def test_every_transport_named_span_is_claimed_by_one_registry(self) -> None:
                     self.assertTrue(condition.endswith(claim), condition)
 
     def test_a_bare_int_composite_is_refused_as_a_whole(self) -> None:
-        """GitHub issue #759's old fix, superseded by the owner's #836 ruling.
-
-        ``TransportProtocol`` dropped its :class:`~aenum.IntFlag` base in GitHub
-        issue #808, so ``tcp | udp`` no longer builds a member at all -- it falls
-        through to ``int.__or__`` and returns a bare :class:`int`. That bare int
-        stays constructible by hand even though no member carries one since
-        GitHub issue #806, which is why this guard is still needed and is tested
-        with composites built here rather than read off a member.
-
-        ``_dispatch`` used to resolve a composite through
-        :func:`~pcapkit.utilities.compat.show_flag_values`, decoding its bits and
-        answering :exc:`~pcapkit.utilities.exceptions.ProtocolError` naming every
-        transport whose bit was set -- the fix for #759, where resolving one by
-        picking the lowest set bit (``tcp``, iterating **LSB-first**) dispatched
-        every composite containing it into the TCP registry whatever else it
-        named. The owner's ruling on #836 retires that decoding
-        instead of refining it: with ``TransportProtocol`` no longer a flag,
-        ``|``-joined values are no longer parsed and accepted, and the value is
+        """A bare-int composite is refused as a whole, per the owner's #836 ruling.
+
+        ``TransportProtocol`` has no :class:`~aenum.IntFlag` base (GitHub issue
+        #808), so ``tcp | udp`` builds no member at all -- it falls through to
+        ``int.__or__`` and returns a bare :class:`int`. That bare int stays
+        constructible by hand even though no member carries one (GitHub issue
+        #806), which is why this guard is needed and is tested with composites
+        built here rather than read off a member.
+
+        GitHub issue #759 was a composite resolved by picking the lowest set bit
+        (``tcp``, iterating **LSB-first**), which dispatched every composite
+        containing it into the TCP registry whatever else it named. #759's fix
+        decoded the bits through
+        :func:`~pcapkit.utilities.compat.show_flag_values` and answered
+        :exc:`~pcapkit.utilities.exceptions.ProtocolError` naming every
+        transport whose bit was set. The owner's ruling on #836 retires that
+        decoding instead of refining it: with ``TransportProtocol`` not a flag,
+        ``|``-joined values are not parsed and accepted, and the value is
         treated as a whole rather than split. A bare-int composite is therefore
         refused exactly like any other value that names no registry -- a stray
         bit, ``undefined``, or a number with nothing to do with any transport
         -- through the one plain :exc:`ValueError` :meth:`AppType._dispatch`
-        already gives those. There is no longer a "too many transports" refusal
+        already gives those. There is no "too many transports" refusal
         distinct from a "no transport" one.
 
-        GitHub issue #860 step 2 PR 2 moved ``TransportProtocol`` off its old
-        power-of-two values onto sequential ones instead (``undefined=0,
-        tcp=1, udp=2, sctp=3, dccp=4``) -- ``undefined`` a direct, explicit
-        ``0``, and ``tcp``/``udp``/``sctp``/``dccp`` continuing from it via
-        ``auto()`` with no ``_start_`` needed, per the owner's own final
-        ruling on this issue. That has one accepted, deliberately
-        *untested* consequence -- a hand-composed ``tcp | udp`` now equals
-        ``sctp`` numerically (``1 | 2 == 3``) and so *resolves* there rather
-        than being refused, where it used to name no member at all. This test
-        is therefore no longer built on the original #759 pair (888,
-        ``tcp | udp``): both the illustrative composite below and the swept
-        ``composites`` list are filtered to the ones that still name no
-        single registry under the current numbering, so this file does not
+        ``TransportProtocol`` takes sequential values, not powers of two
+        (``undefined=0, tcp=1, udp=2, sctp=3, dccp=4``; GitHub issue #860 step
+        2 PR 2) -- ``undefined`` a direct, explicit ``0``, and
+        ``tcp``/``udp``/``sctp``/``dccp`` continuing from it via ``auto()``
+        with no ``_start_`` needed, per the owner's own final ruling on this
+        issue. That has one accepted, deliberately *untested* consequence -- a
+        hand-composed ``tcp | udp`` equals ``sctp`` numerically (``1 | 2 ==
+        3``) and so *resolves* there rather than being refused. This test is
+        therefore not built on #759's own pair (888, ``tcp | udp``): both the
+        illustrative composite below and the swept ``composites`` list are
+        filtered to the ones that name no single registry under this
+        numbering, so this file does not
         become the place that pins the collision the owner said not to test.
         """
         from pcapkit.const.reg.apptype import DCCP, SCTP, TCP, UDP, AppType, TransportProtocol
         from pcapkit.utilities.exceptions import ProtocolError
 
         # 888 carries ``cddbp`` on TCP and ``accessbuilder`` on UDP -- #759's
-        # own reproduction port. The member's own ``proto`` was the ``tcp |
-        # udp`` composite until #806; it is ``udp`` now, and resolving it by
-        # its own single proto is unaffected by the ``auto()`` renumbering.
+        # own reproduction port. The member's own ``proto`` is ``udp``, not a
+        # ``tcp | udp`` composite (#806), and resolving it by its own single
+        # proto does not depend on the ``auto()`` numbering.
         member = next(each for each in UDP.__registry__.getlist(888)
                       if each.svc == 'accessbuilder')
         self.assertIs(member.proto, TransportProtocol.udp)
@@ -825,9 +822,9 @@ def test_a_bare_int_composite_is_refused_as_a_whole(self) -> None:
 
         before = {cls: len(cls) for cls in (TCP, UDP, SCTP, DCCP)}
         for proto in composites:
-            # NOTE: not ``proto.name`` -- ``proto`` is a bare ``int`` since
-            # GitHub issue #808 dropped the ``IntFlag`` base composites used to
-            # be built from, and a bare int has no ``.name``. ``hex`` still
+            # NOTE: not ``proto.name`` -- ``proto`` is a bare ``int``, since
+            # ``TransportProtocol`` has no ``IntFlag`` base (GitHub issue #808),
+            # and a bare int has no ``.name``. ``hex`` still
             # tells the subTests apart on failure.
             with self.subTest(proto=hex(proto)):
                 with self.assertRaises(ValueError) as via_get:
@@ -845,7 +842,7 @@ def test_a_bare_int_composite_is_refused_as_a_whole(self) -> None:
         self.assertEqual({cls: len(cls) for cls in (TCP, UDP, SCTP, DCCP)}, before)
 
         # A single bit resolves, and ``undefined`` is refused the identical way
-        # a composite now is -- there is no longer a distinct refusal for
+        # a composite is -- there is no distinct refusal for
         # "too many transports" versus "no transport".
         self.assertIs(AppType.get(80, proto=TransportProtocol.tcp), TCP.get(80))
         with self.assertRaises(ValueError) as plain:
@@ -859,31 +856,24 @@ def test_a_bare_int_composite_is_refused_as_a_whole(self) -> None:
         self.assertEqual(TCP.get(888, proto=both).svc, 'cddbp')
 
     def test_no_member_carries_a_multi_transport_proto(self) -> None:
-        """GitHub issue #806: the composite that caused #759 is gone at the source.
-
-        This test used to sweep every multi-transport member through
-        ``AppType.get(m.port, proto=m.proto)`` and require each of them to be
-        *refused*, because a member's own ``proto`` was the whole set IANA assigned
-        the service and so named several registries. Retyping ``proto`` to the
-        single transport protocol of the registry the member lives in removes that
-        population outright, and a member's own ``proto`` is now the one thing a
-        lookup can always be given.
-
-        So the assertion inverts. Instead of "every multi-bit member refuses its own
-        ``proto``" it is "no member has a multi-bit ``proto``, and every member
-        resolves under its own" -- which is the same property the old test protected
-        the callers from, established at generation time rather than defended at
-        every entry point.
-
-        The ``(port, service)`` pairs #759 measured are kept and re-checked
-        against the *new* behaviour, because they are the pairs where the defect was
-        observable: each is declared in both the TCP and the UDP registry, and each
-        used to come back as its port's TCP canonical. Every one of them now
-        resolves inside its own registry. The ones whose ``__canonical__`` genuinely
+        """GitHub issue #806: no member carries the composite that caused #759.
+
+        A member's own ``proto`` is the single transport protocol of the registry
+        it lives in, not the whole set IANA assigned the service, so it names one
+        registry and is the one thing a lookup can always be given. The assertion
+        is "no member has a multi-bit ``proto``, and every member resolves under
+        its own" -- a property established at generation time rather than
+        defended at every entry point.
+
+        The ``(port, service)`` pairs #759 measured are re-checked too, because
+        they are the pairs where the defect was observable: each is declared in
+        both the TCP and the UDP registry, and under #759 each came back as its
+        port's TCP canonical. Every one of them resolves inside its own
+        registry. The ones whose ``__canonical__`` genuinely
         disagrees between the registries -- port **888**, ``accessbuilder`` against
         TCP's ``cddbp``, and port **999**, ``puprouter`` against TCP's ``garcon``
         where UDP answers ``applix`` -- were the whole blast radius, and are the
-        sharpest check that the answer now comes from the right registry.
+        sharpest check that the answer comes from the right registry.
 
         Asserted over the whole population rather than over a sample, because the
         population is what the crawler regenerates: a future crawl that adds a
@@ -900,19 +890,16 @@ def test_no_member_carries_a_multi_transport_proto(self) -> None:
         vendor update moves (GitHub issue #1820), so a member the sweep never
         reached still fails it.
 
-        "Multi-bit" used to be checked with :func:`~pcapkit.utilities.compat.
-        show_flag_values`, decoding ``member.proto`` into its set bits --
-        correct only while ``TransportProtocol``'s four real values stayed
-        power-of-two and so each a single, clean bit. GitHub issue #860 step 2
-        PR 2 moved them onto sequential ``auto()`` values instead
-        (``tcp=1, udp=2, sctp=3, dccp=4``), and ``sctp``'s own value, ``3``, is
-        binary ``11`` -- two bits -- despite being every bit as single a
-        member as the other three. A bit-decomposition helper reads that as
-        "multi-bit" regardless of what produced it, so it would flag every one
-        of SCTP's declared members as a false positive under the new
-        numbering. The real invariant was never about bit *shape* in the first
-        place; it is "is this one of the four real transports", checked
-        directly below instead.
+        "Multi-bit" is not checked with :func:`~pcapkit.utilities.compat.
+        show_flag_values`, decoding ``member.proto`` into its set bits:
+        ``TransportProtocol``'s real values are sequential ``auto()`` values
+        (``tcp=1, udp=2, sctp=3, dccp=4``; GitHub issue #860 step 2 PR 2), and
+        ``sctp``'s own value, ``3``, is binary ``11`` -- two bits -- despite
+        being every bit as single a member as the others. A bit-decomposition
+        helper reads that as "multi-bit" regardless of what produced it, so it
+        would flag every one of SCTP's declared members as a false positive.
+        The invariant is not about bit *shape*; it is "is this one of the real
+        transports", checked directly below.
         """
         from pcapkit.const.reg.apptype import DCCP, SCTP, TCP, UDP, AppType, TransportProtocol
 
@@ -943,8 +930,8 @@ def test_no_member_carries_a_multi_transport_proto(self) -> None:
 
         # The ``(port, service)`` pairs #759 measured, kept so the sweep above is
         # not the only thing pinning the fix. Each is a member of both the TCP and
-        # the UDP registry, so each is looked up in both, and each used to answer
-        # from TCP whichever registry it was declared in.
+        # the UDP registry, so each is looked up in both; under #759 each
+        # answered from TCP whichever registry it was declared in.
         mismatched = (
             (42, 'name'), (63, 'whoispp'), (80, 'www'), (80, 'www-http'), (105, 'cso'),
             (351, 'bhoetty'), (352, 'bhoedap4'), (666, 'doom'), (888, 'accessbuilder'),
@@ -963,9 +950,9 @@ def test_no_member_carries_a_multi_transport_proto(self) -> None:
                 with self.subTest(registry=cls.__name__, port=port, svc=svc):
                     member = next(each for each in cls.__registry__.getlist(port)
                                   if each.svc == svc)
-                    # A real, single transport and its own registry's, where
-                    # it used to be the ``tcp | udp`` composite these pairs
-                    # all carried.
+                    # A real, single transport and its own registry's, not
+                    # the ``tcp | udp`` composite these pairs all carried
+                    # under #759.
                     self.assertIn(member.proto, real_transports)
                     self.assertIs(member.proto, cls.__transport__)
                     # And passing it back in resolves inside that registry rather
@@ -977,13 +964,13 @@ def test_no_member_carries_a_multi_transport_proto(self) -> None:
                     # And the member is still reachable, under its own transport.
                     self.assertIn(member, cls.get_all(port))
 
-                    # NOTE: the blast radius, still named. ``tcp`` was the lowest
-                    # bit of every one of them, so the TCP registry's answer is
-                    # what the composite used to resolve to; where that differs
-                    # from the member's own registry's answer, the lookup returned
-                    # a service that registry does not answer at all. Those are the
-                    # rows below, and they are now answered from UDP as they
-                    # should be.
+                    # NOTE: the blast radius, still named. ``tcp`` is the lowest
+                    # bit of a ``tcp | udp`` composite, so the TCP registry's
+                    # answer is what #759's lowest-bit dispatch resolved it to;
+                    # where that differs from the member's own registry's
+                    # answer, that lookup returned a service the registry does
+                    # not answer at all. Those are the rows below, answered
+                    # from UDP as they should be.
                     if TCP.get(port).svc != cls.get(port).svc:
                         divergent.append((cls.__name__, port, svc,
                                           TCP.get(port).svc, cls.get(port).svc))
@@ -1008,38 +995,32 @@ def test_one_transport_protocol_still_resolves_every_port_it_resolved_before(sel
         :func:`_declared`), compared rather than pinned as counts, which every
         vendor update moves (GitHub issue #1820). These are easy to confuse:
 
-        * the declared members, every one of which now carries a single-bit
-          ``.proto``. Most carried a multi-bit one until GitHub issue #806
-          retyped ``proto`` to the registry's own transport protocol. That is a
+        * the declared members, every one of which carries a single-bit
+          ``.proto``: its registry's own transport protocol (GitHub issue
+          #806). That is a
           property of the *members*, and it is not what this test partitions on;
         * the distinct ``(registry, port)`` pairs they sit on, which are fewer,
           since some members share a port with another service, as IANA's
           services on TCP/80 do;
         * so the sweep below makes one lookup per distinct pair, each passing
-          **one** transport protocol, which is now also what every member's own
+          **one** transport protocol, which is also what every member's own
           ``.proto`` holds.
 
-        The sweep resolves each ``(registry, port)`` to the same member either side
-        of #806, since the lookup key is the port and the registry and neither
-        moved. What #806 does change is the *resolved member's* ``.proto``, so a
-        digest over ``registry|port|resolved service|int(resolved proto)`` is not
-        invariant across it and is deliberately not asserted here; the member-by-
-        member rendering is pinned by
+        A digest over ``registry|port|resolved service|int(resolved proto)`` is
+        deliberately not asserted here: the lookup key is the port and the
+        registry, but the digest also moves whenever a *resolved member's*
+        ``.proto`` is retyped, as #806 did. The member-by-member rendering is pinned by
         ``test_every_member_renders_its_own_registrys_transport_protocol`` instead.
 
         Declared members only, filtered by ``svc != 'unknown'`` -- the label
         every mint (:meth:`AppType._missing_`'s own fallback and ``get()``'s
-        second mint site alike) carries and no generated member does. That
-        filter used to matter across test order as well as within this one:
-        before GitHub issue #860 step 2 PR 2, an unassigned lookup minted a
-        real, permanent member via :func:`~aenum.extend_enum`, so
-        ``AppType.get(9899, proto=sctp)`` in
-        ``test_a_port_lookup_on_the_base_dispatches_by_transport`` used to
-        leave one behind for whichever test ran next to trip over. It no
-        longer does -- an unregistered member is never added to
-        ``__members__`` at all -- so ``list(cls)`` here would already exclude
-        it without the filter; the filter is kept anyway, both because it
-        costs nothing and because a regression that reintroduced minting
+        second mint site alike) carries and no generated member does. An
+        unregistered member is never added to ``__members__`` at all (GitHub
+        issue #860 step 2 PR 2), so ``list(cls)`` here would already exclude it
+        without the filter; the filter is kept anyway, both because it costs
+        nothing and because a regression that reintroduced minting -- an
+        unassigned lookup leaving a real, permanent member behind via
+        :func:`~aenum.extend_enum` for whichever test runs next to trip over --
         would otherwise surface here as other tests' leftovers in the
         population compared below, rather than through the before-and-after
         size check, which is about this test's own sweep.
@@ -1111,15 +1092,15 @@ def test_no_lookup_call_site_in_the_library_builds_a_composite_proto(self) -> No
         no import of :mod:`pcapkit.protocols` -- whose runtime dependencies this
         tier does not gate on.
 
-        :func:`~pcapkit.foundation.registry.register_apptype` used to be the one
-        place that handled a member's *composite* ``proto``, reading it off
-        ``code.proto`` and testing it with ``in`` to fan out across the TCP and UDP
-        protocol registries. GitHub issue #806 removed both halves of that: the
-        member's ``proto`` is a single transport protocol, and the function takes
-        ``*transport`` varargs, so it iterates the transports it was given and looks
-        each one up in a mapping. The two source strings the fan-out was pinned by
-        -- ``proto = code.proto`` and ``if test not in proto:`` -- are therefore
-        asserted **absent**, and the new shape asserted present, so that a
+        Guards against :func:`~pcapkit.foundation.registry.register_apptype`
+        handling a member's *composite* ``proto``, reading it off ``code.proto``
+        and testing it with ``in`` to fan out across the TCP and UDP protocol
+        registries (GitHub issue #806). The member's ``proto`` is a single
+        transport protocol, and the function takes ``*transport`` varargs, so it
+        iterates the transports it was given and looks each one up in a mapping.
+        The two source strings the fan-out was pinned by -- ``proto =
+        code.proto`` and ``if test not in proto:`` -- are therefore asserted
+        **absent**, and the varargs shape asserted present, so that a
         reintroduced fan-out cannot pass this test.
         """
         import pathlib
@@ -1230,12 +1211,12 @@ def test_no_lookup_call_site_in_the_library_builds_a_composite_proto(self) -> No
         ])
 
         # ``register_apptype`` takes the transports one at a time and resolves each
-        # against a mapping, so neither half of the old fan-out may reappear. The
-        # *shape* is pinned below on the live signature instead of here: a literal
-        # ``*transport: 'TransportProtocol', class_: ...`` snippet would re-break on
-        # every future change to the annotation (it already broke once, when the
-        # #815 ruling added ``| str``) despite the shape it exists to protect never
-        # having changed at the source-text level it was reading.
+        # against a mapping, so neither half of a fan-out may appear. The *shape*
+        # is pinned below on the live signature instead of here: a literal
+        # ``*transport: 'TransportProtocol', class_: ...`` snippet breaks on every
+        # change to the annotation (such as the ``| str`` the #815 ruling asks
+        # for) even when the shape it exists to protect is the same at the
+        # source-text level it reads.
         source = (root / 'pcapkit' / 'foundation' / 'registry' / 'protocols.py').read_text(encoding='utf-8')
         self.assertNotIn('proto = code.proto', source)
         self.assertNotIn('if test not in proto:', source)
@@ -1244,10 +1225,9 @@ def test_no_lookup_call_site_in_the_library_builds_a_composite_proto(self) -> No
 
         # Its signature, checked on the live object rather than on the text, since
         # the text above cannot show what the parameters bind to. ``class_`` is
-        # positional again, at the sibling position ahead of ``*transport`` --
-        # further maintainer ruling on #815, reversing the keyword-only shape this
-        # test used to pin -- restoring consistency with ``register_tcp`` and its
-        # siblings.
+        # positional, at the sibling position ahead of ``*transport`` -- a
+        # further maintainer ruling on #815, over a keyword-only shape --
+        # consistent with ``register_tcp`` and its siblings.
         from pcapkit.foundation.registry.protocols import register_apptype
 
         parameters = inspect.signature(register_apptype).parameters
@@ -1257,8 +1237,8 @@ def test_no_lookup_call_site_in_the_library_builds_a_composite_proto(self) -> No
 
         # Pure ``bind()`` is purely positional: it cannot see what ``module`` *is*,
         # so a third positional argument lands in ``class_`` regardless -- the very
-        # swallow the keyword-only shape used to prevent. That the swallow does not
-        # actually happen any more is not a fact ``bind()`` can show, because the
+        # swallow a keyword-only shape would prevent. That the swallow does not
+        # actually happen is not a fact ``bind()`` can show, because the
         # disambiguation runs in the function body, keyed on ``type(module)``, and
         # only takes place once ``register_apptype`` actually executes.
         from pcapkit.const.reg.apptype import TransportProtocol
@@ -1303,11 +1283,11 @@ def test_the_new_dunders_are_byte_identical_to_the_percent_form(self) -> None:
         modules declare (see :func:`_declared`) rather than against counts a
         vendor update moves (GitHub issue #1820), but only
         :func:`_dunder_sample` is formatted, each member compared
-        against what the pre-#798 ``%``-style formula would have produced for
-        that same member's own ``svc``/``port``/``proto``. This
-        is an invariance check -- it is true either side of #798's fix by
-        construction, since both formulas render the same text for the same
-        inputs -- rather than a regression test that fails on stock ``main``.
+        against what the ``%``-style formula would produce for that same
+        member's own ``svc``/``port``/``proto``. This is an invariance check
+        -- it holds with or without #798's fix by construction, since both
+        formulas render the same text for the same inputs -- rather than a
+        regression test that fails without the fix.
 
         Runs against a freshly imported, purged-and-restored ``pcapkit`` tree
         (as :class:`~tests.const.test_const_enum_builtin_parity.ConstEnumBuiltinParityTests`
@@ -1378,10 +1358,10 @@ def test_every_member_renders_its_own_registrys_transport_protocol(self) -> None
         Checked against the formula rather than against the member's own ``proto``:
         the expected text is built from ``cls.__transport__``, which is declared once
         per registry and is independent of what any member carries. That is what
-        makes this fail on stock ``4530424df``, where most members render a
+        makes this fail without #806's fix, under which most members render a
         composite -- ``test_the_new_dunders_are_byte_identical_to_the_percent_form``
-        derives its expectation from ``member.proto`` instead and so is invariant
-        across this change by construction.
+        derives its expectation from ``member.proto`` instead and so passes
+        whatever ``proto`` a member carries, by construction.
 
         Swept over every declared member of every per-transport registry rather than
         spot-checked, since the blast radius is most of the enumeration. That the
@@ -1438,50 +1418,45 @@ class creation, and aliases are registerable at runtime.
         self.assertEqual(len(wrong), 0)
 
     def test_transport_protocol_dropped_its_flag_base(self) -> None:
-        """GitHub issue #808: the base itself, once #806 removed every composite.
+        """GitHub issue #808: the base itself, with no member carrying a composite (#806).
 
         Pins three things directly, so a regression that reintroduces the
         ``IntFlag`` base or renumbers the four transports fails here rather
         than only in the ``_dispatch`` refusal tests above:
 
         * ``TransportProtocol`` is a plain :class:`~aenum.IntEnum`, not a
-          :class:`~enum.Flag` of any kind -- ``&``, ``^`` and ``~`` are gone
-          along with ``|``'s member-composing behaviour.
-        * ``tcp | udp`` no longer builds a named member: it falls through to
+          :class:`~enum.Flag` of any kind -- none of ``|``, ``&``, ``^`` and
+          ``~`` composes a member.
+        * ``tcp | udp`` builds no named member: it falls through to
           ``int.__or__`` and returns a bare :class:`int`, so ``.name`` on the
           result raises :class:`AttributeError` rather than answering
           ``'tcp|udp'``.
-        * At the time #808 landed, the five members kept the exact integer
-          values they had as Flag bits -- ``undefined`` 0, ``tcp`` 1, ``udp``
-          2, ``sctp`` 4, ``dccp`` 8 -- since #808 was about the base class,
-          not about renumbering members that predated it. GitHub issue #860
-          step 2 PR 2 is the renumbering #808 deliberately left for later:
-          once ``|``-joined values stopped being parsed at all (the owner's
-          further ruling on that same PR), the power-of-two spacing had
-          nothing left to protect, so the five now number sequentially from
-          0 instead -- ``undefined`` a direct, explicit ``0``, and
-          ``tcp``/``udp``/``sctp``/``dccp`` continuing from it via
-          ``auto()`` with no ``_start_`` needed -- ``sctp`` 3, ``dccp`` 4,
-          the other three unchanged since they were already sequential
-          from 0.
-
-        Fails on stock ``ad4805f5f``: ``TransportProtocol`` there is still an
-        ``IntFlag``, so ``issubclass(TransportProtocol, enum.Flag)`` is
-        ``True``, and ``TransportProtocol.tcp | TransportProtocol.udp`` is a
-        genuine composite member whose ``.name`` answers ``'tcp|udp'`` rather
-        than raising :class:`AttributeError`.
-
-        Also pins a change to plain iteration that is easy to miss because
-        every *member's* own ``repr``/``str``/``.name``/``.value`` stay
-        byte-identical: :class:`~enum.Flag` hides a zero-valued canonical
-        member from ``list(cls)``/``for m in cls``, so stock iterates
-        ``undefined`` out and yields the four real transports alone. A plain
-        :class:`~aenum.IntEnum` has no such convention and yields all five.
+        * The members number sequentially from 0 -- ``undefined`` a direct,
+          explicit ``0``, and ``tcp``/``udp``/``sctp``/``dccp`` continuing
+          from it via ``auto()`` with no ``_start_`` needed, so ``tcp`` 1,
+          ``udp`` 2, ``sctp`` 3, ``dccp`` 4 (GitHub issue #860 step 2 PR 2).
+          #808 was about the base class alone; the power-of-two spacing of
+          Flag bits has nothing to protect once ``|``-joined values are not
+          parsed at all (the owner's further ruling on that same PR).
+
+        Guards against an ``IntFlag`` ``TransportProtocol``, under which
+        ``issubclass(TransportProtocol, enum.Flag)`` is ``True`` and
+        ``TransportProtocol.tcp | TransportProtocol.udp`` is a genuine
+        composite member whose ``.name`` answers ``'tcp|udp'`` rather than
+        raising :class:`AttributeError`.
+
+        Also pins plain iteration, which is easy to miss because every
+        *member's* own ``repr``/``str``/``.name``/``.value`` is byte-identical
+        either way: :class:`~enum.Flag` hides a zero-valued canonical member
+        from ``list(cls)``/``for m in cls``, so an ``IntFlag``
+        ``TransportProtocol`` iterates ``undefined`` out and yields the real
+        transports alone. A plain
+        :class:`~aenum.IntEnum` has no such convention and yields every member.
         Nothing in :mod:`pcapkit` iterates ``TransportProtocol`` bare --
         ``apptype.py``'s own ``__init__.py`` populates ``__registries__``
-        through ``__members__`` (5 either way, unaffected), never through
-        iteration -- so this is a correctness fact about the change worth
-        pinning, not a defect to fix.
+        through ``__members__`` (the same either way), never through
+        iteration -- so this is a correctness fact worth pinning, not a
+        defect to fix.
         """
         import enum
 
@@ -1503,53 +1478,41 @@ def test_transport_protocol_dropped_its_flag_base(self) -> None:
               TransportProtocol.sctp, TransportProtocol.dccp)},
             {'undefined': 0, 'tcp': 1, 'udp': 2, 'sctp': 3, 'dccp': 4})
 
-        # 5 rather than 4: undefined is no longer hidden from iteration. Stock
-        # ad4805f5f gives 4 here (tcp, udp, sctp, dccp only), so this half of
-        # the test would also fail there, on a different assertion than the
-        # ones above.
+        # undefined is not hidden from iteration. An IntFlag TransportProtocol
+        # hides it (tcp, udp, sctp, dccp only), so this half of the test fails
+        # under one too, on a different assertion than the ones above.
         self.assertEqual(len(list(TransportProtocol)), 5)
         self.assertEqual(len(TransportProtocol.__members__), 5)
 
     def test_get_refuses_an_unrecognised_name_rather_than_minting_it(self) -> None:
         """Maintainer ruling on #836, the ``TransportProtocol.get`` inline comment.
 
-        ``TransportProtocol.get`` used to mint a brand-new member for any
-        name it did not recognise. #836's own prior revision minted at
-        ``max_val + 1`` -- right after ``dccp``'s 8, so ``.get('bogus')``
-        minted 9 -- rather than stock ``ad4805f5f``'s ``max_val * 2``
-        doubling, which mints 16 for that same call; the difference between
-        the two schemes is explained below. The maintainer's ruling, given in
-        an inline review comment on #836, refuses minting outright either
-        way: ``TransportProtocol`` is not to be extended at all. There is no
-        bound left to walk and nothing left to mint, so the refusal is the one
-        plain :class:`ValueError` every unrecognised name gets, whether or not
-        it happens to spell a composite like ``'tcp|udp'``. A later round of
-        #836 briefly gave the composite case its own, more specific message;
-        the owner's ruling retired that split too -- with ``TransportProtocol``
-        no longer a flag, ``|``-joined values are no longer parsed and
-        accepted, and the value is treated as a whole rather than split -- so
-        ``'|'`` is not treated specially any more, here or in
-        :meth:`AppType._dispatch` (see
+        The maintainer's ruling, given in an inline review comment on #836:
+        ``TransportProtocol`` is not to be extended at all, so
+        ``TransportProtocol.get`` refuses a name it does not recognise rather
+        than minting a brand-new member for it. There is no bound to walk and
+        nothing to mint, so the refusal is the one plain :exc:`KeyError` every
+        unrecognised name gets, whether or not it happens to spell a composite
+        like ``'tcp|udp'`` -- with ``TransportProtocol`` not a flag,
+        ``|``-joined values are not parsed and accepted, and the value is
+        treated as a whole rather than split -- so ``'|'`` is not treated
+        specially, here or in :meth:`AppType._dispatch` (see
         ``test_a_bare_int_composite_is_refused_as_a_whole``).
 
-        This also retires a sharper defect the old minting scheme created,
-        which is what this test used to be named for: 9 is exactly ``1 | 8``,
-        the bits ``tcp`` and ``dccp`` declare, so an intermediate round of
-        this same PR -- after minting had already moved to ``max_val + 1``
-        but before this ruling -- decoded every ``proto`` reaching
-        :meth:`AppType._dispatch` through
-        :func:`~pcapkit.utilities.compat.show_flag_values` regardless of
-        whether it was a genuine member, and answered "tcp|dccp names 2
-        transport protocols" for a name that named neither. That shape never
-        shipped in stock ``ad4805f5f``, whose ``max_val * 2`` doubling kept
-        every minted value a fresh single bit, and it cannot happen now
-        either, from the other direction: refusing the mint outright leaves
-        :meth:`AppType._dispatch` nothing minted to mis-decode in the first
-        place.
-
-        Regression check: this fails against #836's own prior head,
-        ``3567359e2``, which still mints ``9`` and returns it rather than
-        raising.
+        Minting also opens a sharper defect. Under power-of-two numbering, a
+        mint at ``max_val + 1`` -- right after ``dccp``'s 8 -- makes
+        ``.get('bogus')`` mint 9, which is exactly ``1 | 8``, the bits ``tcp``
+        and ``dccp`` declare there. A :meth:`AppType._dispatch` that decodes
+        every ``proto`` through
+        :func:`~pcapkit.utilities.compat.show_flag_values`, genuine member or
+        not, then answers "tcp|dccp names 2 transport protocols" for a name
+        that named neither. (A ``max_val * 2`` doubling mints 16 instead,
+        keeping every minted value a fresh single bit.) Refusing the mint
+        outright leaves :meth:`AppType._dispatch` nothing minted to
+        mis-decode in the first place.
+
+        Without the refusal, ``TransportProtocol.get`` mints a member for an
+        unrecognised name and returns it rather than raising.
         """
         from pcapkit.utilities.exceptions import ProtocolError
 
@@ -1558,14 +1521,13 @@ def test_get_refuses_an_unrecognised_name_rather_than_minting_it(self) -> None:
         self.assertNotIn('unit_test_836_bogus', TransportProtocol.__members__)
         before = len(TransportProtocol.__members__)
 
-        # KeyError-shaped since GitHub issue #923 retired this override's
-        # ``KeyError`` -> ``ValueError`` conversion; the message is unchanged,
-        # and so is what this test is about -- refused, not minted.
+        # KeyError-shaped: this override does no ``KeyError`` -> ``ValueError``
+        # conversion (GitHub issue #923). What this test is about is refused,
+        # not minted.
         with self.assertRaises(KeyError) as caught:
             TransportProtocol.get('unit_test_836_bogus')
-        # Not the ProtocolError the old show_flag_values-based decoding
-        # briefly answered with for a minted 9, back before this ruling
-        # retired minting entirely.
+        # Not the ProtocolError a show_flag_values-based decoding answers for
+        # a minted 9 (see the docstring).
         self.assertNotIsInstance(caught.exception, ProtocolError)
         self.assertIn('unit_test_836_bogus', str(caught.exception))
         self.assertIn('is not a valid', str(caught.exception))
@@ -1582,28 +1544,26 @@ def test_get_refuses_an_unrecognised_name_rather_than_minting_it(self) -> None:
     def test_get_refuses_a_composite_spelled_string(self) -> None:
         """A ``'|'``-joined name is just another unrecognised name.
 
-        :meth:`TransportProtocol.get` used to mint whatever string it did not
-        recognise, including one spelling a composite -- ``'tcp|udp'`` -- as a
-        brand-new, single-bit member whose own name lies about being one
-        transport. That member's value would then satisfy the bare-int
-        composite branch :meth:`AppType._dispatch` used to have just as
+        Guards against :meth:`TransportProtocol.get` minting a string spelling
+        a composite -- ``'tcp|udp'`` -- as a brand-new, single-bit member whose
+        own name lies about being one transport. A bare-int composite branch
+        in :meth:`AppType._dispatch` would accept that member's value just as
         readily as a genuinely OR-ed value, the mirror image of the
-        minted-member defect above -- and that branch is gone now too (see
-        ``test_a_bare_int_composite_is_refused_as_a_whole``).
+        minted-member defect above; :meth:`AppType._dispatch` has no such
+        branch (see ``test_a_bare_int_composite_is_refused_as_a_whole``).
         :func:`~pcapkit.foundation.registry.protocols.register_apptype` refuses
         the identical string the same generic way it refuses any other
         unrecognised one, and the owner's ruling on #836 -- with
-        ``TransportProtocol`` no longer a flag, ``|``-joined values are no
-        longer parsed and accepted, and the value is treated as a whole rather
-        than split -- settles :meth:`TransportProtocol.get` onto that same
-        answer: ``'|'`` is not special, it is simply not the name of a declared
-        member. A review round of #836 briefly carved the composite case out
-        with its own diagnostic message; the owner's ruling retired that too.
+        ``TransportProtocol`` not a flag, ``|``-joined values are not parsed
+        and accepted, and the value is treated as a whole rather than split --
+        settles :meth:`TransportProtocol.get` onto that same answer: ``'|'`` is
+        not special, it is simply not the name of a declared member, and the
+        composite case gets no diagnostic message of its own.
         """
         from pcapkit.const.reg.apptype import TransportProtocol
 
         self.assertNotIn('tcp|udp', TransportProtocol.__members__)
-        # KeyError-shaped since GitHub issue #923; see
+        # KeyError-shaped (GitHub issue #923); see
         # ``test_get_refuses_an_unrecognised_name_rather_than_minting_it``.
         with self.assertRaises(KeyError) as caught:
             TransportProtocol.get('tcp|udp')
@@ -1614,15 +1574,14 @@ def test_get_refuses_a_composite_spelled_string(self) -> None:
     def test_a_bare_int_with_a_stray_bit_names_no_registry_either(self) -> None:
         """A stray bit gets the exact same refusal a clean composite does.
 
-        ``17`` is ``1 | 16`` -- ``tcp`` plus a bit no registry declares -- so
-        it never named a clean composite of real transports the way ``3``
-        (``tcp | udp``) once did either, back when ``_dispatch`` still
-        decoded a bare int's bits at all. The owner's ruling on #836
-        retired that decoding entirely (see
-        ``test_a_bare_int_composite_is_refused_as_a_whole``), so ``17`` and
-        ``3`` are no longer two different cases -- both are simply an
-        ``int`` that names no registry, and both get the identical plain
-        ``ValueError`` any other unmatched value gets.
+        ``17`` is ``1 | 16`` -- ``tcp`` plus a bit no registry declares.
+        ``_dispatch`` decodes no bare int's bits, per the owner's ruling on
+        #836 (see ``test_a_bare_int_composite_is_refused_as_a_whole``), so a
+        stray bit is not a case of its own: ``17`` is simply an ``int`` that
+        names no registry, and gets the identical plain ``ValueError`` any
+        other unmatched value gets -- as does a composite matching no member,
+        such as ``tcp | dccp`` (``5``; see
+        ``test_a_bare_int_composite_is_refused_as_a_whole``).
         """
         from pcapkit.const.reg.apptype import AppType
         from pcapkit.utilities.exceptions import ProtocolError
diff --git a/tests/const/test_const_enum_builtin_parity.py b/tests/const/test_const_enum_builtin_parity.py
index eb2cb244a9..b677f56965 100644
--- a/tests/const/test_const_enum_builtin_parity.py
+++ b/tests/const/test_const_enum_builtin_parity.py
@@ -25,15 +25,15 @@
   :exc:`AttributeError` (``'int' object has no attribute 'upper'``) rather than
   :exc:`ValueError`.
 
-All six now carry a guard raising a bare :exc:`ValueError`, emitted by their
+All six carry a guard raising a bare :exc:`ValueError`, emitted by their
 templates under :mod:`pcapkit.vendor` rather than hand-written -- the tree is
 generated, so a fix that is not in the template is reverted by the next crawl.
 
 The one divergence from the built-in the owner named was the *mutable*
 registries': look a value up, miss, and then **register** it with
-:func:`~aenum.extend_enum` instead of raising. GitHub issues #775 and #860
-retired it, so a miss resolves to an equal, unregistered member instead, and
-only :class:`~pcapkit.const.mh.cga_type.CGAType` still extends on a miss.
+:func:`~aenum.extend_enum` instead of raising. Per GitHub issues #775 and #860,
+a miss resolves to an equal, unregistered member instead, and only
+:class:`~pcapkit.const.mh.cga_type.CGAType` extends on a miss.
 :class:`ConstEnumRegisterFallbackTests` pins that, and that no guard turns the
 lookup into an outright crash -- the failure mode GitHub issues #584 and #623
 are both about.
@@ -75,7 +75,7 @@
 UNRESOLVABLE = 1 << 70
 
 #: The six registries GitHub issue #647 converged, as ``(module, class name,
-#: what the pre-fix lookup did with an invalid value)``. Named individually as
+#: what the lookup did with an invalid value without the fix)``. Named individually as
 #: well as swept, so a regression reports *which* registry came apart rather
 #: than only that the sweep shrank.
 ISSUE_647_OUTLIERS = (
@@ -99,13 +99,13 @@
 #: "Unassigned" spans that a capture can legitimately contain. They still
 #: reject a *negative* value, which no span covers.
 #:
-#: Only :class:`~pcapkit.const.mh.cga_type.CGAType` still ends in
+#: Only :class:`~pcapkit.const.mh.cga_type.CGAType` ends in
 #: :func:`~aenum.extend_enum` (its mint is not an IANA-style range at all, so
-#: the #775/#847 ruling never touched it).
+#: the #775/#847 ruling does not cover it).
 #: :class:`~pcapkit.const.ipv4.protection_authority.ProtectionAuthority`
-#: resolves the same way but no longer *registers* -- its bare ``Unassigned``
-#: converted, so it now goes through ``_unregistered_member`` and the
-#: resolution is not permanent; see
+#: resolves the same way but does not *register* -- its bare ``Unassigned``
+#: goes through ``_unregistered_member``, so the resolution is not
+#: permanent; see
 #: :meth:`ConstEnumRegisterFallbackTests.test_protection_authority_now_
 #: resolves_without_extending`. The name is kept for both because this set's
 #: own test only checks "does it raise", not "does it grow".
@@ -349,7 +349,7 @@ def setUpClass(cls) -> None:
         # The out-of-range probe below registers a junk member on the two
         # auto-extending registries, which are module-global classes. Restore
         # the region to what it held before this class purged it, rather than
-        # purging again (as this used to do, GitHub issue #720): a second purge
+        # purging again (GitHub issue #720): a second purge
         # cannot achieve "pollution cannot reach another module" -- it just
         # leaves the region empty for whoever runs next, exactly the gap #720
         # reports, whereas restoring rebinds it straight back to the pristine,
@@ -474,7 +474,7 @@ def test_an_out_of_range_value_is_rejected_unless_the_registry_registers_it(self
                                                       f'{raised.__name__ if raised else None}')
 
     def test_the_registries_named_in_issue_647(self) -> None:
-        """The six outliers, by name, with what each used to do."""
+        """The six outliers, by name, with what each did without the fix."""
         for module_name, class_name, before in ISSUE_647_OUTLIERS:
             with self.subTest(enum=f'{module_name}.{class_name}', before=before):
                 obj = getattr(importlib.import_module(module_name), class_name)
@@ -513,12 +513,12 @@ def test_every_new_guard_is_a_classmethod(self) -> None:
         # The six of issue #647 specifically, since the sweep above would still
         # pass if they had no ``_missing_`` at all -- which was the defect.
         #
-        # ``TransportProtocol`` is the one deliberate exception: GitHub issue
-        # #808 dropped its ``IntFlag`` base once nothing built a composite, and
-        # with it the custom ``_missing_`` this guard checks for -- a plain
-        # ``IntEnum``'s own default ``_missing_`` already rejects everything
-        # undeclared, so declaring one here would only reproduce the base
-        # class. Its ``-1`` rejection is still checked, just not through this
+        # ``TransportProtocol`` is the one deliberate exception: it has no
+        # ``IntFlag`` base (GitHub issue #808), and so no custom ``_missing_``
+        # for this guard to check -- a plain ``IntEnum``'s own default
+        # ``_missing_`` already rejects everything undeclared, so declaring one
+        # here would only reproduce the base class. Its ``-1`` rejection is
+        # checked, just not through this
         # guard shape; see ``test_the_registries_named_in_issue_647`` above,
         # which does not skip it.
         for module_name, class_name, _ in ISSUE_647_OUTLIERS:
@@ -573,7 +573,7 @@ def test_tcp_flag_composites_resolve(self) -> None:
                 self.assertEqual(Flags(composite), Flags[first] | Flags[second])
 
         # Every declared bit at once is the widest legitimate value, and it is
-        # what Flags(-1) used to return.
+        # what Flags(-1) returns without the #647 guard.
         every = 0
         for member in Flags:
             every |= int(member)
@@ -591,15 +591,13 @@ def test_tcp_flag_composites_resolve(self) -> None:
         self.assertEqual(int(Flags(1)), 1)
 
     def test_the_other_flag_registry_composes(self) -> None:
-        """GitHub issue #808 dropped ``TransportProtocol`` out of this group.
-
-        This used to test ``TransportProtocol`` here too, as the third
-        registry in the codebase sharing Flag semantics alongside ``Flags``
-        (:class:`ConstFlagCompositeTests` above) and ``CommandType``. #808
-        dropped ``TransportProtocol``'s ``IntFlag`` base once nothing built a
-        composite, so it no longer belongs to this group; its own -- now
-        negative -- assertions live in
-        :meth:`test_transport_protocol_no_longer_composes` below instead.
+        """``CommandType`` composes; ``TransportProtocol`` is not in this group.
+
+        ``TransportProtocol`` has no ``IntFlag`` base (GitHub issue #808), so it
+        does not share Flag semantics with ``Flags``
+        (:class:`ConstFlagCompositeTests` above) and ``CommandType``; its own,
+        negative, assertions live in
+        :meth:`test_transport_protocol_no_longer_composes` below.
         """
         from pcapkit.const.ftp.command import CommandType
 
@@ -609,16 +607,16 @@ def test_the_other_flag_registry_composes(self) -> None:
             CommandType(0x08)
 
     def test_transport_protocol_no_longer_composes(self) -> None:
-        """GitHub issue #808: dropping the ``IntFlag`` base removed composing.
-
-        ``TransportProtocol(0x0F)`` used to equal the union of all four
-        declared bits, and ``TransportProtocol(0x10)`` -- one past the widest
-        legitimate combination -- was rejected by the range check
-        ``_missing_`` used to carry. Both mechanisms are gone now rather than
-        dormant: a plain :class:`~aenum.IntEnum` recognises only the five
-        declared values, so any other integer -- in range for the old bound
-        or not -- is rejected by the base class's own default ``_missing_``,
-        with no custom one declared here to widen it.
+        """GitHub issue #808: without an ``IntFlag`` base, nothing composes.
+
+        Guards against the ``IntFlag`` shape, under which, with power-of-two
+        values, ``TransportProtocol(0x0F)`` equals the union of the declared
+        bits and ``TransportProtocol(0x10)`` -- one past the widest legitimate
+        combination -- is rejected by a custom ``_missing_`` range check. A
+        plain :class:`~aenum.IntEnum` has neither mechanism: it recognises
+        only the declared values, so any other integer -- inside that range
+        check's bound or not -- is rejected by the base class's own default
+        ``_missing_``, with no custom one declared here to widen it.
         """
         from pcapkit.const.reg.apptype import TransportProtocol
 
@@ -653,19 +651,18 @@ def test_a_bounded_flag_matches_the_built_in_under_its_strict_boundary(self) ->
 
 
 class ConstEnumRegisterFallbackTests(unittest.TestCase):
-    """A once-sanctioned divergence, now retired for these three specific
-    registries.
+    """A once-sanctioned divergence, retired for these specific registries.
 
     The owner's design intent, recorded on GitHub issue #647, was for the const
     enums to mirror the built-in enum's behaviour with one exception: a missing
     value falls back to registering it (the mutable enums). :class:`~pcapkit.const.http.method.Method`,
     :class:`~pcapkit.const.ftp.command.Command`,
     :class:`~pcapkit.const.ftp.command.FEATCode` and
-    :class:`~pcapkit.const.reg.apptype.apptype.AppType` (with its four
-    transport subclasses) were, until GitHub issue #860 step 2, the last
-    registries still living that divergence for an *unrecognised* value
-    (every numeric registry had already lost it under #775/#847's ruling).
-    GitHub issue #860 is where the owner retired it for all of them:
+    :class:`~pcapkit.const.reg.apptype.apptype.AppType` (with its
+    transport subclasses) are the registries GitHub issue #860 step 2
+    covers for an *unrecognised* value (every numeric registry is covered
+    by #775/#847's ruling). GitHub issue #860 is where the owner retired
+    the divergence for all of them:
     ``get()`` must not mint, because only ``register()`` may create a new
     registry entry, and for these registries only IANA-registered values
     are legitimate -- ``get()`` does not have enough information to build
@@ -679,11 +676,11 @@ class ConstEnumRegisterFallbackTests(unittest.TestCase):
     :attr:`~pcapkit.const.ftp.command.Command.conf` and
     :class:`Method` needs :attr:`~pcapkit.const.http.method.Method.safe`/
     :attr:`~pcapkit.const.http.method.Method.idempotent`, neither of which a
-    bare unrecognised string carries, so the old fallback used to register a
+    bare unrecognised string carries, so a registering fallback builds a
     permanently hollowed-out member; :meth:`register` is the path that can
-    supply them properly now. What GitHub issues #584 and #623 guarded
+    supply them properly. What GitHub issues #584 and #623 guarded
     against -- a guard turning a registration into an outright crash rather
-    than a clean rejection -- is still checked below, just as "resolves to
+    than a clean rejection -- is checked below, as "resolves to
     an equal, unregistered pseudo-member" rather than "registers".
     """
 
@@ -732,22 +729,16 @@ def test_the_guard_leaves_the_other_lookup_paths_alone(self) -> None:
         for the four modules GitHub issue #647 touched, so a guard that had
         broken either would fail rather than merely go unmeasured.
 
-        This used to also probe the fallback with ``Flags.get(UNRESOLVABLE,
-        0)``, expecting it to resolve -- ``0`` is in-bounds for ``Flags``'s
-        own ``_missing_`` (``0 <= value <= 0xFFFF``), so before GitHub issue
-        #864 it reached ``cls(0)`` and resolved via the converted pseudo-member
-        path, uncaught. It is not a *registered* ``Flags`` member, though
-        (``Flags``'s smallest declared value is ``1 << 4``), so under #864's
-        restriction of ``default`` to a plain ``_value2member_map_`` lookup it
-        no longer resolves at all -- the same accepted cost as an unassigned
-        integer range, here on an :class:`~aenum.IntFlag` registry instead.
-        That is why the prior version of this assertion errored rather than
-        failed: the ``ValueError`` from the *key* (``UNRESOLVABLE``) now
-        propagates uncaught through a bare ``assertEqual`` that expected
-        success. Replaced with the same two-part check used elsewhere in this
-        batch: a *registered* default (``1 << 14``, ``SYN``) is still
-        genuinely consulted and resolves, while the unregistered ``0`` now
-        raises the same original-key error as no default at all.
+        The fallback is probed with a two-part check: a *registered* default
+        (``1 << 14``, ``SYN``) is genuinely consulted and resolves, while
+        ``Flags.get(UNRESOLVABLE, 0)`` raises the same original-key error as
+        no default at all. ``0`` is in-bounds for ``Flags``'s own
+        ``_missing_`` (``0 <= value <= 0xFFFF``), but it is not a *registered*
+        ``Flags`` member (``Flags``'s smallest declared value is ``1 << 4``),
+        and GitHub issue #864 restricts ``default`` to a plain
+        ``_value2member_map_`` lookup -- the same accepted cost as an
+        unassigned integer range, here on an :class:`~aenum.IntFlag` registry
+        instead.
         """
         from pcapkit.const.ftp.command import Command
         from pcapkit.const.http.method import Method
@@ -755,14 +746,14 @@ def test_the_guard_leaves_the_other_lookup_paths_alone(self) -> None:
         from pcapkit.const.tcp.flags import Flags
 
         # String paths, which bypass ``_missing_``. ``Method.get`` is probed
-        # with the exact registered casing rather than ``'get'`` -- GitHub
-        # issue #896 made its matching case-sensitive, so a lower-cased probe
-        # would no longer resolve to ``Method.GET`` at all; that behaviour
-        # change is pinned on its own in
+        # with the exact registered casing rather than ``'get'`` -- its
+        # matching is case-sensitive (GitHub issue #896), so a lower-cased
+        # probe would not resolve to ``Method.GET`` at all; that behaviour
+        # is pinned on its own in
         # :mod:`tests.const.test_const_enum_no_mint`
         # (``BespokeGetUnchangedTests.test_method_get_is_now_case_sensitive``)
         # rather than here, where the point is only that the string path
-        # still bypasses the guard this test is about.
+        # bypasses the guard this test is about.
         self.assertIs(Flags.get('SYN'), Flags.SYN)
         self.assertIs(Command.get('abor'), Command.ABOR)
         self.assertIs(Method.get('GET'), Method.GET)
@@ -774,11 +765,11 @@ def test_the_guard_leaves_the_other_lookup_paths_alone(self) -> None:
 
         # And the fallback the guard's ValueError is what triggers: GitHub issue
         # #584's ``get(key, default)``, which an EnumError would have walked past.
-        # A registered default is still genuinely consulted and resolves.
+        # A registered default is genuinely consulted and resolves.
         self.assertIs(Flags.get(UNRESOLVABLE, 1 << 14), Flags.SYN)
-        # Since #864: ``0`` is not a registered ``Flags`` member, so it no
-        # longer resolves either -- the original key's error propagates, the
-        # same as omitting the default outright.
+        # ``0`` is not a registered ``Flags`` member (GitHub issue #864), so
+        # it does not resolve either -- the original key's error propagates,
+        # the same as omitting the default outright.
         with self.assertRaises(ValueError) as caught:
             Flags.get(UNRESOLVABLE, 0)
         self.assertIn(str(UNRESOLVABLE), str(caught.exception))
@@ -786,17 +777,15 @@ def test_the_guard_leaves_the_other_lookup_paths_alone(self) -> None:
             Flags.get(UNRESOLVABLE)
 
     def test_the_auto_extending_integer_registries_still_extend(self) -> None:
-        """:class:`~pcapkit.const.mh.cga_type.CGAType` is the one true survivor
-        here: its ``Tag_<hex>`` mint is not an IANA-style range at all (a CGA
-        extension type tag is a collision-avoidance random 128-bit value), so
-        the #775/#847 mint-criterion ruling never touched it.
-
-        :class:`~pcapkit.const.ipv4.protection_authority.ProtectionAuthority`
-        used to stand here beside it -- its own unbounded ``_missing_`` also
-        auto-extended for any non-negative integer -- but its label is a bare
-        ``Unassigned``, which the ruling converts; see
-        :meth:`test_protection_authority_now_resolves_without_extending` for
-        its replacement.
+        """:class:`~pcapkit.const.mh.cga_type.CGAType` is the one registry here
+        that extends: its ``Tag_<hex>`` mint is not an IANA-style range at all
+        (a CGA extension type tag is a collision-avoidance random 128-bit
+        value), so the #775/#847 mint-criterion ruling does not cover it.
+
+        :class:`~pcapkit.const.ipv4.protection_authority.ProtectionAuthority`'s
+        own unbounded ``_missing_`` resolves any non-negative integer too, but
+        its label is a bare ``Unassigned``, which the ruling converts; see
+        :meth:`test_protection_authority_now_resolves_without_extending`.
         """
         from pcapkit.const.mh.cga_type import CGAType
 
@@ -812,12 +801,11 @@ def test_the_auto_extending_integer_registries_still_extend(self) -> None:
                     obj(-1)
 
     def test_protection_authority_now_resolves_without_extending(self) -> None:
-        """The other half of the split :meth:`test_the_auto_extending_integer_
-        registries_still_extend` used to cover as one case. Still resolves any
-        non-negative integer -- its ``_missing_`` bound is unchanged -- but
-        since #775/#847 that no longer mints a permanent member: a bare
-        ``Unassigned`` is a notation for the reader, not a name IANA assigned,
-        so two lookups of the same value are equal but no longer identical."""
+        """The counterpart of :meth:`test_the_auto_extending_integer_
+        registries_still_extend`. Resolves any non-negative integer, but does
+        not mint a permanent member (#775/#847): a bare ``Unassigned`` is a
+        notation for the reader, not a name IANA assigned, so two lookups of
+        the same value are equal but not identical."""
         from pcapkit.const.ipv4.protection_authority import ProtectionAuthority
 
         before = len(ProtectionAuthority.__members__)
@@ -835,14 +823,13 @@ def test_protection_authority_now_resolves_without_extending(self) -> None:
             ProtectionAuthority(-1)
 
     def test_apptype_no_longer_registers_an_unassigned_port(self) -> None:
-        """GitHub issue #584's machinery, which used to run through
-        ``_missing_``'s fallthrough and :meth:`AppType.get`'s own second
-        mint site -- both retired by GitHub issue #860 step 2 PR 2, on the
-        same ruling this class's docstring quotes. Renamed from
-        ``test_apptype_still_registers_an_unassigned_port``: 65000 is not in
-        any declared range, so this used to mint a permanent
-        ``PORT_65000_tcp`` member every process keeps forever; it now
-        resolves to an equal-but-not-identical unregistered one instead,
+        """GitHub issue #584's machinery, with no mint at ``_missing_``'s
+        fallthrough or at :meth:`AppType.get`'s own second mint site (GitHub
+        issue #860 step 2 PR 2, on the same ruling this class's docstring
+        quotes). 65000 is not in any declared range, so a minting lookup
+        would leave a permanent ``PORT_65000_tcp`` member every process keeps
+        forever; it resolves to an equal-but-not-identical unregistered one
+        instead,
         the same shape as :meth:`test_a_string_registry_no_longer_
         registers_an_unknown_name` above."""
         from pcapkit.const.reg.apptype import AppType, TransportProtocol
@@ -860,29 +847,22 @@ def test_apptype_no_longer_registers_an_unassigned_port(self) -> None:
     def test_transport_protocol_can_no_longer_be_extended_at_runtime(self) -> None:
         """Maintainer ruling on PR #836: extension refused, not renumbered.
 
-        This used to pin the *shape* of ``TransportProtocol.get``'s
-        registration. GitHub issue #808 dropped the ``IntFlag`` base -- see
-        :meth:`ConstFlagCompositeTests.test_transport_protocol_no_longer_composes`
-        for why composing stopped mattering -- but left the doubling itself
-        alone: stock ``ad4805f5f`` still mints at ``max_val * 2``, so
-        ``.get('quic')`` there returns ``16``, right after ``dccp``'s ``8``.
-        #836's own intermediate revision, not #808, is what switched an
-        unrecognised name to ``max_val + 1`` instead, minting ``9``. The
-        review ruling on PR #836 removes the registration from
-        ``TransportProtocol.get`` entirely, regardless of which scheme numbered
-        it: ``TransportProtocol`` is not to be extended at all. Unlike
+        The review ruling on PR #836 removes the registration from
+        ``TransportProtocol.get`` entirely, whichever scheme would number it --
+        a ``max_val * 2`` doubling (``.get('quic')`` minting ``16``, right
+        after a power-of-two ``dccp``'s ``8``) or a ``max_val + 1`` (minting
+        ``9``): ``TransportProtocol`` is not to be extended at all. Unlike
         :class:`~pcapkit.const.ipv4.protection_authority.ProtectionAuthority`
-        and :class:`~pcapkit.const.mh.cga_type.CGAType` below,
-        ``TransportProtocol`` was never one of :data:`EXPECTED_TO_REGISTER`
+        and :class:`~pcapkit.const.mh.cga_type.CGAType`,
+        ``TransportProtocol`` is not one of :data:`EXPECTED_TO_REGISTER`
         -- it reached the "look up, miss, then register" shape through its
         own hand-written ``get`` rather than through a generated
-        ``_missing_`` -- so pulling it back out of that shape is this
-        module's ruling changing which registries are mutable, not a
-        regression the sweep above would otherwise have to catch.
+        ``_missing_`` -- so refusing that registration is this module's
+        ruling changing which registries are mutable, not a regression the
+        sweep above would otherwise have to catch.
 
-        Regression check: this fails against #836's own prior head,
-        ``3567359e2``, which still registers ``'quic'`` at value 9 rather
-        than raising.
+        Without the ruling's refusal, ``TransportProtocol.get('quic')``
+        registers ``'quic'`` rather than raising.
         """
         from pcapkit.const.reg.apptype import TransportProtocol
 
@@ -891,9 +871,9 @@ def test_transport_protocol_can_no_longer_be_extended_at_runtime(self) -> None:
             TransportProtocol(9)
 
         before = len(TransportProtocol.__members__)
-        # KeyError, not ValueError, since GitHub issue #923 retired this
-        # override's ``KeyError`` -> ``ValueError`` conversion. What this test
-        # is about -- refused rather than registered -- is unchanged.
+        # KeyError, not ValueError: this override does no ``KeyError`` ->
+        # ``ValueError`` conversion (GitHub issue #923). What this test is
+        # about is refused rather than registered.
         with self.assertRaises(KeyError):
             TransportProtocol.get('quic')
         self.assertNotIn('quic', TransportProtocol.__members__)
@@ -906,8 +886,8 @@ def test_transport_protocol_can_no_longer_be_extended_at_runtime(self) -> None:
             TransportProtocol.get('quic2')
         self.assertEqual(len(TransportProtocol.__members__), before)
 
-        # An int naming no declared member is still rejected exactly as
-        # before -- this half of the guard is untouched by the ruling.
+        # An int naming no declared member is rejected -- the ruling concerns
+        # names, not this half of the guard.
         with self.assertRaises(ValueError):
             TransportProtocol(0x20)
 
@@ -919,10 +899,9 @@ class ConstEnumGuardTemplateTests(unittest.TestCase):
     committed tree passing the tests above is not evidence that the templates
     agree with it -- the next crawl would simply revert them. The four templates
     below each carry their own copy of the guard rather than inheriting the one
-    in :mod:`pcapkit.vendor.default`, which is why all four had to be edited and
-    why all four are checked -- each against its own guard text in
-    :data:`BESPOKE_TEMPLATES`, now that GitHub issue #798 finished moving all
-    four off ``%`` formatting (GitHub issue #792 did the first).
+    in :mod:`pcapkit.vendor.default`, which is why all four are checked --
+    each against its own guard text in :data:`BESPOKE_TEMPLATES`, none of
+    which uses ``%`` formatting (GitHub issues #792 and #798).
     """
 
     def setUp(self) -> None:
@@ -945,9 +924,9 @@ def test_no_bespoke_const_module_still_uses_percent_formatting_for_its_guard(sel
         ``skipUnless`` can silently skip -- exactly how #792's regression
         reached seven CI legs -- so this checks the same guards through the
         committed :mod:`pcapkit.const` modules instead, which need no network
-        dependency to import. Asserts the *old* ``%``-style literal is gone
+        dependency to import. Asserts the ``%``-style literal is absent
         rather than merely that a guard exists, so a half-converted template
-        (old and new form both present) would still fail this.
+        (``%`` and f-string form both present) fails this.
         """
         old_guard = "raise ValueError('%r is not a valid %s' % (value, cls.__name__))"
         const_modules = (
@@ -966,21 +945,18 @@ def test_no_bespoke_const_module_still_uses_percent_formatting_for_its_guard(sel
     def test_the_disable_drops_only_where_nothing_else_needs_percent_formatting(self) -> None:
         """GitHub issue #798's third part, finished by #804: the disable is earned.
 
-        All four bespoke const modules now carry no ``%``-formatted code, so
-        all four drop their module-level ``consider-using-f-string``.
+        All four bespoke const modules carry no ``%``-formatted code, so none
+        carries a module-level ``consider-using-f-string`` disable.
         ``pcapkit.const.tcp.flags`` and ``pcapkit.const.reg.apptype.apptype``
-        got there under PR #803, once their guards -- and, for the
-        latter, its three dunders and its span-handling tail -- were
-        converted. ``pcapkit.const.ftp.command`` and
-        ``pcapkit.const.http.method`` were *not* an oversight of #798, whose
-        stated scope named only the ``AppType`` template's dunders; they were
-        tracked as GitHub issue #804 and finished there, two ``__repr__``
-        methods in the former and one in the latter being the last ``%`` in
-        either file.
-
-        This previously asserted the opposite for that pair -- that their
-        disable was retained, and why -- so it fails against any tree where
-        #804's conversion is missing or half-applied, which is the point.
+        are covered by PR #803, which converted their guards -- and, for the
+        latter, its dunders and its span-handling tail.
+        ``pcapkit.const.ftp.command`` and ``pcapkit.const.http.method`` are
+        *not* an oversight of #798, whose stated scope named only the
+        ``AppType`` template's dunders; they are GitHub issue #804, whose
+        ``__repr__`` methods carried the last ``%`` in either file.
+
+        The test fails against any tree where #804's conversion is missing or
+        half-applied.
         Asserts the absence of ``%`` anywhere in the source rather than only
         of the disable, since a file that dropped the disable while keeping a
         ``%`` would otherwise be caught by ``make pylint`` in CI instead of
@@ -1025,10 +1001,10 @@ def test_no_percent_formatting_survives_in_the_issue_804_pair(self) -> None:
 
         Covers the vendor modules as well as the const ones because the tree
         is generated: a conversion that is not in the template is reverted by
-        the next crawl. Fails against stock ``55e1b756e`` reporting four
-        sites -- two in :file:`pcapkit/const/ftp/command.py`, one in
-        :file:`pcapkit/const/http/method.py`, and one apiece in the two
-        generators' ``process`` methods.
+        the next crawl. Without #804's conversion it reports the ``%`` sites
+        in :file:`pcapkit/const/ftp/command.py`,
+        :file:`pcapkit/const/http/method.py` and the two generators'
+        ``process`` methods.
         """
         for vendor_name, _, const_name in ISSUE_804_PAIR:
             for module_name in (const_name, vendor_name):
@@ -1047,7 +1023,7 @@ def test_the_converted_reprs_render_exactly_what_percent_formatting_did(self) ->
         :class:`str` and :data:`None`, and ``Command.desc`` is the one
         ``Optional[str]`` among them -- but GitHub issue #796's text claimed
         an equivalence in generated output that did not hold, so this derives
-        the old form's output for every member rather than assuming the two
+        the ``%`` form's output for every member rather than assuming the two
         forms agree.
         """
         from pcapkit.const.ftp.command import Command, FEATCode
@@ -1083,7 +1059,7 @@ def test_the_converted_generators_emit_the_same_comment_text(self) -> None:
         """The two ``wrap_comment`` arguments, run rather than inspected.
 
         :meth:`test_no_percent_formatting_survives_in_the_issue_804_pair`
-        proves these two lines no longer use ``%`` in the *source*; this
+        proves these two lines use no ``%`` in the *source*; this
         proves the replacement produces the same text, which the
         render-and-diff below cannot reach because it supplies the
         enumeration block ready-made instead of crawling for it.
@@ -1097,7 +1073,7 @@ def test_the_converted_generators_emit_the_same_comment_text(self) -> None:
         vendor_ftp = importlib.import_module('pcapkit.vendor.ftp.command')
         command = vendor_ftp.Command.__new__(vendor_ftp.Command)
         command.record = collections.Counter()
-        # GitHub issue #860: process() now returns (enum rows, distinct
+        # GitHub issue #860: process() returns (enum rows, distinct
         # per-command FEAT codes) rather than just the enum rows, since
         # FEATCode must declare the latter as real members instead of
         # minting them as a side effect of evaluating Command's own rows.
@@ -1105,8 +1081,8 @@ def test_the_converted_generators_emit_the_same_comment_text(self) -> None:
             'h0,h1,h2,h3,h4,h5',
             'ABOR,base,Abort a transfer,s,m,[RFC959]',
         ])
-        # The old form, derived here rather than hardcoded, so this compares
-        # the two expressions rather than the new one against a guess.
+        # The ``%`` form, derived here rather than hardcoded, so this compares
+        # the two expressions rather than the f-string one against a guess.
         expected_ftp = command.wrap_comment('%s %s' % (  # pylint: disable=consider-using-f-string
             'Abort a transfer', '[:rfc:`959`]'))
         self.assertEqual(expected_ftp, "Abort a transfer [:rfc:`959`]")
@@ -1138,7 +1114,7 @@ def test_the_converted_generators_emit_the_same_comment_text(self) -> None:
         # And the falsy-``rfcs`` branch, whose f-string form has to keep the
         # conditional inside the replacement field. ``wrap_comment`` drops the
         # trailing space ``'%s %s'`` leaves behind, so the expectation is
-        # derived from the old form rather than written as ``'GET '``.
+        # derived from the ``%`` form rather than written as ``'GET '``.
         emitted_norfc = method.process(['h0,h1,h2,h3', 'GET,yes,yes,'])
         expected_norfc = method.wrap_comment(re.sub(
             r'\r*\n', ' ', '%s %s' % ('GET', ''), flags=re.MULTILINE))  # pylint: disable=consider-using-f-string
@@ -1174,13 +1150,12 @@ def test_the_issue_804_templates_render_the_committed_modules(self) -> None:
                     const_module.__file__  # type: ignore[arg-type]
                 ).read_text(encoding='utf-8')
 
-                # GitHub issue #860: both classes now mix in EnumRegistry,
-                # and both now close their enumeration block with a
+                # GitHub issue #860: both classes mix in EnumRegistry, and
+                # both close their enumeration block with a
                 # ``_unregistered_member`` classmethod (the override each
-                # needed for its own extra per-member attributes) rather
+                # needs for its own extra per-member attributes) rather
                 # than falling straight through to the ``get()`` override
-                # each still keeps -- a classmethod on both since #908 and
-                # #1824.
+                # each keeps -- a classmethod on both (#908, #1824).
                 block = re.compile(
                     rf'class {cls_name}\(EnumRegistry, StrEnum\):\n    """.*?\n\n    (#:.*?)'
                     r'\n\n    @classmethod', re.S)
@@ -1188,9 +1163,9 @@ def test_the_issue_804_templates_render_the_committed_modules(self) -> None:
                 self.assertIsNotNone(enum_block, f'no enumeration block in {const_name}')
 
                 if cls_name == 'Command':
-                    # GitHub issue #860: Command's LINE gained a fifth
+                    # GitHub issue #860: Command's LINE carries a fifth
                     # positional argument, FEAT -- the per-command FEATCode
-                    # members FEATCode must now declare as real members
+                    # members FEATCode must declare as real members
                     # rather than mint as an import-time side effect (see
                     # BespokeOpenVocabularyUnmintConvertedTests). Read back
                     # out of the committed module the same way as ENUM.
@@ -1226,13 +1201,13 @@ def test_the_tcp_flags_template_renders_the_committed_module(self) -> None:
         enumeration block, which is read back out of the committed module.
 
         NOTE: the class statement names ``EnumRegistry`` and the first method
-        after the enumeration block is a ``classmethod``, because GitHub issue
-        #775's tier 2 found ``tcp/flags``' own exclusion rationale did not hold
-        -- see ``tests.const.test_const_registry_protocol`` -- and converted it
-        onto :class:`~pcapkit.corekit.enum.EnumRegistry` alongside the four
-        ``mh/*_flag`` templates. The generated ``@staticmethod get`` that used
-        to close the block is gone, leaving ``_missing_`` next, the same
-        rewrite ``test_const_enum_lookup.py`` made for those four.
+        after the enumeration block is a ``classmethod``, because ``tcp/flags``
+        is on :class:`~pcapkit.corekit.enum.EnumRegistry` alongside the four
+        ``mh/*_flag`` templates (GitHub issue #775's tier 2 found its own
+        exclusion rationale did not hold -- see
+        ``tests.const.test_const_registry_protocol``). No generated
+        ``@staticmethod get`` closes the block, leaving ``_missing_`` next, the
+        same shape ``test_const_enum_lookup.py`` expects for those four.
         """
         import pathlib
 
@@ -1263,10 +1238,10 @@ def test_the_tcp_flags_template_renders_the_committed_module(self) -> None:
     @unittest.skipUnless(importlib.util.find_spec('requests') is not None,
                          'pcapkit.vendor needs requests')
     def test_the_tcp_flags_checker_covers_the_value_domain_not_the_bit_offsets(self) -> None:
-        """The checker the template used to drop, and why it could not be kept.
+        """The template's checker, and why a bit-offset one could not be kept.
 
-        ``Flags.FLAG`` read ``4 <= value <= 15`` -- the *offsets* the IANA
-        registry indexes -- while the members it generates are ``1 << offset``.
+        A ``Flags.FLAG`` of ``4 <= value <= 15`` covers the *offsets* the IANA
+        registry indexes, while the members it generates are ``1 << offset``.
         The template never interpolated it, so it was never wrong in practice;
         interpolating it unchanged would have rejected every composite, every
         single member above bit 3, and ``Flags(0)``.
@@ -1308,8 +1283,8 @@ def test_no_percent_formatting_survives_in_the_issue_818_triples_repr(self) -> N
         modules keep formatting their ``__str__`` and ``_missing_`` guard with
         ``%`` -- that is unrelated to GitHub issue #818, which is about
         ``__repr__`` specifically, and a whole-module check would never turn
-        green. Fails against stock ``75c340413`` reporting one line apiece in
-        the three const modules.
+        green. Without #818's conversion it reports one line apiece in the
+        three const modules.
 
         The vendor half is checked separately, by
         :meth:`test_no_percent_formatting_survives_in_the_issue_818_triples_vendor_repr_template`,
@@ -1333,8 +1308,8 @@ def test_no_percent_formatting_survives_in_the_issue_818_triples_vendor_repr_tem
         module sees an ordinary f-string and nothing to flag. This checks the
         template's source text directly instead, the same distinction GitHub
         issue #804's own docstring draws between "template text" and
-        "expression". Fails against stock ``75c340413``, whose three
-        templates still hold ``return "<%s...>" % (...)`` verbatim.
+        "expression". Without #818's conversion the templates hold
+        ``return "<%s...>" % (...)`` verbatim.
         """
         for vendor_name, _, _ in ISSUE_818_TRIPLE:
             with self.subTest(vendor=vendor_name):
diff --git a/tests/const/test_const_enum_get.py b/tests/const/test_const_enum_get.py
index 7d7a3194b7..7e7df3af85 100644
--- a/tests/const/test_const_enum_get.py
+++ b/tests/const/test_const_enum_get.py
@@ -80,67 +80,59 @@
 #: An integer no wire field in the library is wide enough to carry, so every
 #: registry that bounds its own domain rejects it. Deliberately far outside the
 #: ``0..0xFF`` range the Mobility Header flag registries check, because a value
-#: *inside* an unbounded-but-undefined span reaches a separate, pre-existing
-#: recursion in their ``_missing_`` (``return cls(value)``) that is not what
-#: this module is about.
+#: *inside* that range is resolved by their ``_missing_`` (through
+#: ``super()._missing_``) rather than rejected, so it would exercise flag
+#: composition rather than the ``default`` fallback this module is about.
 UNRESOLVABLE = 1 << 70
 
 #: Enums whose integer path resolves *anything* rather than raising, so there is
 #: no fallback for ``default`` to supply.
 #:
-#: :class:`~pcapkit.const.tcp.flags.Flags` was a third entry until GitHub issue
-#: #647. It resolved anything for a different reason -- it defined no
-#: ``_missing_`` at all, so ``aenum`` composed a pseudo-member for any integer,
-#: and ``Flags(-1)`` read back as every TCP header flag set at once. It now
-#: bounds its own domain like the rest of the tree and so belongs in the sweep
-#: below rather than in this set.
+#: :class:`~pcapkit.const.tcp.flags.Flags` is not in this set: it bounds its
+#: own domain like the rest of the tree (GitHub issue #647), and so belongs in
+#: the sweep below. Without that guard it resolves anything for a different
+#: reason -- it defines no ``_missing_`` at all, so ``aenum`` composes a
+#: pseudo-member for any integer, and ``Flags(-1)`` reads back as every TCP
+#: header flag set at once.
 #:
-#: Both used to auto-*extend* their unassigned span across the full integer
-#: range, via :func:`~aenum.extend_enum`. The #775/#847 mint-criterion
-#: ruling converted :class:`~pcapkit.const.ipv4.
-#: protection_authority.ProtectionAuthority`'s bare ``Unassigned`` label, so it
-#: now resolves via :meth:`~pcapkit.corekit.enum.EnumRegistry.
-#: _unregistered_member` instead -- it still resolves anything (the property
-#: that excuses it from the sweep below), it just no longer extends.
-#: :class:`~pcapkit.const.mh.cga_type.CGAType` is untouched: its ``Tag_<hex>``
-#: mint is not an IANA-style range at all, so the ruling never applied.
+#: Both resolve their unassigned span across the full integer range.
+#: :class:`~pcapkit.const.ipv4.protection_authority.ProtectionAuthority`'s
+#: bare ``Unassigned`` label resolves via
+#: :meth:`~pcapkit.corekit.enum.EnumRegistry._unregistered_member`, per the
+#: #775/#847 mint-criterion ruling -- it resolves anything (the property that
+#: excuses it from the sweep below), it just does not extend.
+#: :class:`~pcapkit.const.mh.cga_type.CGAType` auto-*extends* via
+#: :func:`~aenum.extend_enum`: its ``Tag_<hex>`` mint is not an IANA-style
+#: range at all, so the ruling does not apply.
 EXPECTED_TO_RESOLVE_ANYTHING = frozenset({
     'pcapkit.const.ipv4.protection_authority.ProtectionAuthority',
     'pcapkit.const.mh.cga_type.CGAType',
 })
 
 #: Enums carrying no ``get(key, default)``, so there is no ``default`` to drop.
-#: Empty since GitHub issue #930: its two occupants,
+#: Empty: every enumeration the sweep walks takes the base ``get(key,
+#: default)`` through :class:`~pcapkit.corekit.enum.EnumLookup`, including
 #: :class:`~pcapkit.const.ftp.command.CommandType` and
-#: :class:`~pcapkit.const.ftp.command.ConformanceRequirement`, were the last
-#: of #877's non-registry enumerations still outside
-#: :class:`~pcapkit.corekit.enum.EnumLookup` -- held here rather than moved by
-#: GitHub issue #877's own PR because :mod:`pcapkit.const.ftp.command` was
-#: still held by #913 at the time. Re-parenting them gave each the base
-#: ``get(key, default)`` for the first time, so both moved into the main
-#: sweep below instead, the same way #877's own re-parenting already moved
-#: :class:`~pcapkit.const.reg.apptype.TransportProtocol` out of this set.
-#:
-#: :class:`~pcapkit.const.ftp.return_code.GroupingInformation` and
-#: :class:`~pcapkit.const.ftp.return_code.ResponseKind` were here too until
-#: GitHub issue #860 step 2 brought them onto
-#: :class:`~pcapkit.corekit.enum.EnumRegistry` -- they inherit the base
-#: ``get(key, default)`` now, so they moved into the main sweep below instead.
+#: :class:`~pcapkit.const.ftp.command.ConformanceRequirement` (GitHub issue
+#: #930), :class:`~pcapkit.const.reg.apptype.TransportProtocol` (GitHub issue
+#: #877), and :class:`~pcapkit.const.ftp.return_code.GroupingInformation` and
+#: :class:`~pcapkit.const.ftp.return_code.ResponseKind`, which are on
+#: :class:`~pcapkit.corekit.enum.EnumRegistry` (GitHub issue #860 step 2).
 EXPECTED_WITHOUT_AN_INTEGER_DEFAULT = frozenset()  # type: frozenset[str]
 
 #: :class:`~pcapkit.const.pcapng.filter_type.FilterType` declares *no* static
-#: members at all -- every one of its 256 codes reaches ``_missing_``. Before
-#: the #775/#847 ruling that was masked by an accident: importing
-#: :mod:`pcapkit.protocols.misc.pcapng` evaluates ``Enum_FilterType(0)`` as a
-#: default argument at class-definition time, which used to permanently mint
-#: ``'Unassigned_0'`` as a side effect of merely importing the library --
-#: leaving exactly one member for this sweep's ``next(iter(obj))`` fallback to
-#: find. The ruling correctly converted FilterType's bare ``Unassigned`` label,
-#: so that same import no longer mints anything, and the registry is now
-#: genuinely empty: :func:`next` on it raises :exc:`StopIteration`, with no
-#: value at all that ``obj(fallback)`` would resolve to a *cached* identity
-#: for. Excused from the main sweep for that reason and covered by its own
-#: test instead, :meth:`ConstEnumGetDefaultTests.
+#: members at all -- every one of its 256 codes reaches ``_missing_``.
+#: Importing :mod:`pcapkit.protocols.misc.pcapng` evaluates
+#: ``Enum_FilterType(0)`` as a default argument at class-definition time, but
+#: FilterType's bare ``Unassigned`` label resolves to an unregistered member
+#: (the #775/#847 ruling), so that import mints nothing -- a minting label
+#: would permanently mint ``'Unassigned_0'`` as a side effect of merely
+#: importing the library, leaving exactly one member for this sweep's
+#: ``next(iter(obj))`` fallback to find. The registry is genuinely empty:
+#: :func:`next` on it raises :exc:`StopIteration`, with no value at all that
+#: ``obj(fallback)`` would resolve to a *cached* identity for. Excused from the
+#: main sweep for that reason and covered by its own test instead,
+#: :meth:`ConstEnumGetDefaultTests.
 #: test_filter_type_default_never_resolves_but_key_path_still_uses_an_uncached_member`.
 EXPECTED_WITHOUT_A_CACHEABLE_FALLBACK = frozenset({
     'pcapkit.const.pcapng.filter_type.FilterType',
@@ -196,8 +188,8 @@ def setUpClass(cls) -> None:
         # permanently registers a junk member on a module-global class. Restore
         # the region to what it held before this class purged it, so those
         # polluted class objects are unreachable rather than merely dropped from
-        # :data:`sys.modules` -- purging again here (as this used to do, GitHub
-        # issue #720) does not achieve that: it only forces whoever imports
+        # :data:`sys.modules` -- purging again here (GitHub issue #720) does
+        # not achieve that: it only forces whoever imports
         # ``pcapkit`` next to rebuild it from source, and until they do, the
         # region sits empty for them exactly as it does for this class's own
         # first test, which is the leak #720 reports. Restoring is exact and
@@ -211,24 +203,24 @@ def test_the_reported_case_returns_the_default(self) -> None:
         """#584's own repro, on the enum it was reported against."""
         from pcapkit.const.arp.hardware import Hardware
 
-        # Before the fix this raised ValueError('99999 is not a valid Hardware'),
-        # dropping the caller's default entirely. Both ``0`` (``Reserved_0``)
-        # and ``1`` (``Ethernet``) are genuinely registered members, so #864
-        # leaves this half of the repro untouched: a registered default still
+        # Without the fix this raises ValueError('99999 is not a valid
+        # Hardware'), dropping the caller's default entirely. Both ``0``
+        # (``Reserved_0``) and ``1`` (``Ethernet``) are genuinely registered
+        # members, so under #864's restriction too a registered default
         # resolves, exactly as #584 asked for.
         self.assertIs(Hardware.get(99999, 0), Hardware(0))
         self.assertIs(Hardware.get(99999, 1), Hardware.Ethernet)
 
-        # GitHub issue #864 changes what an *unresolvable* default does, though:
-        # #584 passed a ``str`` where the signature says ``int``, and ``'X'`` is
-        # not a registered value either way -- before #864 that failed with
-        # ``cls('X')``'s own error, naming ``'X'``; #864's ruling (only
-        # ``register`` can mint, and ``get`` may mint only where the lookup falls
-        # through to the ranges ``_missing_`` mints) replaces ``cls(default)``
-        # with a plain ``_value2member_map_`` lookup for exactly this reason, so
-        # an unresolvable default no longer gets an attempt of its own to fail
-        # from -- it now falls through to the *original* key lookup's own error
-        # instead, same as if no default had been supplied at all.
+        # An *unresolvable* default is a different matter: #584 passed a
+        # ``str`` where the signature says ``int``, and ``'X'`` is not a
+        # registered value either way. GitHub issue #864's ruling (only
+        # ``register`` can mint, and ``get`` may mint only where the lookup
+        # falls through to the ranges ``_missing_`` mints) consults ``default``
+        # through a plain ``_value2member_map_`` lookup rather than
+        # ``cls(default)``, so an unresolvable default gets no attempt of its
+        # own to fail from (which would name ``'X'``) -- it falls through to
+        # the *original* key lookup's own error instead, same as if no default
+        # had been supplied at all.
         with self.assertRaises(ValueError) as caught:
             Hardware.get(99999, 'X')
         self.assertIn('99999', str(caught.exception))
@@ -236,18 +228,18 @@ def test_the_reported_case_returns_the_default(self) -> None:
 
         # A resolvable key is untouched.
         self.assertIs(Hardware.get(1), Hardware.Ethernet)
-        # 40 falls in Hardware's unassigned 39-255 range: since #775 tier 1,
-        # that no longer mints a permanent member, so each lookup returns its
-        # own unregistered pseudo-member -- equal, but no longer the same
-        # object, which is why this is assertEqual rather than assertIs.
+        # 40 falls in Hardware's unassigned 39-255 range, which mints no
+        # permanent member (#775 tier 1), so each lookup returns its own
+        # unregistered pseudo-member -- equal, but not the same object, which
+        # is why this is assertEqual rather than assertIs.
         self.assertEqual(Hardware.get(40), Hardware(40))
         self.assertIs(Hardware.get('Ethernet'), Hardware.Ethernet)
 
     def test_omitting_the_default_still_raises_for_the_original_key(self) -> None:
-        """GitHub issue #857: ``-1`` used to be compared with ``==`` against
-        :data:`~pcapkit.corekit.sentinels.NO_DEFAULT`, so a caller-supplied ``-1``
-        was silently read as *no default was supplied*.
-        :data:`~pcapkit.corekit.sentinels.NO_DEFAULT` is now an exported instance
+        """GitHub issue #857: guards against ``-1`` being compared with ``==``
+        against :data:`~pcapkit.corekit.sentinels.NO_DEFAULT`, which silently
+        reads a caller-supplied ``-1`` as *no default was supplied*.
+        :data:`~pcapkit.corekit.sentinels.NO_DEFAULT` is an exported instance
         of the dedicated :class:`~pcapkit.corekit.sentinels.NoDefaultType`,
         compared with ``is`` rather than ``==`` -- so a caller-supplied
         ``-1`` is never confused with the sentinel. That fact is pinned
@@ -255,26 +247,18 @@ def test_omitting_the_default_still_raises_for_the_original_key(self) -> None:
         :class:`~tests.const.test_const_registry_protocol.NoDefaultSentinelTests
         .test_no_default_is_not_equal_to_any_plausible_caller_value`.
 
-        Before GitHub issue #864, that distinction was *also* observable
-        through ``get()`` itself: a supplied-but-unresolvable ``-1`` failed
-        with its own name (``cls(-1)`` raising directly), differently from the
-        omitted case's original-key error. #864's ruling (only ``register`` can
-        mint, and ``get`` may mint only where the lookup falls through to the
-        ranges ``_missing_`` mints) removes that particular observation for an
-        *unregistered* default specifically: ``default`` no longer reaches
+        Through ``get()`` itself the distinction is not observable for an
+        *unregistered* default: GitHub issue #864's ruling (only ``register``
+        can mint, and ``get`` may mint only where the lookup falls through to
+        the ranges ``_missing_`` mints) keeps ``default`` from reaching
         ``cls(default)`` at all, and ``-1`` is not a registered value on either
-        registry here (both domains start at ``0``), so supplying it now
-        converges on exactly the *same* original-key error as omitting it
-        outright, rather than a distinguishable one of its own. The test's own
-        title is, if anything, more true after #864 than before: *omitting* the
-        default raises for the original key, and now so does supplying an
-        unregistered one -- pinned below for both.
-
-        The genuinely-consulted half of #857's claim is repinned with a
+        registry here (both domains start at ``0``), so supplying it converges
+        on exactly the *same* original-key error as omitting it outright --
+        pinned below for both.
+
+        The genuinely-consulted half of #857's claim is pinned with a
         *registered* default instead (``0``, ``Reserved_0`` on both
-        registries), which still resolves rather than raising -- the
-        observable proof #864 leaves available once ``-1`` no longer
-        provides it.
+        registries), which resolves rather than raising.
         """
         from pcapkit.const.arp.hardware import Hardware
         from pcapkit.const.arp.operation import Operation
@@ -285,17 +269,16 @@ def test_omitting_the_default_still_raises_for_the_original_key(self) -> None:
                     enum.get(99999)
                 self.assertIn('99999', str(omitted.exception))
 
-                # Since #864: an unregistered default (neither registry here
-                # has a member at ``-1``) converges on the *same*
-                # original-key error as omission, rather than a distinct one
-                # naming ``-1``.
+                # An unregistered default (neither registry here has a member
+                # at ``-1``) converges on the *same* original-key error as
+                # omission (#864), rather than a distinct one naming ``-1``.
                 with self.assertRaises(ValueError) as supplied:
                     enum.get(99999, -1)
                 self.assertIn('99999', str(supplied.exception))
                 self.assertNotIn('-1', str(supplied.exception))
 
-                # A *registered* default, by contrast, is still genuinely
-                # consulted rather than raising at all.
+                # A *registered* default, by contrast, is genuinely consulted
+                # rather than raising at all.
                 self.assertIs(enum.get(99999, 0), enum(0))
 
     def test_the_two_unverified_enums_from_the_issue(self) -> None:
@@ -309,10 +292,10 @@ def test_the_two_unverified_enums_from_the_issue(self) -> None:
     def test_the_sweep_size_is_pinned(self) -> None:
         # If this drifts, a const enum was added, removed or renamed, and the
         # exception sets below need a fresh look rather than a silent pass.
-        # 118 became 120 with GitHub issue #880's ngap.ProcedureCode and
-        # ngap.ProtocolIE, moved onto EnumRegistry from hand-rolled IntEnum
-        # classes in pcapkit.protocols.application.ngap; neither needs an
-        # exception-set entry, since both take the base's own get(key, default).
+        # GitHub issue #880's ngap.ProcedureCode and ngap.ProtocolIE are on
+        # EnumRegistry rather than hand-rolled IntEnum classes in
+        # pcapkit.protocols.application.ngap; neither needs an exception-set
+        # entry, since both take the base's own get(key, default).
         names = {_qualname(obj) for obj in self.enums}
         self.assertEqual(len(self.enums), 120)
         for expected in (EXPECTED_TO_RESOLVE_ANYTHING, EXPECTED_WITHOUT_AN_INTEGER_DEFAULT,
@@ -350,28 +333,10 @@ def test_every_integer_path_consults_the_default(self) -> None:
                 fallback = next(iter(obj)).value
                 self.assertIs(obj.get(UNRESOLVABLE, fallback), obj(fallback))
                 covered += 1
-        # 111 from GitHub issue #647, which gave
-        # :class:`~pcapkit.const.tcp.flags.Flags` a range guard and moved it
-        # out of ``EXPECTED_TO_RESOLVE_ANYTHING`` and into this sweep; minus 1
-        # for ``FilterType``, which #775/#847's ruling moved the other way --
-        # it used to be counted here only because an import-time side effect
-        # (see ``EXPECTED_WITHOUT_A_CACHEABLE_FALLBACK``) happened to leave it
-        # one real member to use as ``fallback``, and the ruling removed that
-        # side effect along with the mint it came from; plus 2 for GitHub
-        # issue #860 step 2, which gave ``GroupingInformation`` and
-        # ``ResponseKind`` the base ``get(key, default)`` they never had
-        # before, moving them out of ``EXPECTED_WITHOUT_AN_INTEGER_DEFAULT``
-        # and into this sweep; plus 2 for GitHub issue #880's
-        # ngap.ProcedureCode and ngap.ProtocolIE, which take the base
-        # ``get(key, default)`` from the moment they exist under
-        # pcapkit.const at all; plus 1 for GitHub issue #877's re-parenting of
-        # ``TransportProtocol`` onto ``EnumLookup``, which gave its own ``get``
-        # override a forwarding ``default`` parameter and moved it out of
-        # ``EXPECTED_WITHOUT_AN_INTEGER_DEFAULT`` the same way; plus 2 for
-        # GitHub issue #930's re-parenting of ``CommandType`` and
-        # ``ConformanceRequirement`` onto ``EnumLookup``, which gave each the
-        # base ``get(key, default)`` for the first time and emptied
-        # ``EXPECTED_WITHOUT_AN_INTEGER_DEFAULT`` entirely.
+        # The sweep size ``test_the_sweep_size_is_pinned`` pins, less every
+        # registry excused above: ``EXPECTED_TO_RESOLVE_ANYTHING`` and
+        # ``EXPECTED_WITHOUT_A_CACHEABLE_FALLBACK``, with
+        # ``EXPECTED_WITHOUT_AN_INTEGER_DEFAULT`` empty.
         self.assertEqual(covered, 117)
 
     def test_the_always_resolving_registries_have_nothing_to_fall_back_to(self) -> None:
@@ -382,18 +347,18 @@ def test_the_always_resolving_registries_have_nothing_to_fall_back_to(self) -> N
         than merely listed, so ``EXPECTED_TO_RESOLVE_ANYTHING`` cannot quietly
         grow to hide a registry that does raise.
 
-        Probing :class:`~pcapkit.const.mh.cga_type.CGAType` still *mutates*
-        the registry: the call permanently registers a member on a
-        module-global class, because its mint is untouched by the
-        #775/#847 ruling. That is done deliberately here, and
-        ``setUpClass`` registers a class cleanup that purges :mod:`pcapkit`
-        afterwards so the pollution cannot reach another module.
+        Probing :class:`~pcapkit.const.mh.cga_type.CGAType` *mutates* the
+        registry: the call permanently registers a member on a module-global
+        class, because the #775/#847 ruling does not cover its mint. That is
+        done deliberately here, and ``setUpClass`` registers a class cleanup
+        that purges :mod:`pcapkit` afterwards so the pollution cannot reach
+        another module.
         :class:`~pcapkit.const.ipv4.protection_authority.ProtectionAuthority`
-        no longer mutates anything -- its bare ``Unassigned`` converted, so it
-        resolves through a throwaway pseudo-member instead -- which is why the
-        identity check below only applies to ``CGAType``.
+        mutates nothing -- its bare ``Unassigned`` resolves through a throwaway
+        pseudo-member -- which is why the identity check below only applies to
+        ``CGAType``.
 
-        Measured: ``CGAType`` still grows 7 members to 8; ``ProtectionAuthority``
+        Measured: ``CGAType`` grows 7 members to 8; ``ProtectionAuthority``
         stays at 8.
         """
         for qualname in sorted(EXPECTED_TO_RESOLVE_ANYTHING):
@@ -405,11 +370,11 @@ def test_the_always_resolving_registries_have_nothing_to_fall_back_to(self) -> N
                 resolved = obj.get(UNRESOLVABLE)
                 self.assertIsNotNone(resolved)
                 self.assertEqual(int(resolved), UNRESOLVABLE)
-                # It resolves with or without a default, so the sentinel branch
-                # this change added is never reached for either of them.
+                # It resolves with or without a default, so the ``NO_DEFAULT``
+                # sentinel branch is never reached for either of them.
                 self.assertEqual(resolved, obj.get(UNRESOLVABLE, 0))
                 if qualname == 'pcapkit.const.mh.cga_type.CGAType':
-                    # Still mints permanently -- identity holds.
+                    # Mints permanently -- identity holds.
                     self.assertIs(resolved, obj.get(UNRESOLVABLE, 0))
                 else:
                     # Converted: a fresh, equal-but-not-identical pseudo-member
@@ -423,33 +388,27 @@ def test_filter_type_default_never_resolves_but_key_path_still_uses_an_uncached_
 
         FilterType declares *no* static members at all, so its own
         ``_value2member_map_`` is permanently empty -- not ``0``, not
-        anything. Before GitHub issue #864, ``default=0`` still resolved
-        because ``get`` called ``cls(0)`` directly, reaching ``_missing_``
-        and its converted, uncached pseudo-member path. #864's ruling
-        closes exactly that path for ``default``: it is restricted to a
-        plain ``_value2member_map_`` lookup, and FilterType's is
-        permanently empty, so *no* default can ever resolve for this
-        registry any more -- the strongest instance of the ruling's own
-        accepted cost, since it is not one range that stops resolving but
-        the registry's entire domain.
-
-        ``key`` resolution is untouched by #864, though, and it is where
-        the uncached pseudo-member path this test was written to cover
-        still lives: ``FilterType.get(0)`` -- ``0`` as the *key*, no
-        default at all -- still reaches ``cls(0)`` -> ``_missing_``
-        directly, resolving to a fresh, equal-but-not-identical
-        pseudo-member every call, exactly as before. Restored here through
-        the path #864 does not touch, now that ``default`` can no longer
-        demonstrate it.
+        anything. GitHub issue #864 restricts ``default`` to a plain
+        ``_value2member_map_`` lookup rather than ``cls(default)``, which
+        would reach ``_missing_`` and its converted, uncached pseudo-member
+        path, so *no* default can ever resolve for this registry -- the
+        strongest instance of the ruling's own accepted cost, since it is not
+        one range that does not resolve but the registry's entire domain.
+
+        ``key`` resolution is outside #864's restriction, and it is where the
+        uncached pseudo-member path this test covers lives:
+        ``FilterType.get(0)`` -- ``0`` as the *key*, no default at all --
+        reaches ``cls(0)`` -> ``_missing_`` directly, resolving to a fresh,
+        equal-but-not-identical pseudo-member every call.
         """
         from pcapkit.const.pcapng.filter_type import FilterType
 
         with self.assertRaises(ValueError):
             FilterType.get(UNRESOLVABLE)
 
-        # No default can resolve on FilterType any more -- it has no
-        # registered members at all -- so even a value that is in-bounds
-        # (0x00-0xFF) for the *key* path, like ``0``, now falls through to
+        # No default can resolve on FilterType -- it has no registered
+        # members at all -- so even a value that is in-bounds (0x00-0xFF)
+        # for the *key* path, like ``0``, falls through to
         # the *original* ``UNRESOLVABLE`` error rather than resolving.
         before = len(FilterType.__members__)
         with self.assertRaises(ValueError) as caught:
@@ -457,12 +416,11 @@ def test_filter_type_default_never_resolves_but_key_path_still_uses_an_uncached_
         self.assertIn(str(UNRESOLVABLE), str(caught.exception))
         self.assertEqual(len(FilterType.__members__), before)
 
-        # The uncached pseudo-member path itself is unaffected: as a *key*
-        # (no default supplied), ``0`` still resolves via ``cls(0)`` ->
-        # ``_missing_``, returning a fresh, equal-but-not-identical member
-        # every time rather than a cached identity -- the strength this
-        # test was written to add over the generic sweep, now demonstrated
-        # through ``key`` instead of ``default``.
+        # The uncached pseudo-member path itself: as a *key* (no default
+        # supplied), ``0`` resolves via ``cls(0)`` -> ``_missing_``,
+        # returning a fresh, equal-but-not-identical member every time rather
+        # than a cached identity -- the strength this test adds over the
+        # generic sweep.
         resolved = FilterType.get(0)
         self.assertEqual(int(resolved), 0)
         self.assertEqual(resolved, FilterType(0))
@@ -474,22 +432,18 @@ def test_filter_type_default_never_resolves_but_key_path_still_uses_an_uncached_
     def test_the_vendor_template_still_emits_the_fix(self) -> None:
         """A regeneration must not undo the fix.
 
-        GitHub issue #775's tier 3 moved #584's fix off the per-file generated
-        ``get()`` entirely: it now lives permanently in
-        :meth:`~pcapkit.corekit.enum.EnumRegistry.get`, which every
-        default-template registry *inherits* rather than copies, so
-        there is no longer a ``get()`` block here for a regeneration to drop
-        the fix from -- the block this test used to extract and compare no
-        longer exists in either the template's output or the generated
-        module, in either case for the same reason.
-
-        What a regeneration could still undo is the inheritance itself, or
-        bring back a local copy of ``get``, ``register`` or
-        ``_unregistered_member`` that would shadow the base and silently
-        resurrect the pre-#775 two-contract bug -- this pins their absence,
-        and the presence of the mix-in, on both the freshly rendered template
-        (with synthetic content, as the pre-#775 version of this test did for
-        ``get()``) and the real, committed module.
+        #584's fix lives in :meth:`~pcapkit.corekit.enum.EnumRegistry.get`
+        (GitHub issue #775's tier 3), which every default-template registry
+        *inherits* rather than copies, so neither the template's output nor
+        the generated module has a per-file ``get()`` block for a
+        regeneration to drop the fix from.
+
+        What a regeneration could undo is the inheritance itself, or bring
+        back a local copy of ``get``, ``register`` or ``_unregistered_member``
+        that would shadow the base and silently resurrect #775's two-contract
+        bug -- this pins their absence, and the presence of the mix-in, on
+        both the freshly rendered template (with synthetic content) and the
+        real, committed module.
         """
         import pathlib
 
diff --git a/tests/const/test_const_enum_lookup.py b/tests/const/test_const_enum_lookup.py
index 47f868bb94..eb8a0ba387 100644
--- a/tests/const/test_const_enum_lookup.py
+++ b/tests/const/test_const_enum_lookup.py
@@ -32,7 +32,7 @@
 :class:`~pcapkit.const.tcp.flags.Flags`, which at the time defined no
 ``_missing_``, never had the defect -- and, as GitHub issue #647 then found, had
 no range guard either, so it resolved *any* integer and ``Flags(-1)`` read back
-as every TCP header flag set at once. It now carries the same guard ending in
+as every TCP header flag set at once. It carries the same guard ending in
 ``return super()._missing_(value)``, which is what keeps issue #623 fixed while
 issue #647 is too; :mod:`tests.const.test_const_enum_builtin_parity` is where
 that lands. :class:`~pcapkit.const.mh.binding_ack_flag.BindingACKFlag` and its
@@ -48,13 +48,12 @@
 under :mod:`pcapkit.const`, including ones nothing else touches (e.g.
 :mod:`pcapkit.const.reg.apptype`). ``tests/cli/test_main.py`` stubs pieces of
 :mod:`pcapkit.utilities.compat` and :mod:`pcapkit.utilities.exceptions`
-straight into :data:`sys.modules` for its own isolation and, depending on
-suite order, those stubs used to still be sitting there when this module ran --
-purging first forces a clean re-import instead of tripping over them. That file
-has since been put under :func:`tests._support.isolate_modules` and puts them
-back itself (issue #688), so it is no longer the specific hazard; the purge stays
-because the convention is worth keeping and because the *next* stand-in written
-without the helpers would be.
+straight into :data:`sys.modules` for its own isolation; it runs under
+:func:`tests._support.isolate_modules` and puts them back itself (issue #688).
+The purge stays because the convention is worth keeping: a stand-in written
+without the helpers would leave its stubs sitting there when this module runs,
+depending on suite order, and purging first forces a clean re-import instead of
+tripping over them.
 
 """
 from __future__ import annotations
@@ -276,8 +275,8 @@ def test_ftp_return_code_missing_methods_are_classmethods(self) -> None:
         self.assertIsInstance(ResponseKind.__dict__['_missing_'], classmethod)
         self.assertIsInstance(GroupingInformation.__dict__['_missing_'], classmethod)
 
-        # And the actual symptom: every unknown value used to raise TypeError
-        # rather than extending the enum, not merely value 0.
+        # And the actual symptom: without the fix, every unknown value raises
+        # TypeError rather than extending the enum, not merely value 0.
         self.assertEqual(int(ResponseKind(7)), 7)
         self.assertEqual(int(ResponseKind(0)), 0)
         self.assertEqual(int(GroupingInformation(9)), 9)
@@ -290,8 +289,8 @@ class ConstFlagMissingRecursionTests(unittest.TestCase):
     enumerations ended in ``return cls(value)`` -- the constructor that had just
     failed to find the value -- so every in-range non-member re-entered
     ``_missing_`` unbounded and raised :exc:`RecursionError`. The tests below
-    assert the *resolved* value rather than catching the recursion, so an
-    unfixed tree fails on the error rather than on an assertion, and the four
+    assert the *resolved* value rather than catching the recursion, so without
+    the fix they fail on the error rather than on an assertion, and the four
     named registries are covered alongside the sweep.
 
     """
@@ -408,10 +407,11 @@ def test_the_vendor_templates_still_emit_the_fix(self) -> None:
         import pathlib
 
         # NOTE: the class statement names EnumRegistry and the first method after
-        # the enumeration block is a classmethod, because #775's tier 2 moved
-        # get/get_all/register/register_alias off these templates and onto
-        # pcapkit.corekit.enum.EnumRegistry -- the generated `@staticmethod get`
-        # that used to close the block is gone, leaving `_missing_` next.
+        # the enumeration block is a classmethod, because
+        # get/get_all/register/register_alias live on
+        # pcapkit.corekit.enum.EnumRegistry (#775's tier 2), not on these
+        # templates -- no generated `@staticmethod get` closes the block,
+        # leaving `_missing_` next.
         block = re.compile(
             r'class \w+\(EnumRegistry, IntFlag\):\n    """.*?"""\n\n    (.*?)\n\n    @classmethod',
             re.S)
diff --git a/tests/const/test_const_enum_no_mint.py b/tests/const/test_const_enum_no_mint.py
index c1d1d9c291..36a251da28 100644
--- a/tests/const/test_const_enum_no_mint.py
+++ b/tests/const/test_const_enum_no_mint.py
@@ -4,113 +4,96 @@
 The ruling on #775 is that no registry creates a registered enum out of an
 unrecognised or unregistered value, however legitimate but unbounded the values
 are, unless the user or caller explicitly created it -- and lookup never counts as
-asking for a name, only the new :meth:`register` classmethod does. Before this change, both ``get()``'s string
-path and ``_missing_``'s bounded-but-unassigned range branch called
-:func:`aenum.extend_enum`, permanently growing the registry for a value nobody
-asked to be named. Measured on this tree before the fix:
+asking for a name, only the :meth:`register` classmethod does. Without the fix,
+both ``get()``'s string path and ``_missing_``'s bounded-but-unassigned range
+branch call :func:`aenum.extend_enum`, permanently growing the registry for a
+value nobody asked to be named. Measured on a tree without the fix:
 :class:`~pcapkit.const.arp.hardware.Hardware`'s ``__members__`` moved from 41
 entries to 42 after a single ``Hardware(40)`` (40 sits in the documented
 39-255 "Unassigned" range) and stayed at 42 on a second call -- growth that
 never reverses for the life of the process, and that a long-running capture
 walking many such values would accumulate without bound.
 
-Tier 1 touches only the shared ``get()`` template in :mod:`pcapkit.vendor.default`
+Tier 1 covers the shared ``get()`` template in :mod:`pcapkit.vendor.default`
 and the ``_missing_`` range-branch :meth:`~pcapkit.vendor.
-default.Vendor.process` assembles -- see that module for those hunks. It is
-scoped to the registries that inherit both unmodified, which this module's
-:data:`REGISTRIES_WITH_UNASSIGNED_RANGES` and :data:`ALL_REGISTRIES` enumerate;
-the vendor files that replace the shared template wholesale (and whatever
-they generate) are out of scope and untouched.
-
-Tier 1 fixed the *mechanism* (a lookup should never mint); it did not decide,
-registry by registry, which of the remaining ``_missing_`` bodies mint
-something worth keeping. That is tier 2; the owner's mint/unmint criterion was
-settled on PR #847 and confirmed on #775 as the core of the ruling: a name
-is minted when it is the final concrete name an assignment gave, and left
-unminted when it is only a notation for the readers. A dynamically or statically
-assigned range is as unspecified as any other -- it gets concrete names when
-something assigns them -- so its placeholder is notation, not a name worth
-registering. Applied registry by registry to every ``_missing_`` that still called
-:func:`~aenum.extend_enum` -- measured
-by an AST walk over ``pcapkit/const/*.py`` rather than estimated, as an earlier
-pass in this programme had -- the ruling converted most
-of them outright (:data:`RULING_CONVERTED_REGISTRIES` below),
-left :class:`~pcapkit.const.reg.ethertype.EtherType` and
-:class:`~pcapkit.const.ipx.socket.Socket` *mixed* (each keeps some branches
-minting and converts others -- see :data:`ETHERTYPE_UNASSIGNED_PROBES` and
-:data:`IPX_SOCKET_UNASSIGNED_PROBES`), and left the bespoke classes
-untouched because they do not inherit :class:`~pcapkit.corekit.enum.
-EnumRegistry` and so have no ``_unregistered_member`` to convert to until
-GitHub issue #860 lands (blocked on #859); :class:`~pcapkit.const.reg.
-apptype.apptype.AppType` is by far the largest of those in still-minting
-branches. :class:`~pcapkit.const.mh.cga_type.CGAType` keeps minting too, but
-for a different reason: its ``Tag_<hex>`` mint is not an IANA-style
-range at all (see its own module for why), so the ruling never touched it.
-
-GitHub issue #860 (step 2, PR 1) brought every one of those classes except
-:class:`~pcapkit.const.reg.apptype.apptype.AppType` onto
-:class:`~pcapkit.corekit.enum.EnumRegistry` and converted their branches --
-see :data:`BESPOKE_UNMINT_CONVERTED_REGISTRIES` and
+default.Vendor.process` assembles -- see that module for those hunks -- and so
+the registries that inherit both unmodified, which this module's
+:data:`REGISTRIES_WITH_UNASSIGNED_RANGES` and :data:`ALL_REGISTRIES` enumerate.
+
+Tier 1 fixes the *mechanism* (a lookup should never mint); tier 2 decides,
+registry by registry, which ``_missing_`` bodies mint something worth keeping.
+The owner's mint/unmint criterion was settled on PR #847 and confirmed on #775
+as the core of the ruling: a name is minted when it is the final concrete name
+an assignment gave, and left unminted when it is only a notation for the
+readers. A dynamically or statically assigned range is as unspecified as any
+other -- it gets concrete names when something assigns them -- so its
+placeholder is notation, not a name worth registering. Applied registry by
+registry to every ``_missing_`` calling :func:`~aenum.extend_enum` -- measured
+by an AST walk over ``pcapkit/const/*.py`` rather than estimated -- the ruling
+converts them (:data:`RULING_CONVERTED_REGISTRIES` below).
+:class:`~pcapkit.const.mh.cga_type.CGAType` keeps minting, for a different
+reason: its ``Tag_<hex>`` mint is not an IANA-style range at all (see its own
+module for why), so the ruling does not cover it.
+
+GitHub issue #860 (step 2) brings the bespoke classes -- the vendor files that
+replace the shared template wholesale, and what they generate -- onto
+:class:`~pcapkit.corekit.enum.EnumRegistry` and converts their branches -- see
+:data:`BESPOKE_UNMINT_CONVERTED_REGISTRIES` and
 :class:`BespokeOpenVocabularyUnmintConvertedTests` below. Two distinct
 shapes:
 
-Range-bounded registries whose old mint used a manufactured
-placeholder label (``Unassigned``, ``Unknown_%d``, ``opt_unknown_%d``):
+Range-bounded registries whose mint used a manufactured placeholder label
+(``Unassigned``, ``Unknown_%d``, ``opt_unknown_%d``):
 :class:`~pcapkit.const.http.status_code.StatusCode`,
 :class:`~pcapkit.const.ftp.return_code.ReturnCode`,
 :class:`~pcapkit.const.ftp.return_code.ResponseKind`,
 :class:`~pcapkit.const.ftp.return_code.GroupingInformation` and
 :class:`~pcapkit.const.pcapng.option_type.OptionType`,
-unambiguous under the mint/unmint criterion from the first measurement.
+unambiguous under the mint/unmint criterion.
 Each carries a custom ``__new__`` with extra per-member attributes (unlike
-any of the tier-2 registries above), so each needed its own
+any of the tier-2 registries above), so each has its own
 ``_unregistered_member`` override reconstructing those attributes rather
 than the shared base's generic one, and :class:`StatusCode` and
-:class:`ReturnCode` had their own hand-written
-``get()`` replaced by the base's -- see :class:`BespokeGetReplacementTests`
-for the ``default == -1`` -> ``NO_DEFAULT`` behaviour change that implies.
+:class:`ReturnCode` use the base's ``get()`` rather than a hand-written one
+-- see :class:`BespokeGetReplacementTests` for the ``default == -1`` ->
+``NO_DEFAULT`` behaviour change that implies.
 :class:`OptionType` keeps its own ``get()`` (genuine multi-namespace
-dispatch the base does not replicate), but round 2 review found that
-``get()`` still minted on both its int/namespace path and its ``str`` path
--- the same "leaving ``get()`` minting while ``_missing_`` does not
-contradicts the ruling" argument that converted :class:`Command`'s and
-:class:`Method`'s own ``get()`` mint sites below, just missed the first
-time round for the third registry that has one. Both are now
-``_unregistered_member`` calls too; see
+dispatch the base does not replicate), and both its int/namespace path and
+its ``str`` path are ``_unregistered_member`` calls too -- the same
+"leaving ``get()`` minting while ``_missing_`` does not contradicts the
+ruling" argument that converts :class:`Command`'s and :class:`Method`'s own
+``get()`` mint sites below; see
 :meth:`BespokeUnmintConvertedRegistriesTests.
 test_optiontype_get_int_path_no_longer_mints`,
 ``..._namespace_path_...`` and ``..._str_path_...``.
 
-Open-vocabulary registries whose old mint used the exact, unmodified
-observed value as its own name rather than any manufactured label:
+Open-vocabulary registries whose mint used the exact, unmodified observed
+value as its own name rather than any manufactured label:
 :class:`~pcapkit.const.ftp.command.FEATCode`,
 :class:`~pcapkit.const.ftp.command.Command` and
 :class:`~pcapkit.const.http.method.Method` -- a single ``_missing_`` branch each,
-initially left minting pending the owner's ruling (this measurement's own
-report flagged them as genuinely ambiguous under the criterion, since
-nothing about them is a manufactured placeholder). GitHub issue #860 is
-where the owner settled it: ``get()`` must not mint, because only
-``register()`` creates a new registry entry -- for these registries
-only IANA-registered values are legitimate, and ``get()`` does not have
-enough information to construct one itself. That rule is about ``get()``
-in its own right, and it extends just as much to
-``_missing_`` -- :class:`Command` needs ``feat``/``desc``/``type``/``conf``
+genuinely ambiguous under the criterion, since nothing about them is a
+manufactured placeholder. GitHub issue #860 is where the owner settled it:
+``get()`` must not mint, because only ``register()`` creates a new registry
+entry -- for these registries only IANA-registered values are legitimate,
+and ``get()`` does not have enough information to construct one itself.
+That rule is about ``get()`` in its own right, and it extends just as much
+to ``_missing_`` -- :class:`Command` needs ``feat``/``desc``/``type``/``conf``
 and :class:`Method` needs ``safe``/``idempotent``, neither of which a bare
 wire string carries -- so both classes' own ``get()`` (a second, independent
 mint site bypassing ``_missing_`` entirely) converts too, alongside
-``_missing_``; :class:`FEATCode` has no custom ``__new__``, and had no
-``get()`` of its own at the time either, so only its one ``_missing_`` branch
-was in play. (It has one now -- GitHub issue #903's audit gave it a
-case-insensitive ``get`` per :rfc:`5797#section-2` -- but that override never
-calls ``cls(key)``, so it added no mint site to this file's concern.)
-
-GitHub issue #860 step 2's PR 2 converted the last of those classes:
-:class:`~pcapkit.const.reg.apptype.apptype.AppType` and its four per-transport
+``_missing_``. :class:`FEATCode` has no custom ``__new__``, and its
+case-insensitive ``get`` (GitHub issue #903's audit, per
+:rfc:`5797#section-2`) never calls ``cls(key)``, so only its one
+``_missing_`` branch is in play.
+
+GitHub issue #860 step 2's PR 2 covers
+:class:`~pcapkit.const.reg.apptype.apptype.AppType` and its per-transport
 registries (:class:`~pcapkit.const.reg.apptype.tcp.TCP`,
 :class:`~pcapkit.const.reg.apptype.udp.UDP`,
 :class:`~pcapkit.const.reg.apptype.sctp.SCTP`,
-:class:`~pcapkit.const.reg.apptype.dccp.DCCP`) now mix in
-:class:`~pcapkit.corekit.enum.EnumRegistry` and no longer mint on either of
+:class:`~pcapkit.const.reg.apptype.dccp.DCCP`), which mix in
+:class:`~pcapkit.corekit.enum.EnumRegistry` and mint on neither of
 AppType's mint sites -- its ``_missing_`` branches, and the one more inside
 ``get()`` itself. See :class:`AppTypeUnmintConvertedTests` below, including
 the deliberate scope decision on those branches that name a real (if
@@ -125,44 +108,43 @@
 ``IntEnum``; see :class:`BespokeOpenVocabularyUnmintConvertedTests`'s own
 ``test_commandtype_is_untouched``.
 :class:`~pcapkit.const.reg.apptype.apptype.TransportProtocol`, by contrast,
-*did* change -- on a different ruling than CommandType's, not the same one.
-GitHub PR #836 is what first retired ``|``-composite decoding: once
-``TransportProtocol`` is no longer a ``Flag``, a ``|``-joined value is not parsed
-and accepted but treated as a whole, instead of being split. GitHub issue #860
-later drew the further consequence once nothing decoded a composite any more:
-the power-of-two spacing existed only for the ``tcp | udp``-style code that
-composition served, and since the new logic does not accept that piping, ``auto()``
-is the expected numbering. So it numbers its members sequentially from
-0 -- ``undefined`` a direct, explicit ``0``, the rest continuing from it
-via ``auto()`` with no ``_start_`` needed, per the owner's own further
-ruling settling the declaration shape -- rather than by the power-of-two
-spacing that composition used to need. The owner also ruled, on #860, that no
-test should pin the one behavioural consequence, since it is an obsolete path
-left by an accepted breaking change -- and it is a real consequence,
-not a refusal: a hand-composed ``tcp | udp`` (or a bare, uncomposed ``3``)
-now silently resolves as ``sctp``'s own value through
-:meth:`AppType._dispatch`, where it used to name no registry at all and
-raise. None of the tests below pin that, per the same ruling.
-
-GitHub issue #775's final round closes the two mixed registries themselves:
+is not a ``Flag`` -- on a different ruling than CommandType's, not the same
+one. GitHub PR #836 retires ``|``-composite decoding: ``TransportProtocol``
+not being a ``Flag``, a ``|``-joined value is not parsed and accepted but
+treated as a whole, instead of being split. GitHub issue #860 draws the
+further consequence: the power-of-two spacing exists only for the
+``tcp | udp``-style code that composition served, and since the logic does
+not accept that piping, ``auto()`` is the expected numbering. So it numbers
+its members sequentially from 0 -- ``undefined`` a direct, explicit ``0``,
+the rest continuing from it via ``auto()`` with no ``_start_`` needed, per
+the owner's own further ruling settling the declaration shape. The owner
+also ruled, on #860, that no test should pin the one behavioural
+consequence, since it is an obsolete path left by an accepted breaking
+change -- and it is a real consequence, not a refusal: a hand-composed
+``tcp | udp`` (or a bare, uncomposed ``3``) silently resolves as ``sctp``'s
+own value through :meth:`AppType._dispatch`. None of the tests below pin
+that, per the same ruling.
+
+GitHub issue #775's final round closes the two registries tier 2 left
+*mixed* (keeping some branches minting and converting others):
 every one of :class:`~pcapkit.const.reg.ethertype.EtherType`'s
-still-minting range branches, and :class:`~pcapkit.const.ipx.socket.Socket`'s
-one (``Registered by Xerox``), now convert to
+range branches, and :class:`~pcapkit.const.ipx.socket.Socket`'s
+``Registered by Xerox`` one, convert to
 :meth:`~pcapkit.corekit.enum.EnumRegistry._unregistered_member` too -- PR #878
-scoped it this way: keeping the existing hex-suffixed name, since this change
-is about not registering rather than renaming. So each keeps the hex-suffixed
-name it always rendered (``Xyplex_0x0888``, not a bare ``Xyplex``) even though
-it no longer registers -- neither is "mixed" any more, both are wholly
-converted like those in :data:`RULING_CONVERTED_REGISTRIES`, and
-:class:`EtherTypeMixedMintTests`/:class:`IPXSocketMixedMintTests` below are
-retitled in place to prove the formerly-kept probe no longer mints rather than
-that it still does. The one consequence worth naming: this reintroduces the
-exact "manufactured, value-suffixed name" shape :func:`is_manufactured` exists
-to flag, on calls that are still safe because :meth:`_unregistered_member`
-never registers regardless of what its ``name`` argument looks like -- see
+scoped it this way: keeping the existing hex-suffixed name, since the
+conversion is about not registering rather than renaming. So each keeps the
+hex-suffixed name (``Xyplex_0x0888``, not a bare ``Xyplex``) even though it
+does not register -- both are wholly converted like those in
+:data:`RULING_CONVERTED_REGISTRIES`, and
+:class:`EtherTypeMixedMintTests`/:class:`IPXSocketMixedMintTests` below
+prove that the probe each once kept minting does not mint. The one
+consequence worth naming: this reintroduces the exact "manufactured,
+value-suffixed name" shape :func:`is_manufactured` exists to flag, on calls
+that are safe because :meth:`_unregistered_member` never registers
+regardless of what its ``name`` argument looks like -- see
 :func:`_is_hex_suffixed_unregistered_name` in
 :class:`UnregisteredMemberNameIsBareTests` for the scoped exemption this
-required, keyed on the ``name`` argument's own shape rather than on the
+requires, keyed on the ``name`` argument's own shape rather than on the
 files it happens to live in.
 
 """
@@ -356,26 +338,24 @@ def _first_unassigned_value(cls: 'type') -> 'int':
     return int(match.group(1))
 
 
-#: (module, class name) for every one of the registries the owner's
-#: #775/#847 ruling converted outright: every ``_missing_`` branch that used
-#: to mint via :func:`~aenum.extend_enum` now returns :meth:`~pcapkit.corekit.
-#: enum.EnumRegistry._unregistered_member` instead, because what it minted was
-#: a bare status word (``Unassigned``, ``Reserved [...]``, ``Reserved for
-#: Private/Experimental Use``, ``Unspecified in the IANA registry``, and
-#: similar) rather than a name anyone assigned. Derived from the same AST walk
-#: that measured the modules still minting on ``main`` before this change:
-#: most of them are here, including the *mixed* registries (:class:`~pcapkit.
+#: (module, class name) for every registry the owner's #775/#847 ruling
+#: converts outright: every ``_missing_`` branch that would mint via
+#: :func:`~aenum.extend_enum` returns :meth:`~pcapkit.corekit.
+#: enum.EnumRegistry._unregistered_member` instead, because what it would
+#: mint is a bare status word (``Unassigned``, ``Reserved [...]``, ``Reserved
+#: for Private/Experimental Use``, ``Unspecified in the IANA registry``, and
+#: similar) rather than a name anyone assigned. Derived from an AST walk over
+#: the modules that mint without the fix, including the registries
+#: tier 2 left *mixed* until #775's final round (:class:`~pcapkit.
 #: const.reg.ethertype.EtherType` and :class:`~pcapkit.const.ipx.socket.
-#: Socket`, which convert some branches and keep minting others -- see
-#: :data:`ETHERTYPE_UNASSIGNED_PROBES` and :data:`IPX_SOCKET_UNASSIGNED_
-#: PROBES`). The rest are untouched: the files whose classes do
-#: not inherit :class:`EnumRegistry` yet and so have no ``_unregistered_
-#: member`` to convert to (:class:`~pcapkit.const.reg.apptype.apptype.
-#: AppType`, :class:`~pcapkit.const.http.status_code.StatusCode`, :mod:
-#: `pcapkit.const.ftp.return_code`, :mod:`pcapkit.const.ftp.command`,
+#: Socket` -- see :data:`ETHERTYPE_UNASSIGNED_PROBES` and
+#: :data:`IPX_SOCKET_UNASSIGNED_PROBES`). Not listed: the bespoke classes
+#: GitHub issue #860 converts instead (:class:`~pcapkit.const.reg.apptype.
+#: apptype.AppType`, :class:`~pcapkit.const.http.status_code.StatusCode`,
+#: :mod:`pcapkit.const.ftp.return_code`, :mod:`pcapkit.const.ftp.command`,
 #: :class:`~pcapkit.const.http.method.Method`, :class:`~pcapkit.const.pcapng.
-#: option_type.OptionType` -- see the module docstring), plus :class:
-#: `~pcapkit.const.mh.cga_type.CGAType`, which the ruling never touched
+#: option_type.OptionType` -- see the module docstring), and :class:
+#: `~pcapkit.const.mh.cga_type.CGAType`, which the ruling does not cover
 #: because its mint is not an IANA-style range at all.
 RULING_CONVERTED_REGISTRIES = (
     ('pcapkit.const.esp.cipher', 'Cipher'),
@@ -474,20 +454,17 @@ def _first_unassigned_value(cls: 'type') -> 'int':
 #: are declared). They are proved by :class:`RulingConversionSourceTests` (a
 #: source sweep) instead.
 #:
-#: :class:`~pcapkit.const.reg.ethertype.EtherType` used to be held out for a
-#: second, distinct reason on top of those 13: its *first* converted branch by
-#: source order ("Old Xerox Experimental...", 0x0101-0x01FF) was itself
-#: unreachable, masked by the wider 0x0000-0x05DC branch before it, so a naive
-#: probe would have silently exercised the wrong branch. GitHub issue #862
-#: (fixed by #865) reordered :meth:`pcapkit.vendor.reg.ethertype.EtherType.
-#: process` so the narrower range is tested first, which makes that branch
-#: directly probeable like any other reachable-gap registry -- the same shape
-#: :class:`~pcapkit.const.ipx.socket.Socket` (mixed at the time) already
-#: demonstrates in this list below. EtherType has therefore joined this set;
-#: see :data:`ETHERTYPE_UNASSIGNED_PROBES`'s comment for the probe itself,
-#: still covered explicitly by :class:`EtherTypeMixedMintTests` as well.
-#: #775's final round left neither registry actually mixed -- see that
-#: class's own docstring.
+#: :class:`~pcapkit.const.reg.ethertype.EtherType` is in this list because
+#: :meth:`pcapkit.vendor.reg.ethertype.EtherType.process` tests the narrower
+#: 0x0101-0x01FF range ("Old Xerox Experimental...") before the wider
+#: 0x0000-0x05DC branch that contains it (GitHub issue #862, fixed by #865),
+#: so its *first* converted branch by source order is directly probeable like
+#: any other reachable-gap registry's, as
+#: :class:`~pcapkit.const.ipx.socket.Socket`'s is below. Without that
+#: ordering the branch is masked, and a naive probe would silently exercise
+#: the wrong one. See :data:`ETHERTYPE_UNASSIGNED_PROBES`'s comment for the
+#: probe itself, also covered explicitly by :class:`EtherTypeMixedMintTests`.
+#: Neither registry is mixed -- see that class's own docstring.
 #:
 #: Derived the same way as :data:`RULING_CONVERTED_REGISTRIES`: computed once
 #: by walking each candidate's own bounds for a gap, not hand-picked.
@@ -568,25 +545,20 @@ def _first_unassigned_value(cls: 'type') -> 'int':
 #: "Old Xerox Experimental values. Invalid as an Ethertype since 1983." both
 #: convert, because the label itself says nothing was assigned. Every *other*
 #: named block -- companies the historical list attributes a real code range
-#: to -- used to stay a mint; :data:`ETHERTYPE_FORMERLY_KEPT_PROBE` pins one
-#: (``Xyplex``) as a regression guard, now flipped to prove it no longer
-#: mints either, since #775's final round converts every remaining branch.
+#: to -- kept minting under that original ruling, and #775's final round
+#: converts every remaining branch; :data:`ETHERTYPE_FORMERLY_KEPT_PROBE` pins
+#: one (``Xyplex``) as a regression guard that it does not mint either.
 #:
-#: "Old Xerox Experimental" (0x0101-0x01FF) used to not be behaviourally
-#: probeable: it was a strict subset of the earlier, wider "IEEE802.3 Length
-#: Field" branch (0x0000-0x05DC), which the ``_missing_`` if-chain matched
-#: first and so masked it completely -- the same shape of ordering bug GitHub
-#: issue #841 found in :mod:`pcapkit.const.ipx.socket`, present on ``main``
-#: before this change and not part of #775/#847's ruling, so it was left as a
-#: follow-up rather than reordered as part of that ruling. GitHub issue #862
-#: is that follow-up, fixed by #865: :meth:`pcapkit.vendor.reg.ethertype.
-#: EtherType.process` now tests the narrower Old Xerox range before the wider
-#: IEEE802.3 one, so 0x0101 resolves to Old Xerox and is directly probeable --
-#: it is included below alongside ``DEC Unassigned``, giving it the same
-#: behavioural no-mint proof :class:`EtherTypeMixedMintTests` already gives
-#: DEC Unassigned, rather than the weaker source-text check that stood in for
-#: it before #865 (an order-insensitive string search that would keep passing
-#: even if the ordering regressed).
+#: "Old Xerox Experimental" (0x0101-0x01FF) is a strict subset of the wider
+#: "IEEE802.3 Length Field" branch (0x0000-0x05DC). :meth:`pcapkit.vendor.reg.
+#: ethertype.EtherType.process` tests the narrower range first (GitHub issue
+#: #862, fixed by #865 -- the same shape of ordering bug GitHub issue #841
+#: found in :mod:`pcapkit.const.ipx.socket`), so 0x0101 resolves to Old Xerox
+#: and is directly probeable. It is included below alongside ``DEC
+#: Unassigned``, giving it the same behavioural no-mint proof
+#: :class:`EtherTypeMixedMintTests` gives DEC Unassigned -- stronger than a
+#: source-text check, an order-insensitive string search that would keep
+#: passing even if the ordering regressed.
 ETHERTYPE_OLD_XEROX_LABEL = 'Old_Xerox_Experimental_values_Invalid_as_an_Ethertype_since_1983'
 ETHERTYPE_UNASSIGNED_PROBES = {
     0x8039: 'DEC_Unassigned',
@@ -595,21 +567,20 @@ def _first_unassigned_value(cls: 'type') -> 'int':
 #: The one probe the original ruling kept minting -- Xyplex, 0x0888 -- because
 #: a proprietary protocol has no public name of its own, so the company name
 #: serves as one (#775, #847). #775's final round converts it too, preserving
-#: the hex-suffixed name exactly as the crawler always rendered it (PR #878
-#: scoped it this way: keeping the existing hex-suffixed name, since this
-#: change is about not registering rather than renaming), so this now pins the
-#: opposite of what its name suggests: that the formerly-kept probe no longer
-#: mints either. Kept as its own constant, distinct from
-#: :data:`ETHERTYPE_UNASSIGNED_PROBES`, because
-#: :class:`EtherTypeMixedMintTests` below still wants it named individually in
+#: the hex-suffixed name exactly as the crawler renders it (PR #878 scoped it
+#: this way: keeping the existing hex-suffixed name, since the conversion is
+#: about not registering rather than renaming), so this pins the opposite of
+#: what its name suggests: that this probe does not mint either. Kept as its
+#: own constant, distinct from :data:`ETHERTYPE_UNASSIGNED_PROBES`, because
+#: :class:`EtherTypeMixedMintTests` below wants it named individually in
 #: its own regression test.
 ETHERTYPE_FORMERLY_KEPT_PROBE = (0x0888, 'Xyplex_0x0888')
 
 #: :class:`~pcapkit.const.ipx.socket.Socket` probes for the owner's original
 #: #775/#847 ruling: ``Experimental`` and the three dynamically/statically
 #: assigned labels convert, as notation for the reader rather than a final
-#: concrete assigned name; ``Registered by Xerox``, the company one, used to
-#: keep minting, pinned by :data:`IPX_SOCKET_FORMERLY_KEPT_PROBE`.
+#: concrete assigned name; ``Registered by Xerox``, the company one, kept
+#: minting under it, and is pinned by :data:`IPX_SOCKET_FORMERLY_KEPT_PROBE`.
 IPX_SOCKET_UNASSIGNED_PROBES = {
     0x0025: 'Experimental',
     0x4001: 'Dynamically Assigned Socket Numbers',
@@ -826,14 +797,12 @@ def test_unresolvable_string_key_with_default_falls_back_by_value(self) -> None:
 
     def test_unresolvable_string_key_with_default_in_unassigned_range(self) -> None:
         """The fallback is itself a value lookup (GitHub issue #864), so a
-        default landing in a bounded-unassigned range no longer returns the
+        default landing in a bounded-unassigned range does not return the
         pseudo-member the int path does -- it simply does not resolve, and
-        the original key's own error propagates instead. Before #864 this
-        resolved via ``cls(default)`` -> ``_missing_`` to an unregistered
-        pseudo-member; that is exactly the cost the owner accepted on #864 in
-        choosing a value-only lookup: a default naming a value with no
-        registered member stops resolving, on every registry, where it used
-        to return an unregistered member via ``_missing_``."""
+        the original key's own error propagates instead. That is exactly the
+        cost the owner accepted on #864 in choosing a value-only lookup over
+        ``cls(default)`` -> ``_missing_``: a default naming a value with no
+        registered member does not resolve, on every registry."""
         from pcapkit.const.arp.hardware import Hardware
 
         before = len(Hardware.__members__)
@@ -1000,8 +969,8 @@ def is_manufactured(name_arg: 'Optional[ast.expr]') -> 'bool':
     """Whether an ``_unregistered_member(...)`` call's ``name`` argument is
     built *from the value being looked up*, rather than being independent of
     it -- the one shape #775/#860's ruling forbids, because a label that
-    varies with the value risks the exact ``__members__`` collision minting
-    used to risk. Keyed on *which operand is combined*, not on the format
+    varies with the value risks the exact ``__members__`` collision a mint
+    risks. Keyed on *which operand is combined*, not on the format
     spec: ``'%s_unknown' % namespace`` on :class:`~pcapkit.const.pcapng.
     option_type.OptionType`'s ``get()`` is a ``%``-format and is not
     flagged, because the combined operand is ``namespace`` (one of a
@@ -1042,10 +1011,9 @@ def is_manufactured(name_arg: 'Optional[ast.expr]') -> 'bool':
     than its receiver does: a bare ``value``/``key`` passed as data to
     ``str(...)``, ``operator.mod(...)``, ``.format_map(...)``, or nested
     inside a set/generator/list-comprehension/``map(...)`` argument to
-    ``.join(...)``, is a reference this function used to clear the same
-    way it clears a receiver -- wrongly, since an argument being the value
-    at all is already how each of those shapes glues it to something
-    else. Every argument of any call is therefore walked bluntly for
+    ``.join(...)``, is not to be cleared the way a receiver is, since an
+    argument being the value at all is already how each of those shapes
+    glues it to something else. Every argument of any call is therefore walked bluntly for
     ``value``/``key`` regardless of how deeply it is wrapped, while a
     receiver keeps the narrower, recursive check that preserves
     ``value.upper()``'s exemption.
@@ -1266,7 +1234,7 @@ class UnregisteredMemberNameIsBareTests(unittest.TestCase):
     than pinning one example -- and asserts that every
     ``cls._unregistered_member(...)`` call site's ``name`` argument is not a
     *manufactured* numeric-suffixed label: a bare string constant containing
-    ``%`` (the old ``'Unassigned_%d' % value`` shape, spelled out as a
+    ``%`` (the ``'Unassigned_%d' % value`` mint shape, spelled out as a
     literal), or an equivalent ``%``-formatted :class:`~ast.BinOp` or
     f-string. It therefore covers every call site tier 1's follow-up
     touched, every one tier 2's #775/#847 ruling added, and those #860
@@ -1324,17 +1292,11 @@ class UnregisteredMemberNameIsBareTests(unittest.TestCase):
     since it never calls ``_unregistered_member`` in the first place; minting
     there is the explicit, caller-named path the sweep is not about.
 
-    (Corrected from an earlier draft of this docstring, which estimated
-    the still-minting registries rather than measuring them and named ``pcapkit.const.mh`` and
-    ``BlockType`` as examples -- both were converted by tier 2 and no longer
-    apply; the AST walk in the module docstring above measured the real
-    set.)
-
     GitHub issue #775's final round converts the last minting branches --
     every one of :class:`~pcapkit.const.reg.ethertype.EtherType`'s and
     :class:`~pcapkit.const.ipx.socket.Socket`'s one -- and deliberately keeps
     each one's hex-suffixed name unchanged (PR #878 scoped it this way:
-    keeping the existing hex-suffixed name, since this change is about not
+    keeping the existing hex-suffixed name, since the conversion is about not
     registering rather than renaming). That is the exact manufactured,
     value-suffixed shape :func:`is_manufactured` exists to flag -- unlike
     ``'%s_unknown' % namespace`` above, the substituted operand here really is
@@ -1401,8 +1363,8 @@ def test_every_unregistered_member_call_passes_a_non_manufactured_name(self) ->
 
 
 class RulingConversionDoesNotMintTests(unittest.TestCase):
-    """Tier 2's #775/#847 ruling, behaviourally: a value that used to mint a
-    bare status word must now come back as a throwaway pseudo-member instead,
+    """Tier 2's #775/#847 ruling, behaviourally: a value whose label is a
+    bare status word must come back as a throwaway pseudo-member, not a mint,
     the same regression :class:`UnassignedRangeDoesNotMintTests` above proves
     for tier 1's registries. Swept across :data:`RULING_CONVERTED_WITH_REACHABLE_GAP`
     -- the converted registries whose branch a real lookup can
@@ -1456,40 +1418,38 @@ def test_repeated_lookup_does_not_grow_members(self) -> None:
                 self.assertIsNot(first, second)
 
 
-#: :class:`~pcapkit.const.reg.ethertype.EtherType` and :class:`~pcapkit.const.
-#: ipx.socket.Socket` used to be the two *mixed* registries: most of their
-#: ``_missing_`` legitimately kept minting (real attributed names), so the
-#: blanket "no extend_enum left" sweep below did not apply to them.
-#: GitHub issue #775's final round converts every remaining branch on both,
-#: so neither is mixed any more -- kept as an empty-by-construction frozenset
-#: (rather than deleted outright) so the two subtractions below stay
-#: self-documenting about *why* nothing is excluded now, and so a future
-#: registry that goes back to being genuinely mixed has a named place to be
-#: added again. :class:`EtherTypeMixedMintTests` and
-#: :class:`IPXSocketMixedMintTests` (retitled in place, not renamed) now prove
-#: their formerly-kept probe no longer mints either, alongside the rows that
-#: already didn't.
+#: Registries whose ``_missing_`` legitimately keeps minting on some branches
+#: (real attributed names), so the blanket "no extend_enum left" sweep below
+#: does not apply to them. Empty: GitHub issue #775's final round converts
+#: every branch on :class:`~pcapkit.const.reg.ethertype.EtherType` and
+#: :class:`~pcapkit.const.ipx.socket.Socket`, the two tier 2 left *mixed*.
+#: Kept as an empty-by-construction frozenset so the two subtractions below
+#: stay self-documenting about *why* nothing is excluded, and so a future
+#: registry that becomes genuinely mixed has a named place to be added.
+#: :class:`EtherTypeMixedMintTests` and :class:`IPXSocketMixedMintTests` prove
+#: the probe each once kept minting does not mint either, alongside the rows
+#: that never did.
 _MIXED_REGISTRIES = frozenset()  # type: frozenset[tuple[str, str]]
 
 
 class RulingConversionSourceTests(unittest.TestCase):
     """Source-level proof for those of :data:`RULING_CONVERTED_REGISTRIES`
     with no reachable gap (every in-bounds value already names a real member,
-    so no lookup can exercise the branch either before or after this change)
+    so no lookup can exercise the branch)
     -- and, as a completeness check, for the wholly-converted registries:
     none of their ``_missing_`` bodies may call :func:`~aenum.extend_enum`.
     :data:`_MIXED_REGISTRIES` is empty, #775's final round having
     converted both, so nothing is excluded here -- see its own docstring."""
 
     def test_no_reachable_gap_registries_no_longer_call_extend_enum(self) -> None:
-        # EtherType belongs to RULING_CONVERTED_WITH_REACHABLE_GAP: its
-        # masked-branch exclusion (Old Xerox shadowed by the wider IEEE802.3
-        # range) was fixed under GitHub issue #862, and its first converted
-        # branch by source order is directly probeable like any other
-        # reachable-gap registry. The `_MIXED_REGISTRIES` subtraction
-        # below is a defensive no-op -- neither mixed registry needs
-        # removing from `RCR - RG` (EtherType is already in RG;
-        # Socket never appeared in RULING_CONVERTED_REGISTRIES to begin with)
+        # EtherType belongs to RULING_CONVERTED_WITH_REACHABLE_GAP: its Old
+        # Xerox branch is not shadowed by the wider IEEE802.3 range (GitHub
+        # issue #862), so its first converted branch by source order is
+        # directly probeable like any other reachable-gap registry. The
+        # `_MIXED_REGISTRIES` subtraction below is a defensive no-op -- neither
+        # mixed registry needs removing from `RCR - RG` (EtherType is already
+        # in RG; Socket never appeared in RULING_CONVERTED_REGISTRIES to begin
+        # with)
         # -- kept so a mixed registry that regains a masked or absent branch
         # in the future does not silently inflate this count.
         excluded = set(RULING_CONVERTED_REGISTRIES) - set(RULING_CONVERTED_WITH_REACHABLE_GAP) - _MIXED_REGISTRIES
@@ -1511,13 +1471,12 @@ def test_every_wholly_converted_registry_no_longer_calls_extend_enum(self) -> No
                 self.assertNotIn('extend_enum', source)
 
     def test_ethertype_and_socket_no_longer_call_extend_enum_either(self) -> None:
-        """The two former mixed registries, now that nothing excludes them:
-        GitHub issue #775's final round leaves no ``extend_enum`` call on
-        either, the same invariant :meth:`test_every_wholly_converted_
-        registry_no_longer_calls_extend_enum` already proves for the other
-        80 -- named separately because neither is actually a member of
-        :data:`RULING_CONVERTED_REGISTRIES` in Socket's case, so the loop
-        above alone would never reach it."""
+        """The two registries tier 2 left mixed: GitHub issue #775's final
+        round leaves no ``extend_enum`` call on either, the same invariant
+        :meth:`test_every_wholly_converted_registry_no_longer_calls_extend_enum`
+        proves for the rest -- named separately because Socket is not a
+        member of :data:`RULING_CONVERTED_REGISTRIES`, so the loop above alone
+        would never reach it."""
         from pcapkit.const.ipx.socket import Socket
         from pcapkit.const.reg.ethertype import EtherType
 
@@ -1529,15 +1488,14 @@ def test_ethertype_and_socket_no_longer_call_extend_enum_either(self) -> None:
 
 
 class EtherTypeMixedMintTests(unittest.TestCase):
-    """:class:`~pcapkit.const.reg.ethertype.EtherType` was the ruling's mixed
-    case: ``DEC Unassigned`` and the "Old Xerox Experimental..." row converted
-    first, while every other attributed vendor block (a real company's own
-    name for its own code) kept minting. GitHub issue #775's final round
-    converts the rest too -- :meth:`test_formerly_attributed_vendor_block_
-    no_longer_mints` below proves the one named probe (``Xyplex``) that used
-    to be this class's own regression guard for "still mints" now proves the
-    opposite, and the class is no longer actually mixed (retitled in place
-    rather than renamed, so history stays easy to follow)."""
+    """:class:`~pcapkit.const.reg.ethertype.EtherType` is tier 2's mixed
+    case: tier 2's ruling converts ``DEC Unassigned`` and the "Old Xerox
+    Experimental..." row and leaves every other attributed vendor block (a
+    real company's own name for its own code) minting. GitHub issue #775's
+    final round converts those too, so no branch mints -- ``EtherType(0x0888)``
+    resolves to an unregistered ``Xyplex_0x0888`` -- and the class keeps its
+    tier-2 name. :meth:`test_formerly_attributed_vendor_block_
+    no_longer_mints` below pins that one named probe (``Xyplex``)."""
 
     def setUp(self) -> None:
         reimport_once_per_class(self, restore=True)
@@ -1557,29 +1515,14 @@ def test_unassigned_rows_do_not_mint(self) -> None:
                 self.assertEqual(before, len(EtherType.__members__))
                 self.assertNotIn(value, EtherType._value2member_map_)  # type: ignore[attr-defined]
 
-    # ``test_masked_old_xerox_row_converts_by_source`` retired here, not simply
-    # deleted: it used to prove 0x0101-0x01FF converts *by source* (an
-    # order-insensitive string search for the two calls in
-    # EtherType._missing_'s text) because the row was unreachable at runtime,
-    # masked by the wider 0x0000-0x05DC branch that preceded it. GitHub issue
-    # #862, fixed by #865, reordered the generator so that row is no longer
-    # masked, and 0x0101 is now one of the values ``test_unassigned_rows_do_
-    # not_mint`` above probes directly via ``ETHERTYPE_UNASSIGNED_PROBES`` --
-    # a strictly stronger, behavioural proof of the same fact (it also catches
-    # a regression the old source check would have missed: the string search
-    # never checked *order*, so it would keep passing even if the ordering
-    # regressed and 0x0101 started minting again). Nothing this test checked
-    # is left unchecked; it is subsumed rather than replaced by a weaker test.
-
     def test_formerly_attributed_vendor_block_no_longer_mints(self) -> None:
-        """The regression guard this class used to carry the other way: this
-        exact probe (``Xyplex``, 0x0888) used to prove the ruling *kept*
-        minting a real attributed name; GitHub issue #775's final round
-        converts it, preserving the hex-suffixed name exactly as the crawler
-        always rendered it -- PR #878 scoped it this way: keeping the existing
-        hex-suffixed name, since this change is about not registering rather
-        than renaming. Same shape as :meth:`test_unassigned_rows_do_not_mint`
-        above, just for the one probe that used to be the exception."""
+        """``Xyplex`` (0x0888), the real attributed name tier 2's ruling
+        *kept* minting: GitHub issue #775's final round converts it,
+        preserving the hex-suffixed name exactly as the crawler renders it --
+        PR #878 scoped it this way: keeping the existing hex-suffixed name,
+        since the conversion is about not registering rather than renaming.
+        Same shape as :meth:`test_unassigned_rows_do_not_mint` above, for the
+        one probe tier 2 kept as the exception."""
         from pcapkit.const.reg.ethertype import EtherType
 
         value, name = ETHERTYPE_FORMERLY_KEPT_PROBE
@@ -1599,10 +1542,12 @@ def test_formerly_attributed_vendor_block_no_longer_mints(self) -> None:
 
 
 class IPXSocketMixedMintTests(unittest.TestCase):
-    """:class:`~pcapkit.const.ipx.socket.Socket` was the ruling's other mixed
-    case: ``Experimental`` and the three dynamically/statically assigned
-    labels converted first, while ``Registered by Xerox``, the company one,
-    kept minting. GitHub issue #775's final round converts it too; see
+    """:class:`~pcapkit.const.ipx.socket.Socket` is tier 2's other mixed
+    case: tier 2's ruling converts ``Experimental`` and the three
+    dynamically/statically assigned labels and leaves ``Registered by
+    Xerox``, the company one, minting. GitHub issue #775's final round
+    converts it too, so ``Socket(0x0010)`` resolves to an unregistered
+    ``Registered by Xerox_0x0010``; see
     :meth:`test_registered_by_xerox_no_longer_mints` below."""
 
     def setUp(self) -> None:
@@ -1624,11 +1569,10 @@ def test_unassigned_rows_do_not_mint(self) -> None:
                 self.assertNotIn(value, Socket._value2member_map_)  # type: ignore[attr-defined]
 
     def test_registered_by_xerox_no_longer_mints(self) -> None:
-        """The regression guard this class used to carry the other way: this
-        exact probe (``Registered by Xerox``, 0x0010) used to prove the
-        ruling *kept* minting the company name; GitHub issue #775's final
-        round converts it, preserving the hex-suffixed name exactly as the
-        crawler always rendered it -- same ruling, same reasoning as
+        """``Registered by Xerox`` (0x0010), the company name tier 2's ruling
+        *kept* minting: GitHub issue #775's final round converts it,
+        preserving the hex-suffixed name exactly as the crawler renders it --
+        same ruling, same reasoning as
         :meth:`EtherTypeMixedMintTests.
         test_formerly_attributed_vendor_block_no_longer_mints`."""
         from pcapkit.const.ipx.socket import Socket
@@ -1678,7 +1622,7 @@ class BespokeUnmintConvertedRegistriesTests(unittest.TestCase):
     attributes unset and make ``str()``/``repr()`` raise on the result. Each
     class therefore overrides :meth:`_unregistered_member` to reconstruct
     them the same way ``__new__`` would. These tests exercise that
-    reconstruction directly, not just that lookup no longer mints.
+    reconstruction directly, not just that lookup does not mint.
 
     """
 
@@ -1776,8 +1720,8 @@ def test_returncode_unregistered_member_displays_correctly(self) -> None:
     def test_responsekind_and_groupinginformation_unregistered_member_bare_name(self) -> None:
         """Neither has a custom ``__new__``, so the base's generic
         ``_unregistered_member`` needs no override for either -- pinned here
-        so a future edit that adds one notices it changed something that
-        used to be free."""
+        so a future edit that adds one notices it is changing something the
+        base provides for free."""
         from pcapkit.const.ftp.return_code import GroupingInformation, ResponseKind
 
         self.assertNotIn('_unregistered_member', ResponseKind.__dict__)
@@ -1803,8 +1747,7 @@ def test_optiontype_members_ns_is_not_corrupted(self) -> None:
         unregistered lookup either -- growing it would silently defeat the
         whole point of *unregistered* through a side channel the generic
         ``_value2member_map_``/``__members__`` assertions above cannot see.
-        This is deliberately the opposite of what the pre-conversion mint did
-        (it *did* add to ``__members_ns__``, every time), so it is pinned
+        A mint *does* add to ``__members_ns__``, every time, so this is pinned
         both ways: the table must not grow, and the value must not appear in
         it, either directly under the resolving namespace."""
         from pcapkit.const.pcapng.option_type import OptionType
@@ -1825,16 +1768,16 @@ def test_optiontype_members_ns_is_not_corrupted(self) -> None:
         self.assertIsNot(first, second)
 
     def test_optiontype_get_int_path_no_longer_mints(self) -> None:
-        """:meth:`OptionType.get` used to mint directly on a miss (bypassing
-        ``_missing_`` entirely) -- a second, independent mint site #869's
-        first pass left alone. Round 2 review measured it live on the
-        wire-facing path (:meth:`pcapkit.protocols.misc.pcapng.PCAPNG.
-        _make_pcapng_options` calls ``get()`` with raw option-code bytes),
-        and the owner's ruling names ``get`` explicitly -- the same reason
+        """Guards against :meth:`OptionType.get` minting directly on a miss
+        (bypassing ``_missing_`` entirely) -- a second, independent mint
+        site, on the wire-facing path round 2 review measured live
+        (:meth:`pcapkit.protocols.misc.pcapng.PCAPNG._make_pcapng_options`
+        calls ``get()`` with raw option-code bytes). The owner's ruling names
+        ``get`` explicitly -- the same reason
         :class:`~pcapkit.const.ftp.command.Command`/:class:`~pcapkit.const.
-        http.method.Method`'s own ``get()`` mint sites converted. Leaving
-        this one minting while ``_missing_`` did not would have been the
-        exact contradiction that conversion was for."""
+        http.method.Method`'s own ``get()`` mint sites convert. Leaving this
+        one minting while ``_missing_`` does not would be the exact
+        contradiction that conversion is for."""
         from pcapkit.const.pcapng.option_type import OptionType
 
         before = len(OptionType.__members__)
@@ -1874,11 +1817,11 @@ def test_optiontype_get_namespace_path_no_longer_mints(self) -> None:
         self.assertIsNot(first, second)
 
     def test_optiontype_get_str_path_no_longer_mints(self) -> None:
-        """The subtler of the two: ``get()``'s ``str``-keyed branch used to
-        mint ``key`` itself as the member's *name*, with ``default`` as its
-        value -- the same "no information to register one properly"
-        reasoning as the int path, just with the roles of ``key`` and
-        ``default`` swapped in the old ``extend_enum`` call."""
+        """The subtler of the two: guards against ``get()``'s ``str``-keyed
+        branch minting ``key`` itself as the member's *name*, with
+        ``default`` as its value -- the same "no information to register one
+        properly" reasoning as the int path, just with the roles of ``key``
+        and ``default`` swapped in the ``extend_enum`` call."""
         from pcapkit.const.pcapng.option_type import OptionType
 
         before = len(OptionType.__members__)
@@ -1913,7 +1856,7 @@ class BespokeOpenVocabularyUnmintConvertedTests(unittest.TestCase):
     :class:`~pcapkit.const.ftp.command.Command` needs ``feat``/``desc``/``type``/``conf`` and
     :class:`~pcapkit.const.http.method.Method` needs
     ``safe``/``idempotent``, neither of which a bare wire string carries, so
-    minting used to register a permanently hollowed-out member for each.
+    minting registers a permanently hollowed-out member for each.
     :class:`~pcapkit.const.ftp.command.FEATCode` has no custom ``__new__``
     at all and needed no override.
 
@@ -1921,17 +1864,17 @@ class BespokeOpenVocabularyUnmintConvertedTests(unittest.TestCase):
     independent mint site bypassing ``_missing_`` entirely, the same shape
     as :class:`~pcapkit.const.pcapng.option_type.OptionType`'s) are
     converted, since the owner's reasoning names ``get`` explicitly and
-    leaving it minting while ``_missing_`` did not would have been a
-    direct contradiction. ``Command``/``Method``'s ``_unregistered_member``
+    leaving it minting while ``_missing_`` does not would be a direct
+    contradiction. ``Command``/``Method``'s ``_unregistered_member``
     override canonicalises the member's *name* to upper case and keeps the
     caller's own casing as its value, so ``get('frob')`` and ``get('FROB')``
     are unequal, and a repeated ``get('frob')`` is equal but, with nothing
-    cached any more, never again *identical* -- see the production
-    regression test this forced,
+    cached, never *identical* -- see the production regression test,
     ``tests/protocols/application/test_ftp_unit.py::FTPUnitTests::test_command_get_is_case_insensitive``,
     which pins exactly that with ``assertEqual``, ``assertIsNot`` and
-    ``assertNotEqual``. Its HTTP twin was replaced under #896 by
-    ``tests/protocols/application/test_http_unit.py::HTTPUnitTests::test_method_get_is_now_case_sensitive``.
+    ``assertNotEqual``. Its HTTP counterpart is
+    ``tests/protocols/application/test_http_unit.py::HTTPUnitTests::test_method_get_is_now_case_sensitive``
+    (#896).
 
     """
 
@@ -1942,12 +1885,12 @@ def test_featcode_import_mints_nothing(self) -> None:
         """The guard against the import-time mutation coming back -- count-
         agnostic on purpose.
 
-        Before this fix, importing :mod:`pcapkit.const.ftp.command` minted
+        Without the fix, importing :mod:`pcapkit.const.ftp.command` mints
         :class:`~pcapkit.const.ftp.command.FEATCode` members as a side
         effect of evaluating :class:`~pcapkit.const.ftp.command.Command`'s
         own class body -- each row referencing an upper-case ``FEAT code``
-        called ``FEATCode('AUTH')`` etc., and :meth:`FEATCode._missing_`
-        minted one the first time. The generator now declares every ``FEAT
+        calls ``FEATCode('AUTH')`` etc., and :meth:`FEATCode._missing_`
+        mints one the first time. The generator declares every ``FEAT
         code`` the live IANA registry's own column names as a real member,
         so every :class:`Command` row references one by plain attribute
         access and nothing is minted merely by importing the module.
@@ -1979,7 +1922,7 @@ def test_command_rows_reference_declared_featcode_members(self) -> None:
         :class:`~pcapkit.const.ftp.command.FEATCode` member as every other
         row naming the same code -- not a fresh, unregistered one apiece,
         which is what calling ``FEATCode(...)`` at class-body-evaluation
-        time used to build."""
+        time would build."""
         from pcapkit.const.ftp.command import Command, FEATCode
 
         self.assertIs(Command.AUTH.feat, FEATCode.AUTH)  # type: ignore[attr-defined]
@@ -2015,12 +1958,10 @@ def test_featcode_missing_no_longer_mints(self) -> None:
     def test_command_missing_no_longer_mints(self) -> None:
         """Same convention as :class:`~pcapkit.const.ftp.command.FEATCode`'s:
         the *value* is exactly what was observed (``value == 'wire casing'``
-        holds), matching ``main``'s own pre-#860 behaviour for this class --
-        only the *name* is canonicalised. Verified directly against a
-        measured regression risk: swapping the value for the canonicalised
-        name (as an earlier revision of this conversion did) would make
-        ``Command('xyzw') == 'xyzw'`` false, which never held on ``main``
-        and would have been #869's one real behaviour break."""
+        holds), matching what a mint does for this class -- only the *name*
+        is canonicalised. Swapping the value for the canonicalised name would
+        make ``Command('xyzw') == 'xyzw'`` false, a real behaviour break for
+        any caller comparing a member with its wire string."""
         from pcapkit.const.ftp.command import Command, CommandType, ConformanceRequirement
 
         before = len(Command.__members__)
@@ -2046,10 +1987,10 @@ def test_command_get_unknown_no_longer_mints(self) -> None:
         """The value keeps the caller's own casing (see :meth:`Command.
         _unregistered_member`'s own docstring) -- so a repeated call with
         the *same* casing is equal but not identical, while a *different*
-        casing is a genuinely different value and correctly not equal. On
-        ``main`` minting's cache made both calls return the identical,
-        first-seen-casing object regardless; losing that is #860's one
-        observable behaviour change here, not a casing change."""
+        casing is a genuinely different value and correctly not equal. A
+        minting lookup caches instead, returning the identical,
+        first-seen-casing object for both calls; not caching is #860's one
+        observable difference here, not a casing change."""
         from pcapkit.const.ftp.command import Command
 
         before = len(Command.__members__)
@@ -2070,22 +2011,13 @@ def test_method_missing_no_longer_mints(self) -> None:
         """Same convention as :class:`~pcapkit.const.ftp.command.FEATCode`'s
         and :class:`~pcapkit.const.ftp.command.Command`'s: an *unregistered*
         member's value is the caller's own casing, with real :class:`str`
-        content. This test used to also pin a genuine asymmetry with every
-        *registered* member of this class, tracked as GitHub issue #870:
-        :meth:`Method.__new__` called ``str.__new__(cls)`` with no argument
-        at all, so every declared member's own :class:`str` payload was
-        permanently empty regardless of value (``str(Method.GET) == ''``,
-        ``Method.GET == 'GET'`` was :obj:`False`) -- true on ``main`` at
-        ``60b85e3a4`` as well as when this test was first written. #870
-        fixed :meth:`Method.__new__` to ``str.__new__(cls, value)``,
-        mirroring :class:`~pcapkit.const.ftp.command.Command`'s own
-        ``__new__``, so a registered member now carries its value as its
-        :class:`str` payload too -- see
-        :mod:`tests.const.test_const_str_payload_870_unit` for the direct
-        pin of that fix, registry-wide. What is left here is what this
-        test was always really about: the *unregistered* path, which
-        already carried real content before #870 (it bypasses ``__new__``
-        entirely) and is unaffected by that fix."""
+        content. The *unregistered* path bypasses ``__new__`` entirely, so it
+        is independent of GitHub issue #870's fix to :meth:`Method.__new__`
+        (``str.__new__(cls, value)``, mirroring
+        :class:`~pcapkit.const.ftp.command.Command`'s own ``__new__``), which
+        gives a *registered* member its value as its :class:`str` payload too
+        -- see :mod:`tests.const.test_const_str_payload_870_unit` for the
+        direct pin of that fix, registry-wide."""
         from pcapkit.const.http.method import Method
 
         before = len(Method.__members__)
@@ -2136,11 +2068,11 @@ def test_registered_lookups_are_still_unaffected(self) -> None:
         those.
 
         ``Method.get`` is probed with its exact registered casing
-        (``'GET'``), not the lower-cased ``'get'`` this test used before
-        GitHub issue #896: ``Command``'s FTP command codes stay
-        case-insensitive per :rfc:`959#section-5`, but the HTTP method
-        token :rfc:`9110#section-9.1` covers is case-sensitive, so
-        ``Method.get('get')`` no longer resolves to :attr:`Method.GET` --
+        (``'GET'``), not the lower-cased ``'get'``: ``Command``'s FTP command
+        codes stay case-insensitive per :rfc:`959#section-5`, but the HTTP
+        method token :rfc:`9110#section-9.1` covers is case-sensitive
+        (GitHub issue #896), so ``Method.get('get')`` does not resolve to
+        :attr:`Method.GET` --
         see :class:`BespokeGetUnchangedTests`'s
         ``test_method_get_is_now_case_sensitive`` for that behaviour
         directly. ``Method('GET')`` (the constructor, reaching
@@ -2191,23 +2123,21 @@ def test_commandtype_is_untouched(self) -> None:
 
 class BespokeGetReplacementTests(unittest.TestCase):
     """:class:`~pcapkit.const.http.status_code.StatusCode` and
-    :class:`~pcapkit.const.ftp.return_code.ReturnCode` are the
-    converted classes whose hand-written ``get()`` -- on the
-    ``default == -1`` convention #857/#859 already retired everywhere else
-    -- was removed in favour of the base's :meth:`~pcapkit.corekit.enum.
-    EnumRegistry.get`, which uses :data:`~pcapkit.corekit.sentinels.NO_DEFAULT`
-    and never mints while resolving ``default`` (#864).
-
-    Verified before this replacement that no caller in :mod:`pcapkit` or
-    :mod:`tests` depends on the retired form: ``grep`` found exactly one
+    :class:`~pcapkit.const.ftp.return_code.ReturnCode` are the converted
+    classes that use the base's :meth:`~pcapkit.corekit.enum.EnumRegistry.get`
+    -- which uses :data:`~pcapkit.corekit.sentinels.NO_DEFAULT` and never
+    mints while resolving ``default`` (#864) -- rather than a hand-written
+    ``get()`` on the ``default == -1`` convention #857/#859 retired.
+
+    Measured when the hand-written form was replaced, so that no caller in
+    :mod:`pcapkit` or :mod:`tests` depends on it: ``grep`` found exactly one
     production call site each (:mod:`pcapkit.protocols.application.httpv1`
     and :mod:`pcapkit.protocols.application.ftp`), neither passing a
     ``default`` or a ``str`` key -- both call ``get(<int>)`` with no default,
-    which raises identically either way on an unresolvable key. Their own
-    ``str``-key ``get()`` branch (look up-or-mint *by name*, keyed on
-    ``default``) had no caller anywhere in this tree and is simply gone; the
-    base's ``str``-key path does an ordinary name-then-value lookup instead
-    and never mints.
+    which raises identically either way on an unresolvable key. The
+    hand-written ``str``-key branch (look up-or-mint *by name*, keyed on
+    ``default``) had no caller anywhere in the tree; the base's ``str``-key
+    path does an ordinary name-then-value lookup instead and never mints.
 
     """
 
@@ -2216,20 +2146,20 @@ def setUp(self) -> None:
 
     def test_statuscode_get_omitted_default_still_raises(self) -> None:
         """The one production call site's shape: no default passed, so an
-        unresolvable key must still raise -- true under both the old
-        ``default == -1`` convention and the new ``NO_DEFAULT`` one."""
+        unresolvable key must raise -- true under both the ``default == -1``
+        convention and the ``NO_DEFAULT`` one."""
         from pcapkit.const.http.status_code import StatusCode
 
         with self.assertRaises(ValueError):
             StatusCode.get(9999)
 
     def test_statuscode_get_minus_one_is_now_an_ordinary_default(self) -> None:
-        """Behaviour change, stated plainly: ``-1`` used to be the sentinel
-        for *no default*; it is now just an :class:`int` that -- like any
-        other -- is only honoured if it already names a registered member.
-        ``-1`` never has, on this registry, so passing it explicitly now
-        raises the *original* key's error instead of re-raising because it
-        matched the old sentinel."""
+        """``-1`` is not the sentinel for *no default* (it is under the
+        retired ``default == -1`` convention); it is just an :class:`int`
+        that -- like any other -- is only honoured if it already names a
+        registered member. ``-1`` does not, on this registry, so passing it
+        explicitly raises the *original* key's error rather than a re-raise
+        for matching a sentinel."""
         from pcapkit.const.http.status_code import StatusCode
 
         with self.assertRaises(ValueError) as caught:
@@ -2237,8 +2167,8 @@ def test_statuscode_get_minus_one_is_now_an_ordinary_default(self) -> None:
         self.assertIn('9999', str(caught.exception))
 
     def test_statuscode_get_default_never_mints(self) -> None:
-        """#864's ruling, on this registry for the first time: a ``default``
-        landing inside a now-converted unassigned range does not resolve to
+        """#864's ruling, on this registry: a ``default`` landing inside a
+        converted unassigned range does not resolve to
         an unregistered member the way ``key`` does -- it simply does not
         resolve, and ``key``'s own error propagates."""
         from pcapkit.const.http.status_code import StatusCode
@@ -2287,18 +2217,17 @@ class BespokeGetUnchangedTests(unittest.TestCase):
     :mod:`tests.const.test_const_method_case_sensitive_896_unit`
     (``test_command_get_stays_case_insensitive``).
 
-    :class:`Method` used to resolve case-insensitively the same way (#583),
-    but GitHub issue #896 retired that: RFC 9110 Section 9.1 makes the HTTP
-    method token case-sensitive, unlike FTP's command codes (RFC 959 Section
-    5.3), so ``Method.get('Get')`` no longer returns :attr:`Method.GET` --
-    see ``test_method_get_is_now_case_sensitive`` below, which replaces the
-    case-insensitive pin this class used to carry for it. ``Method`` still
-    keeps its own ``get()`` rather than the base's, because it still needs to
-    build an unregistered member preserving the caller's own casing on a
-    miss (the base's generic ``get()`` only ever raises or falls back to an
+    :class:`Method` does not resolve that way: it is case-sensitive (GitHub
+    issue #896, over #583's case-insensitive lookup), since RFC 9110 Section
+    9.1 makes the HTTP method token case-sensitive, unlike FTP's command codes
+    (RFC 959 Section 5.3), so ``Method.get('Get')`` does not return :attr:`Method.GET`
+    -- see ``test_method_get_is_now_case_sensitive`` below. ``Method`` keeps
+    its own ``get()`` rather than the base's, because it needs to build an
+    unregistered member preserving the caller's own casing on a miss (the
+    base's generic ``get()`` only ever raises or falls back to an
     already-registered ``default`` for a ``str`` key, per
-    :meth:`~pcapkit.corekit.enum.EnumRegistry.get`'s own docstring) -- what
-    #896 changed is only whether the lookup that precedes that fallback is
+    :meth:`~pcapkit.corekit.enum.EnumRegistry.get`'s own docstring) -- #896
+    concerns only whether the lookup that precedes that fallback is
     case-sensitive.
 
     :class:`OptionType`'s ``get()`` does its own multi-namespace dispatch via
@@ -2313,11 +2242,8 @@ def setUp(self) -> None:
     def test_method_get_is_now_case_sensitive(self) -> None:
         """GitHub issue #896: only the exact registered casing resolves.
 
-        Replaces this class's own ``test_method_get_is_still_case_
-        insensitive``, whose title and body pinned the opposite -- that
-        ``Method.get('Get')``/``Method.get('get')`` resolved to
-        :attr:`Method.GET`. RFC 9110 Section 9.1 makes the method token
-        case-sensitive, so a differently-cased probe now builds its own
+        RFC 9110 Section 9.1 makes the method token case-sensitive, so a
+        differently-cased probe such as ``Method.get('Get')`` builds its own
         unregistered member (preserving the caller's casing, same
         convention as :meth:`Method._unregistered_member`) rather than
         resolving to :attr:`Method.GET`.
@@ -2362,7 +2288,7 @@ class AppTypeUnmintConvertedTests(unittest.TestCase):
     :class:`~pcapkit.corekit.enum.EnumRegistry` and stopped from minting.
 
     Largest of the bespoke classes #860 step 2 converts: an AST walk over
-    :meth:`AppType._missing_` on ``c411d072a`` found range-bounded branches
+    :meth:`AppType._missing_` finds range-bounded branches
     -- placeholders (``unassigned_<port>`` and ``reserved_<port>``), and
     branches naming a real service IANA assigns to a whole span rather than
     to one declared member each (``x11`` for TCP and again for UDP,
@@ -2393,30 +2319,28 @@ class AppTypeUnmintConvertedTests(unittest.TestCase):
     ``TCP.register(6010, 'x11')`` explicitly.
 
     Unlike every bespoke class #860 step 2's PR 1 converted,
-    :meth:`AppType.get` already existed before #874 and does genuine
-    transport-protocol dispatch through :meth:`~AppType._dispatch` -- so,
-    unlike :class:`~pcapkit.const.http.status_code.StatusCode`/
+    :meth:`AppType.get` does genuine transport-protocol dispatch through
+    :meth:`~AppType._dispatch` -- so, unlike
+    :class:`~pcapkit.const.http.status_code.StatusCode`/
     :class:`~pcapkit.const.ftp.return_code.ReturnCode`, it keeps its own
     ``get()`` rather than being replaced by the base's; and, unlike
     :class:`~pcapkit.const.ftp.command.Command`/
     :class:`~pcapkit.const.http.method.Method`/
     :class:`~pcapkit.const.pcapng.option_type.OptionType`, its own
-    ``_unregistered_member`` override reconstructs three attributes
-    (``svc``, ``port``, ``proto``) rather than one or two, because
+    ``_unregistered_member`` override reconstructs three attributes (``svc``,
+    ``port``, ``proto``) rather than one or two, because
     :meth:`AppType.__new__` sets all three and none is optional for
     :meth:`__repr__`/:meth:`__str__`/:meth:`__int__`/the comparison
     operators/:attr:`~AppType.aliases` to run on the result without raising.
 
-    :meth:`AppType.register` arrived with #874. ``AppType`` already had a
-    working ``get``/``get_all``/``register_alias`` of its own, but never a
-    working ``register`` -- and the base's generic one (which calls
-    ``cls.__new__(cls, value)`` with only ``value``) would have built a
+    :meth:`AppType.register` comes from #874. The base's generic one (which
+    calls ``cls.__new__(cls, value)`` with only ``value``) would build a
     member with ``svc='<null>'`` and ``proto=TransportProtocol.undefined``,
-    silently wrong, the moment this class mixed in
+    silently wrong, if this class mixed in
     :class:`~pcapkit.corekit.enum.EnumRegistry` without an override. Scoped
     like :meth:`~AppType.register_alias` to **this** per-transport registry
     rather than dispatched through :meth:`~AppType._dispatch`, for the same
-    reason register_alias already was: minting on one transport must never
+    reason register_alias is: minting on one transport must never
     leak onto a transport IANA never assigned the service to.
 
     """
@@ -2427,8 +2351,8 @@ def setUp(self) -> None:
     def test_apptype_family_carries_the_registry_protocol(self) -> None:
         """#842's ruling is that ``get``/``get_all``/``register``/
         ``register_alias`` exist on every registry -- #860 step 2 PR 2 is
-        what actually delivers that for this family, including ``register``,
-        which none of the five had a working version of before #874."""
+        what actually delivers that for this family, including ``register``
+        (#874)."""
         from pcapkit.const.reg.apptype.apptype import AppType
         from pcapkit.const.reg.apptype.dccp import DCCP
         from pcapkit.const.reg.apptype.sctp import SCTP
@@ -2494,10 +2418,10 @@ def test_named_transport_span_still_dispatches_and_does_not_mint(self) -> None:
         lookup cannot come back carrying TCP's label -- and 6665-6669 is the
         sharper case, ``ircu`` on TCP but IANA's own ``reserved`` marker on
         UDP for the *same* span, so a merged branch could not have kept both.
-        Converting ``extend_enum(...)`` to ``_unregistered_member(...)`` left
-        every ``if``/``cls.__transport__ is ...`` test untouched -- this pins
-        that the dispatch survived the conversion, not just that minting
-        stopped."""
+        Every ``if``/``cls.__transport__ is ...`` test has the same shape
+        whether its branch ends in ``extend_enum(...)`` or
+        ``_unregistered_member(...)`` -- this pins the dispatch, not just
+        that nothing mints."""
         from pcapkit.const.reg.apptype.tcp import TCP
         from pcapkit.const.reg.apptype.udp import UDP
 
@@ -2520,8 +2444,8 @@ def test_named_transport_span_still_dispatches_and_does_not_mint(self) -> None:
 
     def test_get_second_mint_site_no_longer_mints(self) -> None:
         """54321 is not a declared member and not inside any of
-        ``_missing_``'s ranges either, so it used to reach :meth:`AppType.
-        get`'s own, second, independent ``extend_enum(...)`` call --
+        ``_missing_``'s ranges either, so it reaches :meth:`AppType.
+        get`'s own, second, independent mint site --
         distinct from the one inside ``_missing_``, and easy to miss when
         converting only the latter (exactly what round 2 review of #860 step
         2 PR 1 caught on :class:`~pcapkit.const.pcapng.option_type.
@@ -2546,9 +2470,9 @@ def test_missing_direct_call_still_raises_for_the_same_port(self) -> None:
         """The asymmetry #874 leaves in place, deliberately: a direct
         ``TCP(54321)`` has no ``get()`` around it to catch ``_missing_``'s
         :obj:`None` answer and build an ``'unknown'`` member from it, so it
-        still raises exactly as it did on ``main`` -- only :meth:`AppType.
-        get` gained the fallback, matching the constructor's own long-
-        standing behaviour of raising rather than minting for a value inside
+        raises -- only :meth:`AppType.get` has the fallback, the constructor
+        keeping its own behaviour of raising rather than minting for a value
+        inside
         ``0..65535`` but outside every declared member and every
         ``_missing_`` span."""
         from pcapkit.const.reg.apptype.tcp import TCP
@@ -2587,11 +2511,10 @@ def test_unregistered_member_on_apptype_itself_raises(self) -> None:
     def test_register_mints_a_real_member_and_refuses_a_duplicate_port(self) -> None:
         """``AppType._value_`` is the formatted ``'svc [port - proto]'``
         string, not the bare port -- so ``TCP(port)`` is not how a
-        registered member is reached at all, on ``main`` as well as here
-        (verified directly: ``TCP(80)`` raises for the real, declared
-        ``http`` member too). ``TCP.get(port)`` and the ``__registry__``
-        side table are the two things a real ``register()`` call is checked
-        against below."""
+        registered member is reached at all (verified directly: ``TCP(80)``
+        raises for the real, declared ``http`` member too). ``TCP.get(port)``
+        and the ``__registry__`` side table are the two things a real
+        ``register()`` call is checked against below."""
         from pcapkit.const.reg.apptype.tcp import TCP
 
         port = 59991
@@ -2617,10 +2540,10 @@ def test_register_on_apptype_itself_raises(self) -> None:
             AppType.register(1234, 'x')
 
     def test_register_alias_still_works_after_the_sanitizer_refactor(self) -> None:
-        """:meth:`AppType.register`/:meth:`AppType.register_alias` now share
+        """:meth:`AppType.register`/:meth:`AppType.register_alias` share
         :meth:`AppType._sanitize_identifier` rather than each carrying its
-        own copy of the sanitising steps -- this is the regression check
-        that the refactor changed nothing observable about the alias path."""
+        own copy of the sanitising steps -- this checks the alias path
+        through it."""
         from pcapkit.const.reg.apptype.tcp import TCP
 
         port = 59992
@@ -2649,11 +2572,11 @@ def test_apptype_get_dispatches_via_proto_without_minting(self) -> None:
     def test_apptype_unrecognised_proto_is_still_refused(self) -> None:
         """A ``proto`` naming no registry at all -- not one of the two real
         collision cases ``auto()`` introduced, just an ordinary invalid value
-        -- is still refused by :meth:`AppType._dispatch`, unaffected by
-        #874. (Deliberately not a composite like ``tcp | udp``: under
-        ``auto()`` that now equals ``sctp`` numerically and dispatches
-        there rather than raising, which is the one accepted, explicitly
-        untested consequence of the ``auto()`` change -- see
+        -- is refused by :meth:`AppType._dispatch`, as #874 leaves it.
+        (Deliberately not a composite like ``tcp | udp``: under ``auto()``
+        that equals ``sctp`` numerically and dispatches there rather than
+        raising, which is the one accepted, explicitly untested consequence
+        of the ``auto()`` numbering -- see
         :class:`TransportProtocolAutoTests`.)"""
         from pcapkit.const.reg.apptype.apptype import AppType
 
@@ -2663,15 +2586,16 @@ def test_apptype_unrecognised_proto_is_still_refused(self) -> None:
 
 class TransportProtocolAutoTests(unittest.TestCase):
     """:class:`~pcapkit.const.reg.apptype.apptype.TransportProtocol`'s
-    ``auto()`` conversion, #860 step 2 PR 2's other change. The owner ruled on
-    #860 that, since ``|`` composition is no longer allowed, ``auto()`` in place
-    of power-of-two spacing is the right move -- a breaking change, but an
+    ``auto()`` numbering, from #860 step 2 PR 2. The owner ruled on #860
+    that, since ``|`` composition is not allowed, ``auto()`` in place of
+    power-of-two spacing is the right move -- a breaking change, but an
     accepted one. On the one behavioural consequence -- a hand-composed
-    ``tcp | udp`` now equalling ``sctp`` numerically (``1 | 2 == 3``), where it
-    used to name no member at all and be refused as a whole -- the same thread
-    settled that no test should pin it: the path is obsolete after the breaking
-    change, and a test would preserve it as though it still mattered. So this class deliberately covers only the values and the
-    stale comment's removal, not the composition consequence: no test here
+    ``tcp | udp`` equalling ``sctp`` numerically (``1 | 2 == 3``) rather than
+    naming no member and being refused as a whole -- the same thread settled
+    that no test should pin it: the path is obsolete after the breaking
+    change, and a test would preserve it as though it still mattered. So this
+    class deliberately covers only the values and the stale comment's
+    absence, not the composition consequence: no test here
     calls ``_dispatch`` with a composed value at all, unlike
     :meth:`AppTypeUnmintConvertedTests.
     test_apptype_unrecognised_proto_is_still_refused`, which uses an
@@ -2689,10 +2613,10 @@ def test_values_are_sequential_from_zero(self) -> None:
         self.assertEqual(int(TransportProtocol.dccp), 4)
 
     def test_still_not_a_registry(self) -> None:
-        """Unaffected by #874: ``TransportProtocol`` never minted through
+        """``TransportProtocol`` does not mint through
         :meth:`~pcapkit.corekit.enum.EnumRegistry._unregistered_member`, and
-        does not mix in :class:`~pcapkit.corekit.enum.EnumRegistry` now
-        either -- only ``AppType`` and its four transport subclasses do."""
+        does not mix in :class:`~pcapkit.corekit.enum.EnumRegistry` -- only
+        ``AppType`` and its transport subclasses do."""
         from pcapkit.const.reg.apptype.apptype import TransportProtocol
         from pcapkit.corekit.enum import EnumRegistry
 
@@ -2700,25 +2624,25 @@ def test_still_not_a_registry(self) -> None:
 
     def test_get_still_refuses_an_unrecognised_name(self) -> None:
         """GitHub PR #836's ruling against extending ``TransportProtocol``
-        at all is untouched by the ``auto()`` change -- :meth:`~pcapkit.const.
-        reg.apptype.apptype.TransportProtocol.get` still has no ``_missing_``
-        of its own and still refuses outright rather than minting.
+        at all holds under the ``auto()`` numbering -- :meth:`~pcapkit.const.
+        reg.apptype.apptype.TransportProtocol.get` has no ``_missing_`` of its
+        own and refuses outright rather than minting.
 
-        :exc:`KeyError`-shaped since GitHub issue #923, which retired the
-        override's ``KeyError`` -> ``ValueError`` conversion; the refusal itself
-        is what this test is about and that is unchanged."""
+        :exc:`KeyError`-shaped: the override does no ``KeyError`` ->
+        ``ValueError`` conversion (GitHub issue #923); the refusal itself is
+        what this test is about."""
         from pcapkit.const.reg.apptype.apptype import TransportProtocol
 
         with self.assertRaises(KeyError):
             TransportProtocol.get('not-a-real-transport')
 
     def test_stale_power_of_two_comment_is_gone(self) -> None:
-        """Per GitHub issue #860: the in-code comment claiming
-        the values "must keep" power-of-two spacing contradicted the PR #836
-        ruling that nothing composes a ``TransportProtocol`` any
-        more, and is deleted rather than merely superseded -- checked
-        against the generated source itself, not the docstring here, so a
-        regeneration that reintroduces it fails this test."""
+        """Per GitHub issue #860: an in-code comment claiming the values
+        "must keep" power-of-two spacing contradicts the PR #836 ruling that
+        nothing composes a ``TransportProtocol``, so the generated source
+        carries none -- checked against the generated source itself, not the
+        docstring here, so a regeneration that reintroduces it fails this
+        test."""
         import pcapkit.const.reg.apptype.apptype as apptype_module
 
         source = pathlib.Path(apptype_module.__file__).read_text(encoding='utf-8')
diff --git a/tests/const/test_const_ethertype_862_unit.py b/tests/const/test_const_ethertype_862_unit.py
index 5592b4dbbe..4c5cecf13b 100644
--- a/tests/const/test_const_ethertype_862_unit.py
+++ b/tests/const/test_const_ethertype_862_unit.py
@@ -18,14 +18,13 @@
 crawler -- :mod:`pcapkit.vendor.reg.ethertype` fetches the live IANA CSV on
 every regeneration, so there is no local data table to hand-reorder. The fix
 is therefore general rather than a special case for these two constants:
-:meth:`~pcapkit.vendor.reg.ethertype.EtherType.process` now collects every
+:meth:`~pcapkit.vendor.reg.ethertype.EtherType.process` collects every
 range row's ``(start, stop, body)`` before rendering, and
 :meth:`~pcapkit.vendor.reg.ethertype.EtherType._insert_range` places each new
 range immediately ahead of the first already-placed range that fully contains
 it, leaving every non-overlapping pair in the CSV's own row order. Sweeping
-every range test in the committed, generated file (measured directly against
-``main`` at ``70fa92010``, the #861 merge commit this issue was blocked on)
-found this to be the *only* containment pair among them -- no other subsumed
+every range test in the committed, generated file finds this to be the *only*
+containment pair among them -- no other subsumed
 range exists in :class:`~pcapkit.const.reg.ethertype.EtherType`, so
 :class:`EtherTypeGeneratorGeneralOrderingTests` below pins the algorithm
 itself against synthetic nested ranges rather than a second real-world pair.
@@ -167,15 +166,12 @@ def test_unrelated_non_overlapping_range_keeps_table_order(self) -> None:
     def test_both_ranges_still_render_with_their_own_body(self) -> None:
         # Reordering must not lose either range or swap their bodies.
         #
-        # NOTE: the second assertion used to check for the ``extend_enum``
-        # form ("IEEE802.3 Length Field" was one of the ranges GitHub issue
-        # #775's original ruling left minting). #775's final round converts
-        # every remaining range branch on this crawler -- see
-        # tests/const/test_const_enum_no_mint.py's own docstring -- so this
-        # now checks for the ``_unregistered_member`` form instead, keeping
-        # the hex-suffixed name exactly as before; only the registration
-        # mechanism changed, because PR #878 scoped the change as not
-        # registering rather than renaming.
+        # NOTE: the second assertion checks for the ``_unregistered_member``
+        # form, not ``extend_enum``: #775's final round converts every range
+        # branch on this crawler -- see
+        # tests/const/test_const_enum_no_mint.py's own docstring. The
+        # hex-suffixed name is kept, because PR #878 scoped that conversion
+        # as not registering rather than renaming.
         _enum, miss = self._process_fixture()
         text = '\n'.join(miss)
 
diff --git a/tests/const/test_const_ftp_command_get_key_type_1824_unit.py b/tests/const/test_const_ftp_command_get_key_type_1824_unit.py
index 92e3bb663e..d3a29e42d1 100644
--- a/tests/const/test_const_ftp_command_get_key_type_1824_unit.py
+++ b/tests/const/test_const_ftp_command_get_key_type_1824_unit.py
@@ -10,7 +10,7 @@
 which made it a :class:`classmethod` delegating to
 :meth:`~pcapkit.corekit.enum.EnumLookup.get`.
 
-``Command.get`` now follows it: a non-``str`` key goes to the base, whose call
+``Command.get`` follows it: a non-``str`` key goes to the base, whose call
 to ``Command._validate_value`` (added by #1823) raises
 :exc:`~pcapkit.utilities.exceptions.EnumValueError`. ``default`` is not
 forwarded there, exactly as ``Method.get`` forwards none, because this
diff --git a/tests/const/test_const_ftp_featcode_case_903_unit.py b/tests/const/test_const_ftp_featcode_case_903_unit.py
index c11e3a87a9..4233d80cb7 100644
--- a/tests/const/test_const_ftp_featcode_case_903_unit.py
+++ b/tests/const/test_const_ftp_featcode_case_903_unit.py
@@ -46,7 +46,7 @@
 RFC and IANA themselves use upper and lower case for the same field, that mix
 is itself an indication of case insensitivity.
 
-**Pre-change behaviour, measured before the fix** (throwaway process, no
+**Behaviour without the fix, as measured** (throwaway process, no
 probe that could mint; ``_member_map_`` and ``_value2member_map_`` both 15
 entries before and after)::
 
@@ -80,7 +80,7 @@
 :class:`~pcapkit.const.pcapng.tls_key_label.TLSKeyLabel`, whose RFC 9850
 Section 4.2 registry and live IANA CSV agree on upper case in all 10 rows
 with no comparison rule stated anywhere, is measured below as the witness
-that the base is untouched by this change.
+that the base ``get`` stays case-sensitive.
 """
 
 import inspect
@@ -102,7 +102,7 @@ class FEATCodeCaseInsensitiveLookupTests(unittest.TestCase):
     """``get`` resolves a FEAT code whatever case the caller spells it in."""
 
     def test_a_lower_case_placeholder_resolves_from_upper_case(self) -> 'None':
-        """The issue's repro. ``get('BASE')`` used to raise ``KeyError``.
+        """The issue's repro. Without the fix, ``get('BASE')`` raises ``KeyError``.
 
         Upper case is what RFC 2389 Section 3.2 recommends implementations
         transmit, so this is the casing a caller reading a real ``FEAT``
diff --git a/tests/const/test_const_ipv6_extension_header_925_unit.py b/tests/const/test_const_ipv6_extension_header_925_unit.py
index 211c364191..9466dba894 100644
--- a/tests/const/test_const_ipv6_extension_header_925_unit.py
+++ b/tests/const/test_const_ipv6_extension_header_925_unit.py
@@ -1,40 +1,32 @@
 # -*- coding: utf-8 -*-
-"""``ExtensionHeader`` drops ``BIT_EMU``, per GitHub issue #925.
-
-Issue #925's own diagnosis: :mod:`pcapkit.const.ipv6.extension_header` had 12
-members, but IANA's authoritative *IPv6 Extension Header Types* registry
-(``ipv6-parameters/extension-header.csv``) has 11 -- the crawler used to be
-sourced from the *Protocol Numbers* registry's ``IPv6 Extension Header``
-column instead, which disagrees with the authoritative registry on header
-147 (``BIT-EMU``). :mod:`tests.vendor.test_vendor_ipv6_extension_header_925_unit`
-fixes and pins that crawler, and its
+"""``ExtensionHeader`` has no ``BIT_EMU``, per GitHub issue #925.
+
+Issue #925's own diagnosis: IANA's authoritative *IPv6 Extension Header Types*
+registry (``ipv6-parameters/extension-header.csv``) and the *Protocol Numbers*
+registry's ``IPv6 Extension Header`` column disagree on header 147
+(``BIT-EMU``), so a crawler sourced from the latter generates a
+:mod:`pcapkit.const.ipv6.extension_header` member the authoritative registry
+does not have. :mod:`tests.vendor.test_vendor_ipv6_extension_header_925_unit`
+pins the crawler to the authoritative registry, and its
 ``test_context_matches_the_committed_const_file_byte_for_byte`` proves this
 file is exactly what the fixed crawler produces from the fixture the issue's
 own investigation fetched.
 
-Removing ``BIT_EMU`` looked blocked at first: :meth:`pcapkit.protocols
-.internet.ipv6.IPv6._decode_next_layer` resolves ``Enum_ExtensionHeader
-(proto)`` at the top of its extension-header walk loop, wrapped in
-``try/except ValueError: break``, and ``tests.protocols.internet
+:meth:`pcapkit.protocols.internet.ipv6.IPv6._decode_next_layer` resolves
+``Enum_ExtensionHeader(proto)`` at the top of its extension-header walk loop,
+wrapped in ``try/except ValueError: break``. ``tests.protocols.internet
 .test_ipv6_ext_unit.IPv6ExtUnitTests
-.test_unimplemented_terminal_code_stops_the_walk_not_the_packet`` used to
-build its packet around ``TransType.BIT_EMU``/``ExtensionHeader.BIT_EMU``.
-But that test's own docstring says 147 was only ever the *example*: ``"253``
-/``254`` are the same code path (also unregistered, also resolve to
-``Raw``)"``. Unlike 147, 253 *is* in the authoritative extension-header
-registry, so that test now builds its packet around 253 instead --
-identical code path, still a real IANA extension-header code, and no longer
-tied to a member this file is dropping. That is what frees ``BIT_EMU`` to
-actually go.
-
-This suite is what is left to pin on the const side of that boundary: the
-member count, ``BIT_EMU``'s absence, and that :meth:`pcapkit.protocols
-.internet.ipv6.IPv6._decode_next_layer`'s walk still resolves a next-header
-code no longer backed by any ``ExtensionHeader`` member -- 147 itself is
-still a real :class:`~pcapkit.const.reg.transtype.TransType` value (it
-legitimately belongs there; that enum is sourced from the still-correct
-Protocol Numbers registry and is untouched by this fix) -- without raising
-or losing the packet's own header fields.
+.test_unimplemented_terminal_code_stops_the_walk_not_the_packet`` builds its
+packet around 253, not 147: the same code path, and unlike 147 a code the
+authoritative extension-header registry holds.
+
+This suite pins the const side of that boundary: the member count,
+``BIT_EMU``'s absence, and that :meth:`pcapkit.protocols
+.internet.ipv6.IPv6._decode_next_layer`'s walk handles a next-header code not
+backed by any ``ExtensionHeader`` member -- 147 itself is a real
+:class:`~pcapkit.const.reg.transtype.TransType` value (it legitimately belongs
+there; that enum is sourced from the Protocol Numbers registry, which is
+correct for it) -- without raising or losing the packet's own header fields.
 
 """
 from __future__ import annotations
@@ -58,7 +50,7 @@ def _ipv6_bytes(next_code: 'int', ext_and_payload: 'bytes') -> 'bytes':
 
 
 class ExtensionHeaderBitEmuRemovedTests(unittest.TestCase):
-    """``BIT_EMU`` is gone, and the ``ipv6.py`` walk still handles 147 cleanly."""
+    """There is no ``BIT_EMU``, and the ``ipv6.py`` walk handles 147 cleanly."""
 
     def test_extension_header_now_has_exactly_eleven_members(self) -> None:
         from pcapkit.const.ipv6.extension_header import ExtensionHeader
@@ -69,9 +61,9 @@ def test_extension_header_now_has_exactly_eleven_members(self) -> None:
 
     def test_bit_emu_value_no_longer_resolves(self) -> None:
         # The exact call IPv6._decode_next_layer makes at the
-        # top of its extension-header walk loop. With BIT_EMU gone and no
+        # top of its extension-header walk loop. With no BIT_EMU member and no
         # _missing_ defined on this generated file (neither EnumLookup nor
-        # EnumRegistry in pcapkit.corekit.enum defines one either), 147 now
+        # EnumRegistry in pcapkit.corekit.enum defines one either), 147
         # raises plain ValueError instead of resolving.
         from pcapkit.const.ipv6.extension_header import ExtensionHeader
 
@@ -87,8 +79,8 @@ def test_transtype_still_carries_bit_emu(self) -> None:
         self.assertEqual(int(TransType.BIT_EMU), 147)
 
     def test_ipv6_walk_stops_cleanly_on_the_code_bit_emu_used_to_occupy(self) -> None:
-        # The behaviour actually worth protecting, restated for 147 now that
-        # it is no longer an ExtensionHeader member: IPv6._decode_next_layer
+        # The behaviour actually worth protecting, restated for 147, which is
+        # not an ExtensionHeader member: IPv6._decode_next_layer
         # must not raise or lose the packet's own header just because a
         # next-header code does not resolve as an extension header at all.
         # ExtensionHeader(147) raising breaks the walk loop on its very
@@ -107,8 +99,8 @@ def test_ipv6_walk_stops_cleanly_on_the_code_bit_emu_used_to_occupy(self) -> Non
         self.assertEqual(str(ipv6.src), '::1')
         self.assertEqual(str(ipv6.dst), '::1')
 
-        # no longer recorded as an extension header at all -- 147 is not one
-        # any more, so the walk loop's own top-of-loop check breaks
+        # not recorded as an extension header at all -- 147 is not one, so
+        # the walk loop's own top-of-loop check breaks
         # immediately rather than ever reaching self._exthdr.add(...).
         exthdrs = list(ipv6.extension_headers.items(multi=True))
         self.assertEqual(exthdrs, [])
diff --git a/tests/const/test_const_linktype_209_unit.py b/tests/const/test_const_linktype_209_unit.py
index 71a84904e0..ad99cf3bb4 100644
--- a/tests/const/test_const_linktype_209_unit.py
+++ b/tests/const/test_const_linktype_209_unit.py
@@ -16,7 +16,7 @@
 fixing this).
 
 The fix is in the generator, :mod:`pcapkit.vendor.reg.linktype`, not in the
-generated file: :meth:`~pcapkit.vendor.reg.linktype.LinkType.process` now
+generated file: :meth:`~pcapkit.vendor.reg.linktype.LinkType.process`
 sinks any row whose notes column mentions "legacy" into a bucket appended
 *after* every other row, so the current name is always the first one defined
 for a shared value regardless of the source table's own row order.
@@ -27,7 +27,7 @@
 meaning a future *current* row whose notes happened to mention "legacy" about
 some unrelated code would be wrongly sunk, and a single ``USER0``-style range
 row would sink all sixteen expanded members at once instead of none.
-:meth:`~pcapkit.vendor.reg.linktype.LinkType.process` now only sinks a
+:meth:`~pcapkit.vendor.reg.linktype.LinkType.process` only sinks a
 single-value row when its value is a genuine duplicate elsewhere in the same
 table, and never routes a range row through the sink at all.
 
@@ -35,8 +35,8 @@
 first cut of the duplicate-value pre-scan counted only single-value rows, so a
 value duplicated *across a range boundary* -- a single-value row sharing a
 value with one member of a ``USER0``-style range -- was invisible to it, and
-that row's legacy alias was no longer sunk even when correctly worded. The
-pre-scan now expands ``a–b`` ranges the same way the main loop does
+that row's legacy alias was not sunk even when correctly worded. The
+pre-scan expands ``a–b`` ranges the same way the main loop does
 before counting, so no duplicate is missed regardless of which branch the
 value comes from.
 
@@ -311,10 +311,10 @@ def _process(html: str) -> 'list[str]':
     def test_non_duplicated_legacy_wording_does_not_reorder(self) -> None:
         """A row cannot be sunk unless another row actually shares its value.
 
-        Fails against the value-blind, word-only predicate on ``main``: that
-        predicate sinks ``FOO_LEGACY_WORDED`` purely because its notes
-        contain "legacy", swapping it after ``BAR_PLAIN`` in the returned
-        list even though value 500 has no duplicate anywhere in this table.
+        Fails against a value-blind, word-only predicate, which sinks
+        ``FOO_LEGACY_WORDED`` purely because its notes contain "legacy",
+        swapping it after ``BAR_PLAIN`` in the returned list even though
+        value 500 has no duplicate anywhere in this table.
         The value-aware predicate leaves both rows in table order, because
         neither of their values is duplicated.
         """
@@ -343,7 +343,7 @@ def test_duplicate_pair_canonical_member_is_order_independent(self) -> None:
         is earned here rather than borrowed from a sibling class. A predicate
         that regressed to counting only a positional prefix (e.g. "has this
         value already been appended to ``enum``") would still pass a
-        single-order test like the old one, because that predicate is only
+        single-order test, because that predicate is only
         wrong for the *first* occurrence of a value it has not seen yet --
         exactly what running the reversed order below would catch.
         """
@@ -397,11 +397,11 @@ def test_duplicate_pair_canonical_member_is_order_independent(self) -> None:
 class LinkTypeGeneratorRangeSinkIsolationTests(unittest.TestCase):
     """Item 2 of GitHub issue #852: a range row must never sink its whole expansion.
 
-    The ``ValueError`` branch that expands a ``USER0``-style range used to
-    reuse the same per-row ``sink`` the single-value branch computed, so one
-    range row whose notes mentioned "legacy" would have sunk every expanded
+    Guards against the ``ValueError`` branch that expands a ``USER0``-style
+    range reusing the per-row ``sink`` the single-value branch computes, which
+    makes one range row whose notes mention "legacy" sink every expanded
     member at once. :meth:`~pcapkit.vendor.reg.linktype.LinkType.process`
-    now always appends range-expanded members straight into ``enum``,
+    always appends range-expanded members straight into ``enum``,
     unconditionally, and this pins that deliberately.
     """
 
@@ -474,7 +474,7 @@ class LinkTypeGeneratorCrossRangeDuplicateTests(unittest.TestCase):
     ``enum`` instead of ``legacy``, ahead of the range it duplicates, making
     the deprecated ``OLDUSER`` canonical for value 900 instead of ``USER0``.
     That is exactly the failure mode #844 and #852 both exist to close,
-    reopened by narrowing the predicate. :meth:`process`'s pre-scan now
+    reopened by narrowing the predicate. :meth:`process`'s pre-scan
     expands ``a–b`` ranges the same way the main loop does before counting,
     so this duplicate is caught regardless of which branch either occurrence
     comes from.
@@ -505,20 +505,18 @@ def test_legacy_row_duplicating_a_range_member_is_sunk(self) -> None:
         )
 
     def test_malformed_en_dash_range_still_raises_loudly(self) -> None:
-        """A malformed registry row must still fail loudly -- via the pre-existing main loop.
+        """A malformed registry row must still fail loudly -- via the main loop.
 
         A number column with more than one en dash (``900–903–905``) cannot
         ``start, stop = map(int, ...)`` -- too many values to unpack. The
         pre-scan's local ``_expand`` swallows exactly that ``ValueError`` and
         contributes no counted values for the row, quietly -- but that is
         *not* what makes this test pass. This is a regression guard on the
-        main loop's own, pre-existing ``start, stop = map(int,
-        temp.split('–'))``, which hits the identical unpack error a few
-        lines later and still raises, uncaught, out of :meth:`process`.
-        That statement predates #852 entirely, so this assertion passes
-        identically on ``main``, on #854's first commit (before
-        ``_expand`` existed), and here: nothing about the pre-scan is what
-        is being pinned.
+        main loop's own ``start, stop = map(int, temp.split('–'))``, which
+        hits the identical unpack error a few lines later and still raises,
+        uncaught, out of :meth:`process`. That statement is independent of
+        #852's pre-scan, so this assertion holds with or without ``_expand``:
+        nothing about the pre-scan is what is being pinned.
         """
         import bs4
 
@@ -589,7 +587,7 @@ class LinkTypeGeneratorSignedOrUnderscoredValueTests(unittest.TestCase):
     Not reachable against tcpdump's table as vendored here: every committed
     member matches a plain unsigned decimal, so this is a latent
     hole rather than a live defect, exactly as #844 and #852's original
-    word-only rule was. :meth:`process`'s ``_expand`` now tries ``int(temp)``
+    word-only rule was. :meth:`process`'s ``_expand`` tries ``int(temp)``
     directly, before the en-dash range check, so it recognises the same
     values the main loop does.
     """
diff --git a/tests/const/test_const_method_case_sensitive_896_unit.py b/tests/const/test_const_method_case_sensitive_896_unit.py
index c745b15c43..77362c5dfe 100644
--- a/tests/const/test_const_method_case_sensitive_896_unit.py
+++ b/tests/const/test_const_method_case_sensitive_896_unit.py
@@ -1,9 +1,9 @@
 # -*- coding: utf-8 -*-
 """``Method.get`` must be case-sensitive, per RFC 9110 Section 9.1.
 
-GitHub issue #896: :meth:`pcapkit.const.http.method.Method.get` used to
-upper-case its ``key`` before looking it up (``name = key.upper()``, then
-``name not in Method._member_map_``), so ``Method.get('get')`` resolved to
+GitHub issue #896: without the fix, :meth:`pcapkit.const.http.method.Method.get`
+upper-cases its ``key`` before looking it up (``name = key.upper()``, then
+``name not in Method._member_map_``), so ``Method.get('get')`` resolves to
 the same object as ``Method.get('GET')`` -- :attr:`Method.GET`. RFC 9110
 Section 9.1 says the opposite is required::
 
@@ -40,14 +40,14 @@
 ``GET``" into "raises ``KeyError``", not into "resolves to an unregistered
 member preserving ``'get'``" as the issue's own *expected behaviour* section
 asks for -- and as :mod:`tests.protocols.application.test_http_unit` and
-:mod:`tests.const.test_const_enum_no_mint` already require elsewhere in this
-change. So the fix keeps ``Method``'s own ``get`` override -- it still needs
-to build that unregistered member on a miss, which the base's ``get`` does
-not do for a ``str`` key -- and only removes the ``.upper()`` folding from
-the *match* it performs before falling through to that fallback. The
-``_unregistered_member`` call it falls through to still canonicalises the
+:mod:`tests.const.test_const_enum_no_mint` also require. So the fix keeps
+``Method``'s own ``get`` override -- it still needs to build that unregistered
+member on a miss, which the base's ``get`` does not do for a ``str`` key -- and
+only removes the ``.upper()`` folding from the *match* it performs before
+falling through to that fallback. The ``_unregistered_member`` call it falls
+through to still canonicalises the
 *name* (the identifier) to upper case, exactly as :meth:`Method._missing_`
-does; only the *value* -- and now, the match against a *registered* name --
+does; only the *value* -- and the match against a *registered* name --
 keeps the caller's exact casing.
 
 This module also pins the crawler and the generated file against each
@@ -87,7 +87,7 @@ def _reconstruct_fixture_csv() -> 'str':
 
     This is the offline substitute for a live crawl against
     ``https://www.iana.org/assignments/http-methods/methods.csv``, which
-    this change must not perform. Faithfulness is what
+    no test here may perform. Faithfulness is what
     :meth:`MethodGetCaseSensitivityTests.
     test_vendor_template_matches_the_generated_module` below checks: feeding
     this fixture back through :meth:`~pcapkit.vendor.http.method.Method.
@@ -185,7 +185,7 @@ def test_get_lowercase_does_not_resolve_to_the_standard_member(self) -> None:
         self.assertNotEqual(probed, 'GET')
 
     def test_unregistered_member_preserves_the_callers_casing(self) -> None:
-        """The value of the unregistered member ``get('get')`` now builds is
+        """The value of the unregistered member ``get('get')`` builds is
         exactly what the caller passed -- never upper-cased -- matching the
         convention :meth:`~pcapkit.const.http.method.Method.
         _unregistered_member` documents and :class:`~pcapkit.const.ftp.
diff --git a/tests/const/test_const_method_value_lookup_908_unit.py b/tests/const/test_const_method_value_lookup_908_unit.py
index d0a0bda72d..238849f74f 100644
--- a/tests/const/test_const_method_value_lookup_908_unit.py
+++ b/tests/const/test_const_method_value_lookup_908_unit.py
@@ -160,7 +160,7 @@ class DefaultSignatureTests(unittest.TestCase):
     def test_default_still_names_the_unregistered_members_value(self) -> None:
         """Omitted or ``None``, ``default`` uses ``key`` itself; supplied,
         it replaces the *value* of the freshly minted unregistered member --
-        unchanged from before #908, and distinct from the base's own
+        the same with or without #908's fix, and distinct from the base's own
         ``default``, which must already name a registered value."""
         from pcapkit.const.http.method import Method
 
@@ -192,8 +192,8 @@ class HTTPv1EndToEndTests(unittest.TestCase):
     def test_a_baseline_control_request_line_reports_the_registrys_idempotent_flag(
             self) -> None:
         """``_RE_METHOD`` admits the hyphen, so this request line reaches
-        ``Enum_Method.get(...)`` in ``httpv1.HTTP._read_start_line`` and used to come back
-        with ``idempotent=False`` -- the wrong answer for a parse that
+        ``Enum_Method.get(...)`` in ``httpv1.HTTP._read_start_line``, which without the
+        fix comes back with ``idempotent=False`` -- the wrong answer for a parse that
         otherwise succeeds silently. Pins the whole path, not only the
         direct ``Method.get`` call above."""
         from pcapkit.const.http.method import Method
@@ -252,24 +252,24 @@ def tearDown(self) -> None:
         )
 
     def test_an_int_key_raises_value_error(self) -> None:
-        """Was :exc:`AttributeError` from ``key.upper()`` before #908."""
+        """Without #908's fix, this raises :exc:`AttributeError` from ``key.upper()``."""
         from pcapkit.const.http.method import Method
 
         with self.assertRaises(ValueError):
             Method.get(42)
 
     def test_a_none_key_raises_value_error(self) -> None:
-        """Was :exc:`AttributeError` from ``key.upper()`` before #908."""
+        """Without #908's fix, this raises :exc:`AttributeError` from ``key.upper()``."""
         from pcapkit.const.http.method import Method
 
         with self.assertRaises(ValueError):
             Method.get(None)  # type: ignore[arg-type]
 
     def test_a_bytes_key_raises_instead_of_returning_a_bytes_valued_member(self) -> None:
-        """The one that changed from a *return* to a raise.
+        """The one case that *returns* rather than raises without the fix.
 
-        Before #908 this handed back a member whose ``name`` and ``value``
-        were both ``b'GET'``. ``bytes`` is the plausible mistake here, since
+        Without #908's fix this hands back a member whose ``name`` and
+        ``value`` are both ``b'GET'``. ``bytes`` is the plausible mistake here, since
         ``_RE_METHOD`` (in ``pcapkit/protocols/application/http.py``) is a
         bytes pattern and ``httpv1`` is bytes throughout -- the live call in
         ``httpv1.HTTP._read_start_line`` is safe only because it wraps the match in
diff --git a/tests/const/test_const_register_validates_every_registry_1816_unit.py b/tests/const/test_const_register_validates_every_registry_1816_unit.py
index 689da7467e..eb30850916 100644
--- a/tests/const/test_const_register_validates_every_registry_1816_unit.py
+++ b/tests/const/test_const_register_validates_every_registry_1816_unit.py
@@ -5,7 +5,7 @@
 new value through :meth:`~pcapkit.corekit.enum.EnumLookup._validate_value`, but
 only ``AppType`` (#1792) overrode that hook, so everywhere else ``register``
 minted a value ``get`` refuses: ``Hardware.register(70000, 'x')`` minted, and
-``Hardware.get(70000)`` then returned the new member. Every registry now overrides
+``Hardware.get(70000)`` then returned the new member. Every registry overrides
 the hook. A generated one uses the check its ``_missing_`` makes; ``TLSKeyLabel``
 and ``ExtensionHeader`` have no ``_missing_``, so they check the member type and
 the 8-bit Next Header field respectively.
diff --git a/tests/const/test_const_registry_protocol.py b/tests/const/test_const_registry_protocol.py
index 4c80a95fca..235d1b137b 100644
--- a/tests/const/test_const_registry_protocol.py
+++ b/tests/const/test_const_registry_protocol.py
@@ -14,7 +14,7 @@
 subclasses override further where their contracts differ.
 
 :class:`~pcapkit.corekit.enum.EnumRegistry` is tier one of that hierarchy. This
-module pins both halves of the claim: that the generated registries in this batch
+module pins both halves of the claim: that the generated registries covered here
 really do inherit the protocol rather than carry a copy of it, and that each of
 the four methods honours the contract the maintainer wrote for it.
 
@@ -56,7 +56,7 @@
 #: ``ftp/return_code``, ``http/method``, ``http/status_code``,
 #: ``pcapng/option_type``) do each define a custom ``__new__`` attaching further
 #: attributes, so an unregistered member of theirs would be missing them; they
-#: need their own override and stay out of this batch.
+#: need their own override and are not in this set.
 CONVERTED = (
     ('pcapkit.const.mh.binding_ack_flag', 'BindingACKFlag', 'pcapkit/const/mh/binding_ack_flag.py'),
     ('pcapkit.const.mh.binding_update_flag', 'BindingUpdateFlag', 'pcapkit/const/mh/binding_update_flag.py'),
@@ -66,8 +66,8 @@
     ('pcapkit.const.tcp.flags', 'Flags', 'pcapkit/const/tcp/flags.py'),
 )
 
-#: The crawlers whose bespoke templates were converted, and which must therefore
-#: no longer spell a ``get()`` of their own.
+#: The crawlers whose bespoke templates are converted, and which must therefore
+#: spell no ``get()`` of their own.
 CONVERTED_VENDORS = (
     'pcapkit/vendor/mh/binding_ack_flag.py',
     'pcapkit/vendor/mh/binding_update_flag.py',
@@ -128,7 +128,7 @@ def test_converted_const_modules_declare_the_base(self) -> None:
 
     def test_converted_const_modules_carry_no_copy_of_the_protocol(self) -> None:
         """A ``def get``/``def register`` left behind would silently shadow the
-        base class, which is the failure this batch exists to remove."""
+        base class, which is the failure this module guards against."""
         for _, name, relpath in CONVERTED:
             source = (REPO_ROOT / relpath).read_text()
             for method in PROTOCOL:
@@ -198,9 +198,9 @@ class _Str(EnumRegistry, StrEnum):
 
 
 class _PreConversionFlags(IntFlag):
-    """A reproduction of ``pcapkit.const.tcp.flags.Flags`` exactly as it stood
-    on commit ``02296b5dd`` (this batch's prior head), before ``tcp/flags``
-    joined :data:`CONVERTED`: a plain ``class Flags(IntFlag)`` with its own
+    """A reproduction of ``pcapkit.const.tcp.flags.Flags`` without its
+    conversion onto :class:`~pcapkit.corekit.enum.EnumRegistry` (see
+    :data:`CONVERTED`): a plain ``class Flags(IntFlag)`` with its own
     hand-copied ``get`` (omitted here -- irrelevant to ``_missing_``) and this
     ``_missing_``, copied verbatim. Kept inline rather than fetched from git
     history so :class:`TCPFlagsConversionTests` runs offline and the
@@ -242,21 +242,21 @@ def _resolve_or_raise(cls: 'Any', value: 'Any') -> 'Any':
 
 
 class TCPFlagsConversionTests(unittest.TestCase):
-    """GitHub issue #775's own finding: the PR description's stated reason
-    for excluding ``tcp/flags`` from this batch -- "each attach extra
-    attributes in ``__new__``" -- does not hold for it.
+    """GitHub issue #775's own finding: the stated reason for excluding
+    ``tcp/flags`` from :data:`CONVERTED` -- "each attach extra attributes in
+    ``__new__``" -- does not hold for it.
     ``grep -c 'def __new__'`` reports ``0`` for both
     ``pcapkit/vendor/tcp/flags.py`` and ``pcapkit/const/tcp/flags.py``, the
-    same shape as the four ``mh/*_flag`` registries this batch already
-    converts, so it belongs in :data:`CONVERTED` rather than in the five
-    templates excluded for actually defining one.
+    same shape as the four ``mh/*_flag`` registries in :data:`CONVERTED`, so
+    it belongs there rather than among the five templates excluded for
+    actually defining one.
     """
 
     def setUp(self) -> None:
         reimport_once_per_class(self, restore=True)
 
     def test_tcp_flags_now_inherits_the_base(self) -> None:
-        """Fails on ``02296b5dd``, where ``Flags`` is a plain ``IntFlag``.
+        """Guards against ``Flags`` being a plain ``IntFlag``.
 
         Resolves ``EnumRegistry`` freshly from the just-reimported
         ``pcapkit.corekit.enum`` rather than the module-scope import above --
@@ -299,11 +299,11 @@ def test_missing_resolves_identically_to_the_pre_conversion_shape(self) -> None:
                                  _resolve_or_raise(Flags, value))
 
     def test_tcp_flags_gains_the_protocol_it_never_had(self) -> None:
-        """On ``02296b5dd`` none of these exist on ``Flags`` at all -- its own
-        hand-copied ``get`` was the only member of the protocol it carried,
-        and it had no ``get_all``, ``register``, ``register_alias``,
+        """Without the conversion none of these exist on ``Flags`` -- its own
+        hand-copied ``get`` is the only member of the protocol it carries,
+        with no ``get_all``, ``register``, ``register_alias``,
         ``register_aliases`` or ``_unregistered_member`` -- so this raises
-        :exc:`AttributeError` there and only passes once the conversion lands.
+        :exc:`AttributeError`.
         """
         from pcapkit.const.tcp.flags import Flags
 
@@ -356,9 +356,9 @@ def test_string_miss_without_default_raises_and_does_not_mint(self) -> None:
         self.assertEqual(before, len(BindingUpdateFlag.__members__))
 
     def test_string_miss_with_default_falls_back_by_value(self) -> None:
-        """The normalisation half of this batch: the hand-copied ``get()`` ended
-        in a bare ``return NAME[key]``, so ``default`` silently applied to
-        integer keys only."""
+        """The normalisation half of the conversion: guards against a
+        hand-copied ``get()`` ending in a bare ``return NAME[key]``, under
+        which ``default`` silently applies to integer keys only."""
         from pcapkit.const.ipv6.extension_header import ExtensionHeader
 
         target = list(ExtensionHeader)[0]
@@ -490,7 +490,7 @@ def test_register_over_a_taken_name_raises_value_error(self) -> None:
         self.assertEqual(before, len(HandoverACKFlag.__members__))
 
     def test_register_over_a_taken_value_raises_value_error_and_does_not_alias(self) -> None:
-        """The guard this batch adds: :func:`~aenum.extend_enum` does not mint
+        """The guard ``register`` carries: :func:`~aenum.extend_enum` does not mint
         anything for a value that already has a member -- :mod:`aenum` treats
         that as a request to *alias* the existing member under the caller's
         name instead, silently. Without a guard, ``register(existing_value,
@@ -546,19 +546,18 @@ def test_register_over_a_taken_value_on_a_flag_registry_also_refuses(self) -> No
 
     def test_register_alias_still_aliases_after_the_value_guard(self) -> None:
         """:meth:`register_alias` depends on :meth:`register` accepting an
-        already-registered value -- that dependency moved to the shared,
-        ungated :meth:`~pcapkit.corekit.enum.EnumRegistry._extend` when this
-        guard was added, so this pins that the move did not also gate the
-        path :meth:`register_alias` needs. A naive guard placed directly in
+        already-registered value -- a dependency carried by the shared,
+        ungated :meth:`~pcapkit.corekit.enum.EnumRegistry._extend`, so this
+        pins that the value guard does not also gate the path
+        :meth:`register_alias` needs. A naive guard placed directly in
         the body :meth:`register` calls would make every alias registration
         raise the exact error this test's sibling above checks for, rather
         than aliasing. Deliberately on ``ExtensionHeader`` rather than
-        ``Flags``: this registry already inherited
-        :class:`~pcapkit.corekit.enum.EnumRegistry` before this change, so
-        this is a regression pin on the internal refactor and holds on both
-        the prior head and this one -- unlike this class's ``Flags``-based
-        siblings above, which pin the guard itself and so only hold once
-        ``tcp/flags`` has joined :data:`CONVERTED` too."""
+        ``Flags``: this registry inherits
+        :class:`~pcapkit.corekit.enum.EnumRegistry` independently of
+        ``tcp/flags``'s conversion, so this pins the internal refactor alone
+        -- unlike this class's ``Flags``-based siblings above, which pin the
+        guard itself and so also need ``tcp/flags`` in :data:`CONVERTED`."""
         from pcapkit.const.ipv6.extension_header import ExtensionHeader
 
         target = list(ExtensionHeader)[0]
@@ -700,18 +699,17 @@ class _Str(EnumRegistry, StrEnum):
 #: their crawler's own ``process()``/``context()`` with a bespoke ``get()``/
 #: ``_missing_`` pair that does not share :mod:`pcapkit.vendor.default`'s
 #: template at all -- mixing :class:`~pcapkit.corekit.enum.EnumRegistry` in
-#: without further care would still have silently changed behaviour rather
-#: than just moved it, since four of the six are :class:`~aenum.StrEnum`
-#: registries whose own ``__new__`` attaches further attributes the base's
-#: generic ``_unregistered_member`` does not set. GitHub issue #860 fixed
-#: the base ``get()``'s own str-key-never-tries-the-value-path limitation
-#: this comment used to cite -- measured on a synthetic registry in
-#: :class:`StrEnumValueFallbackTests` below -- and issue #860's step 2 has
-#: since actually converted all six (``FEATCode``, ``Command``, ``Method``,
+#: without further care would silently change behaviour rather than just
+#: move it, since four of the six are :class:`~aenum.StrEnum` registries whose
+#: own ``__new__`` attaches further attributes the base's generic
+#: ``_unregistered_member`` does not set. GitHub issue #860 fixes the base
+#: ``get()``'s own str-key-never-tries-the-value-path limitation -- measured
+#: on a synthetic registry in :class:`StrEnumValueFallbackTests` below -- and
+#: issue #860's step 2 converts all six (``FEATCode``, ``Command``, ``Method``,
 #: ``ReturnCode``/``ResponseKind``/``GroupingInformation``, ``StatusCode``
 #: and ``OptionType`` in PR 1; ``AppType`` and its four transport subclasses
 #: in PR 2), each with its own ``_unregistered_member`` override where a
-#: custom ``__new__`` needed one. They stay excluded from *this* file's
+#: custom ``__new__`` needs one. They stay excluded from *this* file's
 #: tier-3 sweep regardless, because the exclusion here is about their
 #: bespoke ``process()``/``get()`` shape not sharing the generated template,
 #: which conversion onto the base does not change -- unlike the
@@ -733,10 +731,8 @@ class _Str(EnumRegistry, StrEnum):
 #:
 #: The name below is deliberately about what the set *does*, not why: it is
 #: everything this file's ``IntEnum``-only census (:data:`GENERATED_SAMPLE`
-#: and the ``generated`` list below) leaves out, historical and anchored at
-#: commit ``05468a06b`` like the counts in
-#: ``test_every_generated_const_module_is_accounted_for`` below -- not a
-#: claim that every entry shares one reason. At least three apply, and the
+#: and the ``generated`` list below) leaves out -- not a claim that every
+#: entry shares one reason. At least three apply, and the
 #: grouping below tags each entry with its own: (a) is a
 #: :class:`~aenum.StrEnum` registry, so would miss this file's
 #: ``class \w+(EnumRegistry, IntEnum):`` regex regardless of anything else;
@@ -810,7 +806,7 @@ def test_generated_sample_declares_the_base(self) -> None:
     def test_generated_sample_carries_no_copy_of_the_protocol(self) -> None:
         """A ``def get``/``def register``/``def _unregistered_member`` left
         behind would silently shadow the base -- the exact two-contract bug
-        this tier exists to remove. ``_missing_`` must survive, since it
+        #775's tier 3 removes. ``_missing_`` must survive, since it
         carries each registry's own bounded ranges and was never meant to
         move."""
         for _, name, relpath in GENERATED_SAMPLE:
@@ -822,33 +818,23 @@ def test_generated_sample_carries_no_copy_of_the_protocol(self) -> None:
                 self.assertIn("def _missing_(cls, value: 'int')", source)
 
     def test_every_generated_const_module_is_accounted_for(self) -> None:
-        """The full census, measured on this batch rather than assumed: 124
-        modules under :mod:`pcapkit.const`, splitting exactly three ways --
-        the 6 :data:`CONVERTED` bespoke ones tier 2 already handled, the 11
-        :data:`EXCLUDED_FROM_INTENUM_CENSUS` deliberately left alone, and the
-        remaining 107 this tier converts. Measured by me on the prior head
-        (commit ``05468a06b``, this batch's own base): of those 121, 6 carried
-        :class:`~pcapkit.corekit.enum.EnumRegistry` and 111 carried the
-        literal "Backport support for original codes." docstring (including
-        the 6 bespoke StrEnum/AppType files, since a hand-copied docstring is
-        not proof of a shared template) -- 105 is what is left once the 6
-        converted and the 10 excluded are both taken out.
-
-        121 became 122 with GitHub issue #886's
-        ``pcapkit/const/pcapng/tls_key_label.py``, and the 10 excluded became
-        11 to hold it -- see the comment directly above
-        :data:`EXCLUDED_FROM_INTENUM_CENSUS` for why it lands there rather
-        than among the 105. 105 itself does not move there: the new file is
-        absorbed by the excluded side of the split, not the generated side.
-
-        122 became 124 with GitHub issue #880's
+        """The full census, measured rather than assumed: the modules under
+        :mod:`pcapkit.const` split exactly three ways -- the
+        :data:`CONVERTED` bespoke ones tier 2 handled, the
+        :data:`EXCLUDED_FROM_INTENUM_CENSUS` ones deliberately left alone, and
+        the rest, which must all be the generated shape. A literal "Backport
+        support for original codes." docstring is not proof of a shared
+        template: it is hand-copied into the bespoke StrEnum/AppType files
+        too.
+
+        GitHub issue #886's ``pcapkit/const/pcapng/tls_key_label.py`` is on
+        the excluded side -- see the comment directly above
+        :data:`EXCLUDED_FROM_INTENUM_CENSUS` for why. GitHub issue #880's
         ``pcapkit/const/ngap/procedure_code.py`` and
-        ``pcapkit/const/ngap/protocol_ie.py``. Unlike #886's file, both are
-        the generated shape outright -- plain ``EnumRegistry`` + ``IntEnum``,
-        no bespoke ``get()``/``_missing_``-carrying ``__new__`` -- so neither
-        joins :data:`EXCLUDED_FROM_INTENUM_CENSUS`; they land on the
-        *generated* side instead. 6 and 11 hold; 105 becomes 107, and 122
-        becomes 124.
+        ``pcapkit/const/ngap/protocol_ie.py`` are the generated shape
+        outright -- plain ``EnumRegistry`` + ``IntEnum``, no bespoke
+        ``get()``/``_missing_``-carrying ``__new__`` -- so they are on the
+        *generated* side.
         """
         const_root = REPO_ROOT / 'pcapkit' / 'const'
         all_files = sorted(
@@ -909,16 +895,16 @@ def test_member_type_stays_int_not_enumregistry(self) -> None:
         ``class {NAME}(EnumRegistry, IntEnum)`` with the non-``Enum`` mixin
         first is what keeps :mod:`aenum` resolving ``_member_type_`` from
         ``IntEnum`` rather than from the mix-in -- verified rather than
-        assumed, per this tier's own instructions."""
+        assumed."""
         for registry in self.registries:
             with self.subTest(registry=registry.__qualname__):
                 self.assertIs(registry._member_type_, int)
 
 
 class GeneratedMissingRangeParityTests(unittest.TestCase):
-    """``_missing_``'s own bounded ranges must behave identically after the
-    conversion -- it was deliberately left untouched, so this is a
-    regression pin on that claim rather than a test of new behaviour."""
+    """``_missing_``'s own bounded ranges are deliberately outside the
+    conversion onto the base, so this is a regression pin on that claim
+    rather than a test of new behaviour."""
 
     def setUp(self) -> None:
         reimport_once_per_class(self, restore=True)
@@ -926,13 +912,13 @@ def setUp(self) -> None:
     def test_hardware_still_bounds_and_resolves_its_unassigned_ranges(self) -> None:
         """:class:`~pcapkit.const.arp.hardware.Hardware` declares ``0..38``
         and ``39..255``/``258..65534`` as unassigned-but-in-range, ``65535``
-        as its own reserved member, and rejects anything else -- unchanged by
-        this tier, which only removed the duplicate ``get``/``register``/
-        ``_unregistered_member`` sitting next to it."""
+        as its own reserved member, and rejects anything else -- the
+        conversion concerns only the duplicate ``get``/``register``/
+        ``_unregistered_member`` a generated module could carry next to it."""
         from pcapkit.const.arp.hardware import Hardware
 
         # In range, unassigned: resolves without minting a permanent member
-        # (tier 1's fix), reachable via the now-inherited get() too.
+        # (tier 1's fix), reachable via the inherited get() too.
         for value in (39, 255, 258, 65534):
             with self.subTest(value=value):
                 self.assertEqual(Hardware(value).value, value)
@@ -950,14 +936,12 @@ def test_hardware_still_bounds_and_resolves_its_unassigned_ranges(self) -> None:
         self.assertIs(Hardware.get(65536, 1), Hardware.Ethernet)
 
     def test_transtype_no_longer_mints_its_declared_unassigned_range(self) -> None:
-        """:class:`~pcapkit.const.reg.transtype.TransType` used to be the
-        other shape: its own ``_missing_`` minted permanently via
-        :func:`~aenum.extend_enum` for ``148..252`` rather than going through
-        ``_unregistered_member``. The #775/#847 mint-criterion
-        ruling converted it: the label is a bare ``Unassigned``, which is a
-        notation for the reader rather than a name IANA assigned, so it now
-        matches :class:`~pcapkit.const.arp.hardware.Hardware`'s shape above
-        instead of standing apart from it."""
+        """:class:`~pcapkit.const.reg.transtype.TransType`'s own
+        ``_missing_`` goes through ``_unregistered_member`` for ``148..252``,
+        not a permanent :func:`~aenum.extend_enum` mint: per the #775/#847
+        mint-criterion ruling, the label is a bare ``Unassigned``, which is a
+        notation for the reader rather than a name IANA assigned, so it
+        matches :class:`~pcapkit.const.arp.hardware.Hardware`'s shape above."""
         from pcapkit.const.reg.transtype import TransType
 
         before = len(TransType._member_names_)
@@ -974,26 +958,17 @@ def test_transtype_no_longer_mints_its_declared_unassigned_range(self) -> None:
 
 
 class RegisterAlreadyRegisteredNowRaisesOnAGeneratedRegistryTests(unittest.TestCase):
-    """The residue #855 disclosed and this tier's own instructions name:
-    ``register()`` on an already-registered value used to silently alias
-    rather than mint or raise, on every one of the generated registries
-    (they had no guard of their own -- only the six bespoke ones tier 2
-    already fixed did). Measured directly, before and after, in the
-    docstring below rather than only asserted.
+    """The residue #855 disclosed: the duplicate-value guard keeps
+    ``register()`` on an already-registered value from silently aliasing
+    on a generated registry. Without it, ``TransType.register(6,
+    'TOTALLY_NEW_NAME')`` returns the *existing* ``TransType.TCP``, makes
+    ``'TOTALLY_NEW_NAME'`` reachable in ``__members__`` pointing at it, and
+    neither mints nor raises. With it, the call raises::
 
-    Before (commit ``05468a06b``, this batch's own base)::
-
-        >>> TransType.register(6, 'TOTALLY_NEW_NAME')
-        <TransType.TCP: 6>              # returned the *existing* member
-        # 'TOTALLY_NEW_NAME' in TransType.__members__ == True
-        # _member_names_ grew by 0 -- nothing minted, nothing raised
-
-    After (this commit)::
-
-        >>> TransType.register(6, 'TOTALLY_NEW_NAME')
         ValueError: 6 is already registered on TransType as 'TCP'; use
         TransType.register_alias() to add a further name for it
-        # 'TOTALLY_NEW_NAME' in TransType.__members__ == False
+
+    and ``'TOTALLY_NEW_NAME'`` never enters ``__members__``.
 
     """
 
@@ -1030,21 +1005,21 @@ def test_register_still_mints_for_a_genuinely_new_value(self) -> None:
 
 
 class GetDispatchMatrixTests(unittest.TestCase):
-    """The dispatch flip this tier's own instructions name: the generated
-    ``get()`` checked ``isinstance(key, int)`` first and treated anything
-    else as a name; the inherited base checks ``isinstance(key, str)`` first
-    and treats anything else as a value. For a key that actually is an ``int``
+    """The dispatch order: a generated ``get()`` checking
+    ``isinstance(key, int)`` first treats anything else as a name; the
+    inherited base checks ``isinstance(key, str)`` first and treats
+    anything else as a value. For a key that actually is an ``int``
     or a ``str``, both orderings agree, so every probe below except the
     "neither" one is a parity pin rather than a change; the "neither" probe
-    is the one documented, deliberate difference, measured before and after
-    on ``TransType`` (a plain generated ``IntEnum`` registry):
+    is the one documented, deliberate difference, shown on ``TransType``
+    (a plain generated ``IntEnum`` registry):
 
-    Before (commit ``05468a06b``)::
+    An int-first ``get()``::
 
         >>> TransType.get(3.5)
         KeyError: 3.5          # not int -> treated as a name -> dict miss
 
-    After (this commit)::
+    The inherited base::
 
         >>> TransType.get(3.5)
         ValueError: 3.5 is not a valid TransType   # not str -> treated as a
@@ -1082,7 +1057,7 @@ def test_missing_name_with_default_falls_back(self) -> None:
     def test_missing_int_without_default_raises_value_error(self) -> None:
         """``9999`` is outside TransType's declared ``0..255`` domain
         entirely, so this is a genuine miss rather than an unassigned-but
-        in-range value that ``_missing_`` would otherwise mint."""
+        in-range value that ``_missing_`` would otherwise resolve."""
         from pcapkit.const.reg.transtype import TransType
 
         with self.assertRaises(ValueError):
@@ -1094,13 +1069,12 @@ def test_missing_int_with_default_falls_back(self) -> None:
         self.assertIs(TransType.get(9999, 6), TransType.TCP)
 
     def test_a_key_that_is_neither_int_nor_str_flips_exception_type(self) -> None:
-        """The one deliberate, documented behaviour change this tier makes,
-        pinned to the *new* (post-migration) shape: a key that is neither
-        ``int`` nor ``str`` now raises :exc:`ValueError` (treated as a value,
-        rejected by ``_missing_``'s own ``isinstance(value, int)`` guard)
-        rather than the old :exc:`KeyError` (treated as a name, rejected by
-        a plain dict lookup) -- measured before/after in this class's own
-        docstring above."""
+        """The one deliberate, documented behaviour difference of the base's
+        dispatch order: a key that is neither ``int`` nor ``str`` raises
+        :exc:`ValueError` (treated as a value, rejected by ``_missing_``'s own
+        ``isinstance(value, int)`` guard) rather than :exc:`KeyError`
+        (treated as a name, rejected by a plain dict lookup) -- measured in
+        this class's own docstring above."""
         from pcapkit.const.reg.transtype import TransType
 
         for key in (3.5, None, b'x'):
@@ -1168,65 +1142,57 @@ def test_a_key_that_is_neither_int_nor_str_raises_value_error(self) -> None:
 
 
 class StrEnumValueFallbackTests(unittest.TestCase):
-    """GitHub issue #860, step 1: the base ``get()``'s ``isinstance(key, str)``
-    branch used to try only ``cls._member_map_[key]`` -- a *name* lookup --
-    and never fall back to treating a ``str`` key as a *value*, unlike the
-    integer path. That was pre-existing behaviour of
-    :class:`~pcapkit.corekit.enum.EnumRegistry` itself (added by tier 1,
-    #855, which never converted a :class:`~aenum.StrEnum` registry either),
-    found during #858's review on a synthetic registry rather than a real
-    one, since at the time none of the four bespoke ``StrEnum`` const
-    registries mixed in this base yet (:data:`EXCLUDED_FROM_INTENUM_CENSUS`
-    above, which still holds them out of *this* file's tier-3 sweep for a
-    different reason -- they are :class:`~aenum.StrEnum`, not
-    :class:`~aenum.IntEnum`, which is reason (a) there regardless of
-    whether any one of them also overrides the base) --
-    that conversion was #860's separate step 2, landed by PR 1 for three of
-    the four (``FEATCode``, ``Command``, ``Method``) and by PR 2 for the
-    fourth (``AppType``, along with its four transport subclasses, which
-    were not themselves among the original four but inherit the same fix).
-
-    Fixed here by falling back to a plain ``_value2member_map_`` lookup, not
-    ``cls(key)``: at the time this was written, :class:`~pcapkit.const.ftp.
-    command.FEATCode`'s own ``_missing_`` minted directly via
-    :func:`~aenum.extend_enum` for any unrecognised value (that minting call
-    reproduced verbatim in
+    """GitHub issue #860, step 1: guards against the base ``get()``'s
+    ``isinstance(key, str)`` branch trying only ``cls._member_map_[key]`` --
+    a *name* lookup -- and never falling back to treating a ``str`` key as a
+    *value*, unlike the integer path. Found during #858's review on a
+    synthetic registry rather than a real one
+    (:class:`~pcapkit.corekit.enum.EnumRegistry` itself came from tier 1,
+    #855, which converted no :class:`~aenum.StrEnum` registry). The bespoke
+    ``StrEnum`` const registries mix in this base through #860's separate
+    step 2 -- ``FEATCode``, ``Command`` and ``Method`` in PR 1, ``AppType``
+    and its transport subclasses in PR 2 -- and
+    :data:`EXCLUDED_FROM_INTENUM_CENSUS` above holds them out of *this*
+    file's tier-3 sweep for a different reason: they are
+    :class:`~aenum.StrEnum`, not :class:`~aenum.IntEnum`, which is reason
+    (a) there regardless of whether any one of them also overrides the
+    base.
+
+    The fallback is a plain ``_value2member_map_`` lookup, not
+    ``cls(key)``: routing it through the constructor would let a failed
+    *name* lookup mint a permanent member on any registry whose own
+    ``_missing_`` mints directly via :func:`~aenum.extend_enum` for an
+    unrecognised value -- as :class:`~pcapkit.const.ftp.command.FEATCode`'s
+    does without #860's step 2 (that minting call reproduced
+    verbatim in
     :meth:`test_get_never_mints_on_a_registry_whose_missing_mints_directly`
-    below), so routing the value fallback through the constructor would have
-    let a failed *name* lookup mint a permanent member the moment #860's
-    step 2 converted a registry like it onto this base -- exactly the
-    "never mints" defect :meth:`~pcapkit.corekit.enum.EnumRegistry.get`'s
-    own docstring rules out. Step 2 has since landed and converted
-    ``FEATCode`` itself (its ``_missing_`` now calls
-    ``_unregistered_member`` rather than ``extend_enum``, per the owner's
-    #860 ruling), which is why the fixture below is a synthetic local class
-    reproducing the *old* shape rather than importing the real one -- the
-    defect this test guards against is general, not tied to one now-fixed
-    example. A raw dict lookup can never reach ``_missing_``, so it cannot
+    below) -- exactly the "never mints" defect
+    :meth:`~pcapkit.corekit.enum.EnumRegistry.get`'s own docstring rules
+    out. The fixture below is therefore a synthetic local class reproducing
+    that shape rather than an import of a real one: the defect this test
+    guards against is general. A raw dict lookup can never reach ``_missing_``, so it cannot
     mint regardless of what a subclass's own ``_missing_`` does.
     """
 
     def test_a_str_key_that_is_a_value_but_not_a_name_now_resolves(self) -> None:
-        """The defect itself. Fails on ``main`` (raises ``KeyError``, see the
-        module docstring's reproduction), passes here."""
+        """The defect itself: without the fix, this raises ``KeyError``."""
         class _Str(EnumRegistry, StrEnum):
             KNOWN = 'known-value'
 
         # The name resolves, as it always would.
         self.assertIs(_Str.get('KNOWN'), _Str.KNOWN)
 
-        # The *value* -- a different string from the name -- now resolves
-        # too, matching what the constructor already did directly.
+        # The *value* -- a different string from the name -- resolves too,
+        # matching what the constructor does directly.
         self.assertIs(_Str('known-value'), _Str.KNOWN)
         self.assertIs(_Str.get('known-value'), _Str.KNOWN)
 
     def test_name_wins_over_a_different_members_value(self) -> None:
         """Ordering decision: a name match wins over a value match, so a
         string that is *both* a member's name and a different member's
-        value resolves to the name's member. This already held for a name
-        that resolves before this fix (the name branch is untouched), so it
-        passes on both trees -- it is the ordering this fix's fall-through
-        had to preserve, not new behaviour, and is pinned here so the
+        value resolves to the name's member. This holds with or without the
+        fix (the fix leaves the name branch alone) -- it is the ordering the
+        fix's fall-through has to preserve, and is pinned here so the
         ordering stays a decision rather than an accident."""
         class _Str(EnumRegistry, StrEnum):
             ALPHA = 'BETA'
@@ -1236,12 +1202,12 @@ class _Str(EnumRegistry, StrEnum):
         self.assertIsNot(_Str.get('BETA'), _Str.ALPHA)
 
     def test_a_str_value_match_wins_over_a_supplied_default(self) -> None:
-        """A second, compounding half of the same defect: on ``main``, the
-        ``str`` branch's ``except KeyError`` fires for *any* non-name key,
-        so a supplied ``default`` was returned even when the key itself was
-        a perfectly good value -- the default silently overrode a match that
-        should have won. Fails on ``main`` (returns ``_Str('elsewhere')``
-        instead of ``_Str.KNOWN``), passes here."""
+        """A second, compounding half of the same defect: without the fix,
+        the ``str`` branch's ``except KeyError`` fires for *any* non-name key,
+        so a supplied ``default`` is returned even when the key itself is a
+        perfectly good value -- the default silently overrides a match that
+        should win, returning ``_Str('elsewhere')`` instead of
+        ``_Str.KNOWN``."""
         class _Str(EnumRegistry, StrEnum):
             KNOWN = 'known-value'
             ELSEWHERE = 'elsewhere'
@@ -1252,8 +1218,8 @@ def test_missing_value_with_no_match_and_no_default_still_raises_key_error(self)
         """A ``str`` key that resolves neither as a name nor as a value, with
         no default, still raises :exc:`KeyError` -- not :exc:`ValueError` --
         matching :meth:`~pcapkit.corekit.enum.EnumRegistry.get`'s own
-        documented contract for a name miss. Unchanged by this fix: passes
-        on both trees."""
+        documented contract for a name miss. Holds with or without the
+        fix."""
         class _Str(EnumRegistry, StrEnum):
             KNOWN = 'known-value'
 
@@ -1261,26 +1227,23 @@ class _Str(EnumRegistry, StrEnum):
             _Str.get('totally-unknown')
 
     def test_get_never_mints_on_a_registry_whose_missing_mints_directly(self) -> None:
-        """The crux this fix has to get right: the minting half of this
-        fixture's ``_missing_`` was, at the time this test was written,
-        verbatim :meth:`~pcapkit.const.ftp.command.FEATCode._missing_`'s own
-        body -- ``extend_enum(cls, value.upper(), value)`` for any
-        unrecognised string. GitHub issue #860 step 2 has since converted
-        the real ``FEATCode`` onto ``_unregistered_member`` (per the owner's
-        ruling that ``get``/``_missing_`` should not mint there either), so
-        this fixture is kept as a synthetic, self-contained reproduction of
-        the *old* shape rather than updated to import the real class --
-        the point of this test is the general defect class, which a fixed
-        example can no longer demonstrate. Its non-``str`` branch differs
-        from that old shape (delegates to ``super()._missing_`` rather than
-        ``FEATCode``'s own explicit ``ValueError``), which is immaterial to
-        what this test proves. A naive ``return cls(key)`` fallback would
-        mint a permanent member from a mere failed lookup; the
-        ``_value2member_map_`` lookup this fix uses instead never reaches
-        ``_missing_`` at all, so it cannot. Passes on both trees -- ``main``
-        never attempts the value path in the first place, so it cannot mint
-        either; this pins that the fix does not regress that guarantee while
-        closing the gap."""
+        """The crux the fix has to get right: the minting half of this
+        fixture's ``_missing_`` is verbatim
+        :meth:`~pcapkit.const.ftp.command.FEATCode._missing_`'s body without
+        GitHub issue #860 step 2's conversion onto ``_unregistered_member``
+        -- ``extend_enum(cls, value.upper(), value)`` for any unrecognised
+        string. The fixture is a synthetic, self-contained reproduction of
+        that shape rather than an import of the real class, since the point
+        of this test is the general defect class, which a converted example
+        cannot demonstrate. Its non-``str`` branch differs from that shape
+        (delegates to ``super()._missing_`` rather than ``FEATCode``'s own
+        explicit ``ValueError``), which is immaterial to what this test proves.
+        A naive ``return cls(key)`` fallback would mint a permanent member from
+        a mere failed lookup; the ``_value2member_map_`` lookup the fix uses
+        instead never reaches ``_missing_`` at all, so it cannot. Holds with or
+        without the fix -- without it, ``get`` never attempts the value path,
+        so it cannot mint either; this pins that the fix keeps that guarantee
+        while closing the gap."""
         class _MintingStr(EnumRegistry, StrEnum):
             KNOWN = 'known-value'
 
@@ -1301,23 +1264,23 @@ def _missing_(cls, value: 'Any') -> 'Any':
 
 
 class NoDefaultSentinelTests(unittest.TestCase):
-    """GitHub issue #857: :data:`~pcapkit.corekit.sentinels.NO_DEFAULT` is now an
+    """GitHub issue #857: :data:`~pcapkit.corekit.sentinels.NO_DEFAULT` is an
     instance of the dedicated :class:`~pcapkit.corekit.sentinels.NoDefaultType`
     compared with ``is``, rather than the magic value ``-1`` compared with
-    ``==``. Owner ruling on #859: a bare :class:`object` -- this batch's first
-    attempt -- is no less safe under ``is``, but a dedicated class matches the
+    ``==``. Owner ruling on #859: a bare :class:`object` is no less safe
+    under ``is``, but a dedicated class matches the
     house convention :class:`~pcapkit.corekit.sentinels.NullType` and
     :class:`~pcapkit.corekit.sentinels.NoValueType` already set, and gives
     a readable :func:`repr` in a signature, in :func:`help`, and in a
     traceback.
 
-    Before #857, ``default == NO_DEFAULT`` read a caller-supplied ``-1`` --
-    or, worse, ``-1.0``, since ``-1.0 == -1`` -- as if no default had been
-    supplied at all, so the caller's own fallback silently never took effect.
-    There is no live defect in :mod:`pcapkit.const` (no registry's
-    domain reaches ``-1``), so this batch pins the *clarity* fix: ``-1`` and
-    ``-1.0`` are ordinary defaults now, indistinguishable from any other
-    value a caller might pass.
+    Guards against ``default == NO_DEFAULT`` with a ``-1`` sentinel, which
+    reads a caller-supplied ``-1`` -- or, worse, ``-1.0``, since ``-1.0 ==
+    -1`` -- as if no default had been supplied at all, so the caller's own
+    fallback silently never takes effect. There is no live defect in
+    :mod:`pcapkit.const` (no registry's domain reaches ``-1``), so this pins
+    the *clarity* fix: ``-1`` and ``-1.0`` are ordinary defaults,
+    indistinguishable from any other value a caller might pass.
     """
 
     def setUp(self) -> None:
@@ -1328,8 +1291,8 @@ def test_no_default_is_not_equal_to_any_plausible_caller_value(self) -> None:
         :class:`~pcapkit.corekit.sentinels.NoDefaultType` instance -- which defines
         no ``__eq__`` of its own, so it inherits identity comparison from
         :class:`object` -- cannot compare equal to anything a caller might
-        legitimately pass as ``default``, not even ``-1.0``, which the old
-        ``-1`` marker could not tell apart from itself."""
+        legitimately pass as ``default``, not even ``-1.0``, which a ``-1``
+        marker cannot tell apart from itself."""
         from pcapkit.corekit.sentinels import NO_DEFAULT
 
         for value in (-1, -1.0, 0, '', None, False):
@@ -1349,23 +1312,21 @@ def test_repr_is_the_readable_form_not_a_bare_object_address(self) -> None:
         self.assertNotIn('0x', rendered)
 
     def test_type_is_the_dedicated_sentinel_class_and_only_the_object_is_exported(self) -> None:
-        """GitHub issue #911 reversed half of what this used to assert.
-
-        It read ``assertIn('NoDefaultType', enum_module.__all__)`` -- the type
-        *and* the object were exported. GitHub issue #719 is where the owner
-        settled the rule behind this: a module's ``__all__`` lists a
-        sentinel's object (such as ``NO_DEFAULT``), and deliberately leaves
-        its type (such as ``NoDefaultType``) out, because the type is not
-        part of the public surface -- exposing only the final object is what
-        keeps the published API to what a caller actually uses. GitHub issue
-        #911 is the issue that ruling's implementing work belongs to. The
-        type is out of :attr:`__all__` while staying importable by its
-        dotted path, which is what the last assertion here pins.
-
-        GitHub issue #1744 then dropped the re-export from
-        :mod:`pcapkit.corekit.enum` (#1715: a moved name keeps no re-export at
-        its old path), so the export rule is now asserted against
-        :mod:`pcapkit.corekit.sentinels`, the only import path.
+        """Only the sentinel's object is exported, not its type (GitHub issue #911).
+
+        GitHub issue #719 is where the owner settled the rule behind this: a
+        module's ``__all__`` lists a sentinel's object (such as
+        ``NO_DEFAULT``), and deliberately leaves its type (such as
+        ``NoDefaultType``) out, because the type is not part of the public
+        surface -- exposing only the final object is what keeps the published
+        API to what a caller actually uses. GitHub issue #911 implements that
+        ruling. The type is out of :attr:`__all__` while staying importable by
+        its dotted path.
+
+        :mod:`pcapkit.corekit.enum` re-exports neither (GitHub issue #1744;
+        #1715: a moved name keeps no re-export at its old path), so the export
+        rule is asserted against :mod:`pcapkit.corekit.sentinels`, the only
+        import path.
         """
         import pcapkit.corekit.enum as enum_module
         import pcapkit.corekit.sentinels as sentinels
@@ -1413,9 +1374,9 @@ def test_missing_name_with_default_negative_one_is_now_a_real_default(self) -> N
         A throwaway registry holding ``-1`` is what discriminates #857. No
         shipped registry's domain reaches ``-1``, so on one of those the name
         lookup's :exc:`KeyError` propagates whether ``-1`` is read as a default
-        or as the old marker. Here it resolves to that member, while the
-        pre-#857 ``default == -1`` check read the caller's ``-1`` (and ``-1.0``,
-        which compares equal) as *no default* and raised.
+        or as a ``-1`` marker. Here it resolves to that member, while a
+        ``default == -1`` check (GitHub issue #857) reads the caller's ``-1``
+        (and ``-1.0``, which compares equal) as *no default* and raises.
         """
         from aenum import IntEnum
 
@@ -1455,9 +1416,8 @@ def test_negative_one_defaults_on_a_shipped_registry_raise_and_mint_nothing(self
                 self.assertEqual(before, len(ExtensionHeader.__members__))
 
     def test_missing_name_without_default_still_raises_on_an_int_enum(self) -> None:
-        """Omitting ``default`` entirely is unaffected by this change -- it
-        was, and remains, ``NO_DEFAULT`` by the parameter's own default
-        value, so identity trivially holds either way."""
+        """Omitting ``default`` entirely leaves it ``NO_DEFAULT`` by the
+        parameter's own default value, so identity trivially holds."""
         from pcapkit.const.ipv6.extension_header import ExtensionHeader
 
         before = len(ExtensionHeader.__members__)
@@ -1480,20 +1440,20 @@ def test_missing_name_without_default_still_raises_on_an_int_flag(self) -> None:
 
 
 class GetDefaultNoMintTests(unittest.TestCase):
-    """GitHub issue #864. Both ``cls(default)`` sites -- the ``str`` branch's
-    and the value branch's -- reached ``_missing_`` for a ``default`` that
-    fell inside a still-minting registry's own range, growing the registry
-    as a side effect of resolving ``default`` rather than ``key``. The
+    """GitHub issue #864. Guards against ``cls(default)`` -- in the ``str``
+    branch or the value branch -- reaching ``_missing_`` for a ``default``
+    inside a minting registry's own range, growing the registry as a side
+    effect of resolving ``default`` rather than ``key``. The
     owner ruled on #864 that only ``register`` may mint: ``get`` mints only
     as the natural outcome of ``key`` falling through one of ``_missing_``'s
     minted ranges, never because a fallback happened to resolve. Of the
     three mechanisms offered, the owner chose the one that cannot mint by
-    construction -- ``default`` now resolves through a plain
+    construction -- ``default`` resolves through a plain
     ``_value2member_map_`` lookup only, with no snapshot-and-undo and no
     per-class marker to keep in step with future crawlers -- at the price of a
-    ``default`` in a declared-but-unassigned range no longer resolving.
-    ``key`` resolution -- and whatever it lets ``_missing_`` do -- is
-    deliberately unchanged.
+    ``default`` in a declared-but-unassigned range not resolving. ``key``
+    resolution -- and whatever it lets ``_missing_`` do -- is deliberately
+    left alone.
     """
 
     def setUp(self) -> None:
@@ -1501,7 +1461,7 @@ def setUp(self) -> None:
 
     def test_the_issues_own_case_no_longer_mints_and_raises_instead(self) -> None:
         """The exact reproduction from #864, on the real shipped registry.
-        Measured live on ``main`` before this fix::
+        Measured live without #864's fix::
 
             >>> len(EtherType.__members__)
             160
@@ -1512,12 +1472,12 @@ def test_the_issues_own_case_no_longer_mints_and_raises_instead(self) -> None:
 
         ``0x1234`` (4660) falls in no ``_missing_`` range, so the lookup
         falls to ``default``; ``0x0888`` (2184) falls inside the ``Xyplex``
-        range #775's *original* ruling deliberately kept minting at the
-        time -- but only when reached as a ``key``. (#775's final round has
-        since converted that range too; see
+        range #775's *original* ruling deliberately kept minting -- but only
+        when reached as a ``key``. (#775's final round converts that range
+        too; see
         :meth:`GetDefaultNoMintTests.test_key_path_minting_is_preserved`.)
-        Fails on the pre-#864 tree for that reason; passes here because
-        ``default`` no longer reaches ``cls(default)`` at all, so ``0x0888``
+        Without #864's fix this mints for that reason; with it, ``default``
+        does not reach ``cls(default)`` at all, so ``0x0888``
         not being an *already-registered* value propagates the ``0x1234``
         lookup's own failure instead of minting anything."""
         from pcapkit.const.reg.ethertype import EtherType
@@ -1535,20 +1495,17 @@ def test_the_issues_own_case_no_longer_mints_and_raises_instead(self) -> None:
         self.assertNotIn('Xyplex_0x0888', EtherType.__members__)
 
     def test_key_path_minting_is_preserved(self) -> None:
-        """Originally a no-change guard: ``EtherType.get(0x0888)`` -- no
-        ``default`` at all -- used to mint ``Xyplex_0x0888`` through its own
-        ``_missing_``, back when #775's original mint/unmint criterion still
-        classed ``Xyplex`` as a kept-minting, real-attributed-name range --
-        the one kind of mint #864 ruled ``get`` may still produce, by falling
-        through ``_missing_``'s minted ranges. GitHub issue #775's final round converts
-        that range (and every other one still minting on ``EtherType``/
-        :class:`~pcapkit.const.ipx.socket.Socket`) to :meth:`~pcapkit.corekit.
-        enum.EnumRegistry._unregistered_member`, preserving the hex-suffixed
-        name unchanged -- so ``key`` resolution through ``get()`` now goes
-        through the same non-minting path ``_missing_`` always did for this
-        value, and the guard flips to prove that rather than the opposite.
+        """``EtherType.get(0x0888)`` -- no ``default`` at all -- falls through
+        ``_missing_``, the one path by which #864 ruled ``get`` may mint.
+        #775's original mint/unmint criterion classed ``Xyplex`` as a
+        kept-minting, real-attributed-name range; GitHub issue #775's final
+        round converts that range (and every other one minting on
+        ``EtherType``/:class:`~pcapkit.const.ipx.socket.Socket`) to
+        :meth:`~pcapkit.corekit.enum.EnumRegistry._unregistered_member`,
+        preserving the hex-suffixed name unchanged -- so ``key`` resolution
+        through ``get()`` takes the same non-minting path, which this pins.
         #864's own point -- that ``default`` never reaches ``_missing_`` at
-        all -- is unaffected either way."""
+        all -- holds either way."""
         from pcapkit.const.reg.ethertype import EtherType
 
         before = len(EtherType.__members__)
@@ -1569,8 +1526,7 @@ def test_key_path_minting_is_preserved(self) -> None:
 
     def test_default_still_resolves_when_registered_int(self) -> None:
         """The ruling's other half: a ``default`` that *is* already a member
-        still resolves, on an ``int``-valued (and, here, still-minting)
-        registry -- #864 restricts ``default`` to
+        resolves, on an ``int``-valued registry -- #864 restricts ``default`` to
         ``_value2member_map_``, it does not disable it."""
         from pcapkit.const.reg.ethertype import EtherType
 
@@ -1583,13 +1539,13 @@ def test_default_still_resolves_when_registered_int(self) -> None:
         self.assertEqual(before, len(EtherType.__members__))
 
     def test_default_still_resolves_when_registered_str(self) -> None:
-        """As above, on a ``str``-valued registry. Not a hypothetical shape
-        any more: ten shipped :class:`~aenum.StrEnum` registries mix in the
-        base now (``Command``, ``FEATCode``, ``Method``, ``OptionType``,
-        ``TLSKeyLabel``, ``AppType`` and its four transport subclasses --
-        :data:`EXCLUDED_FROM_INTENUM_CENSUS` holds all ten out of *this*
-        file's ``IntEnum``-only sweep, not out of existence). This case
-        still builds its own rather than importing one of them, so the
+        """As above, on a ``str``-valued registry. A shipped shape: shipped
+        :class:`~aenum.StrEnum` registries mix in the base (``Command``,
+        ``FEATCode``, ``Method``, ``OptionType``, ``TLSKeyLabel``,
+        ``AppType`` and its transport subclasses --
+        :data:`EXCLUDED_FROM_INTENUM_CENSUS` holds them out of *this* file's
+        ``IntEnum``-only sweep, not out of existence). This case builds its
+        own rather than importing one of them, so the
         assertion stays pinned to the base's fallback behaviour itself
         rather than to a shipped registry's incidental member values."""
         class _Str(EnumRegistry, StrEnum):
@@ -1603,9 +1559,9 @@ class _Str(EnumRegistry, StrEnum):
 
     def test_default_naming_no_registered_member_raises_the_original_error(self) -> None:
         """Ruling one's accepted cost, made concrete: a ``default`` inside a
-        declared-but-unassigned range used to resolve via ``cls(default)`` ->
-        ``_missing_``; now it simply does not resolve, on either branch, and
-        the *original* lookup error -- the one ``key`` itself would have
+        declared-but-unassigned range does not resolve -- on either branch,
+        since nothing routes it through ``cls(default)`` -> ``_missing_`` --
+        and the *original* lookup error -- the one ``key`` itself would have
         raised -- propagates rather than a new error about ``default``."""
         from pcapkit.const.reg.ethertype import EtherType
 
diff --git a/tests/const/test_const_str_payload_870_unit.py b/tests/const/test_const_str_payload_870_unit.py
index e34293cb13..f844c33f4d 100644
--- a/tests/const/test_const_str_payload_870_unit.py
+++ b/tests/const/test_const_str_payload_870_unit.py
@@ -8,10 +8,10 @@
 == 'GET'``), but the :class:`str` the member itself *is* was not:
 ``str(Method.GET) == ''``, ``len(str(Method.GET)) == 0`` and, most visibly,
 ``Method.GET == 'GET'`` was :data:`False` for every one of the 40 declared
-members. True on ``main`` at ``60b85e3a4`` (measured), and true since the class
-was first written -- GitHub pull request #869 fixed the same inconsistency for an
-*unregistered* member's own str payload
-(:meth:`~pcapkit.const.http.method.Method._unregistered_member` now calls the
+members, as measured, and true since the class was first written -- GitHub
+pull request #869 fixed the same inconsistency for an *unregistered* member's
+own str payload
+(:meth:`~pcapkit.const.http.method.Method._unregistered_member` calls the
 base's :meth:`~pcapkit.corekit.enum.EnumRegistry._unregistered_member`, which
 does pass the value along), which is what exposed this half: after #869,
 ``str(Method('frob')) == 'frob'`` while ``str(Method.GET) == ''`` -- a
@@ -25,18 +25,18 @@
 :mod:`pcapkit.vendor.http.method` (the generator template that produces it),
 since a fix only in the former is silently reverted by the next crawl.
 
-This is a **behaviour change to all 40 public members**: every equality
+The defect is visible on every public member: without the fix, every equality
 comparison of a :class:`~pcapkit.const.http.method.Method` member against its
-own wire string now succeeds where it used to fail silently (no exception --
-just an unexpected :data:`False`). Nothing under :mod:`pcapkit.protocols`
-compared a member this way before the fix (the one caller of
+own wire string fails silently (no exception -- just an unexpected
+:data:`False`). Nothing under :mod:`pcapkit.protocols` compares a member this
+way (the one caller of
 :meth:`~pcapkit.const.http.method.Method.get`,
 :meth:`pcapkit.protocols.application.httpv1.HTTP._read_start_line`, reached
 through :meth:`~pcapkit.protocols.application.httpv1.HTTP._read_http_header`
 and :meth:`~pcapkit.protocols.application.httpv1.HTTP.make`, only builds a
 member from the wire string, and
 :meth:`~pcapkit.protocols.application.httpv1.HTTP._make_start_line` reads
-``.value``; neither calls ``str()`` or ``==`` on the member itself), so the change is
+``.value``; neither calls ``str()`` or ``==`` on the member itself), so the fix is
 observable only to external callers and to this module's own dunders
 (``__repr__``, which reads ``_value_`` and was already correct).
 
@@ -76,8 +76,8 @@ def setUp(self) -> None:
     def test_the_reported_case(self) -> None:
         """``Method.GET``, byte for byte, as the issue measured it.
 
-        Fails against ``main`` at ``60b85e3a4``: ``str(Method.GET)`` there is
-        ``''`` (``len`` 0) and ``Method.GET == 'GET'`` is :data:`False`.
+        Without the fix, ``str(Method.GET)`` is ``''`` (``len`` 0) and
+        ``Method.GET == 'GET'`` is :data:`False`.
         """
         from pcapkit.const.http.method import Method
 
@@ -102,9 +102,10 @@ def test_every_one_of_the_40_registered_members_carries_its_value_as_str_payload
                 self.assertEqual(len(str(member)), len(member.value))
 
     def test_registered_and_unregistered_members_are_now_consistent(self) -> None:
-        """The inconsistency #870 reported: #869 fixed the unregistered half
-        only, so ``str(Method('frob')) == 'frob'`` while ``str(Method.GET) ==
-        ''`` on ``main`` at ``60b85e3a4``. Both now carry real content."""
+        """The inconsistency #870 reported: with #869's fix to the
+        unregistered half alone, ``str(Method('frob')) == 'frob'`` while
+        ``str(Method.GET) == ''``. With #870's fix to the registered half,
+        both carry real content."""
         from pcapkit.const.http.method import Method
 
         registered = Method.GET