DS
Premium Docs

Design System Showroom

Published-package documentation wired to the real DS runtime so the same routes reveal how tenant and engine reshape identical component contracts.
Rottay / modern
Published package
Primary
#0A0A0A
Rottay
Radius
14px
Surface shape
DensitynormalPlatform Flagship
NavigatorLibrary map
8 sections
212 routes
Foundations first, then primitives, patterns, structures, and surfaces. Keep this rail legible enough to scan without hunting.
Foundations4 documented routes
4
Tokens
Themes
Engines
Icons
109
97
Display
Inputs
Feedback
Layout
Navigation
Overlay
48
Data
Forms
Visualization
Communication
Workflow
Navigation
Misc
21
Headers
Workspace
Record
Dashboard
Feedback
36
Admin
Data
Experience
Forms
Operations
Workspace
3
Platform
Bit Hire
Evnto
1
Playground
Runtime fingerprintToken readout from the active provider chain.
Live DS
Runtime
Platform
Rottay
Rottay / ModernPlatform Flagship
Primary
#0A0A0ASecondary #6B6B6B
Radius
14pxxl 18px
Density
normalBorder-light cards
Accent
Badge
Compact runtime evidence across 3+ token signals.
Published DS package ยท Developer Docs ยท Rottay / modernShared route metadata for the active runtime, kept inline so the shell reads like a thin header band.
Palette
#0A0A0ARottay
Chrome
Modernrenderer posture
Radius
14pxsurface shape
Density
normalPlatform Flagship
Developers

Developers

Active profilePlatform Flagship
Runtime postureRottay / modern
Architecture, onboarding, and implementation guidance for the design system.
Runtime controls
Developer hub
Operate the system, do not browse it blindly

Developers should feel like a delivery control room: clear next steps, clear ownership, and a fast route from first render to shared product capability.

This section now frames adoption around tenant-aware runtime proof: get one route healthy, classify shared work correctly, then compare engines and themes before code spreads.
Primitives97
Leaf components and local interaction building blocks.
Patterns47
Reusable task modules with durable behavior.
Structures21
Page chrome, toolbars, headers, and framing.
Surfaces36
Full route contracts configured by apps.
Ship your first screen
Fastest path
Why open thisUse this when the team needs a credible baseline before debating taxonomy or architecture.
OutcomeA healthy DS render in one app route with the provider mounted correctly.
Success signals
Provider mounted
Engine chosen
One screen rendered
Classify shared work correctly
Ownership model
Why open thisUse this before adding abstractions, wrappers, or screen-level APIs to the shared library.
OutcomeNew capability lands in the right tier instead of becoming route-specific glue.
Success signals
4-tier mental model
Ownership guardrails
Decision matrix
Compare real rendering behavior
Live inspection
Success signals
Live scenes
Engine deltas
Theme deltas
Developer routing
4 common developer questions

Start from the question you need answered

Each card points to the shortest path through the showroom instead of asking teams to navigate the taxonomy cold.
01
Open getting started

How do I prove the DS is alive inside my app today?

AnswerInstall once, mount the provider high enough, then render a small but convincing panel using DS primitives.
ArtifactA healthy first render with no custom wrapper debt.
02
Review architecture

Where should a new shared feature actually live?

AnswerStart with the smallest tier that fits the capability: primitive, pattern, structure, or surface.
ArtifactCleaner ownership and fewer extension mistakes.
03
Use the playground

How do I compare tone without building product code first?

AnswerCompare the same scene across engines and brands so visual choices are made with evidence, not memory.
ArtifactAn informed engine and tenant decision.
04
Read foundations

What should I inspect when the UI feels inconsistent?

First-day implementation board

This is the smallest useful slice: install the package, mount the provider, and render a credible panel through DS primitives.
Healthy first renderToken-aware snippet from the active showroom runtime.
tsx
17 lines
Consumption
Runtime-aware snippet

Validation checklist

01
Provider mounted at the correct app boundary.
02
Engine and tenant are chosen intentionally, not left as defaults by accident.
03
First screen uses DS layout primitives instead of ad hoc wrappers.
04
New shared work is classified before APIs or folders are created.
Ownership model
Choose the smallest tier that fits

Learn the 4-tier system map

The best developer docs make classification obvious before shared code is written.

Primitives

97
Leaf components with stable APIs and engine-switched rendering.
Decision ruleUse when the work is still a single component, not a workflow.

Patterns

47
Reusable task modules like tables, builders, stats, and flows.
Decision ruleUse when behavior repeats across products and deserves reuse.

Structures

21
Page chrome around content, patterns, and operational context.
Decision ruleUse when the problem is page framing, not the whole route contract.

Surfaces

36
Declarative page-level recipes consumed by product routes.
Decision ruleUse when the app should configure a whole screen with shared contracts.
Reference map
Intent-led navigation

Reference shelves

Route people by intent instead of by taxonomy so first render, ownership, and visual comparison stay reachable in one pass.
Build screens quicklyConcrete entry points when the team needs production UI, not theory.
PrimitivesPatternsSurfaces
Understand the systemUse these when the problem is ownership, structure, or consistency.
FoundationsArchitectureStructures
Compare rendering toneUse live routes before making aesthetic decisions in product code.
PlaygroundTheme BuilderEngines
Audit data-heavy UIHigh-signal references for dashboards, tables, and operational screens.
ChartsVisualizationDashboard surface
Working rule
The docs are healthier when they route people by intent: first render, ownership, and visual comparison should all be reachable in one scroll.
Primitives97 documented routes
Patterns48 documented routes
Structures21 documented routes
Surfaces36 documented routes
Verticals3 documented routes
Playground1 documented routes
DevelopersCurrent section
2
Developers
Getting Started
Architecture
roundedtop bar ยท solid dividers
TenantRottay
EngineModern
Why open thisUse this when feel, density, or brand voice are still undecided and screenshots are not enough.
OutcomeProduct posture is validated with engine and tenant comparisons before code spreads.
What this hub should unblock today

Start from the job to be done, not the folder tree.

01
Mount
Install the package, mount the provider, and get one route to render with confidence.
02
Classify
Use the 4-tier model before you add shared APIs, wrappers, or route contracts.
03
Compare
Validate engine, theme, and density with playground scenes before polishing product screens.
04
Scale
Move from primitives to surfaces once the ownership model and visual posture are already stable.
If the team only does one thing firstRender one convincing DS panel in the real app shell before inventing wrappers. That single success state unlocks more than any abstract architecture discussion.
AnswerAudit tokens, themes, engines, and icons before changing component APIs or patching route-level CSS.
ArtifactA cleaner diagnosis path for visual drift.
Healthy first renderTSX
Quick copy
import { Badge, Card, DesignSystemProvider, Flex, Stack, Text } from '@rottay/design-system';

export function AppShell() {
  return (
    <DesignSystemProvider forceEngine="modern" tenantSlug="rottay">
      <Card>
        <Stack spacing="md">
          <Flex align="center" justify="between">
            <Text as={"h2" as any} size="lg" weight="semibold">Workspace</Text>
            <Badge variant="success">Healthy</Badge>
          </Flex>
          <Text size="sm">Render one convincing screen before creating wrappers.</Text>
        </Stack>
      </Card>
    </DesignSystemProvider>
  );
}