Make a consistent call on whether to use, extend, or fork a DS component without re-litigating. Walk the decision steps or Review the handshake contract pattern.

Works here: prod · Flos UI · Regions: MY, DK
Owner: Design System Lead

Quick path

1. Match: Does an existing DS component meet the user need? If yes, use as-is.
2. Extend: If 1–2 new props solve it without breaking a11y/tokens, propose an extension.
3. Compose: Combine DS components before creating something new.
4. Fork: Only when 1–3 fail and you have backing from the DS owner.

“Show me” snippet (safe extend)

// Button with icon + loading, token-safe
<Button variant="primary" aria-busy={loading}>
  {loading ? <Spinner size="sm" aria-hidden /> : <IconDownload aria-hidden />}
  <span className="sr-only">{loading ? 'Loading…' : 'Download'}</span>
</Button>

Escalation package (for extension/fork)

Problem: <1 line>
Evidence: screenshot + a11y note
Proposal: extend|compose|fork
Owner: <your squad>
Backup owner: <DS maintainer>
Review slot: <date>

Why we do it this way

Forks explode maintenance; extensions keep invariants, tokens, and tests intact.

Handoff → /operate/handshake-contracts

Related references

• Playbook canon — Especially the Handshake Contracts and Decision Spine entries referenced here.
• Quick-Run check — Run after editing DS documentation to keep receipts.
• UI baseline — Validate any component extension still honors the a11y baseline.