[JarryShaw]

Please follow the guide below

• You will be asked some questions, please read them carefully and answer honestly

• Put an x into all the boxes [ ] relevant to your pull request (like that [x])

• Use Preview tab to see how your pull request will actually look like

• 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. Not run in full; only the narrow runs below.

• Added a changelog entry under docs/source/changelog/ and regenerated CHANGELOG.md, if the change is user-visible: N/A — centralised in docs(changelog): shared 1.5.0 changelog — long-lived, merges last (#610, #616, #617, #618, #620) #657

What is the purpose of your pull request?

Tick the commit type your subject line carries.

• 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
• release — bumps the version or rolls up a distribution
• chore — anything else

---

Description of your pull request and other information

isort is unpinned, so the 3.8 leg installs 5.13.2 and the 3.9 leg 6.1.0. Both call five files red that 9.x calls clean. test_check_only_is_clean_on_every_makefile_line now skips when the installed isort is older than 9.0.1, and the skip reason names that floor. On 9.0.1 and later it runs unchanged, so a newer isort whose verdict moves still turns it red, as pyproject.toml intends. Only tests/project/test_isort_clean.py changes.

The floor comes from a bisection. Each release got a fresh venv on CPython 3.10.21 and ran all four isort: recipe lines through python -m isort --check-only, which is how the test runs them:

isort	verdict
5.13.2, 6.1.0, 7.0.0, 8.0.0	red: the same 5 files (10 blank lines to drop, 1 to add)
8.0.1, 9.0.0a2, 9.0.0a3	red: dpkt.py only
9.0.0b1, 9.0.0b2	clean
9.0.0b5, 9.0.0	cannot run: No code object available for isort.__main__ (the console script reports clean)
9.0.1, 9.0.2	clean

The same table is in the comment on ISORT_FLOOR. The version comes from importlib.metadata, so the test never imports isort. The new decorator is a skipIf, so the class-level HAS_ISORT gate that tests/test_tier_guard.py audits stays as it was. Results are identical before and after rebasing onto 8035434a2, which changed dpkt.py and pyshark.py.

On origin/main the test fails on 3.8.20 and 3.9.25. With this change it skips on both, and on 3.10.21 (isort 9.0.2) and 3.14.8 (9.0.1) it gives 1 passed, 4 subtests passed, the same count as on main. An unsorted temp/sort.py still turns it red on 3.14. tests/test_tier_guard.py passes on 3.14 (110 passed).

Closes #1696

[JarryShaw]

Verdict: GOOD TO GO at ef629da5a. A Sonnet cross-review re-ran isort on each side of the floor in fresh venvs. 5.13.2 through 8.0.0 are red in the five files, 8.0.1 and the alphas are red on dpkt.py only, and 9.0.0b1 and later are clean. 9.0.0b5 and 9.0.0 cannot run under python -m isort. The floor of 9.0.1 is the first final release the test can get a verdict from, which matches pyproject.toml's note. The test skips on 3.8 and 3.9, and runs and passes on 3.10 and 3.14 with the same count as main. An unsorted file still turns it red.

[github-actions]

Coverage: 89.47% (unit tier, Python 3.15, ef629da5a, Unit Tests run success)

Package	Statements	Missed	Branches	Partial	Cover
pcapkit (top level)	104	3	20	3	95.16%
pcapkit/const	18858	954	2366	868	91.06%
pcapkit/corekit	2366	67	760	35	96.48%
pcapkit/dumpkit	275	3	100	3	98.40%
pcapkit/foundation	3035	151	1076	34	94.28%
pcapkit/interface	138	7	52	5	93.68%
pcapkit/protocols	17166	226	4580	190	98.07%
pcapkit/toolkit	1437	279	592	5	78.12%
pcapkit/utilities	494	4	146	4	98.75%
pcapkit/vendor	4417	2342	1010	157	43.38%

Per-file detail: the coverage-html artifact of this run.