pushpakalisted

# Pushpaka — The Flying Chariot (Vercel Frontend Deploys) Pushpaka Vimana flew its passenger wherever intended, instantly and without harm. A frontend deploy should feel the same: every push travels, only `main` lands in production, and any landing can be undone in one motion. ## Environments - Three Vercel environments, three configurations: Production (`main`), Preview (every other branch/PR), Development (`vercel dev`/local). Never share backing services between Production and Preview. - Previews point at a **staging** FastAPI service and a **staging** Supabase project — a preview that writes to production data is an incident, not a convenience (see `dhanvantari`). - Promotion path is git: merge to `main` deploys production. No `vercel --prod` from laptops once the git integration exists; the deploy history should equal the commit history. ## Environment variables - Set per environment in the Vercel dashboard/CLI, mirrored in a committed `.env.example` with every key name and a comment — values live in Vercel, names live in the repo (see `kubera`). - Anything prefixed `VITE_`/`NEXT_PUBLIC_` is compiled into the public bundle. The Supabase URL and anon key belong there; nothing else does. Adding a `NEXT_PUBLIC_` var is a security review question, not a naming choice. - The frontend holds no provider API keys, no service-role key, under any prefix — AI calls go through FastAPI (see `vayu`). - Env var changes require a redeploy to take effect — build-time inlining means