fix(releases-proxy): switch to asset API endpoint + add observability

[thinmintdev]

Summary

releases.hal0.dev/stable.json is silently returning the static _placeholder: true backstop despite Hal0ai/hal0@v0.1.0-alpha.1 shipping a real stable.json asset. Two changes to fix + diagnose.

Background

After PR #10 merged, manual verification showed:

$ curl -sS https://releases.hal0.dev/stable.json | head -5
{
  "_schema": "hal0.releases.v1",
  "_placeholder": true,
  "_note": "Pre-release placeholder. ...",

Upstream is healthy — api.github.com/repos/Hal0ai/hal0/releases returns v0.1.0-alpha.1 with the stable.json asset attached. So the proxy is failing somewhere inside proxyChannelManifest() and returning null, falling through to the static placeholder.

The problem: with the original code, we cannot tell from the outside whether the new middleware ever deployed vs. deployed-and-failed. Both produce byte-identical responses, because the static-placeholder response's cache-control: public, max-age=60, must-revalidate actually comes from public/_headers (not the proxy code), so even that header doesn't disambiguate.

What changed

1. Asset fetch via api.github.com asset endpoint

Switch from asset.browser_download_url to asset.url with Accept: application/octet-stream. Both ultimately land on objects.githubusercontent.com for the bytes, but the api.github.com asset endpoint is the documented direct-download path and is slightly more predictable for CF Workers' cross-origin redirect handling.

2. Observability on every failure branch

Each bailout point now:

Branch	console.warn tag	x-hal0-proxy-failed header value
Releases list fetch threw	gh-list-threw:<err>	same
Releases list non-2xx	gh-list-<status>	same
Releases list JSON parse	gh-list-parse:<err>	same
Asset fetch threw	gh-asset-threw:<err>:<tag>	same
Asset fetch non-2xx	gh-asset-<status>:<tag>	same
No release ships the asset	no-asset:<channel>.json:<count>releases	same

The console.warn calls show up in wrangler tail and the CF Pages logs UI. The x-hal0-proxy-failed response header is visible to any curl -I, so the next time this regresses we can diagnose without Cloudflare account access:

$ curl -sSI https://releases.hal0.dev/stable.json | grep x-hal0
x-hal0-source: github-release/v0.1.0-alpha.1    # success
# or, on failure:
x-hal0-proxy-failed: gh-list-403                # rate-limited on CF outbound IP
x-hal0-proxy-failed: gh-asset-403:v0.1.0-alpha.1  # asset download blocked

Out of scope

• Auth via GITHUB_TOKEN to raise the 60/hr rate limit. If the logs surface that this is the actual failure mode, follow-up PR can add the secret to CF Pages env. Not done here because we don't know it's the issue yet.
• @cloudflare/workers-types still not added. The local PagesFunctionContext type stays the same.
• Cleanup of the stale releases.hal0.dev does not exist yet comment in Hal0ai/hal0:.github/workflows/release.yml lines 13–15 — different repo, separate PR.

Test plan

• CI green (Vercel Preview, Cloudflare Pages, Vercel Agent Review)
• After deploy, curl -sSI https://releases.hal0.dev/stable.json | grep x-hal0 shows either x-hal0-source: github-release/v0.1.0-alpha.1 (fix worked) or a specific x-hal0-proxy-failed: <reason> (fix didn't work but we now know exactly why)
• If the success path fires, body should be the live v0.1.0-alpha.1 manifest with non-zero digest_sha256, not _placeholder: true

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
hal0-web	Ready	Preview, Comment	May 22, 2026 5:04am

[cloudflare-workers-and-pages]

Deploying hal0-web with    Cloudflare Pages

Latest commit:	e6d302b
Status:	✅  Deploy successful!
Preview URL:	https://be61482c.hal0-web.pages.dev
Branch Preview URL:	https://fix-releases-proxy-observabi.hal0-web.pages.dev

View logs