Configure with your assistant

Use the published SDK 0.6.4. Install @extension-report/js@0.6.4 with the repository's existing package manager; keep exact versions and the lockfile.

Inspect the existing repository before changing it: framework, MV2/MV3 background, package manager, manifests, supported browsers, singleton telemetry wrapper, runtime messaging, auth, license/trial state, purchase confirmation and consent setting. Do not replace an existing SDK instance or duplicate listeners.

Determine whether this is WXT, Plasmo, a plain WebExtension or a native Safari container. Do not choose a framework from the project name. Save the detected profile before implementation.

Initialize a single background/service-worker instance with projectPublicKey="pk_er_YOUR_PROJECT_PUBLIC_KEY" and instrumentation adoption:true, engagement:true, reliability:"errors". Preserve existing ceilings/settings when integrating an already-instrumented extension. No owner secret belongs in a browser package.

Merge storage, alarms and the exact Extension Report API origin into the built manifest. Preserve other permissions and CSP. Add optional feature permissions only when the extension actually uses those APIs. For Firefox, inspect required/optional data_collection_permissions and honor the technical-data grant on supported versions; do not bypass or silently reset it. For WXT, use its module or manual background integration consistently; never enable both autoBackground and a duplicate manual SDK.

Connect actual popup/options/side-panel sessions with connectExtensionReportUiSession({surface}); content scripts send narrowly validated messages to the background. Validate message type, payload and sender. Never initialize a second SDK in each UI or content script.

Selected surfaces: inspect existing surfaces. Detect absent surfaces; do not create product UI merely for telemetry.

Keep anonymous installations anonymous. If trials exist without accounts, call sdk.identify(null, safeEntitlementTraits); do not generate a fake user or use installation ID as an account identity.

Reuse existing custom event names for equivalent transitions; the trial/subscription/purchase names above are examples when no equivalent event exists. Inspect the event catalog and preserve continuity. Product-specific signals use sdk.trackCustomEvent(name, safeAttributes). The SDK has no trackPurchase or trackTrial method. TrackOptions supports flush only; implement transition/transaction deduplication in the application's existing persisted state, not a made-up SDK dedupe option. Keep backend revenue separate from client-observed checkout and entitlement events.

Identify the product's existing meaningful-value event with the owner; do not equate activation with installation or opening the popup.

Keep a visible tracking preference and honor existing opt-out/consent. sdk.setTrackingEnabled(false) must stop collection; restoring consent must not backfill suppressed actions. Never collect emails, payment tokens, receipt bodies, document text, full visited URLs or browsing history.

Validate with @extension-report/doctor@0.6.4 against each generated store manifest. Test clean install versus update, service-worker restart, popup/options sessions, offline replay, opt-out, logout/account switch, anonymous trial start/expiry/conversion, canceled subscriptions and duplicate purchase callbacks where applicable. First run against a local/test project or debug.dryRun; do not fabricate financial events in the owner's live project.

Report source edits, built artifact, installed extension and server-observed events as separate verification steps. Existing events are a baseline, not proof that the new build works. Do not commit, publish, deploy or upload a store package without authorization for that action.