Docs: church installs under /var/www/sites/<church>/<product>

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/ROADMAP-v3.md

@@ -482,18 +482,23 @@ picks the tags up per product (§5).
 per product, each at that product's own tag:
 
 ```
-/opt/crosscode/
-  tools/                  the crosscode script (a checkout of main, updated before every run)
-  churches/hopefamily/
+/var/www/sites/
+  hopefamily/
     church.env            slug, products, domains, ports, PM2 names, database names, folders
     accounts/             crosscode-platform at accounts@1.0.0
     events/               crosscode-platform at events@3.1.0
     website/              crosscode-platform at website@1.2.0
+  gracechurch/
+    …
+/opt/crosscode/tools/     the crosscode script (a checkout of main, updated before every run)
 ```
 
-A product's folder can live elsewhere (`church.env` says where), so existing installs such as
-`/opt/hope-events` don't have to move, and their PM2 names, nginx names and database names stay
-as they are. Each checkout installs and builds only its own app (`npm ci -w apps/website`, its
+Every church's installs live under **`/var/www/sites/<church>/`** (decided 2026-11-04; the
+existing Events installs are in `/var/www` today and move there). The script finds churches by
+their `church.env`, so `--every-church` is every folder in `/var/www/sites` that has one. A
+product's folder can be somewhere else if `church.env` says so, but the standard layout is the
+default for `install` and `adopt`. PM2 names, nginx names and database names keep what an install
+already has. Each checkout installs and builds only its own app (`npm ci -w apps/website`, its
 own migrations), so a Website install never builds Events.
 
 **The script** (run as root or the app user; `crosscode help` lists everything):
@@ -508,7 +513,7 @@ own migrations), so a Website install never builds Events.
 | `crosscode status [<church>]` | Each product's version, latest release, health (from `/health`) and last backup |
 | `crosscode install <church> --products events,website --domain … ` | A new church (from today's `install.sh`): Accounts always, plus the products named; databases, `.env` files, PM2, nginx and certificates; prints the DNS records needed |
 | `crosscode add <church> app` | Adds a product to an existing church |
-| `crosscode adopt <church> --events-dir /opt/hope-events` | Once per existing Cross Events install: moves it onto the monorepo (below) |
+| `crosscode adopt <church> --events-dir /var/www/<old folder>` | Once per existing Cross Events install: moves it onto the monorepo and into `/var/www/sites/<church>/events` (below) |
 
 Before Accounts exists (until phase 3), "always Accounts" is skipped for churches that don't have
 it yet.
@@ -528,15 +533,28 @@ it yet.
    reached.
 
 **Moving existing Cross Events installs (Events 2.2.0, `crosscode adopt`).** Once per server
-install, run by Joshua. It writes `church.env` (pointing at the existing folder), changes the
-checkout's remote to `crosscode-platform`, moves the install's own files to the new paths
-(`backend/.env` → `apps/events/backend/.env`, likewise the frontend `.env`,
-`backend/public/uploads/`, `backend/backups/`, `backend/data/*.json`, and `ecosystem.config.js`
-with its `cwd` paths updated), checks out `events@2.2.0`, builds and reloads. The folder, PM2
-names, nginx config (it only proxies to ports), database and its name stay the same. If anything
-fails it moves the files back and returns to the `hope-events` remote and the version it was on.
+install, run by Joshua. It:
+
+1. Moves the install's folder from `/var/www/<old folder>` to `/var/www/sites/<church>/events`
+   (skipped if it's already there, e.g. moved by hand) and writes `church.env`.
+2. Changes the checkout's remote to `crosscode-platform` and moves the install's own files to
+   the new paths: `backend/.env` → `apps/events/backend/.env`, likewise the frontend `.env`,
+   `backend/public/uploads/`, `backend/backups/`, `backend/data/*.json`, and
+   `ecosystem.config.js` with its `cwd` paths updated.
+3. Checks out `events@2.2.0`, builds, and **re-registers the PM2 processes** under their existing
+   names from the new folder (`pm2 delete` + `pm2 start` + `pm2 save`: PM2 remembers the folder a
+   process was started from, so a reload isn't enough after a move).
+
+The PM2 names, nginx config (it only proxies to ports, so it doesn't change when the folder
+moves), database and its name stay the same. If anything fails it moves everything back, returns
+to the `hope-events` remote and the version it was on, and starts PM2 from the old folder again.
 Installs that haven't moved yet keep working with `deploy.sh` on the archived repo.
 
+**Moving a folder by hand before 2.2.0** works too: move it into `/var/www/sites/<church>/events`,
+then `pm2 delete` its two processes, `pm2 start ecosystem.config.js` from the new folder and
+`pm2 save`. `deploy.sh` works from wherever the install is, and `adopt` later sees it's already in
+place.
+
 ---
 
 ## 9. Build order
@@ -748,7 +766,7 @@ ranking.
 |---|----------|----------|
 | 21 | Repos | **Cross Events moves into `crosscode-platform`** (`apps/events`, Events 2.2.0, history kept); `hope-events` is archived. The Hub stays in its own repo (own server, never installed for a church) |
 | 22 | Contracts for the Hub | A packed release **committed to the Hub's repo** (`file:vendor/…`), not Gitea's package registry, so no deploy depends on a registry or a token (§2) |
-| 23 | Deploying | **One `crosscode` script** for every product: `crosscode deploy <church> [events] [website] [app]` always updates Accounts and then the products named, in a fixed order, each rolled back on its own if it fails. Still git checkouts of tags, still run by Joshua; the Hub never deploys (§8) |
+| 23 | Deploying | **One `crosscode` script** for every product, with every church under `/var/www/sites/<church>/<product>`: `crosscode deploy <church> [events] [website] [app]` always updates Accounts and then the products named, in a fixed order, each rolled back on its own if it fails. Still git checkouts of tags, still run by Joshua; the Hub never deploys (§8) |
 | 24 | Product requirements | A release can require a minimum version of a sibling (`— requires accounts 1.2.0` in `WHATS-NEW.md`). The Hub **disables Request update** until it's met, and the script refuses to deploy without it (§5, §8) |
 
 ## Still open