@scalebun/web 1.0.0

package/dist/features/engage/richInApp.js

@@ -0,0 +1,1082 @@
+import { readableOn, sanitizeTheme } from './theme';
+import { makeGameResolver } from './gameResolver';
+import { engageSlots, hasInAppSlot, slotNameFor } from './inappSlots';
+import { inAppGameActionFor } from './gameLogic';
+const rec = (v) => (v && typeof v === 'object' && !Array.isArray(v) ? v : {});
+const str = (v) => (typeof v === 'string' && v.length > 0 ? v : undefined);
+const num = (v, d) => (typeof v === 'number' && Number.isFinite(v) ? v : d);
+/**
+ * The display text of an authored row, whatever the author called the field.
+ *
+ * This read `label` and only `label`, while the registry authors carousel slides and products as
+ * `{ title: 'Cloud Sneakers' }` — so every slide and every product card shipped with an empty
+ * caption. The authoring preview has always read `label ?? title ?? text ?? name`, so the two sides
+ * disagreed about the content while agreeing about the block, which is exactly the gap no parity
+ * check on block KINDS can see. Widened to match the preview.
+ */
+const labelOf = (x) => {
+    if (typeof x === 'string')
+        return x;
+    const o = rec(x);
+    return str(o.label) ?? str(o.title) ?? str(o.text) ?? str(o.name) ?? '';
+};
+const listOf = (ext, keys) => {
+    for (const k of keys)
+        if (Array.isArray(ext[k]))
+            return ext[k];
+    return [];
+};
+/**
+ * Archetypes this bridge can actually build a mechanic for. Anything else — including a served
+ * archetype from a newer registry than this SDK — degrades to the widget and is REPORTED.
+ * Kept as data so the check is one lookup rather than a switch that silently returns [].
+ */
+const RENDERABLE_ARCHETYPES = new Set([
+    'spinWheel', 'scratchReveal', 'slotReward', 'carouselDeck', 'countdown',
+    'questionFlow', 'checklistProgress', 'qrNfc', 'videoCommerce', 'celebration',
+    // R1 — additive layout archetypes. The legacy widget draws seven fixed layouts and has neither a
+    // side-docked panel nor a wizard, so both belong on the rich path even though they are containers
+    // rather than mechanics.
+    'multiStepSheet', 'sideSheet',
+]);
+/**
+ * Archetypes that dictate their own SURFACE, overriding the one derived from `m.layout`.
+ *
+ * Both come straight from the registry's own layout defaults: `sideSheet` is
+ * `position:'right', slide_in_right`, and multiStepSheet "keeps the bottom-sheet defaults … it IS a
+ * bottom sheet, just wizard-paged". Neither needed a new surface — `slideover` already docks to an
+ * edge; it simply had no bottom placement until R1 added one.
+ */
+const ARCHETYPE_SURFACE = {
+    sideSheet: { surface: 'slideover', surfaceOptions: { placement: 'right' } },
+    multiStepSheet: { surface: 'slideover', surfaceOptions: { placement: 'bottom' } },
+};
+/**
+ * LEGACY FALLBACK — superseded by the served `spec.ext.archetype`.
+ *
+ * This map covered 29 of the registry's 100 variants while the dashboard preview resolved
+ * `archetype` from the registry itself and covered all 100 — so the two had drifted by 71 keys and
+ * an author could preview a distinct mechanic while the SDK shipped a plain modal. The registry
+ * states the intended design outright: "`archetype` is DATA so the SDK resolves
+ * ARCHETYPES[def.archetype]". The SDK cannot ship the 55 KB registry against a ~570 B core budget,
+ * so the backend now resolves it and serves it on `ext`.
+ *
+ * Retained ONLY for payloads served before that shipped; it is not extended. Adding a key here
+ * would re-open the drift this exists to close — the fix for a missing mechanic is the registry,
+ * which the backend already reads.
+ */
+const KEY_TO_ARCHETYPE = {
+    spin_wheel: 'spinWheel',
+    scratch_card: 'scratchReveal', mystery_box: 'scratchReveal',
+    slot_reward: 'slotReward',
+    carousel_story: 'carouselDeck', swipe_deck: 'carouselDeck',
+    countdown_offer: 'countdown',
+    poll_card: 'questionFlow', survey_sheet: 'questionFlow', nps_prompt: 'questionFlow',
+    quiz_card: 'questionFlow', product_finder: 'questionFlow', preferences_picker: 'questionFlow',
+    feedback_capture: 'questionFlow', emoji_reaction_bar: 'questionFlow', rating_request: 'questionFlow',
+    progress_unlock: 'checklistProgress', streak_reward: 'checklistProgress', daily_check_in: 'checklistProgress',
+    goal_tracker: 'checklistProgress', interactive_checklist: 'checklistProgress', guided_setup_wizard: 'checklistProgress',
+    first_session_onboarding: 'checklistProgress', community_challenge: 'checklistProgress',
+    milestone_celebration: 'celebration', celebration_confetti_full_screen: 'celebration',
+    nfc_qr_prompt: 'qrNfc', wallet_pass_offer: 'qrNfc',
+    video_commerce_card: 'videoCommerce',
+};
+let onDegrade = null;
+/**
+ * Observe rich-render fall-throughs.
+ *
+ * C4 requires that an unmapped variantKey "degrades to the widget AND reports it". Previously it
+ * degraded in total silence, which is indistinguishable from working — the same failure mode as a
+ * wheel that always lands on segment 0.
+ */
+export function onRichDegrade(fn) {
+    onDegrade = fn;
+}
+/**
+ * The host's gamified-outcome handler, supplied via `engageOptions.onInAppGameRequest`.
+ *
+ * Module-level rather than threaded through every call, mirroring `onRichDegrade` above: the
+ * bootstrap sets it once from config and the render path reads it. Absent handler → the eight game
+ * variants render their unavailable state, never a fabricated prize.
+ */
+let gameHandlerRef = null;
+export function setInAppGameHandler(fn) {
+    gameHandlerRef = fn;
+}
+function report(d) {
+    try {
+        onDegrade?.(d);
+    }
+    catch { /* an observer must never break rendering */ }
+}
+/**
+ * Resolve the render archetype for a message.
+ *
+ * Order is deliberate: the SERVED archetype wins, because the backend resolved it from the
+ * canonical registry — the single source the dashboard preview also reads. The local map is only
+ * consulted for payloads served before the backend started stamping it.
+ */
+export function richArchetype(variantKey, servedArchetype) {
+    const served = typeof servedArchetype === 'string' && servedArchetype ? servedArchetype : null;
+    if (served)
+        return RENDERABLE_ARCHETYPES.has(served) ? served : null;
+    return (variantKey && KEY_TO_ARCHETYPE[variantKey]) || null;
+}
+/** The archetype the config served for this message, if any. */
+function servedArchetypeOf(spec) {
+    const v = spec?.ext?.['archetype'];
+    return typeof v === 'string' && v ? v : undefined;
+}
+/**
+ * Does this engage message use a rich mechanic variant the basic widget can't render?
+ *
+ * Reports the two distinct fall-through reasons instead of returning a bare false: a CONTAINER
+ * archetype (modal/banner/…) legitimately belongs to the widget, whereas a mechanic archetype this
+ * SDK doesn't know is a version gap the host should be able to see.
+ */
+export function isRichInApp(m, resolvedSpec) {
+    // Defaults to the base spec, but callers that have already run A/B resolution MUST pass the
+    // resolved one: variant B carries its own `ext`, so deciding from the base spec here and building
+    // from the resolved spec later can pick two different archetypes for the same render.
+    const served = servedArchetypeOf(resolvedSpec ?? m.spec);
+    const arch = richArchetype(m.variantKey, served);
+    if (arch)
+        return true;
+    if (served) {
+        // Only a MECHANIC archetype we can't build is worth reporting; containers are the widget's job.
+        if (!CONTAINER_ARCHETYPES.has(served)) {
+            report({ variantKey: m.variantKey, reason: 'unrenderable', archetype: served });
+        }
+        return false;
+    }
+    if (m.variantKey)
+        report({ variantKey: m.variantKey, reason: 'unmapped' });
+    return false;
+}
+/**
+ * Archetypes the legacy widget renders correctly — a fall-through here is expected, not a gap.
+ * `multiStepSheet`/`sideSheet` are deliberately NOT listed: the widget has no wizard and no
+ * edge-docked panel, so they take the rich path (see ARCHETYPE_SURFACE).
+ */
+const CONTAINER_ARCHETYPES = new Set([
+    'modal', 'sheet', 'bannerToast', 'fullscreen', 'anchored', 'inline',
+]);
+/**
+ * MOUNT MODEL → surface. The registry's own answer to "where does this attach?", served on `ext`.
+ *
+ * `LAYOUT_SURFACE` below maps the LEGACY layout — a seven-value mobile enum with no way to say
+ * "anchored to an element" or "inline in the document", so those variants fell through to a modal or
+ * a corner toast. Measured across all 100: **10 mounted on the wrong surface**. An Inline Card meant
+ * for a feed opened as a centred modal with a backdrop; a tooltip anchored to a button appeared
+ * bottom-right. The authoring preview mounts by mount model, so author and visitor saw different
+ * placements while every block-level gate stayed green.
+ *
+ * `inline` is deliberately ABSENT — see `mountSurfaceFor`.
+ */
+const MOUNT_SURFACE = {
+    overlay: { surface: 'modal', surfaceOptions: { placement: 'center', size: 'md', backdrop: true } },
+    sheet: { surface: 'slideover', surfaceOptions: { placement: 'right', resizable: true } },
+    banner: { surface: 'banner', surfaceOptions: { placement: 'top' } },
+    fullscreen: { surface: 'takeover' },
+    toast: { surface: 'toast', surfaceOptions: { placement: 'bottom-right' } },
+    bubble: { surface: 'toast', surfaceOptions: { placement: 'bottom-right' } },
+    anchored: { surface: 'popover', surfaceOptions: { placement: 'bottom', maxWidth: 320 } },
+};
+/**
+ * Resolve a served mount model, or null to keep the legacy mapping.
+ *
+ * INLINE IS NOT MAPPED, on purpose. The inline surface renders into a host-registered slot and
+ * `renderVariant` returns `inert()` when no `SlotRegistry` is supplied — and this bridge does not
+ * supply one. Mapping it "correctly" would turn four variants (inline_card, embedded_panel,
+ * empty_state_prompt, smart_inbox_message) from a WRONG surface into NO surface, which is a worse
+ * failure: a modal in the wrong place is at least visible and reportable. Closing it properly means
+ * threading a slot registry through this path and having the host register a mount point, which
+ * changes what an existing campaign does — a product decision, not a mapping fix. Until then these
+ * four keep the legacy modal and the divergence is recorded in the surface-parity gate rather than
+ * being silently "fixed" into invisibility.
+ */
+function mountSurfaceFor(ext) {
+    const mount = str(ext.mountModel);
+    if (!mount)
+        return null;
+    /**
+     * `inline` is placement-conditional, not unconditional.
+     *
+     * The inline surface renders into a HOST-REGISTERED slot and goes inert without one, so mapping it
+     * blindly would turn four variants from a wrong surface into no surface — invisible rather than
+     * misplaced. It is chosen only when the page actually has the slot this campaign names; otherwise
+     * the legacy modal stands and the fall-through is reported, so "my inline card opens as a popup"
+     * has an answer instead of being a mystery.
+     */
+    if (mount === 'inline') {
+        const name = slotNameFor(ext);
+        if (!name || !hasInAppSlot(ext)) {
+            report({ reason: 'unrenderable', archetype: 'inline' });
+            return null;
+        }
+        return { surface: 'inline', surfaceOptions: { slot: name } };
+    }
+    return MOUNT_SURFACE[mount] ?? null;
+}
+const LAYOUT_SURFACE = {
+    modal: { surface: 'modal', surfaceOptions: { placement: 'center', size: 'md', backdrop: true } },
+    fullscreen: { surface: 'takeover' },
+    bottom_sheet: { surface: 'slideover', surfaceOptions: { placement: 'bottom' } },
+    top_banner: { surface: 'banner', surfaceOptions: { placement: 'top' } },
+    bottom_banner: { surface: 'banner', surfaceOptions: { placement: 'bottom' } },
+    tooltip: { surface: 'toast', surfaceOptions: { placement: 'bottom-right' } },
+    toast: { surface: 'toast', surfaceOptions: { placement: 'bottom-right' } },
+};
+/**
+ * `variantKey` is passed alongside the archetype because the registry maps several DISTINCT
+ * variants onto one archetype (mystery_box and scratch_card both resolve to `scratchReveal`). The
+ * archetype picks the mechanic; the key selects the presentation within it.
+ */
+/**
+ * Progress as a PERCENTAGE, from authoring that writes a fraction.
+ *
+ * Every authored example in the registry writes `progress: 0.8` meaning 80%, and the progress block
+ * clamps to 0–100 — so 0.8 rendered a bar that was 0.8% full. Visually that is an empty bar, which
+ * is indistinguishable from "no data", so the bug read as a missing value rather than a wrong one.
+ *
+ * 0–1 is treated as a fraction. That makes a literal 1% unauthorable through this path, which is the
+ * right trade: no example authors 1%, every example authors fractions, and the alternative silently
+ * blanks the common case.
+ */
+const pctOf = (raw, fallback) => {
+    const n = Number(raw);
+    if (!Number.isFinite(n))
+        return fallback;
+    return n > 0 && n <= 1 ? n * 100 : n;
+};
+/**
+ * An absolute deadline from either an ISO timestamp or an authored DURATION.
+ *
+ * `countdown_offer` requires `expiryTime` and its example authors `'02:45:18'` — hours:minutes:seconds
+ * remaining, not a date. The countdown block takes an absolute instant, so a duration has to be
+ * resolved against now or the block ships with `to: undefined` and renders nothing.
+ */
+/**
+ * Which wheel segment the SERVER decided, resolved without a shred of client randomness.
+ *
+ * The outcome is server-authoritative everywhere in this system, and the bridge simply never read
+ * it — so a served result was discarded and the block's `|| 0` default meant every visitor won
+ * segment 0. Precedence mirrors the authoring preview's `resolveWheelPreviewWinner` exactly, so a
+ * campaign that previews a win on segment 3 ships a win on segment 3:
+ *
+ *   numeric index → segment/outcome id → result label → segment 0
+ *
+ * Landing on 0 stays the final fallback rather than picking randomly: a client that chooses its own
+ * prize is a client that can be made to choose again.
+ */
+const resolveWinningIndex = (segments, ext) => {
+    if (!segments.length)
+        return 0;
+    for (const key of ['resultIndex', 'winningIndex']) {
+        const n = Number(ext[key]);
+        if (Number.isInteger(n) && n >= 0 && n < segments.length)
+            return n;
+    }
+    const idOf = (v) => {
+        const o = rec(v);
+        return str(o.id) ?? str(o.segmentId) ?? str(o.key) ?? str(o.value);
+    };
+    const wantedId = str(ext.segmentId ?? ext.winningId ?? ext.resultId ?? ext.outcomeId);
+    if (wantedId) {
+        const i = segments.findIndex((s) => idOf(s) === wantedId);
+        if (i >= 0)
+            return i;
+    }
+    const wantedLabel = str(ext.resultState ?? ext.rewardValue ?? ext.prize ?? ext.rewardResult ?? ext.resultReward);
+    if (wantedLabel) {
+        const target = wantedLabel.trim().toLowerCase();
+        const i = segments.findIndex((s) => labelOf(s).trim().toLowerCase() === target);
+        if (i >= 0)
+            return i;
+    }
+    return 0;
+};
+const countdownProps = (ext) => {
+    const target = deadlineFrom(ext);
+    if (target)
+        return { target };
+    const hrs = Number(ext.durationHours ?? ext.hours);
+    return { durationMs: (Number.isFinite(hrs) && hrs > 0 ? hrs : 24) * 3600000 };
+};
+const deadlineFrom = (ext) => {
+    const absolute = str(ext.endsAt) ?? str(ext.deadline) ?? str(ext.to) ?? str(ext.endAt);
+    if (absolute)
+        return absolute;
+    const raw = str(ext.expiryTime) ?? str(ext.expiresAt);
+    if (!raw)
+        return undefined;
+    // An ISO-ish string parses directly; only a bare hh:mm:ss / mm:ss falls through to the duration path.
+    const parsed = Date.parse(raw);
+    if (Number.isFinite(parsed))
+        return new Date(parsed).toISOString();
+    const parts = raw.split(':').map((p) => Number(p));
+    if (!parts.length || parts.some((p) => !Number.isFinite(p)))
+        return undefined;
+    const [h = 0, m = 0, s = 0] = parts.length === 3 ? parts : [0, ...parts];
+    const ms = ((h * 60 + m) * 60 + s) * 1000;
+    return ms > 0 ? new Date(Date.now() + ms).toISOString() : undefined;
+};
+function mechanicBlocks(arch, ext, title, variantKey, body) {
+    switch (arch) {
+        case 'spinWheel': {
+            const rawSegments = listOf(ext, ['segments', 'prizes', 'rewards']);
+            return [{
+                    kind: 'spinwheel',
+                    props: {
+                        segments: rawSegments.map(labelOf).filter(Boolean),
+                        // Honour a SERVED outcome. Without this the block's own `|| 0` default applied and every
+                        // visitor landed on segment 0 even when the server had already decided otherwise.
+                        resultIndex: resolveWinningIndex(rawSegments, ext),
+                    },
+                }];
+        }
+        case 'scratchReveal':
+            /**
+             * `scratch_card` and `mystery_box` share this archetype but are NOT the same thing.
+             *
+             * The registry declares distinct renderers (ScratchCardRenderer / MysteryBoxRenderer) and then
+             * collapses both onto `scratchReveal`, so the SDK shipped a scratch card for both — a mystery
+             * box that you scratch. They share an outcome MODEL (reveal a server-provided prize), not a
+             * presentation, so the difference rides a prop rather than a second archetype (which would be
+             * a registry change, and the registry is the frozen contract).
+             */
+            return [{
+                    kind: 'scratch',
+                    props: {
+                        // The form names the prize differently per variant — scratch_card writes `rewardValue`
+                        // or `rewardResult`, mystery_box writes `rewardResult`. Reading only `prize` meant the
+                        // authored reward was replaced by the generic "You won!".
+                        prize: str(ext.prize ?? ext.reward ?? ext.rewardValue ?? ext.rewardResult ?? ext.resultReward ?? ext.coupon)
+                            ?? 'You won!',
+                        reveal: variantKey === 'mystery_box' ? 'box' : 'scratch',
+                    },
+                }];
+        case 'slotReward': {
+            // `result` is the 3-symbol combo the server decided; the block spins to it. Unread, the reels
+            // fell back to their own default and the outcome the backend chose never showed.
+            const result = listOf(ext, ['resultSymbols', 'result', 'winningSymbols']).map(labelOf).filter(Boolean);
+            return [{
+                    kind: 'slot',
+                    props: {
+                        symbols: listOf(ext, ['symbols', 'reels', 'slotItems']).map(labelOf).filter(Boolean),
+                        ...(result.length ? { result: result.slice(0, 3) } : {}),
+                    },
+                }];
+        }
+        case 'countdown':
+            /**
+             * The block reads `target` (ISO or epoch ms) or `durationMs`. The bridge emitted `to`, which
+             * the renderer never reads — so every countdown campaign shipped a timer with no deadline. The
+             * kind was right, the prop name was not, and nothing in the type system or the parity gate
+             * could see it because both sides agreed on the KIND.
+             *
+             * `durationMs` is the honest fallback when no deadline was authored: a countdown with no end
+             * is not a countdown, and 24h is what the authoring preview has always shown.
+             */
+            return [{ kind: 'countdown', props: countdownProps(ext) }];
+        case 'celebration':
+            return [{ kind: 'confetti', props: {} }];
+        case 'qrNfc':
+            return [{ kind: 'qr', props: { value: str(ext.url) ?? str(ext.link) ?? str(ext.qrValue) ?? str(ext.deepLink) ?? 'https://app.example.com' } }];
+        case 'carouselDeck': {
+            const rows = listOf(ext, ['slides', 'cards', 'items', 'steps']);
+            const slides = (rows.length ? rows : [{}, {}, {}]).map((r) => {
+                const o = rec(r);
+                return { image: str(o.image ?? o.imageUrl), title: labelOf(r), text: str(o.text ?? o.body ?? o.subtitle) };
+            });
+            return [{ kind: 'carousel', props: { slides } }];
+        }
+        case 'questionFlow': {
+            /**
+             * FIVE shapes, not one.
+             *
+             * Nine variants share this archetype and every one of them shipped a `poll` — an NPS prompt
+             * rendered as multiple choice, a rating request as multiple choice, an emoji bar as multiple
+             * choice. The SDK already had `nps`, `rating`, `emoji` and `quiz` renderers registered; the
+             * bridge simply never emitted them (0 uses each). Same collapse as mystery_box, four times
+             * over, and the fix is a mapping rather than new rendering code.
+             *
+             * The archetype still decides the FAMILY (ask the user something); the variantKey picks the
+             * instrument. Anything unrecognised keeps the poll, so a new question variant degrades to a
+             * working control rather than nothing.
+             */
+            /**
+             * The question comes from the FORM's `question` field, not the campaign title.
+             *
+             * Every question variant authors its prompt in a dedicated field — `poll_card` writes
+             * `question`, `feedback_capture` writes `promptText`, `product_finder` writes a `questions`
+             * array — and the bridge used `spec.title` instead. A poll authored as "Which do you prefer?"
+             * asked whatever the campaign happened to be named.
+             */
+            const questionRows = listOf(ext, ['questions', 'steps']);
+            const firstQuestion = rec(questionRows[0]);
+            const question = str(ext.question ?? ext.promptText ?? ext.prompt)
+                ?? str(firstQuestion.prompt ?? firstQuestion.question ?? firstQuestion.label)
+                ?? title ?? 'Tell us';
+            const rows = listOf(ext, ['options', 'preferenceOptions', 'pollOptions', 'answers', 'choices', 'reactions']);
+            // A multi-question flow degrades to its first question's options rather than to placeholders.
+            const optionRows = rows.length ? rows : listOf(firstQuestion, ['options', 'answers', 'choices']);
+            const options = (optionRows.length ? optionRows : [{ label: 'Option A' }, { label: 'Option B' }])
+                .map((r, i) => ({ id: String(i), label: labelOf(r) }));
+            switch (variantKey) {
+                case 'nps_prompt':
+                    // 0–10 is the definition of NPS; it takes no options.
+                    return [{ kind: 'nps', props: { question } }];
+                case 'rating_request':
+                    // Authoring may hand back "5" as text; a string would fall through to the default and
+                    // silently ignore a 10-star scale the author set.
+                    return [{ kind: 'rating', props: { question, max: num(Number(ext.max ?? ext.scale), 5) } }];
+                case 'emoji_reaction_bar': {
+                    const emojis = listOf(ext, ['emojis', 'reactions', 'options'])
+                        .map((r) => (typeof r === 'string' ? r : str(rec(r).emoji) ?? labelOf(r)))
+                        .filter(Boolean);
+                    return [{ kind: 'emoji', props: { question, ...(emojis.length ? { emojis } : {}) } }];
+                }
+                case 'quiz_card': {
+                    /**
+                     * Correctness stays server-authoritative — no answer key is shipped. The block marks the
+                     * right and wrong answers only once the server has graded the attempt, which it reports as
+                     * `{ answeredId, correctId }`. Forwarded rather than invented.
+                     */
+                    const graded = rec(ext.outcome ?? ext.quizOutcome);
+                    const answeredId = str(graded.answeredId ?? ext.answeredId);
+                    const correctId = str(graded.correctId ?? ext.correctId);
+                    return [{
+                            kind: 'quiz',
+                            props: {
+                                question,
+                                options,
+                                ...(answeredId || correctId ? { outcome: { answeredId, correctId } } : {}),
+                            },
+                        }];
+                }
+                default:
+                    return [{ kind: 'poll', props: { question, options } }];
+            }
+        }
+        case 'checklistProgress': {
+            /**
+             * SIX shapes, not one.
+             *
+             * Eight variants share this archetype and every one shipped `progress + checklist` — a habit
+             * streak drew a to-do list, a daily check-in drew a to-do list, a setup wizard drew a to-do
+             * list. The archetype names the FAMILY (something is partly complete); the variantKey decides
+             * how completeness is shown, and for a streak the shape IS the message.
+             *
+             * Unrecognised keys keep progress + checklist, so a new variant degrades to a working control.
+             */
+            const rows = listOf(ext, ['steps', 'items', 'tasks', 'checklist']);
+            const rawSteps = rows.length ? rows : ['Step one', 'Step two', 'Step three'];
+            const items = rawSteps.map((s, i) => {
+                const o = rec(s);
+                return {
+                    id: String(i),
+                    label: labelOf(s),
+                    // Completion is server-decided, like every other outcome in this file.
+                    done: o.done === true || o.checked === true || o.complete === true,
+                };
+            });
+            const pct = pctOf(ext.progress ?? ext.percent ?? ext.progressValue ?? ext.currentValue, 40);
+            const progressBlock = { kind: 'progress', props: { value: pct } };
+            const reward = str(ext.reward ?? ext.prize ?? ext.rewardValue);
+            switch (variantKey) {
+                case 'streak_reward':
+                case 'daily_check_in': {
+                    // Both are day cells; a streak is a consecutive run, a check-in has a today cell to tap.
+                    const checkin = variantKey === 'daily_check_in';
+                    const rawDays = listOf(ext, ['calendarDays', 'dayLabels', 'days']);
+                    const labels = rawDays.map(labelOf).filter(Boolean);
+                    /**
+                     * Two ways a day count arrives, and the form writes BOTH depending on variant:
+                     * `streak_reward` authors a scalar (`streakValueSource: 7`), while `daily_check_in`
+                     * authors the calendar itself (`[{label:'Mon',done:true}, …]`) and the count is however
+                     * many carry `done`. Reading only the scalar left every check-in calendar at zero.
+                     */
+                    const doneDays = rawDays.filter((d) => {
+                        const o = rec(d);
+                        return o.done === true || o.checked === true || o.complete === true;
+                    }).length;
+                    const filled = num(Number(ext.filled ?? ext.currentStreak ?? ext.streakValue ?? ext.streakValueSource), doneDays);
+                    // The authored calendar can also name today, which is otherwise inferred as filled + 1.
+                    const todayIndex = rawDays.findIndex((d) => rec(d).today === true);
+                    const blocks = [{
+                            kind: 'streak',
+                            props: {
+                                mode: checkin ? 'checkin' : 'streak',
+                                filled,
+                                ...(todayIndex >= 0 ? { today: todayIndex + 1 } : {}),
+                                ...(labels.length ? { labels } : { days: num(Number(ext.days ?? ext.calendarLength), 7) }),
+                                // An author who already checked in today has no today cell to offer.
+                                ...(checkin && ext.alreadyCheckedIn === true ? { today: -1 } : {}),
+                            },
+                        }];
+                    if (reward)
+                        blocks.push({ kind: 'callout', props: { icon: '🎁', text: reward } });
+                    return blocks;
+                }
+                case 'progress_unlock': {
+                    // A locked reward, not a task list: the bar is the lock and the callout is the prize.
+                    const unlocked = pct >= 100;
+                    const blocks = [progressBlock];
+                    if (reward) {
+                        blocks.push({
+                            kind: 'callout',
+                            props: { icon: unlocked ? '🎉' : '🔒', text: unlocked ? reward : `Unlock ${reward}` },
+                        });
+                    }
+                    return blocks;
+                }
+                case 'goal_tracker': {
+                    const current = Number(ext.currentValue ?? ext.progressValue ?? ext.current);
+                    const target = Number(ext.target ?? ext.goal ?? ext.targetValue ?? ext.goalValue);
+                    const blocks = [progressBlock];
+                    /**
+                     * The form's required fields are `goalSource`/`progressValue` with `targetValue` optional,
+                     * but the shipped example authors only `progress` — so a variant whose whole point is a
+                     * number showed a bar and no number. The percentage is a legitimate reading of the goal
+                     * when no absolute pair was authored, rather than dropping the stat entirely.
+                     */
+                    blocks.push({
+                        kind: 'stat',
+                        props: {
+                            value: Number.isFinite(current)
+                                ? (Number.isFinite(target) ? `${current} / ${target}` : current)
+                                : `${Math.round(pct)}%`,
+                            label: str(ext.goalLabel ?? ext.unit ?? ext.goalSource) ?? 'Progress',
+                        },
+                    });
+                    return blocks;
+                }
+                case 'community_challenge': {
+                    const participants = Number(ext.participants ?? ext.members ?? ext.joined);
+                    const blocks = [progressBlock];
+                    if (Number.isFinite(participants)) {
+                        blocks.push({ kind: 'stat', props: { value: participants, label: str(ext.participantsLabel) ?? 'taking part' } });
+                    }
+                    // Milestones are the shared goal's rungs — a list, not personal to-dos.
+                    if (rows.length)
+                        blocks.push({ kind: 'list', props: { items: items.map((i) => ({ label: i.label })) } });
+                    return blocks;
+                }
+                case 'guided_setup_wizard':
+                case 'first_session_onboarding': {
+                    // These are wizards. The registry calls them "guided flow" / "new user guide" and gives
+                    // them a fullscreen surface — one step at a time, which is exactly the `steps` block that
+                    // multiStepSheet already ships. Reused rather than re-implemented.
+                    const steps = rawSteps.map((r) => {
+                        const o = rec(r);
+                        return { title: labelOf(r) || undefined, body: str(o.body ?? o.text ?? o.subtitle) };
+                    });
+                    return [{
+                            kind: 'steps',
+                            props: {
+                                steps,
+                                backLabel: str(ext.backLabel), skipLabel: str(ext.skipLabel),
+                                nextLabel: str(ext.nextLabel), finalLabel: str(ext.finalLabel),
+                            },
+                        }];
+                }
+                default:
+                    // interactive_checklist and any future key: the canonical progress + checklist.
+                    return [progressBlock, { kind: 'checklist', props: { items } }];
+            }
+        }
+        case 'multiStepSheet': {
+            // Steps come from the same authored keys the checklist archetype accepts, so a payload that
+            // already lists steps renders as a wizard without re-authoring. Labels ride `ext` with the RN
+            // precedence (backLabel/skipLabel/nextLabel/finalLabel).
+            const rows = listOf(ext, ['steps', 'pages', 'items', 'screens']);
+            const steps = (rows.length ? rows : [{}]).map((r) => {
+                const o = rec(r);
+                return { title: labelOf(r) || undefined, body: str(o.body ?? o.text ?? o.subtitle) };
+            });
+            return [{
+                    kind: 'steps',
+                    props: {
+                        steps,
+                        backLabel: str(ext.backLabel), skipLabel: str(ext.skipLabel),
+                        nextLabel: str(ext.nextLabel), finalLabel: str(ext.finalLabel),
+                    },
+                }];
+        }
+        case 'sideSheet':
+            // Handled by the container path below — a side sheet earns the rich lane for its SURFACE,
+            // and its body is the same authored content any container renders.
+            return containerBlocks(ext, body);
+        case 'videoCommerce': {
+            const out = [];
+            const video = str(ext.video);
+            if (video)
+                out.push({ kind: 'video', props: { src: video } });
+            const products = listOf(ext, ['products', 'items']).map((p) => {
+                const o = rec(p);
+                return { id: String(o.id ?? ''), image: str(o.image ?? o.imageUrl), title: labelOf(p), price: o.price ?? o.amount };
+            });
+            /**
+             * A shoppable video is usually ONE product, and the form says so: `productTitle` is required
+             * while a `products` array is not offered at all. Reading only the array meant the shipped
+             * example rendered an empty grid under the video — the video played and there was nothing to
+             * buy, which is the entire mechanic missing.
+             */
+            const single = str(ext.productTitle);
+            if (!products.length && single) {
+                products.push({
+                    id: 'product',
+                    image: str(ext.productImage ?? ext.image),
+                    title: single,
+                    price: ext.price ?? ext.amount,
+                });
+            }
+            out.push({ kind: 'product-grid', props: { products } });
+            return out;
+        }
+        default:
+            // CONTAINER archetypes (modal / sheet / bannerToast / fullscreen / anchored / inline).
+            return containerBlocks(ext, body);
+    }
+}
+/**
+ * Content blocks for a CONTAINER archetype.
+ *
+ * Measured before this existed: 70 of the 100 canonical variants shipped `heading + text` and
+ * nothing else — a "Rich modal", a "Compare plans sheet" and a "Coupon wallet" all rendered as a
+ * title over a paragraph, differing only in the surface they arrived on. The authoring preview drew
+ * the bullets, plans and product grids from the same payload, so the author saw a rich card and the
+ * visitor got a plain one.
+ *
+ * The registry's design is that distinctness comes from "the shared block library, not a per-variant
+ * file" — that only holds if the container path actually reaches for the library. These are the same
+ * four content shapes the preview builds, from the same authored keys.
+ */
+/**
+ * Supporting content that belongs to EVERY archetype, not just containers.
+ *
+ * These reads first lived inside `containerBlocks`, which only runs for container archetypes — so a
+ * mystery box's `closedMessage`, a QR prompt's `instruction` and a community challenge's `goal` were
+ * still dropped, because those variants take the mechanic path. The prose, the price line and the
+ * item spotlight are orthogonal to which mechanic (if any) a variant renders, so they are resolved
+ * once, here, for all of them.
+ *
+ * Split in two: `lead` sits directly under the body, `trail` after the mechanic — a prize message
+ * reads before the scratch surface, a price line reads after it.
+ */
+function supportingBlocks(ext, body) {
+    const lead = [];
+    const trail = [];
+    /**
+     * Prose that a variant REQUIRES but does not call `body`.
+     *
+     * `vip_unlock` requires `benefitMessage`, `smart_segment_preview` requires `segmentExplanation`,
+     * `nfc_qr_prompt` requires `instruction` — each is the point of its variant, and the seed maps
+     * only `body`/`message` onto the body slot, so every other name was authored and dropped.
+     * Skipped when it merely repeats the body, which happens when a variant authors both.
+     */
+    const copy = str(ext.benefitMessage ?? ext.segmentExplanation ?? ext.availabilityMessage ??
+        ext.rewardMessage ?? ext.offerMessage ?? ext.proofMessage ?? ext.valueMessage ??
+        ext.reviewMessage ?? ext.assistantMessage ?? ext.supportMessage ?? ext.arrivalMessage ??
+        ext.checkoutMessage ?? ext.instruction ?? ext.instructions ?? ext.closedMessage ??
+        ext.reasonText ?? ext.motivationalText ?? ext.urgencyNote ?? ext.subtitle);
+    if (copy && copy !== body)
+        lead.push({ kind: 'text', props: { text: copy } });
+    /**
+     * A decision hub IS its choices.
+     *
+     * `multi_cta_decision_hub` authors `actions: [{label:'Explore'},{label:'Upgrade'},…]` — the whole
+     * variant — and it rendered a heading and nothing else. These become real CTA buttons rather than
+     * a bulleted list, because that is what the author authored.
+     */
+    const choices = listOf(ext, ['actions', 'ctas']).map((a) => {
+        const o = rec(a);
+        return { label: labelOf(a), action: str(o.action) ?? 'dismiss', deepLink: str(o.deepLink), variant: 'secondary' };
+    }).filter((a) => a.label);
+    if (choices.length)
+        trail.push({ kind: 'cta', props: { actions: choices } });
+    /**
+     * A short detail line: the price on a paywall, the time on an event, the goal on a challenge, the
+     * reward on a quiz. Each is a required field of its variant and none of them rendered — a paywall
+     * with no price.
+     */
+    const detail = str(ext.price ?? ext.eventTime ?? ext.dateTime ?? ext.goal ?? ext.documentType ??
+        ext.lastOrderDate ?? ext.reward ?? ext.rewardTitle ?? ext.resultReward);
+    if (detail)
+        trail.push({ kind: 'badge', props: { text: detail } });
+    /**
+     * A SECOND title — `webinar_registration` and `wallet_pass_offer` author both `title` and an
+     * `eventTitle`/`passTitle` naming the thing itself. Only one can be the heading, so the other
+     * becomes a callout instead of being discarded.
+     */
+    const named = str(ext.eventTitle ?? ext.passTitle);
+    if (named && named !== body)
+        lead.push({ kind: 'callout', props: { icon: '🎟️', text: named } });
+    // `social_proof_popup` authors an avatar for the person being quoted; it rendered nowhere.
+    const avatar = str(ext.avatar ?? ext.avatarUrl);
+    if (avatar)
+        lead.unshift({ kind: 'image', props: { src: avatar, alt: '' } });
+    /**
+     * The item a behavioural alert is ABOUT, with the numbers that give it meaning.
+     *
+     * `price_drop_alert` requires `itemName`, `oldPrice` and `newPrice`, and rendered none of them —
+     * a price-drop alert that showed no price. Same for back-in-stock and reorder reminders.
+     */
+    const item = str(ext.itemName);
+    if (item) {
+        const oldPrice = str(ext.oldPrice);
+        const newPrice = str(ext.newPrice);
+        const prices = oldPrice && newPrice
+            ? `${oldPrice} → ${newPrice}`
+            : newPrice ?? oldPrice ?? str(ext.stockStatus) ?? str(ext.quantity);
+        trail.push({ kind: 'callout', props: { icon: '🏷️', text: prices ? `${item} · ${prices}` : item } });
+    }
+    return { lead, trail };
+}
+function containerBlocks(ext, body) {
+    const out = [];
+    /**
+     * Prose that a variant REQUIRES but does not call `body`.
+     *
+     * `vip_unlock` requires `benefitMessage` and `smart_segment_preview` requires
+     * `segmentExplanation` — each is the entire point of its variant, and neither reached the render.
+     * The seed maps only `body`/`message` onto the body slot, so everything else was authored and
+     * dropped: a VIP unlock that never said what the benefit was.
+     *
+     * Skipped when it merely repeats the body, which happens when a variant authors both.
+     */
+    /**
+     * The authored key names are per-VARIANT, not generic.
+     *
+     * This read `bullets`/`features`/`points` while the form for `rich_modal` writes `bulletList`, the
+     * one for `loyalty_tier_upgrade` writes `perks`, `personalized_digest` writes `digestItems` and
+     * `bundle_builder` writes `bundleItems`. Every one of those authored a list and rendered a plain
+     * modal — which is exactly the "this should be the rich modal with bullets" report.
+     *
+     * Listing the real field names is deliberate over pattern-matching anything list-shaped: a variant
+     * that happens to carry an unrelated array should not have it rendered as body copy.
+     */
+    const bullets = listOf(ext, [
+        'bullets', 'bulletList', 'benefits', 'features', 'newFeatures', 'perks', 'perksList',
+        'reasonList', 'digestItems', 'contentSections', 'contentBlocks', 'suggestedActions',
+        'points', 'highlights', 'dateTimeOptions', 'tabs', 'slots',
+    ])
+        .map(labelOf)
+        .filter(Boolean);
+    if (bullets.length)
+        out.push({ kind: 'list', props: { items: bullets } });
+    const plans = listOf(ext, ['plans', 'planCards', 'tiers', 'pricingTiers', 'packages']);
+    if (plans.length) {
+        out.push({
+            kind: 'table',
+            props: {
+                columns: ['Plan', 'Price'],
+                rows: plans.map((p) => {
+                    const o = rec(p);
+                    return [labelOf(p), String(o.price ?? o.amount ?? '')];
+                }),
+            },
+        });
+    }
+    // Classification MUST match the preview's PRODUCT_KEYS — `bundleItems` and `itemList` are products
+    // there, so listing them as bullets here would show an author a grid and ship them a list.
+    const products = listOf(ext, [
+        'products', 'productList', 'productCards', 'productImages', 'crossSellItems',
+        'recommendations', 'bundleItems', 'cartItems', 'itemList', 'relatedItems',
+    ]);
+    if (products.length) {
+        out.push({
+            kind: 'product-grid',
+            props: {
+                products: products.map((p) => {
+                    const o = rec(p);
+                    return { id: String(o.id ?? ''), image: str(o.image ?? o.imageUrl), title: labelOf(p), price: o.price ?? o.amount };
+                }),
+            },
+        });
+    }
+    // Checklist LAST: it reads as the "what's next" tail of a container, after the pitch.
+    const steps = listOf(ext, ['steps', 'setupSteps', 'tasks', 'checklistItems', 'checklist']);
+    if (steps.length) {
+        out.push({
+            kind: 'checklist',
+            props: { items: steps.map((s, i) => ({ id: String(i), label: labelOf(s), done: rec(s).done === true })) },
+        });
+    }
+    return out;
+}
+/** Build an IAM 2.0 Variant from an engage rich-variant message + its (A/B-resolved) spec. */
+export function engageMessageToVariant(m, spec) {
+    // Resolved off the A/B-resolved `spec` that is actually being rendered, not `m.spec` — variant B
+    // carries its own ext, so reading the base spec here would build variant A's mechanic.
+    const arch = richArchetype(m.variantKey, servedArchetypeOf(spec)) ?? '';
+    // An archetype that dictates its own surface wins over the layout-derived one: `sideSheet` must
+    // dock to an edge and `multiStepSheet` must be a bottom sheet regardless of the legacy layout the
+    // payload also carries for old clients.
+    const ext = rec(spec.ext);
+    /**
+     * Precedence: an archetype that dictates its own surface, then the SERVED mount model, then the
+     * legacy layout. The archetype still wins — `multiStepSheet` must be a bottom sheet and `sideSheet`
+     * must dock to an edge regardless of how either was authored — but everything else now honours the
+     * registry's mount model instead of a mobile layout enum that could not express it.
+     */
+    const base = ARCHETYPE_SURFACE[arch] ?? mountSurfaceFor(ext) ?? LAYOUT_SURFACE[m.layout] ?? LAYOUT_SURFACE.modal;
+    /**
+     * `side_sheet` offers a `sidePosition` field and it was ignored — a sheet authored to dock LEFT
+     * always slid in from the right. The archetype default stands when nothing was authored.
+     */
+    const side = str(ext.sidePosition ?? ext.position);
+    const map = arch === 'sideSheet' && (side === 'left' || side === 'right')
+        ? { ...base, surfaceOptions: { ...base.surfaceOptions, placement: side } }
+        : base;
+    const blocks = [];
+    if (spec.imageUrl)
+        blocks.push({ kind: 'image', props: { src: spec.imageUrl, alt: spec.title ?? '' } });
+    /**
+     * The eyebrow — the small label ABOVE the title. `classic_modal` requires it and the bridge dropped
+     * it entirely, so the one piece of chrome that variant asks for never rendered. Placed here rather
+     * than with the container content because it belongs above the heading, and because a mechanic
+     * variant can author one too. Guards mirror the preview: an eyebrow that merely repeats the title,
+     * or that is long enough to be a sentence, is body copy wearing a badge.
+     */
+    const eyebrow = str(ext.eyebrow ?? ext.badge);
+    if (eyebrow && eyebrow !== spec.title && eyebrow.length < 32) {
+        blocks.push({ kind: 'badge', props: { text: eyebrow } });
+    }
+    /**
+     * Several variants name their headline something other than `title` — `live_event_banner` writes
+     * `eventTitle`, `wallet_pass_offer` writes `passTitle`, `peek_card` writes `expandedTitle` and no
+     * title at all, `smart_inbox_message` writes `subject`. Those campaigns rendered headless.
+     */
+    // `str()` rather than `??` on both: the seed hands back an EMPTY STRING for an unauthored body,
+    // and `'' ?? fallback` keeps the empty string — so peek_card, which authors only `expandedBody`,
+    // rendered no body at all while the fallback sat right there.
+    const heading = str(spec.title)
+        ?? str(ext.eventTitle ?? ext.passTitle ?? ext.expandedTitle ?? ext.subject ?? ext.vipTitle
+            ?? ext.offerTitle ?? ext.bubbleLabel ?? ext.peekLabel);
+    const bodyText = str(spec.body) ?? str(ext.expandedBody);
+    if (heading)
+        blocks.push({ kind: 'heading', props: { text: heading } });
+    if (bodyText)
+        blocks.push({ kind: 'text', props: { text: bodyText } });
+    const support = supportingBlocks(ext, bodyText);
+    blocks.push(...support.lead);
+    // The RESOLVED heading/body are handed down, so a question falls back to the real headline and the
+    // prose dedupe compares against the text that was actually drawn.
+    blocks.push(...mechanicBlocks(arch, ext, heading, m.variantKey, bodyText));
+    blocks.push(...support.trail);
+    const actions = [];
+    if (spec.cta?.label)
+        actions.push({ label: spec.cta.label, action: spec.cta.action ?? 'dismiss', deepLink: spec.cta.deepLink, variant: 'primary' });
+    if (spec.secondaryCta?.label)
+        actions.push({ label: spec.secondaryCta.label, action: 'dismiss', variant: 'dismiss' });
+    if (actions.length)
+        blocks.push({ kind: 'cta', props: { actions } });
+    if (blocks.length === 0)
+        blocks.push({ kind: 'text', props: { text: spec.body } });
+    return {
+        id: m.id,
+        key: m.variantKey ?? m.id,
+        name: spec.title ?? m.id,
+        category: 'misc',
+        platforms: ['web'],
+        surface: map.surface,
+        surfaceOptions: map.surfaceOptions,
+        blocks,
+        priority: 'normal',
+        triggers: [{ type: 'manual' }],
+        dismiss: { xButton: true, escClose: true, backdropClose: true },
+    };
+}
+/**
+ * Bridge the ENGAGE theme contract onto the IAM 2.0 variable namespace.
+ *
+ * Two namespaces exist for good reasons and neither should be renamed: engage's `--sb-*` names are
+ * copied byte-for-byte from the frozen mobile contract (`accent`/`cardBg`/`titleColor`/…), while
+ * IAM's `--scalebun-*` names are the block library's own vocabulary. This maps one onto the other so
+ * an author picks a colour once and both surfaces obey it.
+ *
+ * Before this, `richInApp` never read `spec.style` at all: a campaign's brand colours were authored
+ * in the dashboard, packed by `buildPayload`, served by the backend — and rendered by nobody. Every
+ * rich in-app message came out in ScaleBun's default indigo regardless of what the customer chose.
+ *
+ * Values arrive already validated by `resolveTheme` (strict colour grammar, unsafe values dropped to
+ * defaults), so nothing unvalidated is interpolated into a style property here.
+ */
+/**
+ * Authored entrance animation → a fixed CSS shorthand.
+ *
+ * A DICTIONARY, not interpolation. The value is author-controlled and ends up in a stylesheet, so
+ * the same rule as colours applies: an unknown name maps to nothing and the surface keeps its own
+ * default. Every keyframe referenced here already exists in the surface stylesheet — this maps the
+ * authored vocabulary onto them rather than adding new motion.
+ *
+ * `slide_out_right` is deliberately absent: it only ever appears as an EXIT animation, and applying
+ * an exit as an entrance would play the surface sliding away as it arrives.
+ */
+const ANIMATION_CSS = {
+    fade: 'scalebun-fade .18s ease',
+    fade_scale: 'scalebun-pop .16s ease',
+    slide_up: 'scalebun-slideup .2s ease',
+    slide_down: 'scalebun-slidedown .18s ease',
+    slide_in_right: 'scalebun-slide-in-r .2s ease',
+};
+/**
+ * Apply the authored entrance animation, if the SDK knows it.
+ *
+ * Reduced motion needs no handling here: the host's base stylesheet carries
+ * `@media (prefers-reduced-motion: reduce){ .layer *{ animation:none !important } }`, and an
+ * `!important` rule beats this custom property — so an authored animation cannot override a user's
+ * accessibility preference.
+ */
+function applyEngageAnimation(el, spec) {
+    const authored = spec.ext?.['animationIn'];
+    const css = typeof authored === 'string' ? ANIMATION_CSS[authored] : undefined;
+    if (css)
+        el.style.setProperty('--scalebun-anim-in', css);
+}
+function applyEngageTheme(el, spec) {
+    /**
+     * ONLY tokens the author actually set are applied.
+     *
+     * `resolveTheme` fills every unset token with the SURVEY widget's historical defaults — correct
+     * there, wrong here: IAM has its own defaults (accent `#4f46e5`, auto light/dark) and an unstyled
+     * in-app message must keep them. Applying the resolved record wholesale would silently repaint
+     * every un-themed campaign, which is the regression their module's rule 2 exists to prevent.
+     * Sanitizing gives the authored subset; the rest simply isn't set, so IAM's own vars stand.
+     */
+    const authored = sanitizeTheme(spec.style);
+    const set = (name, v) => {
+        if (v)
+            el.style.setProperty(name, v);
+    };
+    set('--scalebun-accent', authored.accent);
+    set('--scalebun-bg', authored.cardBg);
+    // IAM carries ONE foreground; the contract names title and body separately. Body drives the
+    // general token because it covers more surface, and the heading reads its own var so an author who
+    // set them differently still gets both — without widening the frozen contract.
+    set('--scalebun-fg', authored.bodyColor);
+    set('--scalebun-title', authored.titleColor);
+    /**
+     * CTA text is COMPUTED, not just copied. A pale authored accent with IAM's default white
+     * `--scalebun-accent-fg` gives white-on-pale — legible in the authoring preview at full size,
+     * unreadable in the surface. `readableOn` honours an explicit `ctaText` and otherwise picks a
+     * readable foreground. Only when the accent was authored: otherwise IAM's own pairing is intact.
+     */
+    if (authored.accent)
+        set('--scalebun-accent-fg', readableOn(authored.accent, authored.ctaText));
+    else
+        set('--scalebun-accent-fg', authored.ctaText);
+}
+/**
+ * Render a rich variant through the IAM 2.0 renderer. The render system is dynamic-imported (kept
+ * out of the eager bundle), rendered into its own ShadowHost, and torn down on close. CTA/dismiss
+ * are wired back to the caller's beacons so analytics is identical to the widget path.
+ */
+export async function renderRichInApp(m, spec, cb) {
+    const [{ renderVariant }, { ShadowHost }] = await Promise.all([
+        import('../inapp/surfaces/render'),
+        import('../inapp/core/host'),
+    ]);
+    const host = new ShadowHost();
+    host.ensure();
+    /**
+     * Mode first, then the author's colours on top — `setTheme` re-applies the whole default set, so
+     * the reverse order would wipe the overrides. A campaign that asked for dark gets IAM's dark
+     * defaults for everything it did NOT theme; one that didn't ask keeps 'auto' (the host's existing
+     * behaviour), because a page's colour scheme is not the campaign author's decision.
+     */
+    if (spec.dark === true)
+        host.setTheme('dark');
+    // Brand BEFORE mounting: the surface and its blocks read these vars as they build, so applying
+    // afterwards would paint one frame in the default palette first.
+    const themed = host.element();
+    if (themed) {
+        applyEngageTheme(themed, spec);
+        applyEngageAnimation(themed, spec);
+    }
+    /**
+     * The gamified outcome lane.
+     *
+     * `load` variants (progress_unlock, streak_reward, daily_check_in) are resolved BEFORE the variant
+     * is built, because "load" means the state is what the message is about — painting a 0% bar and
+     * correcting it a moment later would show every visitor a wrong number first. `play` and
+     * `submit_quiz` resolve on interaction instead, via the resolver handed to the surface below.
+     *
+     * A failed load is NOT fatal: the message still renders with its authored defaults, which is
+     * strictly better than showing nothing because a rewards backend was briefly down.
+     */
+    // Same object reference `engageMessageToVariant` will read, so a resolved `load` state merged
+    // here is visible when the blocks are built below.
+    const ext = rec(spec.ext);
+    const resolver = makeGameResolver({
+        campaignId: m.id,
+        variantKey: m.variantKey ?? '',
+        ext,
+        preview: m.preview === true || m.isTest === true,
+        ...(gameHandlerRef ? { handler: gameHandlerRef } : {}),
+    });
+    if (resolver && inAppGameActionFor(m.variantKey) === 'load') {
+        const loaded = await resolver(1);
+        if (loaded.ok && loaded.state)
+            Object.assign(ext, loaded.state);
+    }
+    const variant = engageMessageToVariant(m, spec);
+    let done = false;
+    /**
+     * Detach the per-message host once the surface is gone.
+     *
+     * A user-driven dismiss (X / Esc / backdrop) resolves INSIDE the surface — requestClose tears the
+     * surface down and fires onDismiss — so it never passes through the RichHandle.close() below. That
+     * left this host (and its cached zones) attached to <body> for the page's lifetime, one per
+     * campaign shown. Deferred a microtask because mountSurface calls hooks.onDismiss() BEFORE
+     * inst.destroy(); destroying the host first would pull the DOM out from under that teardown.
+     */
+    let hostGone = false;
+    const dropHost = () => {
+        if (hostGone)
+            return;
+        hostGone = true;
+        queueMicrotask(() => {
+            try {
+                host.destroy();
+            }
+            catch { /* already detached */ }
+        });
+    };
+    const rendered = await renderVariant(variant, {
+        onImpression() { },
+        onView() { },
+        onCtaClick() { if (!done) {
+            done = true;
+            cb.onClick();
+        } },
+        onInteraction() { },
+        onDismiss() {
+            if (!done) {
+                done = true;
+                cb.onDismiss();
+            }
+            dropHost();
+        },
+        /**
+         * Present ONLY for the eight gamified variants — its absence is how a block knows it is not
+         * server-resolved. `load` variants were already resolved above, before paint; this serves the
+         * `play` and `submit_quiz` blocks, which call it when the user actually plays.
+         */
+        ...(resolver ? { requestOutcome: resolver } : {}),
+    }, 
+    // The slot registry rides along so an inline surface can find its host-registered mount.
+    { host, slots: engageSlots });
+    return {
+        close: () => {
+            try {
+                rendered.close();
+            }
+            catch { /* already closed */ }
+            dropHost();
+        },
+    };
+}
+//# sourceMappingURL=richInApp.js.map