You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Officer impact: None — this stops unapproved telemetry without changing an officer or member task.
Officer documentation: None — no officer procedure, navigation, permission, or collected field changes. Engineering architecture/security/operations evidence must distinguish source containment from website and provider behavior.
Deployment evidence: Closure must record source/tests/merge, website publication, exact runmprc.com revision, Firebase Analytics/provider behavior, and live network verification separately. A source merge is not production containment.
Problem
Ordinary hosted pages currently initialize Firebase Analytics automatically. The shared wrapper accepts arbitrary event names and parameters, and current call sites pass event identifiers/slugs, prices, and raw error messages. Waiver.jsx bypasses the wrapper and calls the Analytics SDK directly. The repository has no approved purpose, consent, parameter schema, retention, access, or deletion decision under #110.
Invariant
Until #110 records an approved Analytics policy, application runtime code must not initialize Firebase Analytics or call logEvent. Local/test and capability-callback isolation from #99 must remain unchanged. Removing telemetry must never block or alter a member flow.
Atomic outcome
Disable hosted Analytics SDK initialization, turn the existing wrapper into a no-transport compatibility no-op, remove the direct Waiver SDK bypass, and add synthetic/static tests proving no application runtime import can initialize or emit Analytics. Keep the current call sites source-compatible; a separately approved child may later replace the compatibility API with a closed event/parameter schema.
Exact implementation boundary
src/services/analytics/analytics.ts
src/services/analytics/analytics.test.ts (new)
src/services/firebase/FirebaseResources.ts
src/services/firebase/FirebaseResources.test.ts
src/pages/joinUs/Waiver.jsx
Minimum matching SYSTEM_DESIGN.md, SECURITY.md, and OPERATIONS_RUNBOOK.md status/diagram evidence
Excluded: Sentry, functions/signup.js, Auth/profile, Firestore Rules, Stripe/webhook, Strava, sitemap, Firebase/Sentry provider settings, consent/policy decisions, cookies/storage cleanup, and all production data.
Acceptance criteria
Production, preview, local, test, and callback startup do not call Firebase Analytics isSupported, getAnalytics, or logEvent from application runtime code.
FirebaseResources.analytics remains null and existing wrapper calls return without an SDK/provider call or user-flow error.
Waiver.jsx has no direct Analytics SDK import/call and its confirmation/storage/callback behavior is unchanged.
A repository test fails if a runtime source file directly imports/calls Firebase Analytics outside the explicitly non-runtime test boundary.
Existing callback isolation and the complete frontend suite pass using synthetic data only and no provider traffic.
Engineering documents state that source containment is not proof of website publication, provider collection/cookies, historical data deletion, retention/access/consent, or live behavior.
Creation is not a claim. Before editing, assign the issue, add status:in-progress, post CLAIMED by <canonical agent> at <UTC>; branch <branch>, and re-read comments. The earliest valid claim wins.
Officer impact: None — this stops unapproved telemetry without changing an officer or member task.
Officer documentation: None — no officer procedure, navigation, permission, or collected field changes. Engineering architecture/security/operations evidence must distinguish source containment from website and provider behavior.
Deployment evidence: Closure must record source/tests/merge, website publication, exact
runmprc.comrevision, Firebase Analytics/provider behavior, and live network verification separately. A source merge is not production containment.Problem
Ordinary hosted pages currently initialize Firebase Analytics automatically. The shared wrapper accepts arbitrary event names and parameters, and current call sites pass event identifiers/slugs, prices, and raw error messages.
Waiver.jsxbypasses the wrapper and calls the Analytics SDK directly. The repository has no approved purpose, consent, parameter schema, retention, access, or deletion decision under #110.Invariant
Until #110 records an approved Analytics policy, application runtime code must not initialize Firebase Analytics or call
logEvent. Local/test and capability-callback isolation from #99 must remain unchanged. Removing telemetry must never block or alter a member flow.Atomic outcome
Disable hosted Analytics SDK initialization, turn the existing wrapper into a no-transport compatibility no-op, remove the direct Waiver SDK bypass, and add synthetic/static tests proving no application runtime import can initialize or emit Analytics. Keep the current call sites source-compatible; a separately approved child may later replace the compatibility API with a closed event/parameter schema.
Exact implementation boundary
src/services/analytics/analytics.tssrc/services/analytics/analytics.test.ts(new)src/services/firebase/FirebaseResources.tssrc/services/firebase/FirebaseResources.test.tssrc/pages/joinUs/Waiver.jsxSYSTEM_DESIGN.md,SECURITY.md, andOPERATIONS_RUNBOOK.mdstatus/diagram evidenceExcluded: Sentry,
functions/signup.js, Auth/profile, Firestore Rules, Stripe/webhook, Strava, sitemap, Firebase/Sentry provider settings, consent/policy decisions, cookies/storage cleanup, and all production data.Acceptance criteria
isSupported,getAnalytics, orlogEventfrom application runtime code.FirebaseResources.analyticsremains null and existing wrapper calls return without an SDK/provider call or user-flow error.Waiver.jsxhas no direct Analytics SDK import/call and its confirmation/storage/callback behavior is unchanged.Dependencies and coordination
Claim protocol
Creation is not a claim. Before editing, assign the issue, add
status:in-progress, postCLAIMED by <canonical agent> at <UTC>; branch <branch>, and re-read comments. The earliest valid claim wins.