` accepts standard sizing — `style.height` is forwarded from the `height` prop. The SVG uses `preserveAspectRatio="xMidYMid slice"` so the bloom fills the box without distortion. Variants: | Variant | Tone | Use case | |---|---|---| | `1` | peach (default) | Primary brand — warm sunrise. Use for "create" or "active" surfaces. | | `2` | lavender | Cool dusk. Use for reflective / contemplative surfaces (settings, profile). | | `3` | sage | Lime/green diagonal sweep. Use for "complete" or "verified" surfaces. | | `4` | amber | Blue/violet vertical bloom. Use for "manage" or "in progress" surfaces. | | `5` | peach × lavender | Rare corner bloom. Reserve for accent moments. | ## Props `height` is a convenience — the canonical pattern is to wrap BloomArt in a sized container. Both work. ## States BloomArt has no states. It's a static visual. ## Density Density-agnostic. BloomArt is a hero-tier decoration; the site density toggle has no effect. ## Themes In dark, the bloom variants render at adjusted lightness to maintain perceived intensity. In forced-colors, the gradients flatten to a single fill — the painterly identity is lost but the layout is preserved. ## Tokens consumed BloomArt embeds its own color stops in the SVG. It doesn't consume runtime tokens — the variants are fixed visual identities, not themeable surfaces. ## Accessibility - **Keyboard interactions.** None. - **ARIA roles and properties.** SVG carries `aria-hidden="true"`. Skipped by assistive tech. - **Focus order.** N/A. - **Screen-reader expectations.** Not announced. - **Reduced motion.** Static. The optional [BloomBackdrop](/components/bloom-backdrop) ambient animation respects `prefers-reduced-motion`. - **Forced colors.** Gradients flatten to a single `Canvas` fill. - **WIG rules.** Decorative SVG carries `aria-hidden` (decorative-image rule). No `alt` text — alt only applies to ``. ## Do / Don't

**Do** — match the variant to the lifecycle phase. Peach for Create, amber for Manage, lavender for reflective surfaces.

**Don't** — pick variants arbitrarily. The four canonical families have semantic weight.

**Do** — compose BloomArt with a Glass overlay. The refraction reads correctly only when there's something to refract.

**Don't** — render BloomArt under prose without a Glass overlay. The painterly texture fights with reading.

**Do** — wrap BloomArt in a fixed-height container or pass `height` directly. The SVG fills its parent.

**Don't** — render multiple BloomArt elements stacked on the same surface. The painterly identity is the centre; you get one.

## Recipes This component appears in: - The marketing site's hero blocks. - [Docs corpus recipe](/recipes/docs-corpus) — accent blooms behind hero sections. ## Code example ```tsx import { BloomArt, Glass } from "@matter/components"; export function HeroBackdrop({ children }: { children: React.ReactNode }) { return (

{children}

); } ``` ## Source --- # BloomBackdrop Source: https://design.mattermode.com/components/bloom-backdrop Description: System pattern composing BloomArt positioned absolute behind a section, with an optional frosted `.bloom-veil` overlay. The canonical bloom behind content building block — use for marketing heroes and hero-tier dashboard cards. ## Hero example ## When to use Reach for BloomBackdrop when a section needs a painterly bloom behind content — typical mounts include the marketing-site hero, the dashboard's onboarding card, and any feature-introduction surface. The pattern is "BloomBackdrop in `position: absolute` behind a content container in `position: relative; z-index: 1`." The optional `veiled` flag adds a frosted `.bloom-veil` overlay that softens the bloom so text on top stays legible without a Glass card. Don't reach for BloomBackdrop for dense data surfaces (tables, lists). The painterly texture fights with reading. Don't use it for repeated rows either — the bloom is hero-tier; one per page is usually right.

**Do** — render BloomBackdrop inside a `

