@wireai/activation 0.13.2 → 0.13.3

package/src/theme/ThemeContext.tsx

@@ -3,12 +3,53 @@
  * themed card via `useOnboardingTheme()`. WHY a context rather than prop-drilling:
  * the cards are mounted by the SDK's ComponentRenderer (not by us), so we can't
  * pass them props directly — they must read the theme from context.
+ *
+ * ── WHY THE CONTEXT LIVES ON A `Symbol.for` SLOT ───────────────────────────────────────────────
+ *
+ * It was a plain `createContext(...)`, and tsup inlines this module into FIVE dist bundles
+ * (`.`, `./reviews`, `./questionnaire`, `./coachmarks`, `./showcase`) — so each one carried its own
+ * context 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` was writing one context and reading another. Nothing crashed and
+ * nothing warned: `useOnboardingTheme`'s `ctx ?? mergeTheme()` fallback quietly served the NEUTRAL
+ * default theme, so the tenant's brand simply did not apply to the gate. On-device this was masked
+ * only because Metro's `react-native` export condition collapses every subpath back to this one
+ * `src/` file — the same "bundler accident, not a guarantee" the `currentSession` header names, and
+ * the same root cause as the optional-peers bug 0.13.3 fixed.
+ *
+ * The bundler-agnostic fix, exactly as `coachmarks/runtime`, `analytics/currentSession`,
+ * `context/deviceId` and `features/WireFeaturesProvider` already do it: park the ONE context on a
+ * well-known `globalThis` slot keyed by `Symbol.for(...)`. `Symbol.for` uses the runtime-global
+ * symbol registry, so every inlined copy of this module resolves the SAME symbol, finds the slot
+ * already filled, and reuses that instance — one context identity however many copies exist.
+ * `globalThis` is present and identical in Hermes/React Native, Node and SSR (we never touch
+ * `window`), so this is safe on every host. `test/canary/themeContextIdentity.test.tsx` measures it
+ * in the BUILT artifact, because the defect is invisible in source.
  */
 import React, { createContext, useContext, useMemo } from "react";
 import { mergeTheme } from "./defaultTheme";
 import type { OnboardingTheme } from "./types";
 
-const OnboardingThemeContext = createContext<OnboardingTheme | null>(null);
+/**
+ * Well-known key into the runtime-global symbol registry. `Symbol.for` (NOT a plain `Symbol()`) is
+ * what makes this cross-bundle: it returns the SAME symbol for the same string across every copy of
+ * this module, so duplicated inlined copies all address one slot.
+ */
+const THEME_CONTEXT_SLOT: unique symbol = Symbol.for("@wireai/activation:themeContext");
+
+type GlobalWithThemeContext = typeof globalThis & {
+  [THEME_CONTEXT_SLOT]?: React.Context<OnboardingTheme | null>;
+};
+
+const themeGlobal = globalThis as GlobalWithThemeContext;
+
+// First copy to load creates the context; every later copy adopts it. Never overwrite an existing
+// slot — a second `createContext` here would re-split the identity this guard exists to keep whole.
+if (!themeGlobal[THEME_CONTEXT_SLOT]) {
+  themeGlobal[THEME_CONTEXT_SLOT] = createContext<OnboardingTheme | null>(null);
+}
+const OnboardingThemeContext = themeGlobal[THEME_CONTEXT_SLOT] as React.Context<OnboardingTheme | null>;
 
 export type OnboardingThemeProviderProps = {
   /** Partial overrides merged over the neutral default theme. */

package/src/types.ts

@@ -340,7 +340,7 @@ export type OnboardingProgress = {
    * `answers.interests` silently becomes `answers.what_are_you_into_v2`, with no error anywhere. A
    * slot is the question's identity independent of its wording.
    *
-   * FULLY ADDITIVE, AND LIVE SINCE 2026-07-28 (server `47dae92`). The deployed server sends it on
+   * FULLY ADDITIVE, AND LIVE SINCE 2026-07-28. The deployed server sends it on
    * `progress` for every AI-GENERATED question, as `adaptive_<n>` 1-based over adaptive answers, and
    * for a CONFIGURED question only when the tenant set one. Where the tenant set none the field is
    * simply absent. Every fallback is PER-CARD, so a thread that mixes slotted and unslotted cards

package/src/utils/submitResult.ts

@@ -0,0 +1,39 @@
+/**
+ * submitResult — the ONE delivery verdict every user-payload POST in this kit reports back.
+ *
+ * WHY IT IS SHARED, AND WHY IT IS NOT A BOOLEAN. Two surfaces post a payload the user typed —
+ * `submitReview` (`reviews/transport.ts`) and `submitQuestionnaireResponse`
+ * (`questionnaire/transport.ts`) — and NEITHER has a persisted queue behind it (unlike
+ * `analytics/eventQueue`, with its `maxSize`/`maxRetries`/backoff). Both sit behind a permanent
+ * once-gate: the host writes `wire_review_<id>_seen` / `wire_questionnaire_<id>_<ver>_seen` when the
+ * gate resolves, so a payload that dies in the socket is lost AND the user is never asked again.
+ * Reading the fate of the request is the only thing that lets a caller keep an undelivered payload
+ * recoverable, so the two surfaces must answer the same question in the same words.
+ *
+ *   • `accepted` — the server answered 2xx. Stored.
+ *   • `rejected` — the server ANSWERED, non-2xx. It was reached; it either stored the payload and
+ *                  lost the ack (a gateway 502 after the write commits) or deliberately refused it.
+ *                  Either way the server owns the outcome and a re-post risks a SECOND row.
+ *   • `unsent`   — nothing came back at all: no target, a missing/throwing `fetch`, a rejected
+ *                  request. **This is the ONLY outcome a caller may retry on.**
+ *
+ * ── WHY THREE VALUES AND NOT TWO (pinned here so the defect cannot move surface) ───────────────
+ *
+ * `submitReview` was a boolean for exactly one unpublished release, and the boolean WAS the bug.
+ * `false` meant both "nothing reached the server" and "the server answered non-2xx", and the caller
+ * treats `false` as "still owed" and re-posts. But the server mints its own row id
+ * (`create_review` / `_new_id()`), and neither `CreateReviewRequest` nor the questionnaire response
+ * body carries a client id, so there is NO idempotency key on the wire: a 502 returned AFTER the
+ * insert commits means the re-post writes a SECOND row. A response of any status proves the server
+ * was reached, and that is a different question from whether it liked the payload.
+ *
+ * ── THE RESIDUAL, STATED HONESTLY ─────────────────────────────────────────────────────────────
+ *
+ * `unsent` is not proof the server never got it. A connection dropped after the request was written
+ * — or after the row committed — surfaces as a thrown/rejected `fetch`, exactly like an offline
+ * device. Retrying only on `unsent` is therefore SAFER, not SAFE. Closing that window needs a
+ * CLIENT-MINTED IDEMPOTENCY KEY the server upserts on, which is a server change and not something
+ * the kit can fake. Until it exists, prefer losing a row over inventing one: a lost detractor is a
+ * gap in the data, a duplicated one is a lie in the data.
+ */
+export type SubmitResult = "accepted" | "rejected" | "unsent";