Instrument typed field observability for React apps

A portable, framework-agnostic field-side observability skill for React/React Native, the field complement to the frontend-lighthouse skill (Lighthouse is the synthetic lab gate pre-merge; this is what real users actually experience), living in a services/analytics/ module per frontend-architecture. Five core ideas: events are a typed vocabulary - canonical ANALYTICS_EVENTS constants with a union type, never inline strings, so typos are compile errors and the catalog is one reviewable file; the fan-out is best-effort and non-blocking - a single track(event, props) entry point iterates a registry of tiny provider adapters, each wrapped in its own try/catch and window-guarded, so a missing global, thrown provider, or unloaded script can never break the caller or the other providers; one SSR-safe entry point reached via a 'use client' AnalyticsProvider and a useAnalytics() hook that no-ops outside a provider or on the server; real-user Core Web Vitals (LCP, INP, CLS, FCP, TTFB via the web-vitals library) report through the same fan-out using the identical thresholds as the lighthouse skill, so lab-green-but-field-poor reveals a gap between test conditions and real devices/networks; and consent gates everything at the fan-out boundary in one place (hasConsent() checked once inside track(), not duplicated per call site), defaulting to false where GDPR/CCPA or Do Not Track require it, with props kept PII-light (ids and enums, never raw emails or free text). Firebase Analytics gets one conceptual adapter covering both web and React Native SDKs since they share the same logEvent(name, params) contract, with the web adapter lazily and asynchronously initialized to stay SSR-safe. Error reporting reuses the same fan-out (or a dedicated Sentry adapter) at deliberate route/segment-level error boundaries rather than a global swallow, reporting only unexpected errors - expected ones like validation failures or 404s (typed ApiError from frontend-data-contracts) are handled, not reported as crashes.

Use it when instrumenting a React or React Native app with typed analytics events, real-user Core Web Vitals reporting, consent-gated telemetry, or error reporting at boundaries. It describes a field-side observability system, not a dashboard or a specific analytics vendor.

Given an event name constant and optional props, track() dispatches to every registered provider adapter (best-effort, consent-gated), and reportWebVitals()/error boundaries feed real-user vitals and unexpected errors through the same fan-out.

export const ANALYTICS_EVENTS = { PROJECT_CLICK: "project_click", /* ... */ } as const;

Pairs with any analytics vendor via a window-guarded adapter (Google Analytics, Clarity, Firebase Analytics, PostHog, OpenPanel), the web-vitals library for field CWV, and error-reporting tools like Sentry at ErrorBoundary catch points.

Frontend teams who want typed, consent-respecting, crash-proof analytics instrumentation - a single event vocabulary instead of stringly-typed track() calls scattered through the codebase, and a fan-out where a broken or absent analytics provider can never take down the app.