` with a `` for the content.

**Don't** — render BloomBackdrop without `overflow: hidden` on the parent. The bloom paints outside the section bounds.

## Anatomy Two structural pieces: 1. **BloomArt instance.** Positioned `absolute` with `inset: 0`. The `variant` prop forwards to BloomArt. 2. **Veil overlay (optional).** A `.bloom-veil` div positioned `absolute` over the bloom, with a frosted-glass treatment. Activated by `veiled` flag. Pure CSS — backdrop-filter blur and saturation. The whole component is wrapped in a `

` so the backdrop is skipped by assistive tech. ## Props `variant` mirrors BloomArt's variants (1–5). `veiled` toggles the frosted overlay. ## States Stateless. The bloom variant and veil are configuration, not state. ## Density Density-agnostic. BloomBackdrop is hero-tier. ## Themes In dark, the bloom variants render at adjusted lightness. The veil's backdrop blur and saturation also adapt — slightly more saturation in dark to maintain perceived depth. ## Tokens consumed The veil reads `--surface-veil` (light) or `--surface-veil-dark` (dark). The bloom embeds its own gradients via BloomArt and consumes no runtime tokens. ## Accessibility - **Keyboard interactions.** None. - **ARIA roles and properties.** Outer wrapper carries `aria-hidden="true"`. Children (BloomArt + veil) inherit. - **Focus order.** N/A. - **Screen-reader expectations.** Not announced. - **Reduced motion.** Static. Any motion is consumer responsibility. - **Forced colors.** Bloom flattens to `Canvas`. Veil disappears (backdrop-filter unsupported). - **WIG rules.** `aria-hidden` on the decorative wrapper (decorative-image rule). The backdrop must not interfere with foreground contrast — consumers verify text on top reads at AA against the bloom. ## Do / Don't

**Do** — use `veiled` for surfaces with prose on top. The frost softens the bloom so text stays readable.

**Don't** — render `veiled={false}` over body copy. The painterly bloom and prose will fight.

**Do** — set `overflow: hidden` on the parent Section. The bloom paints to the edges.

**Don't** — render BloomBackdrop in a parent with `overflow: visible`. The bloom escapes the section.

**Do** — use one BloomBackdrop per page. The painterly identity is the centre; multiple blooms compete.

**Don't** — stack BloomBackdrops. The compositing breaks; you get muddy color.

## Recipes This component appears in: - Marketing-site hero blocks. - [Docs corpus recipe](/recipes/docs-corpus) — onboarding cards. ## Code example ```tsx import { BloomBackdrop, Container, Section } from "@matter/components"; export function OnboardingHero({ children }: { children: React.ReactNode }) { return (

{children}

); } ``` ## Source --- # BoardConsentCard Source: https://design.mattermode.com/components/board-consent-card Description: Board consent in flight — title, awaiting-signatures pill, signer rows with per-director state, send-reminder footer. Use when a written consent is mid-execution and the board needs visibility into who has and hasnt signed. ## Hero example ## When to use Reach for BoardConsentCard when a Resolution of type `board_written_consent` is in `partially_signed` state and the founder, board secretary, or an agent on a `tier_3` token needs to see signing progress at a glance — who has signed, who hasn't, what the document is. The card belongs in three surfaces: the dashboard's board-consent inbox row, an inline reply from an agent in the composer ("Here's the status of the SAFE-authorization consent"), and the consent-detail page header. Don't reach for BoardConsentCard when the consent is already executed (`Document.execution_status: executed`) — at that point the signing flow is history and the right surface is a static [SignatureStack](/components/signature-stack) showing the audit trail, not a live tracker. Don't use it for non-board signatures either; investor side-letters and indemnification agreements have their own document state machine and belong in dedicated cards.

**Do** — render BoardConsentCard inline as an agent response when a `tier_3` agent answers "what's the status of the next-round SAFE authorization?"

**Don't** — render BoardConsentCard for a fully executed consent. Use a static SignatureStack instead.

## Anatomy Five structural parts: 1. **Header.** `Doc` icon + "Board Consent — `{title}`" + the awaiting-signatures Pill. The pill flips to `tone="green"` when every signer has signed (consumer responsibility — pass the right `signers` array). 2. **Signer rows.** One per `BoardSigner`. Each row: 24px circular initials avatar (color from the signer's `color` prop or `--fg-soft` fallback), name + role stacked, signed/pending pill aligned right. 3. **Avatar.** Initials only. The `color` prop accepts any CSS color string; if absent, the avatar falls back to `--fg-soft`. Avatars are decorative (`aria-hidden`); the signer's name carries the accessible identity. 4. **Per-signer pill.** `tone="green"` for `signed: true`, `tone="amber"` for the pending default. Geometry matches the announcement-pill shape — 20px height, mono font, 6px dot. 5. **Footer.** [CardsKit](/components/dynamic-card) footer — primary `Send reminder` action plus a secondary `View document` link. ## Props ## States The card has three semantic states driven by the `signers` array: | State | Signer condition | Header pill | |---|---|---| | Partially signed | Some `signed: true`, some `signed: false` | `Awaiting signatures` (amber) | | Fully signed | Every signer `signed: true` | `Executed` (green) — consumer flips header pill | | Awaiting first signature | Every signer `signed: false` | `Awaiting signatures` (amber) | The internal pill for each row reads directly from `signer.signed` — no consumer logic needed for the per-row state. ## Density In `compact`, signer-row padding drops from 10/14px to 6/10px and the row gap from 8px to 4px. The avatar stays 24px (touch target) and the per-row pill stays full size (legibility floor). ## Themes The card surface uses `.glass-card`, which composes the [Glass](/components/glass) backdrop in light and a flat translucent panel in dark. In forced-colors, the glass collapses to `Canvas` and the row borders inherit `ButtonBorder`. ## Tokens consumed The signer-row background reads `--paper-50` (or fully transparent if absent), the row border reads `--ink-5`, and each pill reads its tone family (`--status-green-bg` / `--status-amber-bg` and matching foregrounds). ## Accessibility - **Keyboard interactions.** The primary `Send reminder` button is the first focusable element; `View document` follows. Signer rows themselves are non-interactive — Tab skips past them. - **ARIA roles and properties.** The card is a generic region; no role override. Each per-row pill uses no `role` and relies on its text content for the accessible name. - **Focus order.** Footer primary → footer secondary. There is no focusable element within the signer list by design — the live signing flow happens on the document detail page, not inline. - **Screen-reader expectations.** Reading order: card title, "awaiting signatures", then each row in DOM order as "name, role, signed | pending". Avatars are `aria-hidden`. - **Reduced motion.** No keyframes inside this card. The footer button inherits the [Matter motion contract](/usage/motion-grammar) — hover lift collapses to opacity when `prefers-reduced-motion: reduce`. - **Forced colors.** Avatar fill maps to `Highlight`, pill dot to `ButtonText`. Glass surface collapses to `Canvas`. - **WIG rules.** Footer button respects icon-only `aria-label`, the card is a `

