Overview
A self-contained reference for what WhiskerPlatform is, how its pieces fit together, how external teams plug into it, and where it is brittle.
These documents assume the reader is technical but unfamiliar with the platform. Read them in order, or jump to the section relevant to your task. Each document separates what’s built and running today from what’s planned or proposed — look for the “Planned” sections rather than assuming everything described is live.
Where the platform stands. The tooling stack (
@nike/whisker-cli,@nike/create-whisker,@nike/whisker-module-kit,@nike/whisker-service-kit) is feature-complete for a first Artifactory pilot but not yet published;@nike/whisker-component-libraryis the only package published today. The biggest missing platform piece iswhisker-bff— the host still calls the legacysim-bfffor manifests and login. See Manifest pipeline & deployment and Risks & improvements.
| Document | Read if you want to… |
|---|---|
| WhiskerPlatform Architecture | See the system diagram, runtime flow, and the two integration paths in detail |
| Scaffolder & kits | Know how create-whisker, whisker-module-kit, and whisker-service-kit work |
| Host ↔ module contract | Understand the federation and iframe integration paths and how they are kept stable |
| Manifest pipeline & deployment | Trace a manifest from src/moduleManifest.ts to a user’s browser, including S3 co-location and the publisher Lambda |
| Component library | Use or contribute to @nike/whisker-component-library |
| Automation, devkit & E2E | Understand whisker doctor, the (planned) devkit panel, and the nightly Playwright runner |
| AI-first tooling | See how Thundercats / @nike/whisker-cli brings Nike context to AI agents |
| Consumer integration guide | Onboard an external team — federation module or iframe consumer |
| Risks, brittleness, improvements | Know where the platform is fragile and what we should fix next |
| rwe-core vs whisker-host | Compare the two host implementations side by side |
| Manifest schema reference | Understand what each part of ModuleManifest is for and how it’s namespaced |
| Analytics architecture | Understand the three-layer analytics system shared by host + modules |
Conventions used in these docs
Section titled “Conventions used in these docs”- “Host” refers to
whisker-host(the runtime shell users open in a browser). - “Module” is anything declared by a
module-manifest.json— a federation remote or an iframe consumer. - “Kit” refers to the developer-facing
devDependencythat ships a CLI —@nike/whisker-module-kit(front-end) or@nike/whisker-service-kit(back-end). - “Scaffolder” refers to
@nike/create-whisker, the one-time-use generator invoked throughpnpm create whisker. - Each doc’s “Planned / proposed” section is not yet running in production — treat it as intent, not as something you can depend on today.
Other reference material
Section titled “Other reference material”- ADRs — docs/adr/README.md (overarching 0001 plus paradigm and migration child records)
- Module manifest example: planning/moduleManifest.json
- Open cross-repo proposals: planning/open-proposals.md
