[chussenot]

Why

Release drift has failed every day since late August (runs #49–#53): tags 0.14.0, 0.15.0, 0.15.1 are on master but have no GitHub release. That part is a real finding, and the job is right to report it.

Looking into it turned up a worse problem that nothing reports: GitHub's "Latest" release is 0.13.0, not 0.16.0. 0.13.0 was recovered by re-pushing its tag, as the drift job says to do, and was published on Aug 27, the day after 0.16.0. release.yml didn't pass --latest, so GitHub gave the badge to the newest-published release. Since then, mise use -g github:chussenot/pact@latest (the documented install path) has installed 0.13.0. Following the job's current advice for the remaining three tags would move the badge again, this time to 0.15.1.

Changes

• release.yml: always passes --latest. It is true only when no published release has a higher version than the tag, and false otherwise.
• release-drift.yml:
  • Adds a second check: fail if Latest is not the highest published version. This is the check that would have caught the 7-week mis-install.
  • Both checks now report before the job exits.
  • The missing-tag remedy now ends with gh release edit <highest> --latest. A re-pushed tag runs release.yml as it was at that tag, so the fix above does nothing for 0.14.0–0.15.1.

Validation

I extracted the run: scripts from both workflows and ran them against a stub gh that returns the repo's real release list:

• Current state: reports the 3 missing tags and "Latest is 0.13.0, but the highest published version is 0.16.0". Exit 1.
• After recovery (3 releases added, Latest = 0.16.0): both checks pass. Exit 0.
• release.yml publish step: a late 0.14.0 gets --latest=false; a new 0.17.0 gets --latest=true; the first release in an empty repo gets --latest=true.
• Both files parse as YAML. Shellcheck's only note is the deliberate $missing word-split, the same idiom the existing script uses.

Still needed (manual, outside this PR)

1. gh release edit 0.16.0 --latest: fixes @latest immediately.
2. Re-push the missing tags one at a time, waiting for each Release run:
   git push origin :refs/tags/0.14.0 && git push origin 0.14.0 (same for 0.15.0 and 0.15.1)
3. gh release edit 0.16.0 --latest again, because those tags run the old release.yml.

---

Generated by Claude Code

[chussenot]

The commits check failure isn't caused by this PR. cocogitto-action v4.2.0 pins cog 7.0.0, which rejects the empty [packages] table in cog.toml (unknown field 'packages'). The config fails to parse before any commit is checked, so this breaks every PR. The fix is in #24, and I've ported the same commit here (ea0fa1b). I reproduced the failure with the cog 7.0.0 binary locally and confirmed cog check passes on this branch after the change.

---

Generated by Claude Code