The same design intent can travel across platforms. Implementation availability and verification are specific to each platform.
React
implementation preview
The complete local web component library and original stories run from this workspace. Distribution is a repository package; no standalone npm release is claimed.
Implementation steps and evidence
Read the component contract and its public export before writing JSX. Use the repository workspace package, its token styles and CdsProvider.
Use the real component API and preserve union constraints, controlled state, accessible names and event semantics.
Compare your integration with its named stories in both themes, narrow layouts and keyboard navigation.
Evidence to bring back
Type-check the actual consumer code.
Run the relevant interaction tests and inspect the resulting screen.
Design contracts, web token CSS and rendered states are available. This repository does not provide Vue components or a verified React-to-Vue wrapper.
Implementation steps and evidence
Read the framework-neutral specification for anatomy, states, choices, behavior and accessibility. Use React stories as visual and behavioral references.
Build a Vue implementation using native DOM semantics and the same public --cds-* tokens. React props and callbacks are reference APIs, not Vue bindings.
Record the Vue source path and compare equivalent states before claiming parity.
Evidence to bring back
Compile the consuming Vue application.
Verify focus, form behavior, keyboard access and equivalent states in both themes.
Specifications and token values describe shared intent. No Swift package or native parity verification is included in this repository.
Implementation steps and evidence
Read platform differences and motion/haptic requirements before adapting the component.
Translate dimensions deliberately into points and typography into scalable text styles. Respect safe areas and Dynamic Type; CSS rem, em and environment expressions are not literal Swift values.
Use native accessibility and interaction semantics. Attach a Swift preview or device capture for each required state.
Evidence to bring back
Compile the native consumer and exercise VoiceOver.
Inspect large accessibility text, reduced motion, focus and light/dark appearance.
A component choice is stronger when the behavior around it is explicit.
01
Describe the user task, primary action and required data before choosing components.
02
Identify default, empty, loading, error, success and permission-dependent states that apply.
03
Choose existing components and record any uncovered behavior as a proposed extension.
04
Review the complete flow with design and the target platform engineer, including content and accessibility.
Try one complete flow.
The protected-email pattern connects Field, Input and Button through validation, progress and confirmation. Its service behavior is a local demonstration.
Use the package to resolve a decision and the generated references to understand it.
01
One reviewed source
packages/design-system owns the current component source, design contracts, semantic tokens and stories. The website, Storybook and agent records are generated consumers of that source.
02
Record the exact version
Carry the system version and content digest into a design handoff or implementation. Compare the digest before combining records; fetch again if they differ.
03
Keep provenance separate
The frozen automation import and legacy Figma registry explain where decisions came from. Their earlier approval does not approve local adaptations or override the current package.
04
Resolve a disagreement once
When a design file, implementation or generated record disagrees, record the component, token, version and observed difference. Correct the canonical package through review, then regenerate consumers.
This design-owned implementation is ready to try and review. It does not establish product approval. Imported specifications retain their original review status.