Findings No. 43
A missing session is an anonymous request, not a locked account
A lockout check treated user === null as a locked account and redirected keyed API calls to sign-in, breaking two production sites that consume Replicator's CMS API.
Some requests carry no session on purpose. Account-status checks that treat "no session" as "bad session" will lock out every one of them.
Several of Replicator's API surfaces (the public blog API, chat-log ingest, MCP) authenticate each request with their own credentials and never have a Better Auth session. A lockout refactor in src/hooks.server.ts treated user === null as a locked account and redirected those requests to /sign-in with a 302. Callers expecting JSON received sign-in HTML and failed to parse it. That took down the CMS-backed pages on lightningjar.com, this site, and the blog on securelogix.com, both of which read their content from Replicator's API.
The fix gates the whole check on a session existing: if (sessionData && (!userIsActive || userIsArchived)). A missing session never reaches the account-status logic. tests/routes/hooks-anonymous-api.test.ts pins the behaviour so a future refactor cannot bring it back.
The general rule: in hooks and middleware, give "no session" its own branch. It is a normal state for API traffic, not a falsy version of a deactivated user.
Receipt: Replicator v3.256.3, 2026-08-10 (src/hooks.server.ts, tests/routes/hooks-anonymous-api.test.ts; FINDINGS.md, "Auth and sessions").