WEB-001 — Controlled Firebase Hosting and automatic web releases

[daliu]

Outcome

Replace the split Netlify/GitHub Pages website path with controlled Firebase Hosting and make a reviewed merge into a protected web-production branch automatically publish the exact merged commit. Keep main as the integration branch until production has safely caught up.

Verified current state (2026-07-22)

• runmprc.com is still served by Netlify deploy 6a54a3c93db9d300082e1f5f from source e86a0f702cff6495f50630c5de3337290db8b8cb.
• Current main is 176 commits and 247 files ahead of live and contains frontend, Functions, Rules, workflow, and dependency changes. It must not be connected directly to production hosting.
• Netlify receives main and pull-request events, but repository logic intentionally stops production builds. The current signed-in runmprc@gmail.com account can view deploys but is denied project deployment settings.
• .github/workflows/deploy.yml is manual and deploys a fixed backend plan plus a separate GitHub Pages artifact. It does not publish the live website.
• firebase.json has no Hosting configuration. Optimized browser builds still select the production Firebase project, so a staging Hosting preview would contact production.
• No protected web-production branch exists. main has no required status checks and administrators can bypass its review rule. The GitHub production environment has no reviewer or branch policy.
• The available Google identity cannot access mid-peninsula-running-club. BACKEND-001 — Audit the Firebase cutover and approve legacy data disposition #113, CI-001C — Configure protected short-lived Firebase deployment identity #133, and CI-001D — Prove backend-first staging and deploy the profile repair #136 still own staging inventory, short-lived deployment authority/environment protection, and staged release evidence.

Release contract

feature PR -> main (integration and CI)
approved promotion PR -> protected production-web
merge -> automatic exact-SHA Firebase Hosting deploy -> readback and smoke checks

The promotion merge is production approval. There is no separate deploy button or laptop CLI publication. A release tag is written only after successful verification and is an audit marker, not the authorization trigger.

Scope

1. Make browser Firebase configuration explicit and fail closed for local, isolated staging, and production. Prove an optimized staging build cannot reach production Firebase resources.
2. Add Firebase Hosting configuration for SPA rewrites, canonical/SEO behavior, assets, callback routes, cache policy, release identification, and preview/live channels.
3. Add exact-commit CI for promotion pull requests and pushes to production-web, including frontend tests, SPA tests, non-mutating lint, build, artifact safety, and a release-scope gate.
4. Create and protect production-web. Require reviewed pull requests, exact required checks, current head, stale-review dismissal, last-push approval, conversation resolution, no direct/force pushes or deletion, and no administrator bypass.
5. Restrict the production environment and short-lived WIF/ADC identity to the protected branch. Do not use a service-account JSON key or legacy Firebase token.
6. Automatically deploy a successful main commit only to isolated staging/preview Hosting after BACKEND-001 — Audit the Firebase cutover and approve legacy data disposition #113/CI-001C — Configure protected short-lived Firebase deployment identity #133. Automatically deploy production only after the protected promotion merge.
7. Add a deployment concurrency lock, exact SHA/release marker readback, public deep-route/callback smoke checks, and a rehearsed previous-release rollback.
8. Stage CSP and the approved browser-security headers, then perform an owner-approved DNS/TLS cutover. Remove the GitHub Pages custom-domain claim and retire Netlify only after observation and rollback proof.

Backend-dependent releases remain explicit backend-first release plans. This website lane must never broaden into an all-Functions, Rules, Stripe, email, or provider deployment.

Acceptance criteria

• An optimized staging artifact is proven unable to call production Firebase resources.
• A promotion pull request cannot merge without all exact-head required checks and an authorized independent approval.
• Direct pushes, force pushes, branch deletion, and administrator bypass are disabled for production-web.
• Merging the promotion pull request automatically deploys that exact commit to Firebase Hosting without a second manual deploy action.
• Deployment authority is short lived, environment restricted, and unavailable to pull-request code or the build job.
• Concurrent or superseded production deployments cannot race.
• Provider readback and a public release marker identify the exact published commit; skipped or partial work fails red.
• SPA deep links, static assets, OAuth/payment callback routes, canonical domain behavior, TLS, headers, and caching pass on staging and production.
• The previous known-good release can be restored and the rollback drill is recorded.
• Netlify and the GitHub Pages custom-domain claim are retired only after the Firebase site is verified and the rollback observation period completes.

Stop conditions

• Production hosting is pointed at current main.
• Staging can reach production Firebase, or the Firebase estate/project ownership is still ambiguous.
• Required checks, protected-branch rules, environment restrictions, short-lived authority, exact-SHA readback, or rollback proof are missing.
• An unreviewed backend, Rules, dependency, provider, or production-data change enters the website release.
• DNS, TLS, callback, or custom-domain ownership cannot be verified by an authorized owner.

Officer impact: Officers approve a promotion pull request in GitHub; merging it publishes the reviewed website automatically. Officers do not run terminal commands, handle secrets, or use provider dashboards as the normal release path.

Officer documentation: Update OFFICER_START_HERE.md, docs/officers/PUBLISH_AND_CHECK.md, docs/officers/SYSTEM_MAPS.md, docs/officers/ACCESS_CONTINUITY.md, docs/officers/EMERGENCY_AND_RECOVERY.md, the glossary, SYSTEM_DESIGN.md, SECURITY.md, and OPERATIONS_RUNBOOK.md in the implementation pull requests.

Deployment evidence: None at creation. Record source, tests, staging Hosting URL, exact commit/release marker, protected-environment run, Firebase provider readback, DNS/TLS/deep-route checks, Netlify/Pages retirement, and rollback rehearsal as separate dated evidence.