# REF-TASK-009 — Split authentication HTTP registration by concern

**Status:** Implemented  
**Kind:** Mechanical production refactor  
**Depends on:** REF-TASK-006

## Problem and evidence

`backend/src/auth-http.ts` is about 780 lines and registers CSRF, login/logout/session reads,
profile/password mutation, password recovery, developer email-test, and Mocking Bird routes while
also containing throttling and session-save helpers. These route families have distinct application
collaborators and deployment rules but are exposed through one broad `AuthHttpOptions` surface.

## Proposed change

Keep one `registerAuthHttp` composition entry point for `app.ts`, but delegate to internal
registrars for session, account, recovery, and developer-email concerns. Place route-specific
schemas and helpers beside their registrar; retain shared authentication/session helpers in a
narrowly named auth HTTP support module. Narrow each registrar's collaborator type to what it
consumes.

## Constraints and sequence

Move one route family at a time without changing paths, hooks, registration order, cookies, headers,
statuses, bodies, rate-limit keys, timing padding, or diagnostics. Keep security-sensitive helpers
shared only where semantics are identical. Do not split session policy into independently divergent
implementations or expose internal registrars as package API.

## Validation

After each move run the matching REF-TASK-006 suite. Then run all backend fast tests, auth real-
PostgreSQL integration tests, OpenAPI contract tests, backend typecheck/build/coverage, relevant
auth and recovery E2E specs, and `pnpm quality`.

## Guidance / ADR

REF-TASK-018 should document registrar composition and shared HTTP security ownership. No ADR
because the architectural boundary remains the same.