Make CI check what it claims to check

[GuanzhouSong]

Four fixes, each for something currently unguarded. No behaviour change to the site itself.

1. YAML schema validation has never validated anything

The step ran three commands that all point at paths which do not exist:

npx yaml-ls-check .\articles

Those are Windows separators. On the Ubuntu runner bash treats \a as an escape, so the argument reaching the tool is .articles. Every run to date has printed:

Looking for YAML files to validate at: .articles
Validating 0 YAML files.
Validation complete.        # exit 0

Correcting the paths alone would not have fixed it. yaml-ls-check reads its schema mapping from <root>/.vscode/settings.json, where <root> is the directory you pass — so yaml-ls-check articles looks for articles/.vscode/settings.json, finds nothing, and silently degrades to syntax-only checking. A relative root fails differently: the mapping's ./schema/... entries resolve to /schema/... and the schema cannot be loaded.

Passing the workspace as an absolute path is the form that works. Verified against a deliberately broken file:

articles/content.yml:1:1: Missing property "landing". yaml-schema: Articles Content Configuration
articles/content.yml:1:1: Property notLanding is not allowed.
EXIT=1

Against the tree as it stands it validates 11 files, all passing, so this tightens the check without needing content changes.

The separate npm install yaml-ls-check step is also gone. It pulled in the entire project dependency tree as a side effect and wrote to package.json and package-lock.json inside CI; npx --yes fetches just the tool.

2. Lint never ran anywhere

next build does not lint, and no workflow invoked npm run lint. An ESLint or TypeScript upgrade could go green without its effect on the lint rules ever being exercised — which is exactly the situation the recent ESLint 10 and TypeScript 6 upgrades were in.

3. No job had a timeout

A stalled step ran against GitHub's 6-hour default before failing. Not hypothetical: a Validate YAML files step recently sat over six minutes on work that normally takes 24 seconds, and had to be cancelled by hand. The deployment workflow is the more serious case — its pages concurrency group means one stuck run blocks every deployment queued behind it.

Added: 10 min (YAML), 20 min (build), 30 min (deploy build), 10 min (deploy).

4. Nothing checked where the lockfile resolves from

A package-lock.json generated behind a corporate registry proxy records that proxy's backing-feed URLs rather than registry.npmjs.org. Those hosts are unreachable from public CI and by outside contributors, and the resulting failure surfaces far from its cause. The new step asserts every resolved URL points at the public registry and prints the offenders on failure. Dry-run against current main: passes.

Plus: concurrency

A rebase or force-push now supersedes in-flight PR runs instead of leaving several racing on stale commits — during the recent Dependabot burst four runs were in flight at once. Pushes to main are never cancelled, so every default-branch commit keeps a recorded result.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WWCBtvyCpxc2aqtyLDhDeE