` (not abusing semantic elements), and the `Doc` icon carries `aria-hidden="true"` per the decorative-icon rule. ## Do / Don't

**Do** — pass real `initials` (two characters max) and a `color` derived from a stable hash of the signer's email so the avatar is consistent across renders.

**Don't** — pass full names into `initials`. The avatar caps at 24px and clips beyond two characters.

**Do** — render the card inline when an agent reports "the SAFE-authorization consent has two of four signatures."

**Don't** — render the card with an empty `signers` array as a placeholder. Use a CardSkeleton until the data resolves.

**Do** — keep the `title` short (≤ 60 chars). It composes with the "Board Consent — " prefix and should fit on one line at desktop widths.

**Don't** — duplicate the awaiting-signatures pill in the body. The header pill is canonical.

## Recipes This card appears in: - [Board recipe](/recipes/board) — the full board surface with pending consents, recent resolutions, and the next-meeting agenda. - [Docs corpus recipe](/recipes/docs-corpus) — when a consent is rendered inline as part of an agent reply. ## Code example ```tsx import { BoardConsentCard } from "@matter/components"; export function PendingConsentInline({ resolution }: { resolution: Resolution }) { return ( ({ name: s.full_name, role: s.board_role, initials: s.initials, color: s.avatar_color, signed: s.signature_state === "signed", }))} /> ); } ``` A complete worked example, including the API call that produces `resolution`, lives in the [Board recipe](/recipes/board). ## Source --- # ButtonGroup Source: https://design.mattermode.com/components/button-group Description: Horizontal cluster of buttons with token-driven gap and responsive wrap. ## Hero example ## When to use `ButtonGroup` is the canonical placement for a card's actions — typically 2-3 buttons in the footer of an inline card, aligned to the trailing edge. Use `align="end"` for the canonical card footer; `align="between"` when one action sits at each end; `align="stretch"` when the buttons need to fill the available width equally. For a single CTA, just render `

