0.68.1 was published to npm with no git tag and no GitHub release — a shipped user-facing fix that cannot be checked out or bisected to

[edspencer]

@edspencer/paddock@0.68.1 is on npm. There is no v0.68.1 git tag, locally or on origin, and no GitHub release. A user can install a version that cannot be located in the repository.

Evidence

$ npm view @edspencer/paddock versions
[ …, "0.67.0", "0.68.0", "0.68.1", "0.69.0" ]

$ git tag --list 'v0.68*' 'v0.69*'
v0.68.0
v0.69.0

$ git ls-remote --tags origin | grep -E '0\.68|0\.69'
a0efd9b…  refs/tags/v0.68.0
5addfbc…  refs/tags/v0.69.0

$ gh release list
v0.69.0  Latest  …
v0.68.0          …
v0.67.0          …

The version bump is 7690838 — "chore: version packages (#810)". The ## 0.68.1 section of packages/server/CHANGELOG.md:49-50 is empty: the bump was carried by @paddock/web alone, for #809 (Discover refreshes the project list when a run ends).

Why it matters

0.68.1 is not an internal no-op. It is the fix for a real user-visible bug: after a Discover run, the success screen said the projects were in the sidebar while the sidebar still said "No projects yet" until a manual browser reload (#808 → PR #809).

So there is a published artifact, with a user-facing behaviour change, that:

• cannot be git checkouted by version,
• cannot be bisected to,
• has no release notes anywhere a user would look,
• and is invisible in gh release list, which is where the project's other releases are announced.

Failure scenario

A user reports a bug against 0.68.1. A maintainer tries git checkout v0.68.1 — nothing. They diff v0.68.0..v0.69.0 and get 0.68.1 and 0.69.0's changes mixed, with no boundary between them. The only way to recover the exact tree is to find 7690838 by reading git log for the version-bump commit.

Severity

Process, not code. Nothing is broken for anyone running it. Filed because the failure mode is silent and cumulative: nothing in the repo records that this happened, so if the cause is systematic the next patch release goes the same way.

What I did not determine

Whether this was intentional. I did not read the Release workflow run logs, so this is reported as an anomaly rather than a diagnosis. Two possibilities worth checking:

1. The Release workflow's tag/release step is conditional on something 0.68.1 did not satisfy — e.g. keyed to the server package, whose changelog section for 0.68.1 is empty, while the publish step ran off @paddock/web.
2. A run failed partway, after npm publish and before tagging.

.github/workflows/release.yml is the place to look.

Suggested resolution

1. Work out which of the two it was.
2. Create v0.68.1 at 7690838 and a matching GitHub release, so the published version is locatable.
3. If it is (1), make the tag/release step unconditional on which package moved — a version that exists on npm and not in the repo should not be reachable by any path.