[JarryShaw]

• 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 — 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?

• ci — changes to CI configuration files and scripts

---

Description of your pull request and other information

The second create-release batch for #1967, per option (a) on #1967. It covers the last two inline steps.

• util/release_status.py: replaces Report why this run did or did not release anything in release_status.
• util/release_vendor_update.py: replaces Read whether its vendor-update job ran in vendor_update.
• Permissions: each job gains contents: read (vendor_update keeps actions: read).
• Checkout: each job gets a first Checkout code step at github.sha, using sparse-checkout: util and persist-credentials: false. fix(ci): Create Release tags main's tip at approval time, not the commit it was created for #1634 requires the ref:.
• YAML diff: structurally, removing the new step and permission and blanking the two run: bodies leaves the workflow identical.
• Equivalence tests: test_release_status_scripts_1967 embeds main's two shell bodies verbatim and runs each under bash -e side by side with its script, against a stand-in gh. It requires the same status, stdout, stderr (minus bash's line N: prefix), outputs, summary and calls.
  • release_status: 47 cases reach every exit of the old shell, plus 150 random draws.
  • vendor_update: 23 cases reach all of its exits.
  • Two planted divergences were caught.
• Behaviour change: if the new checkout fails, the job goes red. Before, vendor_update stayed green with updated unset, and release_status still printed. Downstream, nothing changes for vendor_update.
• Results: the release, helper, pin, hardening and docs tests pass, and actionlint 1.7.12 is clean.

[JarryShaw]

GOOD TO GO at 3a7d57d6e (Sonnet cross-review).

• Workflow diff: a YAML diff of vendor_update and release_status shows exactly a new Checkout code step, contents: read, and a run: that calls the script. The checkout pin matches the file's other checkouts. The scripts import only the standard library and _actions, so sparse-checkout: util is enough.
• Old vs new: the reviewer ran main's shell against the scripts on 3,000 random release_status environments (unset variables, %, $(id), quotes) and 26 adversarial vendor_update cases (CRLF, blank lines, partial output, SIGKILL, a missing gh). Output and exit codes match. The one exception is a NUL byte, which gh --jq can't emit.
• Equivalence test: it embeds main's bodies verbatim.
• One unverified point: if the new checkout ever fails, vendor_update goes red. version_check still runs (!cancelled()), but the publishers' implicit success() may then skip them, because the failed job is an indirect dependency. That would delay a release to the next run rather than produce a wrong one. Making the step tolerate a failed checkout would need a fallback for the script, so I've left it as is.

[github-actions]

Coverage: 91.52% (unit tier, Python 3.15, 3a7d57d6e, Unit Tests run success)

Package	Statements	Missed	Branches	Partial	Cover
pcapkit (top level)	104	4	20	2	95.16%
pcapkit/const	19599	881	2618	867	92.11%
pcapkit/corekit	2565	71	812	37	96.56%
pcapkit/dumpkit	282	3	102	3	98.44%
pcapkit/foundation	2930	23	1022	25	98.79%
pcapkit/interface	138	4	52	3	96.32%
pcapkit/protocols	17414	219	4574	185	98.14%
pcapkit/toolkit	869	36	298	10	95.20%
pcapkit/utilities	473	7	136	5	98.03%
pcapkit/vendor	4431	1995	1018	167	51.73%

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

[JarryShaw]

Ready to merge at 3a7d57d6e: the review is GOOD TO GO and CI is complete (56 passed, 0 failed). The ordering leg ran 2000 tests with 0 failures. The 3.8–3.10 KTLO legs show 0 failing tests, and the PR is based on current main (fd0d2e724). #2069 and #2071 also add to the SCRIPTS tuple, so whichever merges after this will need a small rebase, which I'll do.

[JarryShaw]

Rebased onto main (69562f99d), 3a7d57d6e → 722cee41a, to resolve the conflict with #2069. The only conflict was SCRIPTS and RUNS in test_actions_helper_2047, where both sides added names. The resolution is their sorted union (#2069's update_python_versions plus release_status and release_vendor_update from here). git patch-id --stable is identical outside that file. The helper, KTLO-guard, workflow-script, docs-claims and python-versions tests pass on the rebased tree. The old head's CI was green (56 passed, 0 failed), with 0 KTLO failures. Only that test tuple changed, so you can bypass checks and merge.

[JarryShaw]

Rebased onto main (27288aa93), 722cee41a → 0b5f60dd4, after #2071 merged. The only conflict was the SCRIPTS tuple again. The resolution is the sorted union: #2071's check_suite_report plus release_status and release_vendor_update from here. git patch-id --stable is identical outside that file. On the rebased tree, the helper, release-status, release-gate, release-tag, KTLO-guard, workflow-script, discussion-report, matrix-tier and docs-claims tests all pass. The old head's CI was green, and only that tuple changed, so you can bypass checks and merge.