docs: add officer continuity and secure commerce guides

.env.example

@@ -0,0 +1,20 @@
+# Public React build configuration. REACT_APP_* values are embedded in the
+# browser bundle and MUST NOT contain secrets.
+
+# The current FirebaseResources implementation contains the production web
+# config directly; these names document the intended environment-specific
+# migration and match existing local files. Firebase web config is public, but
+# every environment still needs correct Auth, Rules, and App Check controls.
+REACT_APP_FIREBASE_API_KEY=
+REACT_APP_FIREBASE_AUTH_DOMAIN=
+REACT_APP_FIREBASE_PROJECT_ID=
+REACT_APP_FIREBASE_STORAGE_BUCKET=
+REACT_APP_FIREBASE_MESSAGING_SENDER_ID=
+REACT_APP_FIREBASE_APP_ID=
+REACT_APP_FIREBASE_MEASUREMENT_ID=
+
+# Public provider/application identifiers.
+REACT_APP_RECAPTCHA_SITE_KEY=
+REACT_APP_SENTRY_DSN=
+REACT_APP_SENTRY_ENV=development
+REACT_APP_STRAVA_CLIENT_ID=

.github/ISSUE_TEMPLATE/officer-change-request.md

@@ -0,0 +1,43 @@
+---
+name: Officer website change request
+about: Request one clear website change without editing code or sharing private data
+title: "[Officer change] "
+labels: documentation
+assignees: ""
+---
+
+## Desired result
+
+<!-- In one sentence, what should a visitor or officer see or be able to do? -->
+
+## Page or area
+
+<!-- Paste a public page link or name the area. Do not paste a private edit link. -->
+
+## Approved source
+
+<!-- Paste exact approved wording or a public link. Attach only public or redacted images. -->
+
+## Must not change
+
+<!-- Name nearby wording, behavior, data, or access that must stay the same. -->
+
+## Timing and approval
+
+- Requested date:
+- Approving officer role:
+- Second approver required for money, legal, privacy, access, or security:
+
+## Safety
+
+- [ ] I did not include a password, login code, recovery code, secret, member list, private member detail, or payment information.
+- [ ] This request does not ask AI to invent a price, waiver, policy, tax, refund, privacy, insurance, or access decision.
+- [ ] I understand that a merge may start automatic website builds and is not proof that `runmprc.com` or Firebase changed.
+
+## Required handoff
+
+- Officer impact:
+- Officer documentation:
+- Deployment evidence:
+- Preview or redacted screenshot:
+- Plain-language undo plan:

.github/pull_request_template.md

@@ -0,0 +1,40 @@
+## Outcome
+
+<!-- One sentence in plain language. -->
+
+## Scope
+
+- Issue:
+- What changed:
+- What did not change:
+
+## Officer handoff
+
+- Officer impact:
+- Officer documentation:
+- Approving role:
+- Preview or redacted screenshot:
+- Screenshot checked at:
+- Plain-language undo plan:
+- Deployment evidence:
+
+## Proof by surface
+
+- Source changed:
+- Tests passed:
+- Code merged: not yet
+- Website published: not yet / not relevant
+- Netlify intended commit verified: not yet / unknown / not relevant
+- `runmprc.com` verified: not yet / not relevant
+- Firebase deployed: not yet / not relevant
+- Outside provider configured: not yet / not relevant
+- Outside provider verified: not yet / not relevant
+- Production behavior verified: not yet / not relevant
+
+## Safety review
+
+- [ ] No secrets, recovery codes, private member data, or payment data are included.
+- [ ] Planned behavior is marked `NOT AVAILABLE YET`.
+- [ ] Skipped checks or deployments are reported as incomplete, not green/live.
+- [ ] Page/data/access/deployment diagrams were updated when their flow changed.
+- [ ] A backup officer can follow the affected guide without a terminal, or the specialist-only step is explicit.

.gitignore

@@ -78,6 +78,8 @@ web_modules/
 .env.test.local
 .env.production.local
 .env.local
+.secret.local
+functions/.secret.local
 
 # parcel-bundler cache (https://parceljs.org/)
 .cache
