ci(deploy): trigger backend deploys on push to main, not develop

.github/workflows/deploy-backend.yml

@@ -2,7 +2,9 @@ name: Deploy backend
 
 on:
   push:
-    branches: [develop]
+    # main is the release branch (see README.md#deployment); develop is
+    # where day-to-day work happens and doesn't deploy on its own.
+    branches: [main]
     paths:
       - 'backend/**'
       - 'go.work'

README.md

@@ -12,7 +12,7 @@ A full-stack invoicing app: create, edit, and track invoices from draft through
 
 ## 🥧 Deployment
 
-The frontend is on Vercel. The API and its database run on a **Raspberry Pi 5** in my home, reachable at [invoices-api.tyrellcurry.io](https://invoices-api.tyrellcurry.io) behind [Caddy](https://caddyserver.com), which handles TLS automatically. Code ships by pushing to `develop`, then a GitHub Actions workflow cross-compiles the Go binary for `linux/arm64`, it then joins the Pi's Tailscale network, and deploys it over SSH. No cloud compute involved on the backend side at all.
+The frontend is on Vercel. The API and its database run on a **Raspberry Pi 5** in my home, reachable at [invoices-api.tyrellcurry.io](https://invoices-api.tyrellcurry.io) behind [Caddy](https://caddyserver.com), which handles TLS automatically. Code ships by merging into `main` (day-to-day work happens on `develop`; a PR from `develop` into `main` is a release), then a GitHub Actions workflow cross-compiles the Go binary for `linux/arm64`, it then joins the Pi's Tailscale network, and deploys it over SSH. No cloud compute involved on the backend side at all.
 
 Google sign-in is backed by that same Postgres instance, not just a token the frontend trusts blindly. The backend exchanges Google's auth code, verifies the ID token, and upserts a `users` row keyed by the account's stable Google subject ID. Signing in issues a session, also a Postgres row, whose bearer token the frontend holds; a guest ("continue without an account") gets the identical session mechanism, just without a user attached. Every invoice query is scoped to that session's owner at the SQL layer, so a guest and a Google account can never see each other's data, and signing in with Google on a second device picks up the same invoices because they're tied to the account, not the browser.
 

backend/.gitignore

@@ -2,3 +2,4 @@
 # One-time Pi setup script. Already run on the Pi; not something git pull
 # needs to keep delivering updates to, so it's untracked going forward.
 deploy/bootstrap.sh
+.vercel

backend/README.md

@@ -74,4 +74,4 @@ New schema changes get a new numbered pair (`NNNNNN_name.up.sql` / `.down.sql`).
 
 ## Deployment
 
-Live at `https://invoices-api.tyrellcurry.io`, self-hosted on a Raspberry Pi: Postgres in a dedicated Docker container, the binary as a systemd service, Caddy handling HTTPS in front. `deploy/` has the actual tooling, a one-time setup script, the systemd unit, the compose file, and a Caddy config snippet, deployed on every push to `develop` via a GitHub Actions workflow (`.github/workflows/deploy-backend.yml`) that builds for `linux/arm64` and deploys over Tailscale + SSH. See the root [README](../README.md#deployment) for the full picture, including the frontend's side of it.
+Live at `https://invoices-api.tyrellcurry.io`, self-hosted on a Raspberry Pi: Postgres in a dedicated Docker container, the binary as a systemd service, Caddy handling HTTPS in front. `deploy/` has the actual tooling, a one-time setup script, the systemd unit, the compose file, and a Caddy config snippet, deployed on every push to `main` (the release branch, see the root README) via a GitHub Actions workflow (`.github/workflows/deploy-backend.yml`) that builds for `linux/arm64` and deploys over Tailscale + SSH. See the root [README](../README.md#deployment) for the full picture, including the frontend's side of it.