@@ -115,7 +115,7 @@ Explicit Base Declarations
 
 Name the second base **explicitly**, even though it is already in the MRO.
 :class:`~pcapkit.protocols.internet.ipv6_ext.IPv6_Ext` derives
-:class:`~pcapkit.protocols.internet.internet.Internet`, so every one of them
+:class:`~pcapkit.protocols.internet.internet.Internet`, so every extension header
 reaches ``Internet`` transitively and an ``__mro__`` check cannot tell the two groups
 apart. The declaration is the only place the classification exists, which is why
 ``tests/protocols/internet/test_ipv6_ext_unit.py`` pins it against ``__bases__``:
 
@@ -119,8 +119,8 @@ either, and are the one item on this list that is not simply a table entry: the
 high-order 32 bits are never transmitted, so recovering them is stateful, and
 they widen both the ICV coverage and the AEAD associated data.
 
-Some structural notes for anyone starting. Adding an integrity algorithm that is
-not an HMAC needs more than a row --
+Some structural notes matter to anyone starting. Adding an integrity algorithm
+that is not an HMAC needs more than a row --
 :class:`~pcapkit.protocols.internet.esp.IntegritySuite` records the digest as
 the name of a :mod:`hashlib` constructor, which AES-XCBC and AES-CMAC are not.
 And :func:`~pcapkit.protocols.internet.esp.load_cryptography` imports only the
@@ -271,9 +271,11 @@ complaint and yields nothing useful.
 * :class:`~pcapkit.const.reg.ethertype.EtherType` -- the values in
   :attr:`Link.__proto__ <pcapkit.protocols.link.link.Link.__proto__>`: ARP,
   RARP, IPv4, IPv6, IPX and both VLAN tags.
-* :class:`~pcapkit.const.reg.apptype.apptype.AppType`, a registry carrying every
-  IANA service name -- TCP 20 to FTP-DATA and 21 to FTP, port 80 and 8080 to HTTP
-  on both TCP and UDP, and UDP 1701 to L2TP.
+* :class:`~pcapkit.const.reg.apptype.apptype.AppType` -- the ports bound in
+  :attr:`TCP.__proto__ <pcapkit.protocols.transport.tcp.TCP.__proto__>` and
+  :attr:`UDP.__proto__ <pcapkit.protocols.transport.udp.UDP.__proto__>`, out of
+  a registry carrying every IANA service name: TCP 20 to FTP-DATA and 21 to FTP,
+  ports 80 and 8080 to HTTP on both TCP and UDP, and UDP 1701 to L2TP.
 * :class:`~pcapkit.const.sctp.payload_protocol_identifier.PayloadProtocolIdentifier`
   -- the values in :attr:`SCTP.__proto__
   <pcapkit.protocols.transport.sctp.SCTP.__proto__>`: PPIDs 60 and 66, each to
 
@@ -180,12 +180,13 @@ the default branch, and ``tag`` pulled ``main`` before tagging.
   again (``--clobber``). ``conda``'s upload is not gated on ``check_leg``, so a
   leg whose Anaconda upload landed but whose GitHub upload failed still gets
   its asset on a re-run.
-* Where it fails, it differs from the action deliberately. With no release for the tag, the
-  upload fails with ``gh``'s "release not found", where the action made one,
-  with no notes and ``target_commitish`` unset (``src/github.ts:617-628,1026``),
-  which Create a release defaults to "the repository's default branch"; the
-  release is ``github``'s to make, at the run's commit. A file pattern matching
-  nothing exits 1 with ``::error title=Nothing to upload``, where the action,
+* ``gh release upload`` also fails, deliberately, where the action did not.
+  With no release for the tag, the upload fails with ``gh``'s
+  "release not found", where the action made one, with no notes and
+  ``target_commitish`` unset (``src/github.ts:617-628,1026``), which Create a
+  release defaults to "the repository's default branch"; the release is
+  ``github``'s to make, at the run's commit. A file pattern matching nothing
+  exits 1 with ``::error title=Nothing to upload``, where the action,
   ``fail_on_unmatched_files`` unset, only warned (``src/run.ts:15-20``) and
   published the release without that file.
 
@@ -391,23 +392,23 @@ this run, it *skipped*.
 ``cron-vendor.yml``, ``deploy-pages.yml`` and ``cron-conda.yml`` each open
 with ``!cancelled() && needs.unit-tests.result != 'failure'`` so that a
 skipped gate does not cascade-skip them, while an outright failure or a
