tools/check-songs

buck2 run //:check-songs plays every song fast in a silent headless tab on the running dev server and prints what Jev did with each one:

• the path it took, section by section: the section Jev picked and every part's answer;
• late answers, which arrived after their section began, so it played its fallbacks;
• fallbacks from the rate limit, a backoff, or an unusable answer;
• problems Jev's core reported, and the page's warnings and errors.

It exits nonzero when a song fails to evaluate or the page throws.

buck2 run //:check-songs                               # every song, 4× speed
buck2 run //:check-songs -- --speed 8 lightning-in-a-bottle system-one
buck2 run //:check-songs -- --url http://localhost:4395 dial-up   # another dev server

Run from a worktree while the dev server serves another checkout, songs hear the worktree's samples/, and the output says so first (tools/worktree-samples/). The site's code is still that server's: to check a worktree's site or jevCore changes, run a dev server from the worktree on its own ports (tools/dev/CLAUDE.md) and pass --url, as tools/measure takes it.

It needs buck2 run //:dev running and the devshell. Playwright and its browsers come from the flake (.#playwright, .#playwright-browsers), not npm.

This complements website/src/jev/allSongs.test.mjs (nix flake check), which evaluates every song in Node against a stand-in Jev. This tool is the real thing: the browser, the scheduler, the relay and Jev itself. So it needs the dev server, and it spends real calls against the relay's rate limit.

At high speed a section can be shorter than Jev's round trip. The parts request waits for the section's answer, so late answers at 8× are expected and do not happen at 1×.