Mid-Session-L correction to the v0.15.0 release that the dispatched
subagent (Session ξ) shipped. ξ was working from a pre-vendor brief
that specified @amplitude/analytics-browser and treated the API key
as a secret via `flotilla secret set`. Operator subsequently
provisioned the Amplitude project, surfaced the vendor's
recommended installation prompt, and confirmed the key value.
Three downstream changes:
- Package: swap @amplitude/analytics-browser → @amplitude/unified
(analytics + session replay in one install; vendor-recommended).
- Init call: `amplitude.init(KEY, undefined, { defaultTracking: false })`
becomes `amplitude.initAll(KEY, { analytics: { autocapture: true },
sessionReplay: { sampleRate: 1 } })`. Vendor's exact installation-
wizard shape; gates remain on the v0.13.0 consent banner.
- Binding: Amplitude browser keys are bundle-embedded by design
(same nature as VITE_TURNSTILE_SITE_KEY from v0.12.0), so the key
is public, not secret. CHANGELOG MUST step rewritten to bind via
`flotilla overlay set <deployment> VITE_AMPLITUDE_API_KEY=<key>`
rather than `flotilla secret set`. The roadmap row #13's
"new secret: AMPLITUDE_API_KEY" wording predated vendor
consultation; the roadmap will be updated when this ships.
§19.2 candidate captured in CHANGELOG: split the analytics consent
toggle into a separate session-replay category (recording has a
larger privacy footprint than event counters), follow-up release.
Wrapper structural shape (track/identify/anonymize, queue + drain,
consent-flip → setOptOut, lazy import) is unchanged from ξ's work.
Event taxonomy and Login.jsx / App.jsx / Admin.jsx / etc. instrument
sites are unchanged. Frontend build verified green
(VITE_APP_NAME=… npm run build).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Ben Stull
6cfbf69e26