ci: the repo's first .github/ - a verify workflow plus Renovate with the holds encoded

[wormeyman]

Closes #54.

git log --all -- .github was empty, so this is the first .github/ directory in the repository's history. Two files.

.github/workflows/verify.yml

Runs pnpm run verify verbatim - not a re-listing of its three phases as separate steps. verify is the single definition of "this repo is consistent"; splitting it in the workflow would create a second definition free to drift from package.json. It is verify, not the check script, so CI never rewrites files.

• Triggers: pull_request, push to main, plus workflow_dispatch. Concurrency-cancels superseded PR pushes.
• permissions: contents: read and nothing else. The job needs no secrets at all - Cloudflare Pages does not build this repo, so CI here is a check, not a deploy path.
• Third-party actions pinned to full commit SHAs, with the release named in a trailing comment.
• No version: input on pnpm/action-setup. v6+ reads devEngines.packageManager, so the pnpm pin stays in one place instead of being duplicated into YAML. It runs before setup-node because cache: pnpm resolves the store path by invoking pnpm.
• Confirmed rather than assumed: preview:test needs no Docker. The worker tests are pool-workers (workerd installs from npm) and the container tests are node --test against render.mjs. The whole gate runs on a plain runner - see the run linked below.

Deliberately not included: pnpm refs:sync (needs a Factorio binary and ~/GitHub/factorio-data; verify's no-Factorio property is what makes this workflow possible at all), any deploy step, and pnpm vp build - the build reads git history for the stamp and wants a checkout policy of its own. The build gap is real and left as a follow-up rather than silently dropped.

.node-version is now machinery

setup-node reads it via node-version-file, which gives the file its first consumer and flips it from documentation to machinery. CLAUDE.md said the opposite and is corrected here. engines.node stays a permissive floor and is explicitly not what CI runs.

.github/renovate.json5

Renovate rather than Dependabot for the reason #54 gives: the decisions here are holds, and ignore entries cannot express them. Encoded:

rule	why
typescript disabled outright	the row that would otherwise be re-litigated weekly (#48, #52)
pako: 14-day age, note pointing at deflate.ts	legacyHash: true is a pako extension with no zlib-API contract, from a library that flipped that default inside one major
wrangler + @cloudflare/vitest-pool-workers grouped	pool-workers hard-pins an exact wrangler; a split PR cannot resolve
brace-expansion override disabled	2.1.3 is a deliberate maintenance backport, not three majors stale; pnpm audit staying red is not a reason to take 5.x
matchDepTypes: ["engines"] disabled	engines.node is a permissive floor, not a version to keep current
helpers:pinGitHubActionDigests	makes SHA-pinning the rule for any action added later, so pin-vs-tag cannot drift file by file

Three rules carry prBodyNotes, so the reasoning arrives attached to the proposal instead of waiting in CLAUDE.md for someone to remember it.

The pnpm interaction, called out explicitly

This workspace's release-age guard is a pnpm 11 default, not a line in pnpm-workspace.yaml. When pnpm is asked for something fresher than that cooldown it does not refuse - it writes a minimumReleaseAgeExclude: bypass into pnpm-workspace.yaml, which is exactly how vue-tsc@3.3.8 once waived the guard silently. A dependency bot is a machine for manufacturing that situation.

So minimumReleaseAge: "3 days" is declared in the Renovate config, above pnpm's default, so Renovate can never open a PR for a release pnpm would want a bypass for. Declaring it also means a future pnpm changing its own default cannot move this repo's floor silently. If minimumReleaseAgeExclude: ever shows up in a Renovate PR diff, that PR is wrong.

Renovate is inert until the GitHub App is enabled on the repo (https://github.com/apps/renovate) - a one-click repo-owner step I can't do. The config was validated with renovate-config-validator (INFO: Config validated successfully).

Verification

• Baseline pnpm run verify green locally before any of this: 142 test files / 1249 tests, 91s on a loaded machine.
• The workflow's proof is the run on this PR, linked in the thread below - a YAML file that has never executed is not a working CI setup.

Not done here, on purpose

Branch protection on main. #54 raises it and it is the right follow-up, but it is a repository setting, not a file, and "a required check that can be bypassed is most of the cost for none of the benefit" is a decision for the repo owner. Worth doing once this check has a track record.

Interaction with the concurrent PRs

• chore(types): close the .vue type-check gap - adopt vue-tsc in verify #52 (vue-tsc into verify) - adds a phase, so CI's runtime grows with it. Nothing in this workflow needs to change: it invokes pnpm run verify, so whatever chore(types): close the .vue type-check gap - adopt vue-tsc in verify #52 makes verify mean is what CI runs. That is the whole point of not re-listing the phases here.
• deps(worker): bump wrangler 4.115.0 + vitest-pool-workers 0.19.0 #51 (wrangler + pool-workers) - lands in the group this config creates; no conflict.
• perf(export): replace jszip with client-zip - 302 -> 211 kB bundle #55 (client-zip) - no interaction.

🤖 Generated with Claude Code

https://claude.ai/code/session_01F3a2HLJ4beKARi7SPmaM54

[wormeyman]

The workflow has actually run, twice, and the first run earned its keep

Run 1 - https://github.com/wormeyman/FactorioMapWebUI/actions/runs/30512820959 - FAILURE (4m19s)

Every step up to the gate worked first time: checkout, pnpm resolved from devEngines.packageManager with no version: input, setup-node printed Resolved .node-version as 26.5.0, and pnpm install --frozen-lockfile reported Scope: all 3 workspace projects. All three verify phases ran - including preview:test, confirming it needs no Docker.

It failed on exactly one thing, and it was not a bug in this repo:

FAIL test/elevationRenderRequest.spec.ts > runRenderRequest > view 'all' composites all five overlays onto terrain
Error: Test timed out in 5000ms.
    × view 'all' composites all five overlays onto terrain   9826ms
    ✓ view 'all' composites rocks OVER resources             4020ms
Test Files  1 failed | 141 passed | 1 skipped (143)

A 4-core runner is ~3x slower than a dev machine (231s vs 71s for the same suite), which put that test at 9.8s against Vitest's 5s default - and the next one down at 4.0s, i.e. passing by one second. This is the pre-existing too-tight-default problem, surfaced rather than introduced.

Run 2 - https://github.com/wormeyman/FactorioMapWebUI/actions/runs/30514284066 - SUCCESS (4m31s), on 0458303:

pass: All 316 files are correctly formatted (1466ms, 4 threads)
pass: Found no warnings, lint errors, or type errors in 301 files (1.5s, 4 threads)
Test Files  142 passed | 1 skipped (143)
Tests  1246 passed | 6 skipped (1252)
✨ Types at worker-configuration.d.ts are up to date.
Test Files  4 passed (4)        # preview worker
ℹ pass 3                        # preview container

The 6 skips vs 3 locally are the it.skipIf(!oracleAvailable()) tests - correct behaviour, no runner has a Factorio install.

The failing run is worth as much as the passing one: it is the negative control. A real test failure produced a red job with exit 1, so the check gates rather than merely reporting.

How the flaky-timeout risk was handled: raise the default, no retries

vite.config.ts now sets testTimeout: 30_000. Reasoning, in order:

1. The 5s default was already rejected 24 times by hand - 24 individual tests across 10 files carry an explicit }, 120000). Adding a 25th annotation would restate a complaint the codebase has been making for months.
2. The annotation approach fails in a specific, observed way. elevationRenderRequest.spec.ts has 27 tests and zero annotations, which is exactly how a 9.8s test ends up under a 5s cap. It depends on the next author remembering, and the symptom of forgetting reads like a hang rather than a slow machine.
3. 30s is ~3x the slowest measured case. It absorbs runner variance and still fails a genuine hang far inside the job's 15-minute cap. The existing 120000 annotations still win wherever they are set - this is a floor, not a ceiling.
4. No retry. These tests compare pixels against captured game output, so nothing here is nondeterministic. A retry could only ever hide a real regression, so raising a timeout is honest where a retry would not be.

Two local findings, both pre-existing, neither caused by this branch

• test/oracle/oracle.spaceAge.spec.ts fails locally right now, timing out against its own explicit 30_000. It is it.skipIf(!oracleAvailable()), so it only runs where Factorio is installed and is skipped in CI. Verified pre-existing: stashed every change on this branch and ran it on the pristine tree - identical failure. A live Factorio process is currently running on the machine, which is the likely contention.
• Heavy render tests time out locally under load in a way no timeout value fixes. During this work the machine hit load average 14 (an lldb at 102% CPU plus a running game), and previewAgreement's Nauvis case took 223s against its own 120000 annotation - 6-15x its CI duration. That is a machine-contention phenomenon, not a suite defect, and deliberately not chased with a higher default: the same commit passes all 1246 tests on a runner.

Local vp check (exit 0) and pnpm run preview:test (exit 0) are green here; the authoritative full-gate evidence is run 2 above.

Follow-ups deliberately left out of this PR

• Branch protection on main requiring the verify check. Raised in No CI and no dependency automation: this repo has never had a .github directory #54, and the right next step now that the check has a track record - but it is a repository setting rather than a file, and No CI and no dependency automation: this repo has never had a .github directory #54's own point stands: a required check that can be bypassed is most of the cost for none of the benefit. Owner's call.
• Enabling the Renovate GitHub App. The config is committed and validated (INFO: Config validated successfully), but Renovate does nothing until the app is installed on the repo.
• pnpm vp build in CI. Not part of verify, and the build stamp reads git history, so it wants a checkout policy of its own.