ci: run the unit tests on every push and pull request

[ClaydeCode]

The Jest suite has never run in CI. snapshot.yml and release.yml both go straight from npm install to npm run build, so the three suites under tests/unit/ were green only on whichever machine last ran them by hand, and a regression could reach a pushed image without anyone noticing.

Verified before changing anything: on origin/main at 0.40.0 the suite is green — 3 suites, 28 tests, exit 0.

A second gap turned up while checking that one, and is fixed here too: just set-version never touched the lockfile.

What changed

• .github/workflows/snapshot.yml — a Run unit tests step between install and build.
• agents.md — npm run test:unit was missing from the Commands block entirely, which is part of why the gap survived. Added, plus a line saying CI runs it.
• justfile — set-version now writes package-lock.json as well as package.json.
• package-lock.json — corrected to 0.40.0, closing the drift that already existed.
• .gitignore — .worktrees/, so agent worktrees cannot be swept into the generated set version to <v> commits as broken gitlinks. set-version runs git add ., so this is a real path, not a hypothetical one.

Why snapshot.yml and not release.yml

snapshot.yml already triggers on every branch push and every pull request, so it is the gate every commit passes anyway. release.yml builds from a tag whose commit has already been through it, so a second run there would only duplicate. Placing the step before the build means a failing test stops the job before the image is pushed to ghcr.io, rather than after.

The lockfile gap

_set-version-files rewrote package.json only, so the lockfile kept whatever version npm last wrote into it. main carried 0.38.1 in package-lock.json against 0.40.0 in package.json — two releases of drift.

The recipe now walks both files: .version in each, plus .packages[""].version, which is where npm keeps the root package's own version in lockfileVersion: 2. A json round-trip of package-lock.json reproduces the file byte for byte, so writing it back with the same indent touches nothing but the version lines. The resulting diff is identical to what npm install produces on its own.

Verification

• The unit-test step: the CI run on this pull request is itself the check — it exercises the new step on the workflow's Node 14 runner, the one thing that could not be verified locally (this machine runs Node 24). Confirmed in the run log, not just by a green tick: vue-cli-service test:unit was invoked, three suites PASS, Tests: 28 passed, 28 total.
• The set-version recipe: run against a deliberately bogus version, which moved all three fields across both files; then run against 0.40.0 to land the real value. npm ls still exits 0 against the rewritten lockfile.

Recommended reading order

1. .github/workflows/snapshot.yml — the actual change
2. justfile — the second fix, independent of the first
3. package-lock.json — data, produced by the recipe above
4. agents.md — documentation catching up
5. .gitignore — one line of hygiene

Noticed, not touched

GitHub reports 144 Dependabot findings on main (17 critical, 55 high). That is the Node 14 / Vue CLI 4 stack and a separate piece of work.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JMHRfVM4Mzy1bhEUTc3se9