Operating Model

One system, shared across products. Use this guide to find the right source, see how each product uses the system, and understand how design work is checked before release.

One source, many consumers

WorkPal interface preview showing the desktop workspace and mobile assistant.

Wingman interface preview showing desktop dating preferences and the mobile companion.

What the design system and products each own

Shared design system

Design principles and shared documentation content
Color, typography, spacing, radius, motion, and theme tokens
Reusable primitives, promoted patterns, and their shared variants
The company catalog examples that explain those shared definitions

Product code

WorkPal and Wingman directly use the shared components, layouts, and variants provided by packages/design-system; each product configures which ones to use and how they appear, then connects its own features, data, routing, and business logic.

How Codex and Claude Code execute design work

Read the project-level AGENTS.md or CLAUDE.md, then the repository design guidance and applicable product specification.
Check the Component Library first and reuse a shared component wherever possible.
If nothing fits, register and showcase the new shared primitive in the package and company catalog. For WorkPal-originated gaps, also add it to WorkPal's Review Queue for approval.
Run design-lint, relevant tests, and builds; visually verify the affected page, responsive states, and both themes when applicable.

Automated assurance

The assurance model has three layers. Each catches a different kind of risk, from code-level rules to the final page.

Layer 1 — Static rules

Active today. design-lint enforces selected hard rules on new UI changes: token and typography discipline, no emoji in product UI, and touch-target risk warnings. Build validation confirms affected applications compile.

Layer 2 — Component and accessibility contracts

Product-level coverage is active today: tests already verify shared component behavior and accessibility in the applications that use them. Next, this coverage will be consolidated into a consistent design-system contract layer.

Layer 3 — Visual regression

Planned. Repeatable screenshot comparisons will protect stable pages across themes, states, and responsive layouts from unintended visual change.

Public AI implementation resources

Use the public guide and rules to implement with Frame. They support alignment but do not certify design quality, accessibility, correct behavior, or complete compliance; human review remains necessary.

Frame Agent PluginTwo skills help teams design and audit conversational and agentic AI products using Frame principles, released components, implementation rules, and verifiable checks. Candidate package; not yet listed in the plugin directory.AI implementation guideHow people and programming agents select, compose, and verify Frame components.11 machine-readable implementation rulesThe implementation constraints, automation boundaries, examples, and human-review requirements.

Where to look (Internal resources)

Private repository links for authorized collaborators.

AGENTS.md — UI Implementation RulesThe mandatory implementation constraints applied to every product UI change.Design System (DESIGN_SYSTEM.md)Architecture, tokens, components, workflows, and interaction contracts.Shared component sourceThe reusable React primitives products import from @beibei/design-system.Token sourceShared theme variables, typography tiers, utilities, and animations.Design Principles (DESIGN_SYSTEM.md §3)Used by agents for design decisions and UI review.Automatic lint gateThe current diff-scoped checks and their explicit boundaries.