Overview › Design System & Onboarding
Design System & Onboarding
Detailed static-analysis report for design system & onboarding.
Executive summary
The design system is structurally good: a dedicated shared/pallet module with auto-generated tokens (Color, Space, Typography, Font, FontSize, FontWeight, LineHeight). But adoption is poor — hardcoded color literals (Color(0xFF…)) and hardcoded .dp values appear across feature modules, and there are essentially zero @Preview Composables and no Showkase / catalog tooling. Onboarding for a new engineer is high-friction: README references SourceTree, no CONTRIBUTING.md, no per-module READMEs, no scripts/ folder, hardcoded API keys in gradle.properties.
Design system maturity
Token files (shared/pallet)
- Colors: shared/pallet/src/main/java/com/costco/app/pallet/designtokens/base/Color.kt — 60+ tokens (costcoBlue, costcoRed, blue10–95, red10–95, green/yellow/orange palettes)
- Spacing: .../designtokens/base/Space.kt —
PalletSpace(zero,xxs,xs,sm,md,lg,xl,xxl,xxxl) - Typography composite: .../designtokens/composite/Typography.kt
- Font / size / weight / line-height: 4 separate base token files
- Auto-generated by
@nxt-costco-com/forge-design-tokensv3.0.1 (March 2026 timestamp)
Adoption signals
| Signal | Status | Evidence |
|---|---|---|
| Token-driven theming in Composables | PARTIAL | Some files use tokens; many fall back to literals |
| Hardcoded Color literals | PRESENT | Sample: feature/warehouse/.../WarehouseCardComponent.kt · feature/account/.../AccountFeedbackScreen.kt · feature/account/.../AppSettingsScreen.kt |
Hardcoded .dp spacing | PRESENT | Sample: shared/ui/.../NoInternetComponent.kt uses 10/16/8 dp literals |
| @Preview annotations | ABSENT | 0 detected |
| Showkase / catalog | ABSENT | Not found in deps |
| Snapshot tests on tokens | PARTIAL | Karumi Shot exists but design-system catalog snapshots not standard |
| Dark color tokens | PARTIAL | Only geofence + productdetaillanding have values-night |
HIGH
Tokens defined but not enforced
A design-token build pipeline exists, but feature code routinely sidesteps it.
Recommendation: Add a Detekt rule banning
Color(0xFF…) and inline .dp literals outside shared/pallet. Sweep existing literals into tokens. Add a contributing-guide rule.HIGHZero
Zero @Preview Composables
No Compose previews makes UI iteration slow and design-system drift inevitable.
Recommendation: Mandate at least one
@Preview per public Composable. Adopt Showkase to auto-catalog them.MEDIUM
No design-system snapshot tests
Karumi Shot is wired in but not used to lock the visual contract of the design system.
Recommendation: Snapshot every public token combination (button × theme × state). Fail PRs that change the snapshot without a ticket.
New-developer onboarding
| Asset | Status | Note |
|---|---|---|
| README.md | STALE | References SourceTree, old Raizlabs repo, legacy git workflow |
| CONTRIBUTING.md | ABSENT | |
| docs/ folder | ABSENT | |
| CODEOWNERS | ABSENT | |
| Per-module READMEs | ABSENT | Across feature/* and shared/* |
| Makefile / scripts/ | ABSENT | Common dev commands not scripted |
| gradle.properties hygiene | CONCERN | Google Maps API keys hardcoded in committed file |
CRITICALAPI keys committed in
API keys committed in gradle.properties
Hardcoded Google Maps API key in gradle.properties (a committed file). Even with key restrictions enabled in Google Cloud Console, this is poor hygiene and can fail security audits.
Recommendation: Move keys to
local.properties (gitignored) or environment variables. Read into BuildConfig at build time. Restrict the key in Google Cloud Console to your Android package + SHA-1.HIGH
Stale README
References to SourceTree and an older Raizlabs sync workflow add friction for every new engineer.
Recommendation: Rewrite README covering: setup with
./gradlew assembleDebug, module map, branching strategy, CI/CD overview, on-call rotation pointer, security contact. Target a new-engineer-runs-debug-build-in-30-minutes goal.HIGH
No CODEOWNERS
PR reviews go to whoever picks them up. With 56 modules, that scales poorly and slows reviews.
Recommendation: Add
CODEOWNERS at the repo root mapping module paths to teams. Auto-request review from owners on PR.MEDIUM
No per-module README
Each
feature/* and shared/* module benefits from a one-paragraph README describing purpose, public API, owners, and known constraints.Recommendation: Use a
buildSrc task to fail PRs that add a new module without a README.MEDIUMNo
No scripts/ folder
Common operations (clean build, run debug, publish coverage report, generate baseline profile) live as tribal knowledge.
Recommendation: Add
scripts/setup.sh, scripts/build-release.sh, etc. Document a 5-minute first-run path in the README.Costco Android · Code Review Report · Generated 2026-05-07 · 626 machine-curated findings