-genuine run cancellation still does. The publishing jobs here are stricter about
-their *publishing* predecessors -- ``github``, and for ``conda`` also ``tag``:
-``!cancelled() && (needs.<job>.result == 'success' || needs.<job>.result ==
-'skipped')``, not ``!= 'failure'``. The two spellings differ only when a
-predecessor's own result is ``cancelled``, which ``!= 'failure'`` still admits
-and the equality pair does not. Concretely: if ``tag`` is cancelled while the
-run itself is not, ``!= 'failure'`` would let ``conda`` proceed into its
-check that ``conda-<version>+0`` names this run's commit, a tag ``tag`` never
-pushed, trading a clean skip for a failed step; the equality pair skips
-``conda`` outright instead.
-
-``version_check`` is the exception, and deliberately so: each of them requires
-``needs.version_check.result == 'success'`` with no ``|| 'skipped'``. It
-produces the evidence the gates read, so a skipped or cancelled
-``version_check`` leaves them nothing to decide on. ``unit-tests`` is held to
-the same bar for a different reason: it is the release test gate, and it skips
-when nothing is publishable
+genuine run cancellation still does. ``tag``, ``pypi`` and ``conda`` are
+stricter about their *publishing* predecessors -- ``github``, and for
+``conda`` also ``tag``: ``!cancelled() && (needs.<job>.result == 'success' ||
+needs.<job>.result == 'skipped')``, not ``!= 'failure'``. The two spellings
+differ only when a predecessor's own result is ``cancelled``, which
+``!= 'failure'`` still admits and the equality pair does not. Concretely: if
+``tag`` is cancelled while the run itself is not, ``!= 'failure'`` would let
+``conda`` proceed into its check that ``conda-<version>+0`` names this run's
+commit, a tag ``tag`` never pushed, trading a clean skip for a failed step; the
+equality pair skips ``conda`` outright instead.
+
+``version_check`` is the exception, and deliberately so: ``tag``, ``pypi`` and
+``conda`` each require ``needs.version_check.result == 'success'`` with no
+``|| 'skipped'``. It produces the evidence the gates read, so a skipped or
+cancelled ``version_check`` leaves them nothing to decide on. ``unit-tests`` is
+held to the same bar for a different reason: it is the release test gate, and
+it skips when nothing is publishable
 (`#1052 <https://github.com/JarryShaw/PyPCAPKit/issues/1052>`__), so accepting
 ``skipped`` there would publish untested. ``github`` names it in ``needs:`` instead and relies on the implicit
 ``success()``. The gate's own ``if:`` is the union of the publishers'
 
@@ -244,8 +244,8 @@ rather than the event, so its gate can run whichever way the run was raised, onc
 ``workflow_run`` Edges
 ----------------------
 
-Found by grepping every ``on:`` block rather than trusting a hand-maintained
-list:
+These edges come from grepping every ``on:`` block rather than from a
+hand-maintained list:
 
 * ``.github/workflows/cron-vendor.yml:14-16`` -- **Vendor Update** fires on
   completion of **Unit Tests**.
@@ -671,7 +671,7 @@ for the docs-only path -- and checks each result explicitly
 (``unit-tests.yml:1936-1990``). Rulesets match check names literally, with no
 wildcard, so requiring the matrix cells one by one would mean editing the
 ruleset whenever a matrix changes; the aggregate keeps the required list fixed.
-It accepts those legs as ``skipped`` only on a docs-only pull request, where
+It accepts the gating jobs as ``skipped`` only on a docs-only pull request, where
 ``project-tests`` -- every test that reads ``docs/`` or Markdown -- must pass
 instead. The ``Compat`` legs stay required separately because they come from
 ``python-compatibility.yml``, and a job cannot ``needs:`` a job in another
 
@@ -220,23 +220,20 @@ Engine              3.10    3.11    3.12    3.13    3.14
 ``pypcapfile`` [1]_ 0.0133  0.0093      --      --      --
 ``dpkt``             0.0163  0.0113  0.0118  0.0117  0.0125
 ``pypcap`` [2]_      0.0289  0.0212      --      --      --
-``pcap_ct`` [3]_     0.0364  0.0320  0.0366  0.0322  0.0396
+``pcap_ct``          0.0364  0.0320  0.0366  0.0322  0.0396
 ``scapy``            0.1082  0.0822  0.0877  0.0832  0.0967
 ``pcapkit``          0.2342  0.1906  0.1985  0.1920  0.2392
-``pyshark`` [4]_    18.8158 18.7852 19.2694 20.3751      --
+``pyshark`` [3]_    18.8158 18.7852 19.2694 20.3751      --
 =================== ======= ======= ======= ======= =======
 
 The unavailable cells were attempted. They are not zeroes and must not be
 compared with a measured row.
 
 .. [1] `PyPCAPFile`_ 0.12.0 imports :mod:`imp`, which Python removed in 3.12.
 
-.. [2] `PyPCAP`_ 1.3.0 is unsupported on Python 3.12+, and its build does not
-   search Homebrew's libpcap library prefix.
+.. [2] `PyPCAP`_ 1.3.0 is unsupported on Python 3.12+.
 
-.. [3] `pcap-ct`_ and `libpcap`_ are published only as pre-releases.
-
-.. [4] `PyShark`_ 0.6 cannot create the implicit event loop it expects on Python
+.. [3] `PyShark`_ 0.6 cannot create the implicit event loop it expects on Python
    3.14; it ran on 3.10--3.13.
 
 Installation
@@ -376,7 +373,7 @@ below is also enforced in code, by the
 preflight described under `Engine Comparison`_.
 
 :class:`~pcapkit.foundation.engines.pyshark.PyShark`
-   Requirements, none of them visible to an import: the package imports
+   None of its requirements is visible to an import: the package imports
    cleanly and then fails when used.
 
    - Drives Wireshark's :program:`tshark` binary. It need not be on ``PATH``: