CI red on main: build requires env vars (env.ts) + flaky rate-limit test

CI is red on main: build needs env vars + a flaky rate-limit test

Type: CI / infrastructure (not tied to any single feature PR)

Summary

The Core CI Pipeline and CodeQL workflows are currently failing on main itself — every recent merge run (e.g. #1372/#1374, #1369/#1371, #1367/#1369) is red. Because these are pre-existing failures, every contributor PR inherits a red ❌ status that has nothing to do with the change under review, which makes it hard to tell a genuinely broken PR from a healthy one.

There are two independent root causes.

1. npm run build throws on missing env vars in CI

src/lib/env.ts validates the environment at module import time and throws unless NODE_ENV=test/VITEST:

export const env = isTest ? (process.env as unknown as Env) : validateEnv();

validateEnv() requires DATABASE_URL, DATABASE_POOL_URL, GROQ_API_KEY, GITHUB_*, AUTH_SECRET, AUTH_URL, NEXT_PUBLIC_APP_URL. The quality-gate job in .github/workflows/ci.yml runs npm run build with no env: block, so Next.js fails while collecting page data for routes that import env (e.g. /api/webhooks/github, /api/findings/[id]/explain-stream):

Error: Invalid environment variables:
  DATABASE_URL: expected string, received undefined
  ... (GROQ_API_KEY, GITHUB_*, AUTH_SECRET, AUTH_URL, NEXT_PUBLIC_APP_URL)
  at src/lib/env.ts:63

The same wall fails the CodeQL autobuild (exits 1 at ~42s with no code-level findings).

Options to fix (any one):

• Add a non-secret build-time env: block to the quality-gate job (and CodeQL) with placeholder values sufficient to pass schema validation — e.g. DATABASE_URL: "postgresql://user:pass@localhost:5432/db", dummy GITHUB_*/AUTH_*, NEXT_PUBLIC_APP_URL: "http://localhost:9002". These are format-only and safe to hardcode.
• Or introduce a SKIP_ENV_VALIDATION escape hatch honoured in src/lib/env.ts and set it for the build/CodeQL steps (common Next.js pattern), so the build doesn't require a live-looking environment.
• Or move the strict validateEnv() call out of module top-level for build/collect-time and validate lazily at request time.

2. Flaky rate-limit.test.ts — "Redis timeout"

The Unit Tests job intermittently fails at src/lib/rate-limit.test.ts in "trips the circuit breaker and fast-fails after threshold" with Error: Redis timeout. It's timing/Redis-dependent rather than deterministic (the full suite passes locally). It should be made hermetic — inject a fake clock / mock the Redis client and its timeout instead of relying on real timing — or quarantined with a tracking note until it can be stabilised.

Impact

Until these are addressed, contributor PRs show failing required checks for reasons outside their control, and main cannot go green. Neither is caused by application code in feature PRs.

Not in scope here

The Vercel "Authorization required to deploy" status on fork PRs is expected GitHub/Vercel behaviour (a maintainer approves the deploy) and needs no code change.