docs(contributing): sweep pep.rst and testing.rst (#719)

[JarryShaw]

Please follow the guide below

• Searched for similar pull requests
• Followed the coding style (make pylint, make mypy, make isort)
• make test passes, and a test case covers the change
• Added a changelog entry under docs/source/changelog/ and regenerated CHANGELOG.md, if the change is user-visible — N/A — documentation prose only, no library behaviour change

What is the purpose of your pull request?

• fix — corrects a defect
• feat — adds a feature
• perf — changes performance, not behaviour
• refactor — changes neither behaviour nor performance
• test — tests only
• docs — documentation only
• ci — workflows or build tooling
• chore — anything else

---

Description of your pull request and other information

Third slice of #719, taking docs/source/contributing/pep.rst and testing.rst — the two pages in that directory #953 does not touch. pep.rst 1145 → 1084 lines, +159/−226 overall.

Six figures disagreed with the tree. Each was re-derived before being changed:

page said	tree says
16 of the 151 TransType	len(Internet.__proto__) is 17
327 codes registered, 59 not round-tripping	registry walk gives 322; EXPECTED_FAILURES is 43
105 modules matching test_*.py	find gives 192
"plus an allowed-to-fail 3.15 leg"	unit-tests.yml runs 3.10–3.14 and excludes 3.15 deliberately
1.5.0b3 (current)	dates itself on every bump
pcapkit/toolkit/pcap.py:53 filters on DF	the DF filter is at :56

The round-trip table was the worst of them. It had 11 rows totalling 59; the live set has 9 families totalling 43, with tcp-mptcp (8) and ipv6-route-type (1) gone entirely and ipv4-option at 1 rather than 6 — the gap closed as defects were fixed and nothing updated the page. Where a figure will keep rotting, it is replaced by the command that produces it, matching the pattern already on conventions/process.rst. All four commands written into the page were run from the repository root.

Timed context removed: the 16k-lines/800th-commit origin story, the MH and CGA-Parameters chronologies (#445/#446, the reverted half-fix, "four entries went green at once"), the three now-fixed OSPF defects, the logging migration narrative, and testing.rst's note about having come out of the README.

Kept deliberately, because #719 protects rationale over brevity: the two contradicted profiling predictions (recorded so nobody re-spends the time), the flow-finalisation reasoning, why the tracer delegates to the TCP reassembler rather than buffering in capture order, the reassembly-clock choice, and the #472/#483 evidence for the method the sweep itself uses.

Verification. No test pins prose in either file (grep -rn "pep\.rst\|testing\.rst" tests/ is empty). tests/project: 227 passed, 1 skipped, 669 subtests, re-derived as 228 tests, OK under plain unittest, since pytest-subtests undercounts.

Not verified: the performance figures (46%, 82%, 86% + 133 ms, 15%, 30%/3011 calls, 63207 copies) were not re-measured — only 2274/1137 is corroborated, by the in-code note. None was edited. No Sphinx build was run, so a cross-reference regression in the edited blocks is possible.

[JarryShaw]

NEEDS CHANGES at 911e2d8f9 — sonnet cross-review, round 1. Both findings are real; I confirmed each against the file before acting, and both are fixed at 6662c832f.

1. A third 59 survived the fix, two paragraphs below it. pep.rst:1004 still read "which is how these 59 are known at all". The page therefore contradicted itself: the command two paragraphs up yields 43. Now "which is how the shortfall is known at all" — no figure, so it cannot rot again.
2. A dangling reference to the table this change deleted. pep.rst:995 called pcapng-option "the largest family in that table", and the list-table it pointed at went in this same diff. Now just "the largest family".

Finding 1 is the better catch, and it is the failure mode this slice exists to prevent: I replaced a stale figure in one place and left an identical one nearby. Partially fixing a number is worse than not touching it, because the page now disagrees with itself and a reader cannot tell which half is current.

It independently re-derived all six figures and got the same answers — 17 151, the 43-entry Counter across 9 families, 322 18, 192, the 3.10–3.14 matrix, the DF check at :56. It also ran all four shipped commands verbatim from the repository root: every one exits 0. And it added a correction to my own prose — the page ships four invocations across three code-blocks, not three; the commit message now says four.

After fixing, I swept both files for siblings of the same shape (59, 327, 105, 16 of, :53, 1.5.0bN, and three phrasings of a table back-reference). One hit: pep.rst:832's "a beta — 1.5.0b1 — when wave 1's remaining issues are closed", which is a plan rather than a claim about the current version, so it stays.

Round 2 is running against 6662c832f, briefed to look for a third occurrence my grep pattern would have missed. Staying at review: pending until it reports.

[JarryShaw]

GOOD TO GO at 6662c832f — sonnet cross-review, round 2.

I verified its central claim myself rather than taking it: git diff --stat 911e2d8f9 6662c832f is one file, +2/−2, and the two lines are exactly the two reworded sentences. testing.rst is byte-identical between the heads.

It made a point about the first fix that I had not: "shortfall" is not a word I introduced to dodge the figure — the same section already uses it one paragraph earlier ("the shortfall against EXPECTED_FAILURES"), so the sentence now resolves to an established referent instead of to a number. And it re-checked that "largest family by a wide margin" is still true with the table gone: 30 against a next-largest of 3.

The sweep for a third occurrence came back empty, and it searched wider than I did — the bare figures in any form, plus six phrasings of a dangling back-reference my pattern would have missed ("the breakdown above", "those nine families", "as listed below", and so on). Two "list above" hits at :65 and :213 point at the genuine stub list earlier on the page, pre-existing and not dangling. No surviving pcap.py:53, :120, collections.py:402-420 or 1.5.0b3.

It read :832's 1.5.0b1 the same way I did: that names which release closed wave 1, which is marked done, not the current version — and the current version is handled two lines above by :data:pcapkit.version``.

One residual inconsistency it caught, in my own prose rather than the diff: I amended the commit message to say four commands but left the pull request description saying three. The description is a separate field that does not follow an amend. Fixed — it now reads four.

Labelled review: good-to-go. Not ready to merge: CI is still running on this head, and merging is yours.