Sonarist / Design system

Documentation v1.0.0 · Work in progress · UI prototype with separate server foundations

Design system contents

Implementation

Fictional data and isolation

Make realistic evidence without exposing people, contacting providers or changing the source application.

On this page

Fixture policy

Fixture policy
Area	Policy
Source starting data	Use mock-data structure and its varied conversation states; records are fictional.
Owner identity	Substitute Thomas McGee with Morgan Ellis inside snapshot only.
Email addresses	Replace every source address domain with example.com; remove real-domain association.
Operational settings	Retain clearly labeled sample billing/domain/Kit statuses.
Failure specimens	Supply failed outbound status and rejected AI promise to actual components.
Writes	Remove API/server providers; block external browser requests; specimen callbacks no-op.
Credentials	Do not copy .env files, uploads, .git, .vercel or database credentials.
Fonts	Copy original cached Geist files locally; preserve font weight and glyph ranges.

Data constraints

Keep IDs and foreign keys consistent across contact, inbox, product, company and conversation records. Source product descriptions are fictional sample labels, not factual product claims. Give different queue states meaningful content and preserve normal paragraph length so layout stress remains realistic.

No production database is used. The temporary app holds frontend state only. Sending, invitations, billing, domain tests and integrations remain local demonstration behavior; screenshots must not describe them as verified external operations.

Source references

Source references
File	Responsibility
lib/mock-data.ts	Fixture model
lib/types.ts	Foreign-key-like ID contracts
components/helpdesk-app.tsx	Local state boundary

Examples from the app

Actual Sonarist components with fictional conversations, people, example.com addresses and simulated operational states. Captured at 2× resolution or higher. Select an image to inspect it full size.