Advance the separately modeled public-release record only after the immutable GitHub release and 34-asset gate are live. Regenerate the checked-in web facts so install pages and deployed receipts resolve v0.9.5 instead of the prior release.
Record GitHub v0.9.4 as the latest published release while keeping the workspace and website source candidate at v0.9.5. Regenerate the build-time facts fallback so the manual Cloudflare deploy receipt compares against the same published tag already served from KV.
Verified with the focused facts and deploy contracts, the complete 256-test web suite, ESLint, TypeScript, facts/docs drift checks, and a 288-page production build.
Update the repository-backed public release fact from v0.9.2 to the live v0.9.3 GitHub release. Regenerate the website fact module so local and public-surface checks agree before preparing v0.9.4.
Verified with npm run check:facts and npm run check:docs.
Signed-off-by: Hmbown <101357273+Hmbown@users.noreply.github.com>
(cherry picked from commit 59ba8dab1b)
Signed-off-by: Hmbown <101357273+Hmbown@users.noreply.github.com>
The v0.9.2 GitHub Release was published (2026-07-30T10:07:33Z) with
platform assets, but the website's "Latest release" badge still sourced
v0.9.1 from web/data/latest-published-release.json and the embedded
latestPublishedRelease in web/lib/facts.generated.ts.
Bump the JSON to v0.9.2 and regenerate facts.generated.ts via
derive-facts.mjs. Verified: check-versions.sh reports "Version state OK";
check:facts reports committed facts match workspace; the diff is limited
to the latestPublishedRelease block plus a fresh generatedAt stamp.
* fix(web): advance the published-release fact to v0.9.1
web/data/latest-published-release.json is manually advanced only after
publication, by design -- install commands must never advertise a tag before
its binaries exist. v0.9.1 published on 2026-07-24 across all three channels
(GitHub Release with 34 assets, 18 crates on crates.io, npm latest), so the
gate is satisfied and the fact was simply stale.
One file drives every version string on the site. The install page was telling
people "latest published: 0.9.0", pinning the CNB mirror commands to
--tag v0.9.0, and carrying the now-false line that v0.9.1 is a source
candidate not yet published.
Regenerated facts.generated.ts alongside it, since check:facts compares the
committed copy against the workspace before prebuild can self-heal it (#3771).
check:facts OK, check:docs PASS (version=0.9.1, install snippets, 16 topics).
* fix(web): let the published release equal the source candidate
Advancing the published-release fact to v0.9.1 surfaced a wrong invariant in
the public-surface contract:
expect(matrix.latestPublishedRelease.version)
.not.toBe(matrix.sourceCandidate.version);
That asserts the source candidate is always strictly ahead of the published
release, which is false in the window between shipping vX.Y.Z and opening the
next lane. Right now both are 0.9.1 and that is correct, not a drift bug.
The real invariant is directional: the site must never advertise a version
that is not published yet. Assert published <= source candidate instead, via a
numeric comparison rather than string inequality.
Also advances latestPublishedRelease in docs/public-surface-facts.json, which
carries the same fact and is compared against FACTS by the same test.
web: 136 tests pass, check:facts OK, check:docs PASS, eslint clean, tsc clean.
Reject malformed, legacy, and older KV snapshots before they can replace a newer deployed build. Derive runtime facts from one exact main revision, expose a public source receipt, and keep the latest published release distinct from the source candidate.
Signed-off-by: Hunter B <hmbown@gmail.com>
CodeWhale Bot