[binlecode]

Summary

guard-release has failed on every release from v1.9.0 back to v1.6.9, reporting 60 tags as having no GitHub Release object. All 90 tags have one. The guard's own query was the bug.

Both gh api calls ran un-paginated, and the REST API returns 30 items per page:

	count
git/refs/tags (returns all today)	90
/releases un-paginated — what the guard compared against	30
flagged "missing"	60
actually missing (comm of the full lists)	0

The 30 visible releases go back only to v1.3.1, which is exactly where the flagged range started (v0.8.2 … v1.2.3). 90 − 30 = 60.

Why it matters

A permanently-red gate reports nothing. The one real failure this guard exists to catch — a bare git tag + push that skips scripts/tag_release.sh, leaving /releases silently behind the code — would have been indistinguishable from the standing noise. That is the exact failure mode CLAUDE.md cites as the reason the guard was written.

Fix

--paginate on both calls:

• /releases — so the comparison set is complete. This is the actual bug.
• git/refs/tags — not currently truncating (it returns all 90), but it will once the repo passes its own page cap, and a truncated tag list means the guard silently stops checking the newest tags. A false negative is the worse failure for an integrity gate, so it gets the same treatment rather than waiting for it to bite.

Verification

Reproduced against the live repo before and after:

$ gh api "repos/binlecode/actop/releases" --jq '.[].tag_name' | wc -l
30
$ gh api --paginate "repos/binlecode/actop/releases" --jq '.[].tag_name' | wc -l
90
$ comm -23 <all 90 tags> <all 90 releases>     # nothing missing
(empty)

The guard only runs on tag push, so this fix gets exercised for real by the v1.9.1 tag itself — it should go green for the first time in six releases.

Not doing

No backfill. There is nothing to backfill; all 60 gh release create calls would have failed with already_exists.

🤖 Generated with Claude Code