@wireai/activation 0.13.2 → 0.13.5

package/AGENTS.md

@@ -32,7 +32,7 @@ Everything an integration needs lives on the ROOT import (`@wireai/activation`).
 subpaths are optional secondary feature modules; import one only if you use it.
 
 - `@wireai/activation` (root): `WireOnboarding`, the helpers/types below, and the device-only event reporters (`reportClientEvent`, `makeSessionId`, `WIRE_ONBOARDING_EVENTS`, see "App events" below).
-- `@wireai/activation/analytics`: the analytics FACADE and its queue: `createAnalytics`, `useAnalytics`, `createScreenTracker`, `reportAppEvent`, `createEventQueue`, `clearUserContext`. These are NOT root exports; importing them from the root does not compile.
+- `@wireai/activation/analytics`: the analytics FACADE and its queue: `createAnalytics`, `useAnalytics`, `createScreenTracker`, `reportAppEvent`, `createEventQueue`, `clearUserContext`, `wireDoctor`. Except for `clearUserContext`, these are NOT root exports; importing them from the root does not compile. `clearUserContext` IS also a root export (`import { clearUserContext } from "@wireai/activation"`), which is the form the README teaches for the sign-out purge. `wireDoctor({ target, storage })` is the DEV-ONLY integration self-check: it resolves `{ok, checks:[{name, ok, detail}]}`, never throws, and posts one `dry_run` probe event so a broken integration is caught on the first run instead of in a funnel report. It is dev-gated on `__DEV__` (a release build makes no network call), it reports the apiKey's SHAPE and never its value, and its verdict is read from the ack body, never from the status code. See the README "Verify your integration" section.
 - `@wireai/activation/coachmarks`: in-app coachmark tour (`CoachmarkProvider`, `useCoachmarkTour`).
 - `@wireai/activation/showcase`: post-onboarding feature showcase (`FeatureShowcase`).
 - `@wireai/activation/reviews`: store-review gating (`ReviewGate`, `ReviewModal`, `useReviewGate`, `fetchReviewDecision`).
@@ -79,7 +79,9 @@ subpaths are optional secondary feature modules; import one only if you use it.
 | `storage` | `WireOnboardingStorage` | no | Host-injected AsyncStorage-compatible storage. When set, the kit caches its session id so an app kill mid-onboarding resumes the SAME backend session (keeps the `started` count honest). Persists the correlation seed only, never answers. |
 | `sessionTtlMs` | `number` | no | How long a persisted session id stays resumable, ms. Default `3600000` (1h). Only meaningful with `storage`. |
 | `persistKey` | `string` | no | Override the storage key (default `wireai:session:<config.appId>`). Scope it per-user if one device runs onboarding for multiple accounts. Only meaningful with `storage`. |
+| `retainSessionOnComplete` | `boolean` | no | Opt IN: keep the persisted session seed alive ACROSS completion. A multi-stage or replay-after-complete re-entry within one signup (typically a `key=` remount) then resumes the SAME session instead of minting a fresh `metadata.sessionId`, which the backend adopts as a second `contextId` and double-counts as a `session_started`. Omitted or `false` clears the seed on completion, the legacy single-stage behavior, so leaving it unset changes nothing. When `true`, freshness comes from `sessionTtlMs` plus an explicit new-run signal (scope a new `persistKey`, e.g. a per-signup id). Only meaningful with `storage`. |
 | `userContext` | `Record<string, string \| number \| boolean>` | no | Host-injected, non-PII context (signup method, referral, plan tier, a hashed user id). Forwarded to the backend + client events for funnel segmentation. No raw PII. |
+| `autoJoinKey` | `boolean` | no | Opt OUT of the automatic join key. Default `true`. When `userContext` carries no `device_key` and `storage` is present and actually persists (a storage adapter that throws or rejects is treated exactly like no `storage`), the kit injects its own per-install key, the same id `createAnalytics` / `createWireActivation` mint and persist, so the `activated` funnel joins with no host wiring. Pass `autoJoinKey={false}` for a genuinely UNLINKED session: that restores the pre-0.12.2 behavior and the dev warning fires again. It never overrides a `device_key` you passed, and it cannot inject without `storage`. |
 | `userId` | `string` | no | The host's OPAQUE PSEUDONYMOUS user id (not an email/name/phone), so onboarding sessions reconcile to real users. Late binding supported (mount, mid-session, or post-flow via `identifyOnboarding`). Capped at 128 chars. |
 
 ### `config` fields (`WireOnboardingConfig`)
@@ -100,7 +102,7 @@ FACADE (`createAnalytics` and friends) is a different surface and lives on `@wir
 - `WIRE_ONBOARDING_EVENTS` + `toAnalyticsEvent(event)`: canonical `wire_onboarding_*` funnel names; log via the app's own analytics.
 - `reportClientEvent(target, event)` / `reportClientEvents(target, events)`: report device-only funnel events. Contract: `POST {serverUrl}/v1/events`, header `Authorization: Bearer {apiKey}`, body `{ "events": [ ... ] }`. `target = { serverUrl, apiKey }` is derived from `WireOnboardingConfig`. Fire-and-forget: never throws into the UI.
 - `makeSessionId()`: a unique-per-onboarding session id (also seeds the A2A `contextId` so client and server events correlate).
-- `ClientEventType` is `"screen_skipped" | "dropped" | "client_fallback" | "identify"`. `<WireOnboarding>` auto-reports `dropped` (unmount without complete) and `client_fallback` (degrade to static). Hosts must NOT double-report fallback.
+- `ClientEventType` is `"screen_skipped" | "dropped" | "client_fallback" | "identify" | "app_event"` (`app_event` is the type the whole `wire.track` / `reportAppEvent` surface rides on). `<WireOnboarding>` auto-reports `dropped` (unmount without complete) and `client_fallback` (degrade to static). Hosts must NOT double-report fallback.
 
 ## Integration steps (ordered)
 
@@ -117,7 +119,8 @@ FACADE (`createAnalytics` and friends) is a different surface and lives on `@wir
 ## Review firing (do not hand-roll the decision fetch)
 
 If you gate the review prompt on the server, call **`fetchReviewDecision(target, { deviceKey })`**
-from `@wireai/activation/reviews` and pass the result to `useReviewGate({ decision })`. Never
+from `@wireai/activation/reviews` and pass the result to `useReviewGate({ config, decision })`.
+`config` is REQUIRED (the hook reads `config.id`); `decision` alone does not compile. Never
 write your own fetch.
 
 - It returns the FULL `{ fire, reason, arm }` on 2xx, and `null` ONLY when the server is