@@ -145,4 +147,4 @@ dist
 /build
 
 # misc
-.DS_Store
+.DS_Store

AGENTS.md

@@ -0,0 +1,125 @@
+# Repository Instructions for Coding Agents
+
+These instructions apply to all work in this repository. They supplement the issue being implemented; if an issue conflicts with a security invariant below, stop and escalate rather than weakening the invariant.
+
+## Read before changing code
+
+For architecture, security, commerce, or operations work, read the relevant root documents:
+
+- `SYSTEM_DESIGN.md`
+- `STRIPE_COMMERCE_DESIGN.md`
+- `SECURITY.md`
+- `IMPLEMENTATION_PLAN.md`
+- `OPERATIONS_RUNBOOK.md`
+- The exact issue in `GITHUB_ISSUES.md`
+
+Existing files under `docs/` contain useful historical context but may predate the commerce platform. Root documents are authoritative for the target design.
+
+For every officer-visible or operational change, also read:
+
+- `OFFICER_START_HERE.md`
+- `docs/officers/README.md`
+- The short officer task guide affected by the issue
+
+## Officer continuity documentation
+
+Treat `OFFICER_START_HERE.md` and `docs/officers/` as product surfaces, not optional project notes.
+
+- Start every delivery summary with the outcome in plain language.
+- Every issue and pull request must state:
+  - `Officer impact: <plain-language effect>`
+  - `Officer documentation: <updated paths>` or `None — <specific reason>`
+  - `Deployment evidence: <website, Firebase, and provider surfaces verified>`
+- Update the relevant officer guide in the same pull request when work changes public content, navigation, admin duties, collected data, permissions, deployment, hosting, external accounts, payments, refunds, incidents, backup, or recovery.
+- Officer guides describe current verified behavior. Mark future behavior `NOT AVAILABLE YET`; do not mix planned steps into a procedure that looks usable now.
+- Use short sentences, ordinary words, and one action per numbered step. Define an unavoidable technical term once in the glossary.
+- Every procedure must name its purpose, approver, prerequisites, steps, expected result, stop conditions, success proof, undo path, and escalation role.
+- Do not make an officer edit source files, run terminal commands, handle secrets, or change production data as the primary continuity path. Use an issue, a small reviewed pull request, and named approval.
+- Never ask an officer to paste passwords, recovery codes, secrets, customer/member data, payment data, or production records into an issue, screenshot, email, or AI tool.
+- If page structure, data movement, permissions, account ownership, or deployment changes, update the matching Mermaid diagram and its one-sentence text alternative.
+- Distinguish these states explicitly: source changed, tests passed, code merged, website published, `runmprc.com` verified, Firebase deployed, outside provider configured, and production behavior verified.
+- A green workflow alone does not prove a website, Firebase, or provider change is live. Read job details for skipped steps and verify each affected surface.
+- Redact screenshots, include the check date, and pair each visual with written steps.
+- Before closing an issue, review the affected procedure as a backup officer with no terminal. Record any step that still requires a specialist.
+
+## Non-negotiable safety rules
+
+- Never use, request, print, commit, or copy production secrets or real customer/runner data.
+- Never test checkout, refunds, role changes, email, Strava, migrations, or destructive behavior against production.
+- In local development, Auth, Firestore, and Functions must all target emulators; Stripe must be in test mode.
+- The browser never decides price, member eligibility, payment state, capacity, inventory, refund limits, or authorization.
+- A redirect or client field never proves payment. Only verified Stripe state may confirm it.
+- Every external create/refund/email and every webhook transition must be idempotent and retry-safe.
+- Financial state, webhook events, audit records, rate limits, mail outbox, and OAuth secrets are server-only writes. Browser admins are not a trusted server boundary.
+- Do not add an admin catch-all Firestore rule.
+- Do not log request bodies, Checkout URLs, bearer/confirmation tokens, addresses, DOB, emergency contacts, Stripe/OAuth secrets, or raw ID tokens.
+- Do not make legal, tax, insurance, waiver, retention, shipping, or refund-policy decisions. Implement only an approved decision or surface the blocker.
+- Preserve unrelated worktree changes, especially generated or user-modified files such as `public/sitemap.xml`.
+
+## Issue workflow
+
+1. Work on one issue/outcome at a time and confirm its dependencies are complete.
+2. Inspect the current implementation; documentation is a design, not proof the code already matches it.
+3. State the invariant, allowed transitions, failure cases, and migration impact.
+4. Add a test that demonstrates the defect or missing behavior before/with the fix.
+5. Make the smallest backward-compatible change that satisfies the issue.
+6. Use additive schema changes and idempotent, dry-runnable backfills.
+7. Run focused checks, then the relevant full suite.
+8. Review the diff for authorization, App Check, input bounds, PII/secrets, idempotency, impossible state transitions, and production fallback.
+9. Update affected root documentation and the issue status/evidence.
+10. Report commands/results and any residual risk; do not imply external production configuration was verified from source code.
+
+Split an issue before implementation if it cannot be safely reviewed as one focused pull request.
+
+## Repository map
+
+- `src/`: React web application and client services. Treat it as untrusted input/UI.
+- `functions/`: trusted Firebase Functions boundary. Validate every request and external response.
+- `firestore.rules`: browser access boundary. Admin SDK bypasses it, so also review server IAM/code.
+- `tests/firestore-rules/`: required allow/deny tests for every rule change.
+- `.github/workflows/`: CI and deployment trust boundary.
+- `public/404.html` and `public/index.html`: current GitHub Pages SPA fallback. `public/spa-navigation.js` is queued #99 work and is **NOT AVAILABLE YET** on `main`.
+- `docs/`: historical/developer/content context.
+- `docs/officers/`: current plain-language officer procedures, maps, continuity, and emergency guidance.
+
+## Verification
+
+Use Node.js 20 and lockfile installs.
+
+Commands available on the current `main` baseline:
+
+```bash
+npm ci --legacy-peer-deps
+npm --prefix functions ci
+npm --prefix functions run lint
+npm --prefix functions run test:run -- --runInBand
+npm run test:rules
+CI=true DISABLE_ESLINT_PLUGIN=true npx --no-install react-scripts build
+```
+
+The Rules suite needs Java 17. The direct `react-scripts build` command is preferred for a diagnostic build because normal `npm run build` regenerates the sitemap. Run dependency audits for security/dependency issues, but do not apply forced automatic upgrades.
+
+The following are **NOT AVAILABLE YET** on `main`:
+
+- `npm run emulators` and fail-closed Auth/Firestore/Functions isolation — owned by #99.
+- `npm run test:spa-navigation` — owned by #99.
+- A trustworthy frontend Jest baseline/quality gate — owned by #103.
+
+Do not run Firebase-backed local development against the current production-configured client. Do not describe queued working-tree commands as merged or available.
+
+For Stripe lifecycle work, tests must include relevant negative and retry cases: invalid signature, duplicate/out-of-order Event, unpaid completion, amount/currency/environment mismatch, terminal-state protection, async success/failure, expiration, cancellation, and refund retry. Capacity/inventory work must include concurrent final-unit tests.
+
+## Code conventions
+
+- Preserve the current CommonJS style in `functions/` unless a dedicated migration issue changes it.
+- Keep server-authoritative domain logic out of React components.
+- Prefer small pure helpers for validation and state transitions so they can be exhaustively unit-tested.
+- Use integer cents and explicit currency; never floating-point money.
+- Use stable opaque IDs and schema-versioned minimal Stripe metadata; never put PII in metadata.
+- Use structured, redacted logs with correlation IDs.
+- Avoid mutable unbounded arrays for audit history; use append-oriented records.
+- Do not add a new dependency when a small maintained-platform capability suffices. Any dependency change requires lockfile review and an audit.
+
+## Definition of done
+
+An issue is not complete until implementation, positive/negative tests, relevant full checks, migration/compatibility notes, redacted logging review, engineering documentation, and the applicable officer-facing handoff are complete. Provider Console, IAM, DNS, legal, or live-mode work also requires private evidence and named owner approval outside the repository. If officer documentation is not affected, state the specific reason in the pull request.