> [!IMPORTANT] > This project is connected to [Lovable](https://lovable.dev). Avoid rewriting > published git history — force pushing, or rebasing/amending/squashing commits > that are already pushed — as it rewrites history on Lovable's side and the > user will likely lose their project history. > > Commits you push to the connected branch sync back to Lovable and show up in > the editor, so keep the branch in a working state. # Architecture decisions - Admin area (`/admin`) is a shared-password gate, not user accounts: password lives in the server-only `ADMIN_PASSWORD` env var, unlocked state persists in an encrypted `useSession` cookie (`SESSION_SECRET`), and every admin server function re-checks the session server-side. - All public reads (books, events, videos, testimonials) go through `createServerFn` handlers using a server publishable client with the `apikey` fetch shim — never the browser client in loaders (preview proxy 401s). - Newsletter and contact-form writes also run through server functions (`src/lib/forms.functions.ts`) for the same reason; the tables deliberately have no anon INSERT policy, so all writes are validated server-side. - Admin CRUD uses `supabaseAdmin` (service role) loaded inside handlers only, after the session check — it bypasses RLS. - Brand imagery lives as Lovable Assets pointers in `src/assets/*.asset.json`; contact details are centralized in `src/lib/site.ts` (placeholders until Eva supplies real ones).