WhiskerPlatform Architecture Decision Records
Decision records for adopting WhiskerPlatform over rwe-core as the retail store micro-frontend host. Each ADR follows the pattern in payment-systems ADR 0057: context, drivers, options, pros/cons, outcome, consequences, links.
Living reference docs (how things work today) live in
docs/architecture/. ADRs record decisions and
trade-offs; architecture docs record mechanism and status.
Reading order
Section titled “Reading order”| # | ADR | What it decides |
|---|---|---|
| 0001 | Adopt WhiskerPlatform over rwe-core | Overarching — strategic direction for the retail host |
| 0002 | Dynamic manifest registry | S3 → Lambda → DynamoDB vs static host registries |
| 0003 | Self-service module automation | Kit, scaffolder, CI, and zero host PRs for module teams |
| 0004 | Host scalability model | When each model scales; ops cost vs coordination cost |
| 0005 | Per-operator preferences from rwe-core | Keep from rwe-core — athlete-scoped state vs device localStorage |
| 0006 | Declarative widget host vs imperative widget SDK | Paradigm difference — host-agnostic widgets vs notifyReady lifecycle |
| 0007 | Adopt Playwright for E2E | E2E runner choice — Playwright + @playwright/mcp; free vs paid AI tooling |
| 0008 | persona hierarchy and scope model | Access model — role hierarchy vs. store scope; platformOwner split; gated access as grants |
| 0009 | Enforced store/global config vs. per-operator preference | Preference layering — cosmetic per-operator preference vs. ops-required monitoring config; who can enforce, and precedence |