` with no internal structure. The `padding` prop applies via inline style and accepts any CSS length (number → px). All `HTMLAttributes` pass through via spread. The visual identity comes from `.card` in `@matter/components/styles.css`: - `background: var(--bg-elev)` - `border: 1px solid var(--border-soft)` - `border-radius: var(--radius-lg)` There are no slots — Card is a fully transparent container. ## Props ## States Card itself has no states — it's a static container. If you need hover or active states, wrap Card in an interactive element or apply `:hover` styles via the consumer's CSS using a class composition pattern (e.g. ``). ## Density In `compact`, the default padding drops from 32 to 24 (if not overridden). The radius and border stay constant. ## Themes ## Tokens consumed Background reads `--bg-elev`. Border reads `--border-soft`. Radius reads `--radius-lg`. ## Accessibility - **Keyboard interactions.** None — Card is non-interactive. Children carry their own contracts. - **ARIA roles and properties.** Generic container, no role override. If Card represents a named region with a heading, wrap the heading in an `

` and set `aria-labelledby` on the Card pointing to that heading's id — or render the surrounding element as a `

` and let it carry the semantics. - **Focus order.** No internal focus. - **Screen-reader expectations.** Children announce in DOM order. No prefix or suffix from the Card itself. - **Reduced motion.** N/A — no motion. - **Forced colors.** Background → `Canvas`; border → `ButtonBorder`. Radius preserved. - **WIG rules.** No specific WIG implications — Card is passive. Consumers wrap interactive children with the right WIG contracts. ## Do / Don't

**Do** — pass `padding={48}` for hero-level cards and `padding={16}` for inline summary cards. The default 32 is the canonical middle ground.

**Don't** — set padding via inline style. Use the prop so the value lands in the right place in the cascade.

**Do** — wrap multiple related cards in a [Section](/components/section) to share rhythm and spacing.

**Don't** — nest Card inside Card. It breaks the elevation contract — Card is the elevation layer.

**Do** — attach `role="region"` and `aria-labelledby` to Card when it represents a named section. Headings inside need a heading element.

**Don't** — use Card as a `

` substitute without setting `role`. Semantic HTML beats generic divs.

## Recipes This component appears in every recipe under `/recipes`. Card is the default container. ## Code example ```tsx import { Card } from "@matter/components"; export function RecentActivityCard({ events }: { events: AuditEvent[] }) { return (

Recent activity

{event.summary}

); } ``` ## Source --- # CodeBlock Source: https://design.mattermode.com/components/code-block Description: Geist Mono code surface with 5-token syntax coloring. Optional header slot composes any V2 primitive — the V1 CodeCard role. Always translucent white, never dark slate. Bare mode renders

; header mode wraps in .

## Hero example



## When to use

Reach for `` whenever rendering literal code or structured request / response payloads. The 5-token syntax palette (``) handles key / string / number / punct / comment without pulling in a syntax highlighter. The translucent-white surface is canonical — never dark slate. For long-form prose code, bare-`` mode is correct. For endpoint demos and API recipes, pass a `header` to render the card-style surface that V1 `` carried.

Don't reach for CodeBlock for inline code spans — use Markdown backticks, which fall through to the styled `` recipe. Don't use it for terminal output where you want a dark-slate aesthetic — Matter's code surface is intentionally light, even in dark theme.


  **Do** — compose the header with V2 primitives: `` plus a request-time ``.
  **Don't** — bake a dark theme. The surface is white-translucent by design.


## Anatomy

Bare mode renders a single ``. Card mode (header set) wraps in `` with a 44px `.code-card-head` row and the `.code` body underneath — geometry mirrors V1 `.matter-code-card` exactly so the consumer-migration step (action 9) lands as a pixel-parity swap.

The `` companion component colorizes spans inside the code body:

| `kind` | Token type | Color |
|---|---|---|
| `k` | key / identifier | Peach |
| `s` | string | Teal |
| `n` | number | Purple |
| `p` | punctuation | 40% black |
| `c` | comment | 45% black, italic |

## Header slot — V1 CodeCard replacement

```tsx
// V1 (today)

  …


