scripts/fixtures/packaged-plugins-last-release.json now names release 0.7.9, its published archive (sha256 668b9305...) and the openrig-core 0.1.25 payload it shipped (f1838261...), byte-equal to a --snapshot of the published npm tarball and to the v0.7.9 tag's plugin tree. openrig-core moves from 0.1.25 to 0.1.26 in both harness manifests: its files changed on main after 0.7.9 (permission-stop descriptor, refocus and the trace script), and check-packaged-plugin-versions.mjs requires a greater version when packaged bytes change, so existing installs don't keep old content. The check fails at 0.1.25 and passes at 0.1.26; nothing else pins 0.1.25. No other file.
The packaged-plugin version check now compares against the published 0.7.8 package (archive f175a5b1, openrig-core 0.1.24), and openrig-core moves to 0.1.25 in both harness manifests. Since 0.7.8, the plugin's seat-continuity-and-handover skill changed (#2420) while its version stayed 0.1.24, and the old 0.7.6 baseline let that pass, so existing installs could have kept the old file under the same version. Against the new baseline the check fails at 0.1.24 and passes at 0.1.25.
The packaged-plugin version check (`scripts/check-packaged-plugin-versions.mjs`) requires a bundled plugin's version to advance when its files change, measured against `scripts/fixtures/packaged-plugins-last-release.json`. That baseline still described 0.7.2 (openrig-core 0.1.19), so a plugin change since 0.7.6 could pass without a version bump, and two installs could carry different hook or skill files under the same plugin version. The fixture now describes the published 0.7.6 package (openrig-core 0.1.23), checked byte-equal against the published tarball and the v0.7.6 tag's tree. openrig-core moves to 0.1.24 in both harness manifests: main was still at 0.1.21, because 0.7.6's version bump lived only on its release branch, and the plugin's files have changed since. Against the old baseline the check passed wrongly; against the new one it fails at 0.1.21 and passes at 0.1.24. Three files, +6/-6; no source or test change.
Main's openrig-core plugin manifests move from 0.1.17 to 0.1.21, and the packaged-plugin baseline fixture moves from 0.7.1 to the published 0.7.2 archive (plugin 0.1.19). The plugin's payload on main has changed since both published 0.7.2 and the 0.7.3 cut, so a build of main now passes the stock packaged-plugin version check instead of failing it.
3 files, +6 -6, metadata only.
The packaged-plugin baseline now records the published 0.7.1 instead of 0.7.0: tarball sha256 c1637bbe (matching npm's integrity) and openrig-core 0.1.18. It's generated by the script's own refresh command from `npm pack @openrig/[email protected]`. The 0.7.2 cut's plugin check compares against the release users actually have.
Fixture only: +4/-4. No code changes.
A release-preparation check that changed bundled hooks and skills will reach existing installs. Managed refresh replaces installed plugin files only when the bundled version is strictly newer, so changed files at an unchanged version silently stay as they were. Run node scripts/check-packaged-plugin-versions.mjs candidate.tgz on the exact release-candidate archive: it compares the packaged plugins with the last release's (additions, removals, bytes, leaf-link targets), requires a strictly higher numeric version when anything changed, requires consumed manifests to be regular files and harness versions to agree.
The baseline is published 0.7.0's 53 plugin files. --snapshot refreshes it from a newly published archive, writing to a temporary file first so a failed run keeps the old baseline. The check isn't called from per-PR CI, so contributors don't bump plugin versions for individual edits. It runs on our own release-candidate archive and isn't hardened against a crafted one.
Mike Schwarz