Summary

Ran npx npm-check-updates -u to bump every constraint in package.json to the latest published version, then npm install.

No major version bumps were available. Both direct dependencies are already on major 8 and the latest releases upstream are still major 8 (pg@8.22.0, ws@8.21.1). So this is "latest of everything", not a major-version migration — worth stating plainly since the branch name implies otherwise.

Upgrades

Transitive, via pg: pg-protocol 1.13.0 → 1.15.0, pg-pool 3.13.0 → 3.14.0, pg-connection-string 2.12.0 → 2.14.0, pg-cloudflare 1.3.0 → 1.4.0.

Dependabot alerts

Both open alerts are against ws (the medium is not a separate package):

ws@8.21.1 clears both. Open alerts before: 2 (1 high, 1 medium) → after: 0 expected.

This also supersedes the existing dependabot/npm_and_yarn/ws-8.21.0 branch, which can be closed.

Code changes required

None. The only upgraded-package APIs this repo touches are WebSocketServer from ws and Pool / Pool.query from pg (both in server.js); neither changed. npm audit fix was not needed and was not run — the plain upgrade already brought audit to zero.

Verification

Every command below was actually run locally on Node v24.13.0 / npm 11.10.1.

There is no build script and no lint script or lint config in this repo, so those steps were not applicable rather than skipped.

Extra runtime verification

The committed test suite only covers translate.js and registry-panel.js — it never exercises ws or pg, so a green npm test alone would not prove the upgraded packages work. I ran an additional throwaway smoke test (not committed) against a live server:

• ws: client connects to /ws, receives the history frame, and receives a broadcast of an event POSTed to /api/events — pass
• pg: against a real postgres:16-alpine container with the schema server.js queries, /api/users returned [{"id":"key-luis"}] and /api/registry returned the expected humans/agents payload, both HTTP 200 — pass
• pg error path with no DB reachable: /api/users → 200 [], /api/registry → 502 registry unavailable — pass
• static serving / → 200 — pass

7/7 smoke checks passed. Temporary containers were removed afterward.

Pinned back / skipped / left broken

Nothing. No package was pinned back, no test was disabled, and nothing is left failing.

Node 24 standardization (commit 2dc6e46)

Appended after the dependency upgrade above, per the org-wide decision to standardize on Node 24. This is a separate commit on the same branch, not an amend.

Changes

package-lock.json is untouched — adding engines does not alter the dependency tree.

Checked, no change needed

• .github/workflows/container-image.yml — contains no setup-node step and no Node version pin. It only runs docker/build-push-action against ./Dockerfile, so CI picks up Node 24 automatically from the base image. Nothing to edit.
• Repo-wide grep for stale Node references (node:NN, node_version, setup-node, nodejs, engines) across all tracked files found only the Dockerfile line. There is no README, no docs directory, and no compose file in this repo.

Verification

Every command below was actually run. Host: Node v24.13.0, Docker 29.6.1.

Runtime smoke against the running 24-alpine container

The committed tests only cover translate.js and registry-panel.js and never touch ws or pg, so a green npm test does not prove the runtime works. Checks run against the live Node 24 container:

• /health → {"status":"ok"}, HTTP 200 — pass
• ws: client upgrade on /ws succeeded and received a broadcast frame (186 bytes) — pass
• POST /api/events → 200, then GET /events returned the ingested event — pass
• GET / static serving → 200 (25,454 bytes) — pass
• Container stayed up throughout; logs show only Dashboard listening on port 3000, no crashes or warnings

pg and the node:22 control

No Postgres was running in this environment, so pg was exercised only on its error path: /api/users → 200 [] and /api/registry → 502 registry unavailable.

To confirm those responses are a missing-database artifact and not a Node 24 regression, I built the same image on node:22-alpine as a control and hit the same endpoints. Results were byte-identical across both runtimes:

So pg was not verified against a real database on Node 24 in this pass — that gap is stated plainly rather than glossed over. The earlier upgrade verification in this PR did cover pg against a real postgres:16-alpine, and pg is pure JS with no native build step, so the risk is low but not zero.

All containers and images created for this verification were removed afterward.

Pinned back / skipped / left broken

Nothing. No version was reverted, no test disabled, --no-verify was not used, and nothing is left failing.