// V2 (action 9 migration)

      
      142ms
    
  }
>
  …

```

The header slot accepts any `ReactNode`, so consumers can compose it however they need — verb chip, branch indicator, file path, response status, etc. The outer element switches to `` when a header is present so consumers may include a `` for accessible description.

## Props



## States

CodeBlock is single-state. Header mode and bare mode are configuration, not state.

## Density



In `compact`, the code body padding drops from 16 to 12px. Font size and line-height stay constant — code legibility is the floor.

## Themes





In dark, the translucent-white surface inverts to a translucent ink (still light against the dark backdrop) and the Tok colors shift to their dark-theme variants. In forced-colors, Tok colors collapse to system foreground; the surface collapses to `Canvas` with `ButtonBorder`.

## Tokens consumed




Surface reads `--code-surface`. Header band reads `--code-head`. Tok colors resolve through `--tok-k` / `--tok-s` / `--tok-n` / `--tok-p` / `--tok-c`.

## Accessibility

- **Keyboard interactions.** None — the `` is a static surface. Triple-click selects the block.
- **ARIA roles and properties.** `` carries no role override. `` (when header is set) inherits semantic figure role; consumer may add a ``.
- **Focus order.** N/A.
- **Screen-reader expectations.** Code is announced verbatim. Tok spans inherit accessibility — colour is purely visual.
- **Reduced motion.** N/A.
- **Forced colors.** Tok colors → system foreground; surface → `Canvas` with `ButtonBorder`.
- **WIG rules.** `` for monospace code (semantic-element rule). `` + optional `` for captioned code (semantic-element rule). Comment Tok meets AA — verify when surface is tinted.

## Do / Don't


  **Do** — use `` for keys, `` for strings, etc. The 5-token palette covers most syntactic needs without a full highlighter.
  **Don't** — pull in a syntax highlighter library. CodeBlock's palette is the canonical Matter look; highlighters drift.



  **Do** — wrap card-style code in a `` via the `header` prop. The outer element switches automatically.
  **Don't** — nest CodeBlock inside CodeBlock. Use one with a header instead.



  **Do** — pair with a Copy-to-clipboard button at the consumer layer for long examples. CodeBlock doesn't ship one — keep the surface minimal.
  **Don't** — set inline styles on `` to override the surface. Use the `style` prop on the wrapper if a height cap is needed.


## Recipes

This component appears in:

- [API recipe](/recipes/api) — every endpoint demo.
- [Docs corpus recipe](/recipes/docs-corpus) — inline code in agent replies.

## Code example

```tsx
import { CodeBlock, Tok, EndpointBadge } from "@matter/components";

export function CreateEntityExample() {
  return (
    
          
          142ms
        
      }
    >
      {`// Create a Delaware C-Corp`}{"\n"}
      curl "https://api.mattermode.com/v1/entities"{"\n"}
      {"  -H "}"Authorization: Bearer sk_test_…"
    
  );
}
```

## Source




---

# ComposerChip

Source: https://design.mattermode.com/components/composer-chip
Description: Pill-shaped action chip rendered in the Composers bottom-left slot. Used for attach buttons, model pickers, context selectors. Carries an optional leading icon and is a real