Port the public site onto the Go core, and fix a listener data race

[yujiezhang-ops]

Brings the public site work from main onto refactor/walis, adapted to this branch's data sources. refactor/walis was branched before that work landed, so its site/ directory is file-for-file the 2026-07-29 version — none of the 23 new files existed here.

Base is refactor/walis, not main, so this does not ask you to resolve the two parallel Go migrations. That decision stays with PR #2.

The site port

The i18n routing layer, five English pages, the compatibility explorer, the self-playing activation demo, and the theme/locale controls.

main fed the site from src/generated/*.json, produced by Python scripts this branch removes. So the port had to change the data layer, not just move files: catalog.ts now reads agents.lock.json directly (gaining command, configPath and groups, which the explorer and demo display), and a new release-channel.ts maps a GitHub release into the channel shape the download and security pages already consume. Eleven as unknown as / as any casts are gone with the untyped JSON imports they existed to paper over.

catalog.ts also imports its types from explorer.ts instead of redeclaring them — the duplicate declarations were how a new protocol could reach the pages while the explorer still called it unsupported.

A data race in the installer

go test -race -cover ./... failed on internal/process, and it turned out not to be a test artifact.

exec.Cmd copies stdout and stderr on separate goroutines, so the listener passed to RunWithOutput was entered from both at once. The install runtime hands it a closure that redacts and forwards (internal/app/install.go:373), holding no lock. That is a production data race, and it triggers whenever a command writes to both streams — npm does on every install.

The lock now lives in the runner: "calls are serialised" is the contract a listener should be able to rely on, and both streamWriters share one mutex (a mutex per writer would leave the two goroutines taking different locks and entering the listener together anyway).

The existing tests only caught this by accident. They left stderr empty, so -cover adding a GOCOVERDIR not set warning to the child's stderr was what exposed the race at all — and that same warning polluted three assertions about captured output. The helper now gets its own scratch GOCOVERDIR, and TestOSRunnerSerialisesListenerAcrossStreams drives 50 interleaved writes per stream through an unlocked listener. Reverting the fix makes it fail with DATA RACE; I checked.

A fresh clone could not build

manifest_embed.go says a checked-in .keep makes the stage-0 shell buildable before Vite runs. The file was never in the repository: two dist/ rules excluded the directory itself, and excluding a directory stops git descending into it, so the !frontend/dist/.keep exception already sitting in the root .gitignore could never take effect. go:embed all:frontend/dist therefore had nothing to embed, and go vet ./... failed on a fresh clone until someone happened to build the frontend first. Verified by cloning this branch and running go vet ./... with no frontend build — it now passes, and build output stays ignored.

Three judgement calls in the site copy

The security pages asserted something the data cannot support. They claimed a specific macOS arm64 build passed a cleanroom review; the release feed carries no build provenance. They now state what is checkable against the release page — channel, version, platform, digest — and say the provenance conclusions are recorded by the release process rather than asserted by the page. release-channel.ts reports native_build: false and cleanroom: "not-recorded" for the same reason: those are the honest readings of "the feed cannot tell us", and asserting true would put a verification badge on the site that nothing checked.

A verification gate lost its subject. validate-build.mjs used to re-hash every artifact in dist/downloads/ against the digest the release index claimed, so a page could not print a checksum the file did not have. With artifacts on GitHub Releases there is no local file to hash. Removed, with a comment recording the cost: a wrong digest from the release feed now reaches the page unchallenged. Restoring an equivalent check means fetching and hashing each asset during validation.

npm run build was failing after reporting success — it ended in npm run validate, but validate had been deleted from package.json. Restored.

Gates

go vet ./...                      clean
go test -race -cover ./...        all packages ok, 0 failures
frontend: npm run build           ok (tsc --noEmit clean)
site: npm test                    40 passed
site: npm run build               0 type errors, 32 pages, validate-build passed
site: npx playwright test         133 passed, 23 skipped, 0 failed (3 viewports)

Two environment notes for whoever runs this next:

• go.mod requires Go 1.26.5 and proxy.golang.org is unreachable from here, so the automatic toolchain download fails. I installed 1.26.5 from dl.google.com (checksum verified against go.dev/dl) and used GOPROXY=https://goproxy.cn with GOSUMDB=sum.golang.google.cn. go.sum is unchanged — no hash was substituted, and the existing entries were sufficient.
• GITHUB_TOKEN is effectively required for the site build. Unauthenticated GitHub API access is 60 requests/hour and a 32-page build exceeds it; over the limit the build fails outright rather than degrading.

The 23 skips are 8 pre-existing viewport skips plus 15 because this repository has no published releases — getLatestRelease() returns null, so the download page renders its "not published yet" notice and the platform-picker tests have nothing to drive. They skip with a stated reason rather than being deleted, so they still catch a regression once artifacts exist. PR #2's own baseline behaves the same way; I checked before changing anything.

🤖 Generated with Claude Code