package/CHANGELOG.md

@@ -3,13 +3,300 @@
 All notable changes to `@wireai/activation` (formerly `wireai-onboarding`).
 Historical entries below the rename keep the old package name on purpose.
 
+## [0.13.5] - 2026-08-03
+
+Two halves of one idea: stop finding out about a broken events integration from a funnel report.
+
+`POST /v1/events` answers HTTP 200 for a batch it discards and reports the refusal only in the
+response body, so a client/server contract drift breaks nothing anyone can see. It quietly flattens
+a graph. That is exactly how a numeric `ts` threw away every `app_event` through 0.13.0. This
+release adds a check on each side of that gap: one in CI, one on the developer's first run.
+
+(0.13.4 is deliberately skipped.)
+
+### Added
+
+- **`wireDoctor`, a dev-only integration self-check**, exported from `@wireai/activation/analytics`.
+  It resolves a structured report and never throws, whatever the target, the storage adapter or the
+  network does. Four independent checks, each a `{name, ok, detail}` unit:
+
+  1. `target`: the `serverUrl` parses and an `apiKey` is present. It reports the key's SHAPE only,
+     its length and whether the prefix matches, and never any character of the key itself.
+  2. `reachability`: `GET /v1/events/contract` answers, so the URL really is a Wire server.
+  3. `storage`: a write / read / delete probe proves the offline queue can persist. The probe uses
+     its own key, outside the queue's namespace, and deletes it in a `finally` even when the read or
+     the write throws. A diagnostic that eats a pending backlog would be worse than no diagnostic.
+  4. `round_trip`: one synthetic event goes through the REAL transport with `dry_run: true`, so the
+     server validates it exactly as it would a production event and writes nothing. The verdict is
+     read from the ack body (`written === 1 && skipped === 0`), never from the status code. A
+     `ts`-shaped drift surfaces as `skipped: 1` carrying the server's own `field: "ts"`.
+
+  Dev-only by contract: the `__DEV__` guard is the first statement, so a release build makes no
+  network call and writes no storage key. The report says it was skipped rather than reporting a
+  pass it never earned. No new export subpath, no new `globalThis` slot, and a host that never calls
+  it does not bundle it.
+
+- **An `events-contract` CI job** that validates the payloads `buildEventsRequest` actually produces
+  against the JSON Schema the production server publishes, one fixture per send-path family
+  (analytics façade, session-start lifecycle, review transport, `client_fallback`, the unmount
+  `dropped`, and an offline queue flush carrying a persisted numeric-`ts` backlog). It uses the real
+  transport rather than a copied envelope, and reads the schema live rather than from a vendored
+  snapshot, so it cannot pass by validating a replica of something that has already drifted.
+
+  The fixtures are defined once, in `test/fixtures/sendPathFamilies.ts`, and read by both this check
+  and the transport-parity test. Each one names the emitter (`file:line`) whose shape it was built
+  from, and the check prints that line beside its result, so "this is what that path really sends"
+  is a claim you can check rather than one you have to trust. The module is under `test/` and is
+  absent from `files`, so it never reaches the tarball.
+
+  It fails, it never skips. A network error, a non-200, an unparseable contract, a missing
+  `client_event_types`, an unknown `event_type` or any invalid event exits non-zero. Run it locally
+  with `npm run check:contract`. `ajv` is a devDependency and does not ship in the tarball.
+
+### Changed
+
+- **`buildEventsRequest` takes an optional third argument, `options?: { dryRun?: boolean }`.** The
+  `dry_run` key is added to the envelope ONLY on an explicit `true`, so every production send path
+  (which passes nothing) still serializes byte-identical bytes. That parity is asserted per
+  send-path family against golden strings captured from 0.13.3, because FIVE shipped call sites ride
+  this one envelope (the offline queue's `postBatch`, the fire-and-forget POST, the awaitable POST,
+  the review transport, and the session-start lifecycle) and a diagnostic has no business changing it
+  for them.
+- **`readEventsAck` is exported from its module** so `wireDoctor` reuses the same ack reader the send
+  paths use. It is deliberately NOT added to the `./analytics` barrel: the module's surface widens,
+  the package's public API does not. The exports map still has exactly 8 keys.
+
+## [0.13.3] — 2026-08-02
+
+The headline is a fix nobody could see from inside the kit: **on the DEFAULT configuration, a
+backend that never answered left the user on the loading screen forever.** Everything else in this
+release is the machinery that let a defect that severe stay invisible to a 638-test suite.
+
+### Fixed
+
+- **A retry could be recorded as the user's FIRST ANSWER.** Caught pre-publish, and like the double
+  review row it was NEW in this release — the retry-budget fix below is what made it reachable. The
+  auto-start effect keyed the kickoff payload on `resumed`, a MOUNT-time prop, so a retry inside a
+  fresh run re-sent `startMessage`. The server records any non-empty message that arrives while a
+  question is pending as that question's answer (`if user_message and pending and not
+  _stop_requested(...)` → appends `{key, question, answer}` to `session["answers"]`). The trigger
+  is not an outage: the watchdog fires at `startTimeoutMs` (15s default) while a slow LLM is still
+  generating card 1, the server already has that card pending, and the retry lands as its answer.
+  The user's first onboarding answer silently becomes the literal kickoff string — and answer data
+  is the product. On 0.13.2 this was unreachable because no second kickoff could ever fire.
+
+  Only the first attempt of a fresh session now sends `startMessage`; a resumed mount and every
+  retry (auto, timeout-driven, and the "Try again" button) send the skip sentinel, which is safe in
+  both server states — with a pending question it skips one card recording nothing, with no pending
+  it is zeroed and behaves as a normal kickoff.
+
+  ⚠️ **The cost, stated rather than hidden: when the server DID hold card 1 pending, the retry now
+  SKIPS that card — the user loses one question.** That is deliberate. A skipped card emits
+  `screen_skipped` and is visible in the funnel; a kickoff string stored as an answer is invisible
+  and corrupts the data every downstream decision reads. Losing a question beats inventing one.
+
+- **A lost ack wrote TWO review rows.** Caught pre-publish, and it was NEW in this release: reading
+  the submit response is what made it possible, so 0.13.2 could not double-post. `submitReview`
+  returned `false` for two materially different outcomes — *nothing reached the server* and *the
+  server answered non-2xx* — and `ReviewGate.postOnce` un-latches on `false`, so the abandonment net
+  re-posted the identical body. A gateway 502 that arrives AFTER the row commits therefore wrote a
+  second review row, double-counting `count` and corrupting `avg`: the exact corruption the one-row
+  latch exists to prevent, on the code path added to protect the data. There is no idempotency key
+  on the wire (`create_review` mints the row id; `CreateReviewRequest` has no id field), so the kit
+  cannot tell the two apart after the fact — it has to stop guessing.
+
+  `submitReview` now resolves **`ReviewSubmitResult`** — `"accepted"` / `"rejected"` / `"unsent"` —
+  instead of a boolean, and `postOnce` un-latches on `"unsent"` alone. A response of ANY status
+  proves the server was reached, and a row the server answered for is the server's problem. The
+  shape change is free: 0.13.3 was never published. Still non-throwing, still fired synchronously —
+  the caller never awaits.
+
+  ⚠️ **Honest residual: this is safer, not safe.** `"unsent"` is not proof the server never got the
+  row either — a connection dropped after the insert committed throws exactly like an offline
+  device, so the single in-process re-post can still duplicate in that narrow window. Closing it
+  needs a **client-minted idempotency key the server upserts on**, which is a server change and is
+  not something the kit can fake. Until then the kit prefers losing a row to inventing one: a lost
+  detractor is a gap in the data, a duplicated one is a lie in it.
+
+- **The questionnaire had the same hole, and it was worse.** The review fix above landed and its
+  semantic twin got none of it. `submitQuestionnaireResponse` returned `void` over a body of
+  `void fetch(...).catch(() => {})`, so the response was never read at all, and
+  `QuestionnaireGate.finish` set `submittedRef`, fired `questionnaire_submitted` and showed the
+  thank-you unconditionally. `onResolved` → `markResolved` then writes the permanent
+  `wire_questionnaire_<id>_<ver>_seen` key. The questionnaire is the only surface that both burns a
+  permanent once-gate **and** had zero evidence of delivery: a user who answered offline lost their
+  answers and was never asked again. The CHANGELOG's own justification for the review fix applies
+  word for word.
+
+  `submitQuestionnaireResponse` now resolves **`QuestionnaireSubmitResult`** (the shared
+  `SubmitResult`: `"accepted"` / `"rejected"` / `"unsent"`), and the gate posts through a `postOnce`
+  latch that un-latches on `"unsent"` alone, with one in-process re-post when the gate unmounts.
+  Both surfaces now import the verdict from one place, so the retry rule cannot drift between them: a
+  server that ANSWERED, even non-2xx, is never retried, because the response id is server-minted and
+  the wire has no idempotency key. The signature change is free: 0.13.3 was never published. Still
+  non-throwing, still fired synchronously, the caller never awaits.
+
+  ⚠️ **Same honest ceiling as reviews:** recovery is in-process only. A run answered offline and
+  never recovered before the app is killed is still lost, and the host still writes the once-gate on
+  `onResolved`. Durable cross-launch retry needs new public API and is deliberately not in this
+  release.
+
+- **The theme context was not shared across the built subpath bundles.** `OnboardingThemeContext`
+  was a plain `createContext(...)` and tsup inlines it into five bundles, so `dist/index.js`,
+  `dist/reviews/index.js`, `dist/questionnaire/index.js`, `dist/coachmarks/index.js` and
+  `dist/showcase/index.js` each carried their own instance. `OnboardingThemeProvider` is exported
+  only from the root barrel, so on any `dist` resolution path (plain RN CLI,
+  `unstable_enablePackageExports: false`, node, jest, SSR) a host that wrapped its tree in
+  `<OnboardingThemeProvider>` and rendered `<ReviewGate>` from `@wireai/activation/reviews` wrote
+  one context and read another. Nothing crashed: `useOnboardingTheme`'s `ctx ?? mergeTheme()`
+  fallback served the neutral default theme, so the tenant's brand silently did not apply. Metro
+  masked it on-device by collapsing every subpath back to one source file, the same bundler accident
+  behind the coachmark-runtime split and the optional-peers bug fixed above.
+
+  The context now lives on a `globalThis` slot keyed by
+  `Symbol.for("@wireai/activation:themeContext")`, exactly as `coachmarks/runtime`,
+  `analytics/currentSession`, `context/deviceId` and `features/WireFeaturesProvider` already did.
+  Measured in the built artifact, before and after: the root provider reached **0** of the four
+  subpath bundles' theme contexts before, and exactly **1 shared instance** after.
+  `test/canary/themeContextIdentity.test.tsx` loads the real bundles and pins it.
+
+- **`WireFeaturesProvider` read `global` where the other nine symbol slots read `globalThis`.**
+  `global` does not exist in a plain browser, so that line was a `ReferenceError` waiting for the
+  first RN-web or browser-SSR host to mount the provider.
+
+- **`maxRetries` never re-armed, so the fallback was unreachable on every host running the default.**
+  `maxRetries` defaults to `1`, and `1` and `2` behaved *identically*: exactly one retry fired, ever,
+  and no terminal state was ever reached. Measured before the fix — `0` → `{kickoffs:1, fallback:1}`,
+  `1` → `{kickoffs:1, fallback:0}`, `2` → `{kickoffs:1, fallback:0}`. Only `maxRetries={0}` reached
+  the fallback, which is the one value that trades the retry away entirely. A backend hung at start
+  therefore produced a 15s loader and then a permanent "Getting started…": no error, no fallback, no
+  way out. The "Try again" button was dead from the same cause, sending `1 → 1`.
+
+  Two causes, both required. `restartThread()` reset a **ref**, and a ref cannot re-trigger an
+  effect — the auto-start effect's deps held only stable values. And the startup watchdog keyed on
+  `lastCard`, which is still `undefined` after a retry, so no new timer ever armed and `timedOut`
+  could not become true a second time. Both effects now key on an incrementing `runId` held in
+  **state**, so a retry genuinely re-arms both; `started`/`resumed` deliberately do **not** re-fire,
+  so a retry cannot double-count a session in the host's funnel. After the fix, `maxRetries` means
+  what it says: `1` → `{kickoffs:2, fallback:1}`, `2` → `{kickoffs:3, fallback:1}`.
+
+  It survived a 638-test suite because the canary's `wireai-rn` mock hardcoded `error: undefined`,
+  leaving the entire error/retry/fallback state machine with **zero render coverage**. The mock
+  gained an error mode and the budget is now asserted for 0, 1 and 2 along with the timeout path
+  and the "Try again" button.
+
+- **A slow cold-start storage read silently destroyed the persisted analytics backlog.** The
+  hydration read races a 1500 ms deadline, and the loser resolved to `undefined` — indistinguishable
+  from "the adapter answered, there is no backlog". Hydration took its empty early return, the
+  surrounding `catch` never ran, and the next `persist()` wrote the in-memory list over the blob
+  nobody had read; with nothing pending it deleted the blob outright. Up to `maxSize` = **200**
+  real events lost on nothing worse than a cold start where storage took two seconds, with no error,
+  no log and nothing to grep for. A timeout is now a distinct sentinel, persistence is suppressed
+  until the read settles, and the original read is still awaited — the late backlog is merged and
+  flushed rather than abandoned. No test injected a slow adapter; one does now.
+
+- **A review rating was latched as posted before the request settled.** The once-gate was written
+  regardless, and the transport was a fire-and-forget `fetch` whose response was never read — so a
+  1-4 star rating with mandatory free text travelled the kit's least durable path while
+  `analytics.track` got a persisted queue with backoff and six retries. A detractor who rated
+  offline was dropped *and* never asked again. `submitReview` now reports delivery, the latch is
+  released when the row did not land, and the undelivered body is re-posted by the existing
+  abandonment net. ⚠️ Recovery is in-process only: a rating taken offline and then killed with the
+  app is still lost. A persisted review outbox is deliberately left for a later release.
+
+- **The coachmarks kill switch could leave a tour unable to finish.** The flag is a mutable global
+  read once with no subscription: the arm effect omitted it from its deps and the drive effect never
+  read it, so flipping it mid-tour made `show()` a silent no-op and left `finish()`/`onComplete`
+  unreachable. It is now subscribable and read through `useSyncExternalStore` in both effects, and a
+  mid-tour disable exits terminally **without** writing the once-gate, so the tour is not consumed.
+
+- **Four of the six optional peers were missing from the published bundle entirely.** Measured with
+  Metro's own dependency collector, the 0.13.2 tarball's `dist/` collected **2 of 6**
+  `OPTIONAL_MODULES` while the same collector over `src/` collected **6 of 6** — so on every
+  resolution path that lands on `dist/` (plain RN CLI, `unstable_enablePackageExports: false`, node,
+  jest) `@expo/vector-icons`, `expo-constants`, `expo-application` and `expo-device` were not in the
+  bundle at all: `WireIcon` renders null and `by_model` / `by_app_version` stay empty, with the
+  guard's own `catch` hiding it. Source consumers (both monorepo apps, and anything else taking
+  the `react-native` condition) were never affected, which is why a green suite and two shipping
+  apps said nothing. Two independent build-config faults, both silent at exit 0 with zero warnings:
+  - `tsup.config.ts` `external` was a hand-maintained list covering 2 of the 6. The consequence
+    depended on the BUILD MACHINE: a module that happened to resolve in the kit's own
+    `node_modules` (`expo-constants`, pulled in transitively) was **inlined whole** into the bundle,
+    so the host's copy went unused; one that did not resolve was left as an orphan call. `external`
+    is now **derived from `metro/index.js`'s `OPTIONAL_MODULES`** — the same list the Metro helper
+    already treats as the source of truth — plus the statically-imported peers, with a build-time
+    throw if the two ever diverge. The output no longer depends on what is installed here.
+  - Marking them `external` was necessary and **not sufficient**. `treeshake: true` is not an
+    esbuild flag; tsup implements it as a Rollup pass whose ESM output is then re-derived into CJS,
+    and in that conversion esbuild renames `require("expo-device")` to `__require("expo-device")`,
+    external or not. Metro's collector matches only a callee literally named `require`, so a
+    renamed call is collected nowhere — the 0.8.0 bug, reintroduced by a build flag rather than by
+    source. The build now carries a small `renderChunk` hook that restores the literal `require`
+    for exactly the `OPTIONAL_MODULES` specifiers, and only in CJS output, where the rewrite is an
+    identity (esbuild defines `__require` as `typeof require !== "undefined" ? require : …`, so in
+    a CJS chunk it already *is* `require`). `treeshake` stays on and every other byte of the bundle
+    keeps its current shape — `dist/index.js` is 218.6 KB, down from 232.2 KB purely because
+    `expo-constants` is no longer inlined. `dist/*.mjs` keeps `__require`: ESM has no `require` to
+    preserve, and no React Native path reads it (`react-native` → `src/`, `main` / the `require`
+    condition → `dist/*.js`).
+
+  `test/canary/metroResolution.test.tsx` ran Metro's collector over `src/` only, which is how a
+  publish-surface defect stayed invisible to the test that owns exactly this property. It now runs
+  the same assertions over the BUILT `dist/` (build-if-stale, never skipped), with its own negative
+  control pinning that a `__require`-shaped call collects nothing. Verified against the pre-fix
+  config: the new assertion goes red and names all four missing modules.
+
+- **The banned-name canary now actually gates a publish.** It was documented as a "build-time canary
+  that fails the pack" and it was neither: `prepack` was `npm run build` and ran no test at all, so a
+  planted banned name packed at **exit 0**, inside the tarball. The second half compounded it
+  — the canary derives its scan set from `package.json` `files`, which includes `dist`, but `dist` is
+  gitignored and sits in the scanner's `OPTIONAL_WHEN_ABSENT` list, so on an unbuilt tree the suite
+  was **6/6 green while covering none of the built output that ships**. Fixing either half alone
+  still ships a name under some ordering. The gate is now one script that closes both:
+  `prepublishOnly` = `npm run build && npm run test:canary`. It fires on `npm publish`, and it fires
+  *after* the build, so `dist/` is on disk and inside the scan. `test:canary` is a new script that
+  runs `test/canary/**` on its own, and `bannedNames.test.tsx` gained a test that asserts this wiring
+  from inside the suite, so deleting the gate goes red instead of silently reopening the hole.
+  ⚠️ `npm pack` on its own still does not run the canary — the honest verb is *publish*, not *pack*.
+
+### Changed
+
+- **Test integrity.** `npm test` now builds first (`pretest`), because the new `dist/` assertions
+  shell out to a build with `clean: true` while other test files walk `dist/` in parallel — that
+  race could redden CI for a reason unrelated to any change. Separately, the pre-existing
+  `DE-DUP: re-enqueuing an identical pending event is collapsed` test was **flaky on `main`**: it
+  fires three synchronous enqueues against a live clock while the queue stamps `ts` into the de-dup
+  signature, so a millisecond boundary between them makes the third a genuine repeat by the queue's
+  own rules. Measured at 0.32% of runs on an untouched `main`, 0/6000 with the clock frozen; it is
+  now pinned exactly as its three sibling tests already were. And `mergePersisted`'s de-dup branch
+  had **zero coverage** — it could be deleted with the whole suite green — which matters precisely
+  because the backlog fix above newly merges a late read into a pending list that may already hold
+  the same event. It is covered now.
+
+- **Four guards this release relies on had no test at all**, found by mutating the suite. Each one
+  was a promise made in writing and enforced by nothing, so each could be deleted with a fully green
+  run: (1) `started`/`resumed` not re-firing on a retry — stated right here as *"a retry cannot
+  double-count a session"*, and in tension with the `runId` re-arm by construction, so a host funnel
+  would have read one flaky cold start as three sessions; (2) `pretest` itself, whose removal
+  silently reopens the `clean: true` race described above; (3) both build-time throws in
+  `tsup.config.ts`, which are the only thing standing between a refactor of the `external`
+  derivation and a bundle that silently inlines or orphans every guarded optional peer at exit 0;
+  and (4) the dist half of `metroResolution`'s HARD-dependency check, which its own
+  `.filter((m) => !collected.has(m))` had rendered unfailable — a module collected optional in one
+  chunk excused a hard require of it in another, and Metro resolves per call site, not per package.
+
 ## [0.13.2] — 2026-07-31
 
 The headline is a fix: every `track()` / `screen()` `app_event` was being silently discarded by the
 server behind an HTTP 200, on every kit version since 0.11.0. This release also ships the injectable
 mid-flow permission screens below, and it is the FIRST version whose published tarball is clean of
-the banned client name — the 0.13.0 publish-surface scrub now rides a build-time canary that fails
-the pack if the name ever reappears.
+the banned client name — the 0.13.0 publish-surface scrub rides a canary that fails the run if the
+name ever reappears.
+
+> ⚠️ **Corrected 2026-08-02.** This paragraph originally said the canary "fails the pack". It did
+> not: at 0.13.2 nothing ran it on `npm pack` or `npm publish`, and on an unbuilt tree it did not
+> scan `dist/` either. The 0.13.2 tarball is still clean — that was verified by hand — but it was
+> clean without a gate holding it. See the 0.13.3 entry above for the fix.
 
 ### Fixed
 
@@ -146,7 +433,7 @@ direction: the kit now declines and says so, where it used to fabricate and retu
   the question's prompt text (tenant flows slugify it and cut at 32 chars), so re-wording a question mints
   a NEW key and a host reading `answers.interests` silently starts reading `undefined`.
   ⚠️ ~~**INERT UNTIL THE SERVER EMITS IT.** No deployed server sends `slot_id` today.~~
-  ✅ **CORRECTED 2026-07-28: this is LIVE.** The deployed server (`47dae92`) sends `slot_id` on
+  ✅ **CORRECTED 2026-07-28: this is LIVE.** The deployed server sends `slot_id` on
   `progress` for every AI-generated question, as `adaptive_<n>`, and for a configured question
   whenever the tenant set one. Where no slot is configured the field is absent and
   every path degrades to byte-identical 0.12.2 behaviour. Every fallback is decided
@@ -499,7 +786,7 @@ Architecture-audit fixes (#50/#51). One BEHAVIOR CHANGE, called out below.
   store-declaration implications). The blanket "No PII / nothing identifies a device" claims are
   scoped to the onboarding `userContext` prop + the `collectDeviceContext()` snapshot. `llms.txt`
   now lists the `/analytics`, `/reviews`, `/questionnaire` subpath surfaces.
-- Added the `session/sessionIdentity.integration.test.ts` dist-canary (PR #47/#48).
+- Added the `session/sessionIdentity.integration.test.ts` dist-canary.
 
 ## [0.10.0] - 2026-07-20
 

package/INTEGRATION_PROMPT.md

@@ -76,7 +76,13 @@ STEPS (do them in order, stop and ask if a convention is ambiguous):
    onboarding on `user_context.device_key` and never on `session_id` (those are separate id spaces
    and intersecting them returns zero rows). If my app has no single stable device key yet, say so
    instead of inventing one.
-11. Verify: type-check (and lint the changed files); test the flag-off + backend-error paths.
+11. Verify: type-check (and lint the changed files); test the flag-off + backend-error paths. Then
+   prove the events wiring actually works, because `/v1/events` answers 200 for a batch it discards:
+   behind an `if (__DEV__)` guard, call
+   `wireDoctor({ target: { serverUrl: WIREAI_SERVER_URL, apiKey: WIREAI_API_KEY }, storage })` from
+   `@wireai/activation/analytics` once at app root and log the report. Every check must come back
+   `ok`. A failing `round_trip` names the field the server refused. Remove the call, or leave it
+   dev-gated, once the report is green.
 
 Report back: the files you changed (path:line), the typecheck result, and anything you couldn't
 infer about my conventions.

package/README.md

@@ -234,10 +234,13 @@ import { WireOnboarding } from "@wireai/activation";
 | `onComplete` | `(result: { answers, raw }) => void` | Fires when the user taps the terminal recap's CTA. **Required.** |
 | `theme` | `Partial<OnboardingTheme>` | Brand colors/fonts/radius/spacing, deep-merged over a neutral default. |
 | `illustrations` | `Record<string, ReactNode>` | App artwork for `InterstitialCard`, keyed by name. |
+| `icons` | `Record<string, ReactNode>` | Your own icon nodes, keyed by the semantic name the AI emits (`{ instagram: <BrandIg/> }`). Checked first, so use it to put your brand mark on a choice card, to add names the vocabulary does not carry, or to get icons at all without installing `@expo/vector-icons`. Anything you leave out falls back to that optional peer, then to no icon. Never a crash. See [Icons](#icons). |
 | `validators` | `Record<string, StepValidator>` | Per-step, keyed by base-question key (e.g. `username`). Blocks advance + shows an inline error. When the backend sends a `progress.slot_id` for a screen, the kit looks up that slot FIRST and falls back to the question key, so a validator map written against today's keys keeps working. |
 | `permissionScreens` | `PermissionScreenConfig[]` | Priming screens injected mid-flow, starting with notifications. The screen explains why, and the OS dialog opens **only** on the primary tap, never on mount. Zero new dependencies: you inject `request`. See [Permission screens](#permission-screens-the-priming-pattern). |
 | `onSkip` | `() => void` | User skipped. |
-| `onError` | `(err) => void` | Backend error/timeout — host owns recovery (e.g. route to a static flow). Without it, the kit shows an inline retry. |
+| `onError` | `(err) => void` | Backend error or first-card timeout, fired **after retries are exhausted**, not on the first failure. When `fallbackFlow` is not supplied, the host owns recovery (e.g. route to a static flow). With neither, the kit shows an inline retry. `fallbackFlow` takes precedence over this. |
+| `fallbackFlow` | `ReactNode` | Your predefined STATIC onboarding, rendered in place once the AI flow fails and retries are exhausted. **Takes precedence over `onError`.** This is the "it can never break your onboarding" guarantee: pass the same flow you shipped before adding Wire AI and the user always keeps moving. |
+| `maxRetries` | `number` | Consecutive failures to auto-retry before degrading to `fallbackFlow`/`onError`. Default `1` (one silent retry, then degrade). `0` degrades on the first failure. Budget it deliberately: each retry restarts the flow, so with `startTimeoutMs` at its `15000` default the default `maxRetries` puts 30s of loader in front of a user before they see the fallback. A retry also sends a skip sentinel, so the user loses one question and a retry is never recorded as their first answer. |
 | `onEvent` | `(e: OnboardingEvent) => void` | `started` / `turn` / `error` — recover per-turn analytics since the kit owns the loop. |
 | `copy` | `Partial<OnboardingCopy>` | Localize the kit's built-in English loader/completion strings. |
 | `approxScreens` | `number` | Approx total screens — paces the bar as `step/total` (capped, never shown). A backend `progress.total` (the screen budget, sent every turn incl. init) wins, so usually unnecessary. |
@@ -247,6 +250,7 @@ import { WireOnboarding } from "@wireai/activation";
 | `storage` | `WireOnboardingStorage` | Host-injected storage (AsyncStorage-compatible `getItem/setItem/removeItem`) for **session-id persistence**: an app KILL mid-onboarding resumes the SAME backend session instead of minting a new one, so the funnel's `started` count stays honest (no phantom drops). Pass AsyncStorage as-is, or a 3-line MMKV wrapper. Omit for the previous per-mount behavior. Persists the kit's own correlation seed only — answers stay the host's job via `onComplete`. |
 | `sessionTtlMs` | `number` | How long a persisted session id stays resumable. Default `3600000` (1h, the backend's session TTL). With `storage` only. |
 | `persistKey` | `string` | Override the storage key (default `wireai:session:<appId>`). Scope per-user if one device can onboard multiple accounts mid-flow. With `storage` only. |
+| `retainSessionOnComplete` | `boolean` | Opt IN: keep the persisted session seed alive across completion. A multi-stage signup that re-enters onboarding (typically a `key=` remount) then resumes the SAME session instead of minting a fresh `metadata.sessionId`, which the backend adopts as a second `contextId` and double-counts as a `session_started`. Omitted or `false` clears the seed on completion, the legacy single-stage behavior, so leaving it unset changes nothing. With `true`, freshness comes from `sessionTtlMs` plus an explicit new-run signal (scope a new `persistKey`, e.g. a per-signup id). With `storage` only. |
 | `userContext` | `Record<string, string \| number \| boolean>` | **This is where the join key goes.** `user_context.device_key` is the only thing that joins this onboarding session to the app's later events, so pass `userContext={activationJoinContext(deviceKey)}` (or `activationJoinContext(resolveAutoDeviceKey({ appId, storage }))` if your app owns no device id). Since 0.12.2, omitting it no longer empties the funnel silently: with `storage`, the kit injects its own key (see [The join key](#the-join-key-device_key-never-session_id) and `autoJoinKey` below). Second job: any other non-PII context the app already knows (signup method, referral, plan, a HASHED user id), forwarded on session metadata + client events for funnel segmentation. **No PII on THIS prop** (no raw emails/names); primitives only; the server caps size/keys. See [Device & user context](#device--user-context). ⚠️ Distinct from the analytics/activation **`WireUserContext`** object (`createAnalytics` / `useWireActivation`), which additionally accepts an opt-in raw `userEmail` — see [Rich user context & PII](#rich-user-context--pii). |
 | `autoJoinKey` | `boolean` | Opt OUT of the automatic join key. Default `true`. When this prop is left alone, `storage` is present **and actually persists** (0.13.0: a `storage` adapter that rejects or throws is treated exactly like no `storage` — the kit declines and says so, because a key it cannot persist is a different key on every launch, which corrupts `min_sessions` rather than merely leaving the join empty), and `userContext` carries no `device_key`, the kit injects its own per-install key (the same id `createAnalytics` / `createWireActivation` mint and persist), so the `activated` funnel joins with no host wiring. Pass `autoJoinKey={false}` if you genuinely want an UNLINKED onboarding session: that restores the pre-0.12.2 behavior exactly, and the dev warning fires again. It never overrides a `device_key` you passed, and it cannot inject without `storage` (see [The join key](#the-join-key-device_key-never-session_id)). |
 | `userId` | `string` | Your own OPAQUE user id, so onboarding sessions reconcile to real users later (console sessions to your user table / GA4 users). Optional and supports **late binding**: present at mount it rides the session-start metadata; if it changes mid-session (the user just registered) the kit emits an `identify` event; available only after the flow, use `identifyOnboarding(...)`. **No PII** (not an email/name/phone); trimmed and capped at 128 chars. See [User identity](#user-identity). |
@@ -712,6 +716,56 @@ check, because a component name a device cannot render does **not** degrade grac
 `COMPONENT_NOT_FOUND` inside `wireai-rn` before the renderer ever sees it, and the user loses the
 turn to the retry/fallback path.
 
+## Verify your integration (`wireDoctor`)
+
+`POST /v1/events` answers **HTTP 200 for a batch it throws away**. It reports the refusal in the
+response body (`{written, skipped, errors: [{reason, field}]}`), never in the status code. So a
+mis-wired integration looks healthy from the outside while every event disappears. That is how a
+numeric `ts` discarded every `app_event` through 0.13.0.
+
+`wireDoctor` catches that on the first run instead of in a funnel report three weeks later.
+
+```tsx
+import { useEffect } from "react";
+import { wireDoctor } from "@wireai/activation/analytics";
+import AsyncStorage from "@react-native-async-storage/async-storage";
+
+useEffect(() => {
+  if (!__DEV__) return;
+  wireDoctor({
+    target: { serverUrl: DRIVELINE_SERVER_URL, apiKey: DRIVELINE_API_KEY },
+    storage: AsyncStorage,
+  }).then((report) => console.log(report.ok, report.checks));
+}, []);
+```
+
+It resolves `{ ok, checks: [{ name, ok, detail }] }` and **never throws**, whatever the target, the
+storage adapter or the network does. Four independent checks:
+
+| `name` | What it proves |
+|---|---|
+| `target` | `serverUrl` is a valid http(s) URL and an `apiKey` is present. Reports the key's SHAPE only (its length, and whether the prefix matches), never its value. |
+| `reachability` | `GET /v1/events/contract` answers, so the URL really points at a Wire server. |
+| `storage` | The offline queue can persist, via a write / read / delete probe on its own key. Your pending backlog is never read, overwritten or deleted. |
+| `round_trip` | One synthetic event survives real server validation. It goes out with `dry_run`, so nothing is written and no metric moves. The verdict is `written === 1 && skipped === 0`, read from the ack body, because the status code cannot tell you. |
+
+A `ts`-shaped drift shows up as `skipped=1` carrying the server's own `field: ts`.
+
+**Dev-only by contract.** The `__DEV__` guard is the first statement in the function, so a release
+build does nothing at all: no network call, no storage write. In that case the report says it was
+skipped rather than reporting a pass it never earned. A host that never imports `wireDoctor` does not
+bundle it.
+
+### The contract check
+
+The kit's `events-contract` CI job validates the payloads `buildEventsRequest` actually produces
+against the JSON Schema the production server publishes at
+`https://wire-rn-dynamic-onboarding.fly.dev/v1/events/contract`, one fixture per send path. Run it
+yourself with `npm run check:contract`.
+
+It fails, it never skips. An unreachable endpoint, a non-200 or an unparseable contract is a red
+job, because a check that has learned nothing must not report green.
+
 ## Consuming from source (Metro + tsconfig)
 
 The monorepo apps resolve the kit from source. In each app:
@@ -914,6 +968,18 @@ the "personalize from context" thesis. The once-gate
 It reads the active `OnboardingThemeProvider` theme; pass `theme` to override just
 the showcase, or `storage` / `isTesting` to gate independently of the provider.
 
+Until 0.13.3 that sentence only held on a phone. `OnboardingThemeProvider` ships from
+the root barrel, every subpath builds as its own bundle, and each of those bundles
+carried a private copy of the theme context. Metro hid it: its `react-native` export
+condition collapses all five subpaths back to one source file, so on-device the copies
+were the same object by accident. Everywhere else (plain RN CLI,
+`unstable_enablePackageExports: false`, node, jest, SSR) the provider wrote one context
+while the gate read another, and `useOnboardingTheme` quietly falls back to the neutral
+default theme instead of crashing. No error, no warning, wrong brand colors. The context
+now lives in one `Symbol.for` slot on `globalThis`, next to the feature flags and the
+coachmark runtime that already sat there, so a single provider themes every surface on
+every resolution path.
+
 **v2 server seam (future, not built).** The onboarding server's final turn will
 later return an ordered `showcase: string[]` slide-key list chosen server-side from
 the same answers; the host passes it straight in as the `selection` argument.
@@ -1293,7 +1359,7 @@ Least privilege: for the read-only loop, hand the agent just `WIREAI_SERVER_URL`
 A pure-Markdown Claude skill for *using* Wire AI easily: install the kit + wire the
 `WireOnboarding` provider, read your insights (via the MCP or `/v1/insights.md`), and run
 the improve loop (read insights, then adjust the app description / first question /
-generation context). It also carries the `BOILERPLATE20` credit note. For the full
+generation context). For the full
 scaffold-the-screen integration job, the [`wire-rn-integration`](./INTEGRATION_PROMPT.md)
 skill drives it end to end.
 

package/dist/analytics/index.d.mts

@@ -1,10 +1,10 @@
-export { R as ReportAppEventOptions, r as reportAppEvent } from '../transport-CF_eHwzC.mjs';
-import { W as WireUserContext, E as EventQueueOptions } from '../currentSession-ClkLjcJ0.mjs';
-export { A as AUTO_DEVICE_ID_PREFIX, a as AnalyticsEvent, C as ClearUserContextOptions, b as ClientEvent, c as ClientEventTarget, d as ClientEventType, e as ContextEnvelope, f as ContextEnvelopeInput, D as DeviceKeyStorage, g as EnvelopeSource, h as EventQueue, R as ResolveAutoDeviceKeyOptions, i as WIRE_ONBOARDING_EVENTS, j as WireOnboardingEventName, k as analyticsUserIdStorageKey, l as buildContextEnvelope, m as clearPiiFromContext, n as clearUserContext, o as createEventQueue, p as deviceIdStorageKey, q as ensureCurrentSessionId, r as getCurrentSessionId, s as looksLikeEmail, t as makeSessionId, u as reportClientEvent, v as reportClientEventAwait, w as reportClientEvents, x as reportClientEventsAwait, y as resetAutoDeviceKeys, z as resetCurrentSessionId, B as resetEventQueueKeys, F as resolveAutoDeviceKey, G as setCurrentSessionId, H as toAnalyticsEvent } from '../currentSession-ClkLjcJ0.mjs';
-import '../types-CNUqMK0D.mjs';
+export { R as ReportAppEventOptions, r as reportAppEvent } from '../transport-j5gFfJhK.mjs';
+import { C as ClientEventTarget, W as WireUserContext, E as EventQueueOptions } from '../currentSession-DgJf0fRz.mjs';
+export { A as AUTO_DEVICE_ID_PREFIX, a as AnalyticsEvent, b as ClearUserContextOptions, c as ClientEvent, d as ClientEventType, e as ContextEnvelope, f as ContextEnvelopeInput, D as DeviceKeyStorage, g as EnvelopeSource, h as EventQueue, R as ResolveAutoDeviceKeyOptions, i as WIRE_ONBOARDING_EVENTS, j as WireOnboardingEventName, k as analyticsUserIdStorageKey, l as buildContextEnvelope, m as clearPiiFromContext, n as clearUserContext, o as createEventQueue, p as deviceIdStorageKey, q as ensureCurrentSessionId, r as getCurrentSessionId, s as looksLikeEmail, t as makeSessionId, u as reportClientEvent, v as reportClientEventAwait, w as reportClientEvents, x as reportClientEventsAwait, y as resetAutoDeviceKeys, z as resetCurrentSessionId, B as resetEventQueueKeys, F as resolveAutoDeviceKey, G as setCurrentSessionId, H as toAnalyticsEvent } from '../currentSession-DgJf0fRz.mjs';
+import { W as WireOnboardingStorage } from '../types-BpwiRpA8.mjs';
+import '../types-Cju-1_jT.mjs';
 import '../types-BKfpdZzX.mjs';
 import '../types-BcmagF6K.mjs';
-import '../types-CKFhyrMu.mjs';
 import 'react';
 import 'wireai-rn';
 import 'react-native';
@@ -95,6 +95,86 @@ interface NavigationRefLike {
  */
 declare const useScreenTracking: (navigationRef: NavigationRefLike | undefined, options?: ScreenTrackerOptions) => void;
 
