# Customer Brand and Storybook

The customer's published design-system Storybook is both a brand reference and
a component catalog. Customers can describe the character of their brand,
visual principles, voice, layout preferences, and intended component usage in
that Storybook. Use the published version when designing an artifact with a
visual surface.

## Inspect before designing

1. Use the task-provided Storybook MCP. Call `list-all-documentation`, then open
   the brand guidance and the closest relevant component or page stories with
   `get-documentation` or `get-documentation-for-story`.
2. Read the human-authored brand guidance as design intent. Inspect rendered
   stories for concrete evidence of hierarchy, density, typography, color,
   spacing, shape, imagery, interaction, and voice.
3. Use the corresponding vendored components and tokens from
   `src/design-system/`. Materialize approved logos or imagery through the asset
   tools when the brief needs them.
4. Build the app's own stories and rendered draft in that visual language.

Do not treat Storybook as only a test harness. It is the customer's durable
reference for what an application should feel like. Do not infer the brand from
a logo alone or replace a published customer direction with generic dashboard
styling.

## Authority and fallback

Use the current published design system, not an unpublished draft, stale local
copy, or another tenant's stories. The task brief controls the app's purpose;
the published Storybook controls its established visual language. Accessibility,
truthful data presentation, and artifact security/runtime constraints still
apply when a brand preference conflicts with them.

If the Storybook MCP or published design system is unavailable, report that
limitation and use the blessed template plus its vendored defaults. Do not invent
customer-specific colors, typography, voice, or brand rules.

## Validate against the reference

Compare the rendered artifact with the referenced customer stories at desktop
and mobile sizes. Verify the app uses the intended components and tokens and
that its hierarchy, density, voice, and interaction feel related to the
customer's examples without copying an unrelated page layout. Keep the normal
loading, empty, zero, partial, stale, error, permission, dense-data, and long-label
states in the app's Storybook or equivalent rendered validation surface.