# Operating Oncall

README.md opens with the root command sequence. `describe` is authoritative for parser flags; `check` is structural, not a hosted health proof. `rer` provides the pinned Node and pnpm. SQLite/D1 is the relational store; .wrangler/state is canonical local data, .dev.vars contains private settings, .rer/local is local key custody. Never commit these.

The protected API retains held password accounts and adds Base email/dev identity for new installations. On local and hosted apps, the configured owner uses native email links. Members created by an administrator use their installation-local workspace name and password at `/signin/local`; Oncall sends no invitations. Anonymous first-admin bootstrap at `/api/setup` remains loopback-only. All private HTTP mutations require same-origin requests and current member/session authority. Ingress credentials are scoped to services and grant no private read access. /setup and /signin use Base native handlers; no private Start function exists.

Export/import use Base portability for the supported entire installation, including move-in records and journal. Base sessions, Oncall sessions and dev credentials are excluded; imported pending historical timers must remain paused and cannot resume because delivery is OFF. Restore requires an empty destination; use the separate protected checkpoint API for explicitly reviewed replacement. Retained third-party originals may contain personal data: keep archives private.

Release 1 hosts incident coordination alongside the team's existing pager, with paging OFF and no independent standby prerequisite (owner direction, 16 October 2026). Release 2 paging and independent standby are not built. Keep existing pager routes and notification settings authoritative; hosted coordination does not add delivery channels, dual intake, configuration synchronization or external role-move announcements.

Use the published `rer` 0.2.27 pin. Prepare the owner with a real mailbox using `rer setup --owner-email you@example.com`. `rer deploy --dry-run` builds and validates locally without provider requests. For `rer deploy`, supply `CLOUDFLARE_ACCOUNT_ID` and `CLOUDFLARE_API_TOKEN` privately for the intended account. The deployment declaration selects SendGrid and requires `SENDGRID_API_KEY` plus `MAIL_FROM` from a verified sender for hosted email-link sign-in. The command deploys the app and D1 migrations, checks the deployed identity, automatically claims the configured owner and retires the one-time setup token. The owner signs in at the HTTPS app address using the emailed link; local dev keys and owner-entry URLs never grant hosted access. See [Install and run](docs/install.md#host-for-your-team).

Hosted D1 and local `.wrangler/state` are separate stores. Deploy does not upload local records; the maintained export/import commands target local state. Redeploy with the same deployment record and Cloudflare credentials to retain the hosted owner and records. Keep the private `.rer/deploy/` deployment record: removal uses it to identify only the resources this installation created. `rer deploy --remove --yes` uses the same credentials, deletes recorded resources and reads each back as absent. It keeps your local checkout and data. A dry run, local test or structural check is not evidence of remote removal or mail delivery.

If coordination is unavailable, continue through the existing pager and your team's incident communication process. No recovery or standby delivery guarantee is made. Paging acceptance belongs to a later release with independent standby, real-phone and provider-failure drills.