+/**
+ * wireDoctor: a DEV-ONLY, opt-in self-check that proves a fresh integration end to end before the
+ * first real user ever runs it.
+ *
+ * WHY IT EXISTS: the `/v1/events` endpoint answers HTTP **200** for a batch it throws away. It
+ * reports the refusal in the response body (`{written, skipped, errors:[{reason, field}]}`), so a
+ * mis-wired integration looks perfectly healthy from the outside while every event evaporates. A
+ * numeric `ts` did exactly that through 0.13.0. This turns that class of loss from something you
+ * discover in a funnel report weeks later into something the first run tells you.
+ *
+ * SHAPE: four independent checks, each a `{name, ok, detail}` unit that can be read (and tested)
+ * without the others. The report is data, never a thrown error and never a side effect on the host:
+ *
+ *   1. `target`      : is there a server URL and a key, and do they look like a key and a URL?
+ *   2. `reachability`: is the server actually there? (`GET /v1/events/contract`, public and cheap)
+ *   3. `storage`      : can the offline queue persist? (a write / read / delete probe)
+ *   4. `round_trip`   : does a REAL event survive REAL server validation? (a `dry_run` POST)
+ *
+ * NEVER THROWS, under any input, any network condition, or any hostile response object. A doctor
+ * that can crash the screen it is diagnosing is worse than no doctor.
+ *
+ * ⛔ NEVER PRINTS A SECRET. The `target` check reports the key's SHAPE (present / absent, length,
+ * whether the prefix is the expected one) and never any character of the key itself, in any
+ * `detail`, any log line, or any error. `wireDoctor.test.ts` asserts that with a sentinel key.
+ *
+ * COSTS A NON-CALLER NOTHING: it is a plain function behind the `./analytics` subpath, the package
+ * is `sideEffects: false`, and this module has no top-level side effects, so a host that never
+ * imports it never bundles it. It also mints no `globalThis` slot and retains no timer or listener.
+ *
+ * USAGE (dev builds only):
+ *
+ *   import { wireDoctor } from "@wireai/activation/analytics";
+ *
+ *   const report = await wireDoctor({
+ *     target: { serverUrl: "https://api.example.com", apiKey: DRIVELINE_KEY },
+ *     storage: AsyncStorage,
+ *   });
+ *   console.log(report.ok, report.checks);
+ */
+
+/** One diagnosis. `name` is stable and machine-readable; `detail` is for a human reading a console. */
+type WireDoctorCheck = {
+    /**
+     * Stable id: `target` | `reachability` | `storage` | `round_trip` | `dev_only` | `internal_error`.
+     *
+     * `dev_only` means ONE thing and only that thing: `__DEV__` is unset or false, so nothing ran.
+     * `internal_error` is the separate catch-all for a failure that got past every check's own
+     * swallow. They are distinct names because a consumer branching on `dev_only` would otherwise
+     * read an internal fault as "this is a release build" and report a healthy skip.
+     */
+    name: string;
+    ok: boolean;
+    /** Human-readable result. ⛔ Never contains any part of an API key. */
+    detail: string;
+};
+/** What {@link wireDoctor} resolves to. `ok` is true only when EVERY check passed. */
+type WireDoctorReport = {
+    ok: boolean;
+    checks: WireDoctorCheck[];
+};
+/** Input for {@link wireDoctor}. `storage` is optional: without it the queue runs in-memory only. */
+type WireDoctorOptions = {
+    /** The same `{serverUrl, apiKey}` the kit is configured with. */
+    target: ClientEventTarget | undefined;
+    /**
+     * The host storage the offline queue would use (AsyncStorage-compatible). Omit it and the storage
+     * check reports the DEGRADED in-memory mode rather than failing.
+     */
+    storage?: WireOnboardingStorage;
+};
+/**
+ * Run the full diagnosis. Resolves a report; NEVER throws and NEVER rejects.
+ *
+ * DEV-ONLY BY CONTRACT: the `__DEV__` guard is the FIRST statement, so a release build performs no
+ * network call, no storage write, and no work at all. The report says it was skipped rather than
+ * pretending everything passed, because a green report that never ran is the exact failure mode
+ * this whole feature exists to remove.
+ */
+declare const wireDoctor: (options: WireDoctorOptions) => Promise<WireDoctorReport>;
+
 /** Arbitrary non-PII event properties. Serialized to the event's `meta` (a JSON string) on the wire. */
 type AnalyticsProps = Record<string, unknown>;
 /**
@@ -203,4 +283,4 @@ declare const createAnalytics: (config: CreateAnalyticsConfig, options?: Analyti
  */
 declare const useAnalytics: (config: CreateAnalyticsConfig, options?: AnalyticsOptions) => Analytics;
 
-export { type Analytics, type AnalyticsOptions, type AnalyticsProps, type CreateAnalyticsConfig, EventQueueOptions, type NavigationRefLike, type NavigationRouteLike, type NavigationStateLike, type ScreenTracker, type ScreenTrackerOptions, createAnalytics, createScreenTracker, getActiveRouteName, screenTrackingHandler, useAnalytics, useScreenTracking };
+export { type Analytics, type AnalyticsOptions, type AnalyticsProps, ClientEventTarget, type CreateAnalyticsConfig, EventQueueOptions, type NavigationRefLike, type NavigationRouteLike, type NavigationStateLike, type ScreenTracker, type ScreenTrackerOptions, type WireDoctorCheck, type WireDoctorOptions, type WireDoctorReport, createAnalytics, createScreenTracker, getActiveRouteName, screenTrackingHandler, useAnalytics, useScreenTracking, wireDoctor };