Adopt WhiskerPlatform over rwe-core

Status: proposed
Deciders: Platform Team
Date: 2026-06-29

Technical Story: Retail store micro-frontend host — platform direction

Context and Problem Statement

Nike retail store tooling needs a host shell that aggregates independently developed applications — federation modules, dashboard widgets, and legacy iframe apps — for in-store athletes.

Two implementations exist:

	rwe-core	WhiskerPlatform
Scope	Host app (`rwe-host`, federated `rwe-shell`, static registries)	Host + module kit + manifest pipeline + component library (+ optional service/AI layers)
Registration	Host-team PRs to `app-registry.ts`, `widget-registry.ts`, `apps.json`	Module-owned manifests via CI
Module onboarding	Copy example app; DIY federation/CI	`thundercats create module`, `whisker dev`, husky hooks
Real production modules	Separate repos (in-repo demo is example only)	Separate repos (scaffolded)

The organisation has many retail squads on independent release cadences. rwe-core’s static-registry model centralises coordination in the host team. WhiskerPlatform distributes registration, validation, and deployment to module teams behind a shared schema and pipeline.

Neither system is uniformly superior. rwe-core is simpler to operate and has mature patterns Whisker has not yet matched. WhiskerPlatform targets scale, self-service, and a single manifest contract across federation and iframe paths.

This ADR records the overarching direction. Specific paradigm choices and rwe-core capabilities to preserve are child ADRs — linked below — so each decision can be reviewed on its own merits.

Out of scope here: whisker-service-kit, Thundercats / AI tooling, nightly cross-repo E2E orchestration, auth technology (RAPv3 vs BERM), and federated-shell vs host-owned auth. Those are separate concerns from which host registration and platform model retail modules target.

Decision Drivers

Many teams, many modules — Host PR review cannot be the registration gate at expected growth.
Independent cadences — Module releases must not require host releases for nav, widgets, pages, or iframe URLs.
Predictable contract — One manifest schema, one host contract artifact, validated at multiple layers.
Migration realism — rwe-core capabilities that athletes depend on (per-operator preferences, widget lifecycle) must be explicitly tracked, not assumed away.
Honest ops trade-off — Accept Lambda/DynamoDB/DLQ/sync workflow cost where it replaces host-team coordination cost.

Considered Options

Option A — Standardise on rwe-core

Continue/evolve the static-registry host. Improve docs and review process; do not build the manifest pipeline.

Option B — Standardise on WhiskerPlatform (host + module kit)

Adopt whisker-host, @nike/whisker-module-kit, @nike/create-whisker, and the manifest pipeline as the single retail store host for new and migrating modules. rwe-core is not a parallel production target.

Pros and Cons (summary)

Detailed analysis lives in child ADRs. At the strategic level:

Option A — rwe-core

Good: lower AWS operational footprint; simpler mental model; mature federated widget SDK; co-located demo monorepo for host smoke tests.
Bad: registration scales with host-team PR bandwidth; no module scaffolder; per-env toggles require host redeploy; iframe allow-lists are hand-edited.

Option B — WhiskerPlatform

Good: self-service registration, schema validation, admin-aware merge, scaffolding and whisker dev orchestration — see 0002, 0003, 0004.
Bad: higher platform ops surface; onboarding cost; gaps vs rwe-core on per-operator preferences and widget SDK — see 0005, 0006.

Decision Outcome

Chosen option: Option B — standardise on WhiskerPlatform as the only retail store micro-frontend host going forward.

There is one production host: whisker-host. rwe-core is legacy; modules move onto Whisker module-by-module until rwe-core can be decommissioned. New greenfield work always targets whisker-host + module kit — not rwe-core.

Option A (continue/evolve rwe-core as the store host) is not adopted. It remains documented in child ADRs as the superseded model and as a reference for patterns to port (see 0005, 0006).

Child ADRs (paradigm and migration)

ADR	Topic
0002 — Dynamic manifest registry	Runtime/build-time registry vs static TypeScript files
0003 — Self-service module automation	Scaffolding, kit CLI, CI, host sync — automation for other teams
0004 — Host scalability model	Coordination cost vs infrastructure cost
0005 — Per-operator preferences	Adopt from rwe-core — athlete-scoped state vs device localStorage
0006 — Widget host model	Host-agnostic declarative widgets vs imperative `notifyReady` SDK

Positive Consequences

Single strategic direction for retail MFE host work.
Module teams own registration; host team owns platform reliability and contract evolution.
Child ADRs make gaps explicit (preferences, widgets) instead of hiding them in a monolithic comparison doc.

Negative Consequences

Platform team owns manifest pipeline operations until runbooks mature.
Individual modules may temporarily exist on rwe-core until their Whisker migration completes — that is a module migration timeline, not a dual-host operating model.
Whisker must close documented gaps before rwe-core-dependent workflows can fully move — tracked in 0005 and 0006, not assumed complete today.

Recommendations

Treat 0002–0004 as the paradigm baseline for new Whisker modules.
Treat 0005–0006 as required follow-through before claiming feature parity with rwe-core for dashboard/widgets.
Do not add new static registry entries to rwe-core for greenfield work unless an exception is recorded.
Keep docs/architecture/ updated as living reference; update ADR status when decisions are accepted.