[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. Narrow runs only, listed 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

Closes #1705.

• Fix: a Create Release run whose Vendor Update did not conclude success releases nothing, because version_check skips it. Such a run is now keyed on its own github.run_id, so it can no longer cancel a pending run that may release. Tag pushes, and runs that may release, keep their ref's group and cancel-in-progress: false.
• Correction to the issue: the run that displaced 38499150441 was 38499295798, whose Vendor Update was skipped. The issue named 38497304243 and 38497353175, which were created earlier. Each Create Release run was matched to the Vendor Update that finished 2-3 seconds before it.
• Unverified: that github.event.workflow_run.conclusion is already set when GitHub computes the group name. The docs list the github context as available there, and three workflows already key a group on github.event.workflow_run.head_sha. After merge, two back-to-back successful Vendor Updates should queue rather than run in parallel.
• Tests: tests/project/test_release_concurrency_1705.py fails 10 sub-cases against main's workflow and passes here. The release, tier and doc-citation tests in tests/project pass (261 + 50 + 131). actionlint reports no new finding.

[JarryShaw]

Verdict: GOOD TO GO at 19057be82. A Sonnet cross-review checked the change against the GitHub docs. The author was Opus.

• Displacement: a non-success workflow_run lands in create-release-<run_id>, a group of its own, so it cannot cancel the shared group's pending run.
• Triggers: every trigger still publishes as before. A tag push stays in its tag's group, a successful Vendor Update stays in main's group, and the only job left on the other runs is the annotation-only release_status.
• Unchanged: the one diff hunk is lines 15-32. ci(python): a weekly job keeps the Python version tiers current and opens a PR (#1660) #1716's tier read and fix(ci): Create Release tags main's tip at approval time, not the commit it was created for #1634's tag check are untouched, and every create-release.yml:N citation still points at the right line.
• Fail before: I re-ran it myself. Against main's workflow the new test fails (failures=10), and on the branch it passes.
• Unverified: whether workflow_run.conclusion is set when the group name is computed. If it were not, every workflow_run would get a group of its own. The check after merge is to see that two back-to-back successful Vendor Updates queue rather than run side by side.

[github-actions]

Coverage: 89.42% (unit tier, Python 3.15, 19057be82, Unit Tests run success)

Package	Statements	Missed	Branches	Partial	Cover
pcapkit (top level)	104	3	20	3	95.16%
pcapkit/const	18860	954	2368	868	91.06%
pcapkit/corekit	2372	67	762	35	96.49%
pcapkit/dumpkit	275	3	100	3	98.40%
pcapkit/foundation	2887	144	1012	34	94.20%
pcapkit/interface	138	7	52	5	93.68%
pcapkit/protocols	17181	226	4590	190	98.07%
pcapkit/toolkit	1313	280	532	5	75.88%
pcapkit/utilities	500	4	150	4	98.77%
pcapkit/vendor	4417	2342	1010	157	43.38%

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