release: ship the web dashboard, so the Expert Atlas actually reaches users (#578)

[ZacharyZcR]

This is the "why can't I see the atlas" thread, and the answer turned out not to be the atlas.

What is actually broken

The README leads with a dashboard screenshot, and the site's entire argument is the measured Expert Atlas — but no release archive has ever contained either. release.yml packages the engine plus four .py files; web/dist is a build artifact and isn't tracked. So a release user has no web/ to build from, and coli web helpfully told them to cd web && npm install — in a directory the archive does not have.

#578 was right and did work: web/public/experts.json (13,260 experts) does land in web/dist/experts.json at build time — I rebuilt to confirm, 3,497,647 bytes, byte-identical. It just never reached anyone who didn't build the front end themselves.

Worth stating plainly, since it caused the confusion: there are two different atlases.

	data	shipped
site/index.html (inlined ATLAS_RAW)	1,358 experts — 721 canonical + 637 gate-sensitive, "atlas v1"	✅ live on the site
web/ + experts.json	13,260 entries from the full sweep	❌ never packaged

The site's atlas is fine and has been all along. This PR is about the second one. It does not touch site/, and it does not replace v1 with the sweep data — v1 is the stricter set (cross-validated across three kernel families), and mixing them is a separate judgement call.

Packaging alone would not have fixed it

WEB_DIST was one path:

WEB_DIST = Path(__file__).resolve().parent.parent / "web" / "dist"

That only resolves in a source checkout, where this file sits in c/. In a release archive or an installed tree the server sits next to web/dist, one level nearer — so shipping the files without touching this would have produced an archive that contains the dashboard and still 404s. Both openai_server.py and coli now probe for index.html across the two layouts. Probing for the file rather than the directory also stops an empty leftover web/dist from shadowing a real one.

Changes

• release.yml — build the dashboard with setup-node + npm ci && npm run build, package it as web/dist next to coli. Built in CI rather than committed, so dist/ stays an artifact. On Windows the step forces shell: bash: the job default is msys2, whose minimal PATH cannot see the node setup-node installs.
• openai_server.py / coli — two-layout resolution, described above.
• Makefile — install places web/dist next to openai_server.py when it exists, and prints how to build it when it doesn't (it's an optional artifact, so this must not become a hard dependency of make install).
• archive verification — the existing step's own comment says it best: "a packaging mistake is invisible to every other job in this repo: the build is green, the tests are green, and the artifact is still unusable. Assert on behaviour." So it now asserts not just that the files are in the archive, but that the packaged server resolves them — that's the failure mode this whole change is about.

Verification

Replayed all three layouts locally and checked which path each resolves to:

layout	resolves to	index.html + experts.json
source checkout (c/)	<repo>/web/dist	✅
unpacked release tree	<pkg>/web/dist	✅
make install DESTDIR=…	<libexec>/colibri/web/dist	✅
unbuilt tree	source-checkout default	falls through to the "web UI not built" hint, as before

The new verify command was tested both ways — passing on a correct tree, and failing with the resolved path named when web/ is removed. (Shipping an unrun verification step would be the same class of mistake this PR is fixing.)

make check 211 passed.

Note on size

The archive grows by ~3.7 MB, almost all of it experts.json (3.5 MB; the built UI is ~250 KB). That is the atlas itself, so it's the payload rather than overhead — but it's a real jump against a ~1 MB engine, and worth a maintainer's call. If you'd rather keep archives lean, the alternatives are shipping the UI without the atlas data (the hover degrades, the dashboard still works) or serving experts.json compressed. Happy to do either.