release: v0.1.0 post-release follow-ups (latest badge, notes, version flag, docs) #501

The first tagged release (v0.1.0 + clients/ts/v0.1.0, 2026-08-19) shipped successfully — every artifact publishes, verifies, and runs. This tracks the rough edges found while verifying it end-to-end.

Nothing here is a release blocker. The release is good; these are follow-ups.

What was verified working

Recorded so nobody re-audits it:

• Binaries — 8 archives (linux/darwin/windows/freebsd × amd64/arm64), matching the goreleaser matrix; .zip on Windows, .tar.gz elsewhere; checksums.txt verifies.
• -X ldflags — the released binary reports version=0.1.0 build_time=2026-08-19T16:54:06Z git_commit=9d4cef9. The BuildTime initializer fix (ci(release): make every version tag-driven and fix the dev channel #485) works in production.
• go install …@v0.1.0 — works off the module proxy, and reports exactly what development.md claims: version=0.1.0, build_time/git_commit = unknown. The buildInfoFallback() doc claim is empirically correct.
• GHCR — :v0.1.0 and :latest resolve to the same digest sha256:dda9194b533e2ae8e56dbdb5498e216e975e76c24420fe10cf56ecca2c5f2f24.
• Sigstore provenance — binary and image verify under strict --signer-workflow. Negative control passes too: pointing --signer-workflow at ci.yml is rejected (exit 1), so the check discriminates rather than passing vacuously.
• npm — @wavehouse/sdk@0.1.0 under latest; npm audit signatures reports verified registry signatures and verified attestations (SLSA v1).
• npm: the dev channel's versions don't order by recency, so a range resolves to a two-month-old build #475 fixed in production — the dev dist-tag (0.0.1-dev.20260819163639.h62b2f85f436a) is now the semver-highest of all 14 published versions, ^dev resolves forward, and a dev build cannot satisfy ^0.1.0.
• Quickstart against the released image — getting-started.md steps 1–5 run clean on ghcr.io/wave-rf/wavehouse:v0.1.0: table create, ingest ({"ok":true}), query (both rows), SSE (: connected + live event), and wavehouse health exits 0.

1. The SDK release stole the "Latest release" badge

https://github.com/Wave-RF/WaveHouse/releases/latest resolves to clients/ts/v0.1.0, which has 0 assets.

gh release create defaults --latest to automatic, and the SDK release was created at 17:06 vs the server's 17:01 — newest non-prerelease wins. Consequences:

• the repo sidebar advertises the SDK as the headline artifact;
• gh release download --repo Wave-RF/WaveHouse with no tag picks a release containing no binaries;
• any "grab the latest release" automation gets the wrong thing.

Fix, two parts:

gh release edit v0.1.0 --latest     # reclaim it now

and in .github/workflows/publish-npm.yml (~line 339), so future SDK releases never take it again:

+          # The server release owns the repo's "Latest" badge — a client
+          # release must never take it (it carries no binaries).
+          flags+=(--latest=false)
           gh release create "$tag" "${flags[@]}"

2. The SDK release body is a single fallback sentence

clients/ts/v0.1.0's entire body:

First release of @wavehouse/sdk. See the repository releases for the full change list.

That's the intended first-release fallback (no earlier clients/ts/v* to diff from), so it is working as designed and is self-correcting — the next SDK release generates real notes anchored at clients/ts/v0.1.0.

Two things still worth doing:

• the link points at the releases list, whose "Latest" is currently the SDK release itself (see ci: bump golangci/golangci-lint-action from 7 to 9 #1) — circular;
• it could name the SDK's actual surface (install line, docs link) rather than deferring entirely.

3. Auto-generated notes undersell the release

Category counts for v0.1.0 (142 entries):

The taxonomy did its job — Dependabot routing is clean, zero bumps leaked into CI/Docs. The problem is upstream of it: GitHub groups by label, documentation/github_actions are auto-applied by actions/labeler, and enhancement/bug are applied by hand and mostly weren't. So a release that contains the entire product reads as a docs-and-CI release.

Options, roughly in cost order:

1. Accept it for v0.1.0 and treat CHANGELOG.md as the narrative (it already is — development.md says the changelog "is not the source of the release body; it is the longer-form record").
2. Backfill enhancement/bug on the merged PRs that warrant it and regenerate the notes.
3. Make labeling routine going forward so 0.2.0 doesn't repeat this. GitHub cannot categorise on Conventional-Commit title prefixes, so hand-labeling (or a bot that maps feat:/fix: → labels at merge) is the only lever.

4. wavehouse version silently boots the server

main.go:102 special-cases exactly one subcommand:

if len(os.Args) > 1 && os.Args[1] == "health" {

Everything else falls through to run(). So wavehouse version, --version, and -v all start a full server — binding ports and creating a data/ directory in the caller's cwd — instead of printing a version. version is the first thing most people type after go install.

The version is available (first log line, and /version), so this is ergonomics, not a data bug. The code already anticipates it: "If we ever need more, swap to a real argv router." Worth doing now that the binary is public.

5. standalone.yaml can't run the released image

deployments/compose/standalone.yaml:14 uses build: context: ../.., so the documented quickstart requires cloning the repo — it never consumes ghcr.io/wave-rf/wavehouse. Now that :latest and :v0.1.0 exist, a user should be able to run the stack without the source tree. (Verifying #149's "against the released image" box required a hand-written compose file substituting image:.)

Suggest either switching the service to image: ghcr.io/wave-rf/wavehouse:latest with the build stanza as a documented dev override, or shipping a second standalone-released.yaml.

6. Query silently returns [] for a malformed request

Same server, opposite strictness:

A misspelled or omitted columns yields an empty result set that is indistinguishable from "the table has no rows". getting-started.md explicitly promises the strict behaviour for ingest ("Unknown fields, type mismatches, and missing required columns are rejected with a 400"); query does the opposite.

This cost real debugging time during release verification — an empty result was initially read as a broken release. A 400 on "no projection specified" (neither columns nor select_all) would remove the whole failure class.

7. Docs corrections

• development.md:627 — "A tag carrying a prerelease suffix … never takes the 'Latest release' badge from a shipped stable version." True but incomplete: it only covers prerelease-vs-stable, and misses the case that actually bit us (item 1) — two stable tag families in one repo compete for the badge. Should state that the server release owns "Latest" and client releases are created with --latest=false.
• development.md:628 — "Both — release notes generated by GitHub…" is inaccurate for the first release in any tag family, which gets the fallback body instead (item 2). Worth one clause.
• development.md:618 — the Tag naming block documents clients/go/v0.1.0 Go SDK, but there is no clients/go module (only clients/ts). Fine as illustration of the scheme; flagging in case it reads as shipped.
• npm publishing constraints are undocumented (carried from npm publishing: post-launch follow-ups (provenance, release path, latest tag, docs) #268). The one-trusted-publisher constraint and the Node 24 / npm ≥ 11.5.1 requirement for OIDC publishing exist only as comments in publish-npm.yml. development.md → Cutting a release documents the flow and the dev channel but neither of these. Anyone touching the publish jobs needs both.
• README — no release or npm-version badge. Both now exist and resolve; a GitHub release + npm version badge alongside the coverage/Go-report/license row would be cheap.

Refs

Closes out verification for #149; overlaps the release-path items in #268.