Back to Details

gts-design-system-integration

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

GTS Design System Integration

GTS设计系统集成

Quick Workflow

快速工作流程

  1. Identify the app type and current styling stack.
  2. Align dependencies and Tailwind v4 tooling.
  3. Set up one Tailwind css entrypoint and correct import order.
  4. Import GTS css once at the app root.
  5. Remove conflicting token/theme/global style sources.
  6. Apply GTS layout and typography patterns.
  7. For complex pages (for example configurator screens), compose reusable layout sections and variant-driven states.
  8. Validate build, lint, and visual output.
  1. 确定应用类型和当前样式技术栈。
  2. 对齐依赖项和Tailwind v4工具链。
  3. 配置一个Tailwind CSS入口点并设置正确的导入顺序。
  4. 在应用根目录处导入一次GTS CSS。
  5. 移除冲突的token/主题/全局样式源。
  6. 应用GTS布局与排版模式。
  7. 对于复杂页面（例如配置器页面），组合可复用的布局区块和变体驱动的状态。
  8. 验证构建、代码检查和视觉输出效果。

Load These References

参考资料

  • Always read 
    references/guidelines.md
    .
  • Always read 
    references/shadcn-compatibility.md
    .
  • Always read 
    references/tailwind-style-usage.md
    .
  • Always read 
    references/tailwind-utility-inventory.md
    .
  • Read 
    references/app-integration-playbook.md
    for app-specific steps.
  • 务必阅读
    references/guidelines.md
    。
  • 务必阅读
    references/shadcn-compatibility.md
    。
  • 务必阅读
    references/tailwind-style-usage.md
    。
  • 务必阅读
    references/tailwind-utility-inventory.md
    。
  • 针对特定应用的步骤，请阅读
    references/app-integration-playbook.md
    。

Guardrails

注意事项

  • Treat 
    gts-central-library
    as the styling source of truth.
  • Keep app behavior and routing unchanged during migration.
  • Keep local css minimal and app-specific.
  • Avoid duplicate semantic variable systems.
  • Keep Tailwind configuration modern (v4 syntax/tooling) and avoid legacy layering patterns.
  • Prefer GTS components and token-backed values over one-off styles.
  • For configurator implementations, model screen states as explicit variants (
    summary
    , 
    style
    , 
    personalize
    , etc.) instead of duplicating near-identical page code.
  • Reuse existing primitives (
    Header
    , 
    USPBar
    , 
    ActionBar
    , 
    Button
    , 
    SearchBar
    , token utilities) before introducing new components.
  • Keep configurator sections data-driven (accordion rows, swatches, option grids) so behavior and structure stay consistent across variants.
  • Add Storybook coverage for each major layout state; do not create separate stories for transient interactive states (hover/focus/pressed).
  • 将
    gts-central-library
    视为样式的唯一可信来源。
  • 迁移期间保持应用行为和路由不变。
  • 尽量减少本地CSS，仅保留应用特定的样式。
  • 避免重复的语义变量系统。
  • 保持Tailwind配置为现代版本（v4语法/工具），避免传统的分层模式。
  • 优先使用GTS组件和基于token的值，而非一次性样式。
  • 对于配置器实现，将页面状态建模为明确的变体（如
    summary
    、
    style
    、
    personalize
    等），而非复制几乎相同的页面代码。
  • 在引入新组件之前，优先复用现有基础组件（
    Header
    、
    USPBar
    、
    ActionBar
    、
    Button
    、
    SearchBar
    、token工具类）。
  • 保持配置器区块的数据驱动（手风琴行、色板、选项网格），确保不同变体间的行为和结构一致。
  • 为每个主要布局状态添加Storybook覆盖；无需为临时交互状态（悬停/聚焦/按下）创建单独的Story。

Validation

验证

Use the app's standard checks:
bash
npm run build
npm run lint
Then verify representative screens for token resolution, spacing, typography, and color parity.
For 
gts-central-library
itself, use:
bash
bun run build
bun run lint
使用应用的标准检查命令：
bash
npm run build
npm run lint
然后验证代表性页面的token解析、间距、排版和颜色一致性。
对于
gts-central-library
本身，使用：
bash
bun run build
bun run lint