20 of 23 shipped versions have no GitHub Release — main is 1.25.0, newest release is v1.13.1

[wan-huiyan]

20 of the 23 versions this repo has shipped have no GitHub Release. main ships 1.25.0; the newest release is v1.13.1, cut 2026-07-23. Twelve versions have shipped since then and none of them exists as a release.

Found while sweeping every wan-huiyan plugin repo for a different bug — a release workflow filtering paths: ['VERSION'], which fails by not running. This repo does not have that bug. It has no release workflow at all (.github/workflows/ contains only test.yml), which is a separate and larger thing, and the fix is not obvious enough for me to apply it unasked.

The measurement

Every version the manifests have ever held on main, against gh release list:

version	released	first shipped	commit
1.0.0	no	2026-04-02	9982bf5
1.1.0	no	2026-04-02	e5ca1ad
1.2.0	no	2026-04-07	ee2c30d
1.3.0	yes	2026-04-14	22378c9
1.4.0	no	2026-04-24	b2b21dd
1.7.0	no	2026-05-12	f88fc45
1.9.0	no	2026-05-15	7c6aba2
1.9.1	yes	2026-06-01	d8ca2ff
1.13.1	yes	2026-07-23	afdb1ca
1.14.0	no	2026-08-04	8c73f82
1.14.1	no	2026-08-05	904cde7
1.14.2	no	2026-08-05	2d76f26
1.15.0	no	2026-08-05	3307bcd
1.16.0	no	2026-08-06	24758cd
1.17.0	no	2026-08-06	dbc928c
1.18.0	no	2026-08-06	90026b8
1.19.0	no	2026-08-07	ae7c149
1.20.0	no	2026-08-07	d7283ca
1.21.0	no	2026-08-07	ed737cc
1.22.0	no	2026-08-07	e6a0ff4
1.23.0	no	2026-08-07	4e7fbc8
1.24.0	no	2026-08-10	875e7b9
1.25.0	no	2026-08-10	9ee0ad6

3 released, 20 not. The gap is not a slow drift: every version since 1.14.0 — twelve consecutive releases across 2026-08-04 to 2026-08-10 — is missing, which is when this skill was being worked on hardest.

Two things this is not

• Not the path-filter bug. That one is paths: ['VERSION'] on a release.yml that exists. Sibling repos with it: claude-ecosystem-hygiene (v1.12.0: drop the release path filter, and gate the OUTCOME of releasing claude-ecosystem-hygiene#21), memory-hygiene (Drop the release workflow's paths filter — it fails by NOT RUNNING memory-hygiene#11), overnight-workflows (Drop the release workflow's paths filter — it fails by NOT RUNNING overnight-workflows#35). All three measured nil cost. This repo's number is 20, and it is a different mechanism.
• Not necessarily a defect. It may be deliberate that this repo publishes through the marketplace manifest and does not use GitHub Releases. That is a real, defensible choice — which is exactly why I have not added a workflow. If it is the choice, the useful outcome of this issue is a line in the README saying so, so the next sweep does not re-raise it.

If releases are wanted, the shape of the fix

Two separable pieces, in this order:

1. Stop the bleeding — add a VERSION file plus the release-on-version-bump workflow the sibling repos use, without the paths filter (see the three PRs above for why the filter is the dangerous half). From then on every bump cuts a release.
2. Decide about the backlog, separately. Twenty tags cut retroactively against historical commits is a real decision with a real downside — release notes generated now against old diffs are worse than no notes — and it should not ride along with (1). The cheap middle option is to cut v1.25.0 only, so main and the release list agree from today, and record the other 19 as accepted history.

Whichever way it goes, the sibling repos ship a .release-parity-accepted baseline file for exactly this: a gate that ships red gets muted inside a week, so the known holes get recorded once with their reason and only new divergence fails. Note the caveat before reaching for that gate here: its changelog half needs an exactly-## Version history heading and - **vX.Y.Z** bullets. This README satisfies both (the parser reads all 23 entries), so it would work here — unlike four of its siblings. Tracked as wan-huiyan/agent-traffic-control#41.

Reproduce

git clone git@github.com:wan-huiyan/session-handoff.git /tmp/sh
gh release list --repo wan-huiyan/session-handoff --limit 200 --json tagName --jq '.[].tagName' | sort -V
python3 -c "import json;print(json.load(open('/tmp/sh/.claude-plugin/marketplace.json'))['plugins'][0]['version'])"

[wan-huiyan]

Cut: v1.25.0 — the first release since v1.13.1 (2026-07-23). Owner authorised the cut; scope was decided as current version only.

A correction to this issue's own numbers first. It said "every version since 1.14.0 — twelve consecutive releases". The trailing run of unreleased versions is 14, not 12: 1.14.0 1.14.1 1.14.2 1.15.0 1.16.0 1.17.0 1.18.0 1.19.0 1.20.0 1.21.0 1.22.0 1.23.0 1.24.0 1.25.0. The 12 was counted by eye off a printed table rather than computed — the same defect this whole sweep is about, at the smallest possible scale. The table in the issue body was right; the sentence under it was not.

State now:

	before	after
releases	3	4
claimed versions	23	23
unreleased	20	6

v1.25.0 points at 9ee0ad6, which is main's tip. Its created_at is 2026-08-10T19:33:02Z — GitHub dates a release by its target commit — while published_at is 2026-08-12. So it carries the date the code actually shipped, not a backdate.

Deliberately not cut: the six older versions — 1.0.0, 1.1.0, 1.2.0, 1.4.0, 1.7.0, 1.9.0. Reason, so it is on the record rather than assumed: --generate-notes over a four-month-old commit range produces release notes written now against old diffs, which is worse than an honest gap. They are recorded here as accepted history.

This issue stays open for the remaining question, which is unchanged by the cut: this repo still has no release workflow, so the next version bump will go unreleased exactly as these did. Either add one (a VERSION file plus the release-on-version-bump workflow the sibling repos use, without the paths filter — wan-huiyan/claude-ecosystem-hygiene#21, wan-huiyan/memory-hygiene#11, wan-huiyan/overnight-workflows#35), or record in the README that releases here are cut by hand.