[yusuf-gundogdu]

What

src/lib/auth.ts no longer memoizes the JWT secret: signJWT and verifyJWT call
getJwtSecret() directly and the module-level _jwtSecret cache is gone, so there is no state left
to reset and no resetJwtSecretCache seam.

tests/unit/lib/auth-jwt-config.test.ts runs the successful dev-fallback case first and gains a
secret-rotation case. The file is now a regression test for the memo instead of a victim of it:
reintroduce a cache in auth.ts and these cases fail immediately, in any process layout.

Why

The original diagnosis on this branch was right and the defect is real. getJwtSecret() reads the
environment on every call, but auth.ts wrapped it in a module-level memo that only ever holds a
successful read. Once anything in the process has signed a token, the cached key answers and the
guard is never reached — so "JWT_SECRET missing in production" and "JWT_SECRET shorter than 32
characters" cannot be observed.

Reproduced on an otherwise untouched tree, with only the file's own success case moved to the top:

(fail) auth JWT_SECRET config guard > throws AuthConfigError when JWT_SECRET is missing in production
(fail) auth JWT_SECRET config guard > throws AuthConfigError when JWT_SECRET is shorter than 32 characters
 1 pass, 2 fail

Those are exactly the two failures reported here. Whether they surface under bun run test depends
on file load order and on bun re-evaluating auth.ts when this file mocks next/headers, which is
why the same command is green on one machine and red on another. A guard whose observability rests
on that is broken either way — and a cache that can hide a misconfiguration is not only a test
problem.

Why the memo goes rather than gaining a seam

The first revision exported resetJwtSecretCache(). That follows a real convention here
(resetSecurityConfigWarnings, resetAgentCapabilityCache, and resetCookieSecurityWarning in
this very file), but @/lib/auth is not comparable to those modules in one respect: 36 test files
replace it wholesale with an object literal (tests/api/auth/login.test.ts:10), against 1 for the
cited precedents. None of them carries the new name, so a load order that puts one first turns this
file's await import("@/lib/auth") into a link-time Export named 'resetJwtSecretCache' not found
— the failure mode the file's own header comment already documents for next/headers. That trades
an order-dependent assertion failure for an order-dependent link failure with a wider trigger.

Removing the state avoids both:

• auth-env.ts already documents the reader as stateless — "reads the environment on every call".
• oidc.ts, drive-token.ts and storage/encryption.ts all call it fresh; the memo was the odd one
  out (proxy.ts keeps its own, in a separate runtime).
• The cost is one TextEncoder pass per sign, against the HMAC that immediately follows.
• Laziness is unchanged: a misconfigured secret still throws AuthConfigError at sign/verify time,
  never at module load, so the login route keeps turning it into a clear 503.
• A rotated JWT_SECRET now takes effect without a process restart — pinned by the new fourth case.

src/lib/auth-compare.ts referenced the removed memo by line number; its comment now points at
proxy.ts and records why the key there is load-bearing (it is generated, not read, so re-deriving
it per call would make two digests of the same input differ).

Verification

All six gates locally: format, lint (0 errors), typecheck, knip, test, build.
bun run test — the command in the original report — is green end to end: 7070 core, then
All 30 groups passed!. Coverage holds the gate: check-coverage: OK — 36004/36004 lines (100.00%).

Out of scope

The four scripts/lib/pack-standalone-zip.sh failures in the original report are a missing local
7z, as noted there — unrelated to this change and untouched.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud