.gitignore matched .env and .env.*.local but not the copies people and tools
actually leave behind — .env.bak-20260911, .env.save, .env.orig. Those carry
the identical secrets and showed up as untracked, one `git add .` away from
being committed. Patterns verified with git check-ignore.
The .claude/settings.json entry stops Claude Code prompting for confirmation
on every docker/docker compose invocation during local debugging.
Co-Authored-By: claude-flow <ruv@ruv.net>
A dev server started from apps/web never loads the monorepo root .env, so it
came up with no AUTH_SECRET/NEXTAUTH_SECRET at all. getRuntimeEnvViolations()
returned early for every non-production NODE_ENV, so nothing complained —
Auth.js then answered *every* /api/auth/* route with an opaque 500 ("problem
with the server configuration"). The login form swallowed that silently and
bounced the user back to itself with no error, pointing nowhere near the cause.
Two checks now run regardless of NODE_ENV:
- An auth secret must be present. Its absence is fatal everywhere, because
without it Auth.js cannot sign session JWTs and nothing about auth works.
The production-only strength rules (length, entropy, known placeholders)
are unchanged — a weak secret still only fails production.
- E2E_TEST_MODE must not be "true" when the deployment URL is https. An https
URL means the instance is reachable off the machine whatever NODE_ENV says,
and that flag disables login rate limiting and the concurrent-session
registry. The production case stays with getDevBypassViolations().
assertSecureRuntimeEnv() can now fire outside production, so its message drops
the inaccurate "production".
Co-Authored-By: claude-flow <ruv@ruv.net>
Hartmutandclaude-flow