Out of Scope

The backend is intentionally narrow. It is a worker that the frontend calls; it is not a general-purpose application server. The list below is the explicit boundary.

Not in the Backend

• Auth. User accounts, sessions, OAuth, magic links, password resets. All in Supabase Auth, surfaced through the frontend.
• Library, wishlist, purchases. Owned by the frontend (Supabase tables + Stripe for payments).
• Book files, covers, avatars, category images. Stored in Supabase Storage. The frontend uploads them and passes signed URLs to the backend for book files only.
• Comments, ratings, notifications. All in the frontend.
• Admin panel. All in the frontend.
• The chat UI itself. The frontend renders messages, manages input, and handles SSE.
• Stripe webhooks. The frontend handles Stripe; the backend never talks to Stripe.
• Session lifecycle. The frontend creates, lists, and deletes chat sessions. The backend reads them.

Why the Boundary Is Where It Is

The frontend already owns auth, ownership checks, and the system of record for user-facing data. Re-implementing any of that in the backend would mean duplicating the trust boundary. Keeping the backend narrow means:

• The trust surface is small. The backend trusts only user_id and book_id from the frontend.
• The deployment surface is small. Two business endpoints, plus /health and /metrics.
• The blast radius of a backend bug is small. The worst failure is "chat does not work"; user accounts and library are untouched.

What "Trusts the Frontend" Means in Practice

The backend does not verify Supabase JWTs. It accepts whatever user_id and book_id the request body says. This is safe because:

• The backend is not exposed to the public internet. It sits behind the frontend and a reverse proxy (Traefik).
• The frontend enforces auth on every request that reaches the backend. Banned users are filtered before they reach the backend at all.
• The backend's only data writes (characters, messages) are scoped by book_id and session_id, both of which the frontend controls.

If the backend ever needs to be exposed more directly, the trust model will need to be revisited. For the current architecture, the narrow contract is the right choice.