Design system

The interface uses shared matte black/white tokens, Astryx and StyleX, while retaining existing Radix controls where they serve real interactions. Public pages and the account workspace share primitives instead of maintaining two unrelated visual systems.

Extend a component

Use packages/ui/design/ for tokens and reusable controls. Keep component variants explicit and typed. Product-specific copy belongs in dictionaries, not styling files. A second real use case is a reason to extract a component; speculative wrappers make upgrades harder.

Support light, dark and system appearance. The public header has responsive desktop/mobile navigation, keyboard focus, language choices and scroll behavior. Workspace theme state is shared through the existing atom and synchronization component; do not toggle the root theme class from unrelated components.

The early application theme script and later synchronization must agree on storage encoding, resolved colors and language. New controls need labels, visible focus and understandable loading/error states. Respect reduced-motion preferences and keep layout usable at narrow widths.

Language-aware layout

Give labels room to grow. Chinese and English use the same component structure but different complete copy. Avoid fixed-width text controls, decorative line breaks that depend on English length, and icons as the only description of an action.

Keep implementation terminology out of ordinary product journeys unless it helps the user decide. The official website can describe template modules; a generated product should describe its own user task and output.

Check both themes, keyboard navigation, mobile menus and both language versions after changing shared styles. Translation work preserves the existing design direction and does not introduce a new styling framework.