Release 0.15.0: Amplitude Analytics + Session Replay (with #21 Part C identity lifecycle)
Wave 5 / Track A. Roadmap item #13. Folds in #21 Part C user-identity- lifecycle work inline rather than as a follow-up release (operator ask: "implement Amplitude best practices from the very get-go"). Wraps @amplitude/unified with: - consent-gated lazy init (v0.13.0 cookie banner; SDK never loads without explicit analytics opt-in) - amplitude.initAll(KEY, { analytics: { autocapture: true }, sessionReplay: { sampleRate: 1 } }) — vendor-recommended shape - identify({ user_id, properties? }) with set vs setOnce semantics - setUserProperties(properties) for mid-session state changes - anonymize() clears both user_id binding AND property cache Wired into App.jsx (identify on me.user with role / permission_state / passcode_set / device_trusted as set; first_sign_in_at / account_created_at as setOnce; Page Viewed on route change; Sign-out fires User Signed Out + anonymize), Login.jsx (User Signed In + Beta Access Requested), and the per-feature surfaces (ProposeModal, PRModal, RFCView, RFCDiscussionPanel, PRView, Admin). Binding: VITE_AMPLITUDE_API_KEY via `flotilla overlay set` (bundle-embedded public key like VITE_TURNSTILE_SITE_KEY — not secret). Mid-Session-L correction: original dispatch brief specified secret-set; vendor guidance + bundle visibility settled it as overlay. PII discipline: no email, no display_name, no gitea_login, no free-text fields ever sent. Properties are opaque ids + enums + timestamps + booleans only. Subagent ξ shipped the wrapper structure + nine-event taxonomy on feature/v0.15.0-amplitude (0fd8c52+6cfbf69post-correction). Driver-side integration extended the wrapper with setUserProperties + identify properties for the #21 Part C identity-lifecycle work. Frontend build verified green. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -62,3 +62,26 @@ VITE_COOKIES_POLICY_URL=
|
||||
# Examples:
|
||||
# VITE_TURNSTILE_SITE_KEY=0x4AAAAAAA...
|
||||
VITE_TURNSTILE_SITE_KEY=
|
||||
|
||||
# v0.15.0 / roadmap item #13: Amplitude project API key (public).
|
||||
# Embedded in the frontend bundle at build time and used by the
|
||||
# analytics wrapper (`frontend/src/lib/analytics.js`) — which loads
|
||||
# `@amplitude/unified` (Analytics + Session Replay) when the user
|
||||
# has granted analytics consent (v0.13.0 cookie banner). Provision
|
||||
# an Amplitude project at app.amplitude.com → Projects → New, copy
|
||||
# the API key.
|
||||
#
|
||||
# Public by design: Amplitude browser keys are bundle-embedded
|
||||
# (visible in dev tools), same nature as VITE_TURNSTILE_SITE_KEY
|
||||
# (also public; the truly-secret half of that Turnstile pair is
|
||||
# CLOUDFLARE_TURNSTILE_SECRET on the backend). For deployments
|
||||
# behind flotilla, bind via `flotilla overlay set <deployment>
|
||||
# VITE_AMPLITUDE_API_KEY=<key>` — NOT `flotilla secret set`. The
|
||||
# vendor's installation wizard shows the key inline as a literal
|
||||
# string in the init call, confirming the public framing. Leave
|
||||
# unset in dev; the wrapper logs one console warning and no-ops
|
||||
# (the app continues to work).
|
||||
#
|
||||
# Examples:
|
||||
# VITE_AMPLITUDE_API_KEY=01234567890abcdef01234567890abcd
|
||||
VITE_AMPLITUDE_API_KEY=
|
||||
|
||||
Reference in New Issue
Block a user