ci(build): run pnpm vp build - verify never did (#61)

[wormeyman]

Closes #61.

pnpm run verify is vp check && pnpm run check:vue && vp test && pnpm run preview:test. None of those build. A change that passes all four and breaks the production build reaches main unnoticed until someone deploys - possibly days later, and it lands on whoever is deploying rather than whoever broke it. The whole argument for #54 was that a gate nobody runs until deploy time is not a gate.

A separate job, not a phase in verify

deploy already runs pnpm build immediately after pnpm run verify, so folding the build into verify would build twice on every deploy and slow the local gate people run by hand. As a separate job it also runs in parallel with the tests rather than after them, so wall-clock is unchanged.

This adds a second status check named build. It is advisory until added to ruleset EJ - see "follow-up" below.

The shallow checkout is correct, and I measured it

#61 was filed - by me - believing the build stamp needed deeper history, and asked for fetch-depth to be chosen carefully. It does not need any. scripts/buildStamp.ts runs exactly three git commands:

git rev-parse HEAD
git rev-parse --short HEAD
git status --porcelain

None read history, so the default fetch-depth: 1 is sufficient. The workflow comment from #56 saying "the build stamp reads git history" was imprecise - it reads git state. That is now recorded in the job itself, because the next person will make the same assumption I did.

Noted in the job and deliberately not fixed: on a pull_request event, checkout lands on the merge commit, so the stamp this job produces is a synthetic SHA that exists nowhere in the repo. Harmless while CI never ships its artifact - deploy:app builds locally and uploads that. If a CI build ever becomes the thing that deploys, this needs revisiting.

Zero-warning enforcement deliberately NOT added

#61 floated it; both routes were checked and rejected, and the reasoning is in the job so it is not re-derived later:

• Grep the output for /warn/i. vp build has no --fail-on-warn (verified against vp 0.2.6 --help). And this repo has already been burned grepping build output: a version-string grep returned zero because the minifier had rewritten the string into a numeric array, so a shipped fix looked missing. A false pass is worse than no check.
• A build.rollupOptions.onLog hook that throws on warn. Sturdy, but it hard-fails every local build the first time a dependency emits one benign warning - and dependency-sourced warnings are precisely what has happened here (zlib-asm needed two suppressions before deps(codec): replace zlib-asm with pako at legacyHash:true (refutes #40) #46 removed it). The value CLAUDE.md describes is in reading a new warning, not blocking on it.

So warnings stay visible in this job's log and unenforced. If that changes, onLog is the route - not a grep.

Verification

Locally on this branch: vp check clean (316 formatted, 301 no warnings/lint/type errors), and pnpm vp build succeeds in 494ms with zero warnings, emitting index-*.js at 211.44 kB / 73.11 kB gzip. CI runs both jobs on this PR.

Follow-up, needs a ruleset edit rather than a file

build is not a required check yet, so a red build can still merge. Adding it to ruleset EJ is a repository setting, and doing it before this merges would block this very PR on a check that does not exist on main yet. Correct order: merge this, confirm build runs green on main, then add it to the ruleset. Happy to do that as the last step.

🤖 Generated with Claude Code

https://claude.ai/code/session_01F3a2HLJ4beKARi7SPmaM54