BACKEND-001 — Audit the Firebase cutover and approve legacy data disposition

[daliu]

Problem

Commit 1a160da repointed four configuration paths from the inaccessible Firebase project runmprc-97922 to the club-controlled mid-peninsula-running-club project. It did not export or import Firebase Auth users, Firestore documents, Storage objects, Functions state, provider configuration, or Google Forms/Sheets data.

The old Firebase project has existed in source since December 2023 and returned 403 PERMISSION_DENIED to the two accounts available during the June cutover. Its emptiness was inferred from the club's historical use of Google Forms/Sheets, not verified by an authorized inventory. The new project is active and has Firestore indexes, but current checks show no deployed Cloud Function endpoints; deployment evidence, recovery settings, and the disposition of legacy data remain incomplete.

daliu.github.io was only the Claude session's shell working directory. It is not a source database and is not being migrated into MPRC.

Architecture decision under review

Retain Firebase Auth + Cloud Firestore + Cloud Functions as MPRC's operational backend for accounts, membership authorization, private content, registrations, commerce state, provider links, and audited administration. This issue validates the estate cutover and data disposition; it does not select or build another database.

Atomic outcome

Authorized primary and backup owners produce a private, read-only inventory of the legacy Firebase estate, the club-owned Firebase estate, and the active Google Forms/Sheets sources. Publish only redacted counts/configuration conclusions and an approved disposition matrix. Make no production changes.

For each system/data category, record:

• verified owner, backup, access state, MFA/recovery state, environment, region, and intended authority;
• redacted counts and schema/configuration variants, without record contents;
• source date range and whether the source is active, archival, test-only, unknown, or inaccessible;
• disposition: migrate, recreate, retire, reauthorize, bootstrap, or unknown/blocked;
• collision/reconciliation rule, owner, dependency, rollback/stop condition, and approval date.

Required inventory

Firebase estates

• Auth user counts by provider and verification state; custom-claim categories; duplicate/collision risk. Do not list emails or provider identifiers.
• Firestore collection names, redacted document counts, schema variants, TTL state, and obvious orphan relationships. Do not export documents into the repository, an issue, AI context, or a local workspace.
• Deployed Rules/index revision evidence; Function names, regions, and deployment revisions; extensions; Storage buckets; App Check; Secret Manager existence only; billing; IAM; delete protection; PITR/backups; and deployment authority.
• Attempt recovery/read-only access to runmprc-97922 through authorized former maintainers/officers. If access cannot be recovered, record the uncertainty and preserve the project; do not call it empty or delete it.
• Confirm the observed mid-peninsula-running-club baseline, including the absence/presence of live Functions and the exact source commit whose Rules/indexes are deployed.

Legacy operational sources

• Privately inventory the active and historical Google Forms/Sheets used for membership, dues, event signup, waivers, volunteers, communications, and other club operations.
• Record owner, purpose, date range, redacted row count, field/category list, consent/notice state, duplicate semantics, renewal/lapse meaning, and retention-decision status.
• Identify any additional authoritative sources such as Stripe, Google Site/Groups, manual officer records, or provider dashboards without copying credentials, discount codes, invite links, payment data, or member records.

Authority/disposition map

Cover accounts/UIDs, membership/dues state, member-role claims, profiles, events/registrations, waivers, payments/refunds, merchandise, discounts, Google content access, Strava, WhatsApp, Instagram, mail, audit, and backups.

Acceptance criteria

• The report distinguishes verified evidence, owner assertion, inference, and unknown/blocked state.
• Both Firebase estates and every known Google Form/Sheet have an owner/access status and redacted category/count inventory or an explicit inaccessible result.
• No Auth UID is recreated, provider identity linked, custom claim granted, or membership inferred merely by matching email.
• Every category has one intended authority and a disposition; dual-write/dual-authority is either prohibited or time-bounded with a reconciliation owner.
• The report explicitly records that the June change was a configuration cutover, not a completed data migration.
• The new project's live state is truthful: deployed Functions, Rules/index revision, IAM/deploy authority, protection/recovery settings, and hosting consumer are evidenced rather than inferred from source.
• An owner approves one of two outcomes:
  • no recoverable transfer is needed, so bootstrap/account recovery proceeds through MEMBERS-IDENTITY-001 — Define authoritative membership and external-account state #81/AUTH-002 and provider tickets; or
  • recoverable approved data exists, so publish a separate BACKEND-002 dry-run migration/reconciliation issue with exact categories and stop conditions.
• The old project and legacy sources remain preserved until the disposition decision and required retention/hold review are complete.
• Public GitHub evidence contains no real PII, secrets, tokens, private URLs, member rosters, Forms/Sheets locators, discounts, or payment records.

Dependencies and coordination

• Parent programs: COMMUNITY-EPIC — Unified member access and community integrations #79 community/member integrations and ARCH-001 — Establish secure-commerce architecture and an atomic execution backlog #104 secure-platform architecture.
• MEMBERS-IDENTITY-001 — Define authoritative membership and external-account state #81 owns the provider-neutral authoritative membership/account state and role-only migration contract.
• The catalogued AUTH-002 owns retirement/replacement of the stale static-key Sheets role updater; do not build another importer endpoint here.
• DATA-001B — Inventory personal data and approve a minimization/retention matrix #110 owns personal-data purposes, minimization, retention-decision state, request behavior, and vendor treatment.
• SEC-001 — Replace the Firestore admin catch-all with resource-specific rules #100 owns Firestore Rules hardening; CI-001 — Establish trustworthy quality gates and protected deployment #105 owns backend deploy authority, environment protection, and exact-release evidence.
• MEMBERS-ACCESS-001 — Restrict the exposed Google Site and contain leaked discounts #80/MEMBERS-CONTENT-001 — Build the Firebase-native members-only discounts page #83 own exposed/next-generation discount content; AUTH-004 — Link a Google identity to an existing Firebase member account #82 owns Google account linking; STRAVA-001 — Harden and modernize the existing Strava OAuth connection #88 owns Strava token lifecycle.
• Existing payment and resilience programs own Stripe reconciliation and backup/restore implementation. This issue supplies their verified source inventory only.

Current evidence to verify, not overclaim

• mid-peninsula-running-club is an active Firebase project with one web app and a Firestore Native database in us-west2.
• Four composite indexes and four registration field overrides are visible in the new project.
• Known Cloud Function endpoints currently return 404, and the deployment workflow has skipped Firebase when backend credentials are absent.
• Firestore currently reports delete protection and PITR disabled and no backup schedule; closure belongs to the resilience/owner program after retention decisions.
• The legacy Apps Script is not a migration tool: it is hardcoded to an old Sheet tab, contains a placeholder key, uses a request contract that no longer matches the server, and only attempts role updates for existing Auth users.

Explicitly out of scope

• Production writes, exports, imports, account creation/linking, role grants, provider-token copying, data deletion, DNS/hosting changes, IAM changes, deployments, billing changes, or recovery-setting changes.
• Copying production Firebase/Sheets data into local emulators or test fixtures.
• Choosing retention/legal/insurance/accounting policy or declaring inaccessible data empty.
• Implementing BACKEND-002, AUTH-002, membership schemas, Rules, Functions, backup, or provider migrations.

Claim protocol

Creation is not a claim. Engineering coordination must be assigned and begin only after a timestamped CLAIMED by <canonical agent> at <UTC>; branch <branch> comment is posted and re-read. Earliest valid claim wins. All account access, former-maintainer outreach, console inspection, and private evidence handling require a named authorized owner even after an engineering claim.