diff --git a/CHANGELOG.md b/CHANGELOG.md
index 4f7a2b16..c9e54557 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -6,6 +6,43 @@ We are following [Semantic Versioning](https://semver.org/spec/v2.0.0.html), as
## Monorepo Package Releases (`toolkit-v*`, `react-v*`)
+### 2026-03-25
+
+#### @ourfuturehealth/toolkit 4.7.0 (`toolkit-v4.7.0`)
+
+##### Added
+
+- Dedicated `card-callout` and `card-do-dont` toolkit components aligned to the current Card family structure
+- Dismissible-with-image Card examples in the docs site and examples index
+- Responsive `gap-x`, `gap-y`, and `gap` spacing helpers for flex/grid component work
+
+##### Changed
+
+- Realigned the base `card` component to the current Figma structure across basic, dismissible, clickable, clickable-action, clickable-numeric, and icon-led variants
+- Updated the Card family after the v4.5.0 spacing and typography hard cut, including responsive token alignment and shared labelled-panel spacing
+- Aligned the dismissible Card hit-zone with the latest Figma corner-target model
+- Updated Card trailing icons to be neutral by default and support an explicit colour override for monochrome icons
+- Preserved legacy toolkit APIs such as `warningCallout()`, `list()`, and old Card inputs as deprecated compatibility paths for existing consumers
+- Updated Card-family documentation and examples to prefer the new Card family macros and options
+- Refined Card-family docs clarity across site docs, macro options, toolkit READMEs, and Storybook-facing guidance
+
+#### @ourfuturehealth/react-components 0.5.0 (`react-v0.5.0`)
+
+##### Added
+
+- New Card family components using the current API only:
+ - `Card`
+ - `CardCallout`
+ - `CardDoDont`
+- Storybook coverage for base Card variants, Card / Callout, and Card / Do & Don’t
+- Unit and accessibility coverage for the Card family
+
+##### Changed
+
+- Bundled the toolkit icon sprite for React and Storybook consumers so Card icons render without a separately hosted `/assets/icons/icon-sprite.svg`
+- Refined Card-family Storybook docs, controls behaviour, and examples for easier manual QA
+- Updated Card icon stories to expose glyph and colour controls that match the current component behavior
+
### 2026-03-24
#### @ourfuturehealth/toolkit 4.6.0 (`toolkit-v4.6.0`)
diff --git a/UPGRADING.md b/UPGRADING.md
index bddf0513..ec542fca 100644
--- a/UPGRADING.md
+++ b/UPGRADING.md
@@ -8,6 +8,7 @@ This guide provides detailed migration instructions for upgrading between versio
| Version | Date | Breaking Changes | Migration Complexity |
| ------------------------------------------------------- | ------------- | --------------------- | ------------------------------------- |
+| [v4.7.0 / React v0.5.0](#upgrading-to-v470--react-v050) | March 2026 | Card family realignment | 🟡 Medium - API migration recommended |
| [v4.6.0 / React v0.4.0](#upgrading-to-v460--react-v040) | March 2026 | Tag default + naming | 🟡 Medium - Search/replace recommended |
| [v4.5.0](#upgrading-to-v450) | March 2026 | Spacing and typography API changes | 🟡 Medium - Replace legacy APIs and recheck overrides |
| [v4.3.0 / React v0.2.0](#upgrading-to-v430--react-v020) | March 2026 | Button variant naming | 🟡 Medium - Find/replace required |
@@ -16,6 +17,56 @@ This guide provides detailed migration instructions for upgrading between versio
---
+## Upgrading to v4.7.0 / React v0.5.0
+
+**Released:** March 2026
+**Affected packages:**
+
+- `@ourfuturehealth/toolkit` v4.7.0+
+- `@ourfuturehealth/react-components` v0.5.0+
+
+### Breaking Changes
+
+None.
+
+### Card Family Realignment
+
+The Card family has been aligned to the current design-system split:
+
+- `card` remains the base component
+- `warning-callout` has moved to `card-callout`
+- `do-dont-list` has moved to `card-do-dont`
+
+#### Toolkit consumers
+
+Existing toolkit consumers should continue to work without immediate code changes:
+
+- `warningCallout()` still renders, but it is deprecated
+- `list()` still renders, but it is deprecated
+- legacy `card` inputs such as `clickable`, `feature`, `type`, and `HTML` still render, but they are deprecated
+
+For new work, migrate to the new APIs:
+
+| Deprecated toolkit API | Preferred API |
+| ---------------------- | ------------- |
+| `warningCallout()` | `cardCallout({ variant: 'warning', ... })` |
+| `list({ type: 'tick'|'cross' })` | `cardDoDont({ type: 'do'|'dont', ... })` |
+| `card({ clickable: true })` | `card({ variant: 'clickable' })` |
+| `cardWithIcon()` | `card({ icon: { ... } })` |
+| `card({ HTML: ... })` | `card({ descriptionHtml: ... })` |
+
+#### React consumers
+
+React now exposes the Card family directly:
+
+- `Card`
+- `CardCallout`
+- `CardDoDont`
+
+The nested `Card` `tag` prop uses the public React `Tag` API, so tag content is passed with `children` plus optional Tag props such as `variant` and `className`.
+
+---
+
## Upgrading to v4.6.0 / React v0.4.0
**Released:** March 2026
@@ -119,7 +170,7 @@ After updating your code, verify:
## Upgrading to v4.5.0
-**Released:** March 2026
+**Released:** March 2026
**Affected packages:**
- `@ourfuturehealth/toolkit` v4.5.0+
@@ -466,7 +517,7 @@ Install from specific release tag (recommended):
```json
{
"dependencies": {
- "@ourfuturehealth/toolkit": "github:ourfuturehealth/design-system-toolkit#toolkit-v4.0.0:packages/toolkit"
+ "@ourfuturehealth/toolkit": "github:ourfuturehealth/design-system-toolkit#toolkit-v4.5.0:packages/toolkit"
}
}
```
@@ -668,7 +719,7 @@ Server-side rendering templates for generating HTML:
- **Packages can be released independently**
- Tag format:
- Toolkit: `toolkit-v*` (e.g., `toolkit-v4.0.0`)
- - React: `react-v*` (e.g., `react-v0.0.1`)
+ - React: `react-v*` (e.g., `react-v0.2.0`)
### Installing Individual Packages
@@ -679,7 +730,7 @@ Each package in the monorepo can be installed independently:
```json
{
"dependencies": {
- "@ourfuturehealth/toolkit": "github:ourfuturehealth/design-system-toolkit#toolkit-v4.0.0:packages/toolkit"
+ "@ourfuturehealth/toolkit": "github:ourfuturehealth/design-system-toolkit#toolkit-v4.5.0:packages/toolkit"
}
}
```
@@ -689,7 +740,7 @@ Each package in the monorepo can be installed independently:
```json
{
"dependencies": {
- "@ourfuturehealth/react-components": "github:ourfuturehealth/design-system-toolkit#react-v0.0.1:packages/react-components"
+ "@ourfuturehealth/react-components": "github:ourfuturehealth/design-system-toolkit#react-v0.5.0:packages/react-components"
}
}
```
diff --git a/docs/consuming-react-components.md b/docs/consuming-react-components.md
index f61f0de2..84d15fc9 100644
--- a/docs/consuming-react-components.md
+++ b/docs/consuming-react-components.md
@@ -1,5 +1,3 @@
-# WORK IN PROGRESS (Needs to be updated)
-
# Consuming Our Future Health React Components
This guide explains how to consume the `@ourfuturehealth/react-components` package in your React applications.
@@ -19,18 +17,18 @@ Currently, the React components are not published to npm registry. Install direc
### Using pnpm (recommended)
```bash
-pnpm add @ourfuturehealth/react-components@github:ourfuturehealth/design-system-toolkit#react-v0.0.1:packages/react-components
+pnpm add @ourfuturehealth/react-components@github:ourfuturehealth/design-system-toolkit#react-v0.5.0:packages/react-components
```
### Using npm
```bash
-npm install @ourfuturehealth/react-components@github:ourfuturehealth/design-system-toolkit#react-v0.0.1:packages/react-components
+npm install @ourfuturehealth/react-components@github:ourfuturehealth/design-system-toolkit#react-v0.5.0:packages/react-components
```
### Version Pinning
-- **Production**: Use specific version tags (e.g., `#react-v0.0.1`)
+- **Production**: Use specific version tags (e.g., `#react-v0.5.0`)
- **Development**: You can use `#main:packages/react-components` but ensure your lockfile pins a specific commit
**package.json example:**
@@ -38,7 +36,7 @@ npm install @ourfuturehealth/react-components@github:ourfuturehealth/design-syst
```json
{
"dependencies": {
- "@ourfuturehealth/react-components": "github:ourfuturehealth/design-system-toolkit#react-v0.0.1:packages/react-components",
+ "@ourfuturehealth/react-components": "github:ourfuturehealth/design-system-toolkit#react-v0.5.0:packages/react-components",
"react": "^19.2.4",
"react-dom": "^19.2.4"
}
@@ -112,10 +110,13 @@ To add a new custom React theme stylesheet export, follow `docs/theming/adding-a
The React components package currently provides the following components:
-- `Button` - Call-to-action buttons
-- `TextInput` - Text input fields
-
-**More components coming soon!** We're actively developing additional React wrappers for the design system toolkit components.
+- `Button` - Call-to-action buttons and links
+- `TextInput` - Text input fields with hint and error support
+- `ErrorSummary` - Page-level validation summaries with linked errors
+- `Tag` - Status tags aligned with toolkit Tag variants
+- `Card` - Content presentation cards for summaries, status, and next steps
+- `CardCallout` - Feedback-style callout cards for informational, warning, success, and error messages
+- `CardDoDont` - Positive and negative recommendation lists
For complete component documentation and live examples, run Storybook:
diff --git a/docs/prompts/README.md b/docs/prompts/README.md
new file mode 100644
index 00000000..a6938f85
--- /dev/null
+++ b/docs/prompts/README.md
@@ -0,0 +1,22 @@
+# Prompt Workflows
+
+Use these prompts as a staged workflow when updating a component.
+
+## Recommended Order
+
+1. `component-update-template-prompt.md`
+ Use for the full implementation workflow: Figma analysis, toolkit work, React parity, tests, Storybook, and documentation.
+2. `component-validation-qa-template-prompt.md`
+ Use once implementation is mostly done and you want an interactive manual QA pass with exact URLs and step-by-step validation.
+3. `component-pr-readiness-template-prompt.md`
+ Use after QA passes, or when you want the final repo-wide cleanup, release-doc refresh, commit prep, and branch handoff.
+
+## Why These Are Separate
+
+The implementation prompt and the two finish-up prompts ask the agent to work in different modes:
+
+- implementation work should stay focused on design analysis and code changes
+- interactive QA should pause after each step and wait for pass/fail feedback
+- PR-readiness work should keep moving and clean up repo-wide surfaces without stopping after every check
+
+Keeping them separate makes the workflow easier to follow and reduces prompt ambiguity.
diff --git a/docs/prompts/component-pr-readiness-template-prompt.md b/docs/prompts/component-pr-readiness-template-prompt.md
index ac8ec3b6..38610834 100644
--- a/docs/prompts/component-pr-readiness-template-prompt.md
+++ b/docs/prompts/component-pr-readiness-template-prompt.md
@@ -53,6 +53,19 @@ Workflow I want you to follow:
- confirm deprecated compatibility paths exist only where intended
- confirm toolkit vs React consumer expectations are documented clearly
- confirm Storybook controls policy and prop docs are still coherent after any late changes
+ - confirm no interactive single-component stories are still relying on raw JSON controls for stable nested props when clearer story-specific controls would be more usable
+ - confirm no story is exposing controls for values the component visibly ignores or overrides
+ - if the component was touched by a spacing/typography token migration, do a final spot-check for same-number static-token substitutions where Figma expected responsive tokens
+ - do a final spot-check for accidental semantic-element inheritance (`p`, `ul`, `li`, `h*`, `a`) that may have reintroduced wrong spacing or typography
+ - confirm release/version metadata is internally consistent wherever this branch claims a release number or tag:
+ - `packages/*/package.json` version fields
+ - `CHANGELOG.md`
+ - `UPGRADING.md`
+ - release/versioning strategy docs
+ - PR title/body if it mentions planned release versions or tags
+ - if docs claim a package release version or tag that is not reflected in the relevant `package.json`, treat that as a PR-readiness failure and fix it before sign-off
+ - if the component was touched by a spacing/typography token migration, do a final spot-check for same-number static-token substitutions where Figma expected responsive tokens
+ - do a final spot-check for accidental semantic-element inheritance (`p`, `ul`, `li`, `h*`, `a`) that may have reintroduced wrong spacing or typography
- confirm release/version metadata is internally consistent wherever this branch claims a release number or tag:
- `packages/*/package.json` version fields
- `CHANGELOG.md`
diff --git a/docs/prompts/component-update-template-prompt.md b/docs/prompts/component-update-template-prompt.md
index d551f2ed..9b81b663 100644
--- a/docs/prompts/component-update-template-prompt.md
+++ b/docs/prompts/component-update-template-prompt.md
@@ -71,6 +71,14 @@ After implementation is mostly done, move to the dedicated validation and PR-rea
- Typography tokens
- Interactive states (hover, focus, active, disabled)
- Accessibility annotations
+- Build a **token translation table** for the component before implementation:
+ - list each meaningful subelement (container, header/label, body, list, helper text, link/action, icon gap, hit target, etc.)
+ - record the exact Figma token used for spacing, typography, radius, border, and icon sizing
+ - mark each token as `static` or `responsive`
+ - record the actual mobile / tablet / desktop values when the token is responsive
+- Do not assume that a same-number static token is equivalent to a responsive Figma token
+ - example: `ofh/space/vertical/16` is **not** automatically the same as `$ofh-size-16`
+ - example: `paragraph/md` in Figma should map to the responsive typography mixin, not rely on inherited browser or global text styles
### 2. Current Implementation Review
@@ -82,6 +90,10 @@ After implementation is mostly done, move to the dedicated validation and PR-rea
- Review `{component-name}.js` (if exists) - behavior
- Review `README.md` - documentation completeness
- Review `tests/integration/{component-name}.test.js` (if exists)
+- Review how the component interacts with **global semantic element styles**
+ - check `p`, `ul`, `ol`, `li`, `h1-h6`, `a`, `button`, and similar elements used inside the component
+ - identify where the component is intentionally relying on global typography or list spacing
+ - identify where those inherited styles must be overridden to match Figma exactly
**React (`packages/react-components/src/components/{ComponentName}/`):**
@@ -162,12 +174,24 @@ Review the entire component implementation against design system standards:
- [ ] All border-radius values → Check against `$ofh-radius-*` tokens
- [ ] All border widths → Check against `$ofh-stroke-weight-*` tokens
- [ ] All shadow values → Check against `$ofh-shadow-*` tokens
+- [ ] For every spacing and typography token in Figma, map it to the **correct code primitive**:
+ - responsive spacing helper
+ - responsive typography mixin
+ - static size token
+ - iconography token
+- [ ] Do not replace responsive Figma tokens with same-number static tokens just because the desktop value matches
+- [ ] Audit invisible layout/hit-area spacing too, not just visible padding and icon size
+- [ ] Audit semantic-element inheritance:
+ - check whether global `ul > li`, `p`, `h*`, or link styles are adding margins/typography the component did not ask for
+ - add explicit overrides when Figma requires component-specific spacing or typography
**Responsive Pattern Audit:**
- [ ] Manual media queries for spacing → Check if `@include ofh-responsive-padding/margin()` can be used
- [ ] Manual media queries for typography → Check if responsive typography mixin handles this
- [ ] Inconsistent breakpoint usage → Check against `$ofh-breakpoints`
+- [ ] When a responsive helper **cannot** express the exact Figma values, document why and use explicit breakpoint rules intentionally
+- [ ] Verify every responsive token hotspot at mobile, tablet, and desktop instead of only checking the desktop screenshot
**Focus State Audit:**
@@ -430,6 +454,7 @@ it('should be keyboard accessible', async () => {
- ✅ Proper argTypes documentation
- ✅ Component description from design system
- ✅ Auto-generated prop table (via TypeScript)
+- ✅ Story controls that are ergonomic and honest about what the component actually supports
**Story Pattern:**
@@ -524,10 +549,21 @@ Review the component's user-facing documentation surfaces and make sure they exp
- Controls rule:
- keep controls enabled for `interactive single-component example` stories where the controls map cleanly to the rendered output
- disable controls for `showcase/comparison` or `behavior/demo` stories when controls would be misleading or do not control the rendered output meaningfully
+- For structured or nested props, do not default to raw JSON editing when a clearer control model is available
+ - examples: `tag`, `icon`, `dismissButton`, `actionLink`, `metadataItems`
+ - when the story only needs a stable subset of that object shape, add story-only args such as `tagText`, `tagVariant`, `iconName`, `iconSize`, `actionHref`, or similar and map them to the real prop in `render`
+ - hide the raw object control for that story when the story-only controls are the intended interaction path
+ - only keep raw object editing visible when the JSON shape itself is what consumers need to learn
+- Use the most specific control type available for constrained values
+ - `select`, `radio`, `boolean`, `text`, or `number` instead of generic object editors whenever the value set is finite or easy to model
+- Do not expose controls for prop fields that the component visually ignores or overrides
+ - example: if a component slot forces a fixed icon size or color, do not expose a misleading size or tone control for that story unless the story is explicitly demonstrating that constraint
- Check for misleading cases such as:
- `All variants` stories showing one prop panel that does not affect the displayed variants
- `Keyboard navigation` stories showing controls that do not apply to the demo content
- multi-example stories where the controls affect none of the rendered examples
+ - nested object props that require raw JSON editing even though the story only needs a text/select/boolean subset
+ - controls for values that appear editable in Storybook but do not produce any visual or behavioral change in the rendered story
**Prop documentation clarity review (MANDATORY):**
@@ -562,6 +598,8 @@ Review the component's user-facing documentation surfaces and make sure they exp
**Output required before moving to QA:**
- Confirm that each story has an intentional controls policy
+- Confirm that structured props are not exposed as raw JSON when a clearer story-specific control model would be more usable
+- Confirm that no story exposes controls for values the component visibly ignores or overrides
- Confirm that prop descriptions are written in plain language, not just implementation language
- Confirm that Storybook docs, site docs, macro options, and README describe the same API consistently
@@ -589,10 +627,14 @@ Before moving to the validation prompt, answer these checks explicitly:
- [ ] Are any Storybook controls misleading for any story?
- [ ] Does every story have an intentional controls policy?
+- [ ] Are any nested or structured props still exposed as raw JSON even though the story could offer clearer text/select/boolean controls instead?
+- [ ] Do any story controls expose values that the component visually ignores or overrides?
- [ ] Are `heading`, `headingLevel`, and any HTML-overrides explained clearly where relevant?
- [ ] Are advanced props such as `classes`, `className`, `attributes`, and `ref` clearly described as advanced/integration props where appropriate?
- [ ] Do Storybook docs, site docs, macro options, and README describe the same API consistently?
- [ ] Are showcase/demo stories clearly non-interactive where appropriate?
+- [ ] Has every meaningful spacing/typography token from Figma been checked against the actual mobile / tablet / desktop values in code?
+- [ ] Have semantic-element defaults (`p`, `ul`, `li`, `h*`, `a`) been checked so the component is not accidentally inheriting the wrong margins or typography?
If any answer is "no", fix it before moving to the QA prompt.
@@ -630,6 +672,7 @@ pnpm storybook
3. Test with screen reader (if complex component)
4. Visual comparison with Figma specs
5. Test in `example-react-consumer-app`
+6. For components using responsive spacing or typography tokens, spot-check mobile, tablet, and desktop values in DevTools for the highest-risk subelements
### Documentation Review
diff --git a/docs/prompts/component-validation-qa-template-prompt.md b/docs/prompts/component-validation-qa-template-prompt.md
index 2a1dbc96..f3b15a94 100644
--- a/docs/prompts/component-validation-qa-template-prompt.md
+++ b/docs/prompts/component-validation-qa-template-prompt.md
@@ -37,6 +37,7 @@ Workflow I want you to follow:
- exact Storybook docs/story URLs
- a short pass/fail table
- any Figma comparison notes I should keep in mind
+ - any breakpoint-specific token expectations I should keep in mind for mobile / tablet / desktop
4. Then walk me through that QA script one step at a time.
5. After each step, stop and wait for my response in the format:
- `pass`
@@ -58,6 +59,9 @@ Important constraints:
- If Storybook examples are misleading or make validation harder, improve them.
- If docs/examples are missing what is needed to validate behavior, improve them too.
- Treat misleading Storybook controls or vague prop documentation as implementation misses to be fixed before QA is considered complete.
+- Treat raw JSON controls for stable nested props as implementation misses when the story could reasonably offer clearer text/select/boolean controls instead.
+- Treat controls for values the component visibly ignores or overrides as implementation misses to be fixed before QA is considered complete.
+- Treat responsive token mismatches or accidental inherited element styles (`p`, `ul`, `li`, `h*`, `a`) as implementation misses to be fixed before QA is considered complete.
- If implementation used a temporary internal adapter because a dependency was missing, call that out clearly during QA and include the affected surfaces in the validation script.
- Include exact URLs for every QA step.
- Keep the flow interactive. Do not skip ahead after giving me a step.
diff --git a/docs/release-versioning-strategy.md b/docs/release-versioning-strategy.md
index 56198a42..47df42ff 100644
--- a/docs/release-versioning-strategy.md
+++ b/docs/release-versioning-strategy.md
@@ -87,8 +87,10 @@ This table is a visual aid for pre-monorepo vs post-monorepo release identificat
| 11 | `toolkit-v4.4.0` | `4.4.0` | N/A | Monorepo | Released |
| 12 | `react-v0.3.0` | N/A | `0.3.0` | Monorepo | Released |
| 13 | `toolkit-v4.5.0` | `4.5.0` | N/A | Monorepo | Released |
-| 14 | `toolkit-v4.6.0` | `4.6.0` | N/A | Monorepo | Planned in this branch |
-| 15 | `react-v0.4.0` | N/A | `0.4.0` | Monorepo | Planned in this branch |
+| 14 | `toolkit-v4.6.0` | `4.6.0` | N/A | Monorepo | Released |
+| 15 | `react-v0.4.0` | N/A | `0.4.0` | Monorepo | Released |
+| 16 | `toolkit-v4.7.0` | `4.7.0` | N/A | Monorepo | Planned in this branch |
+| 17 | `react-v0.5.0` | N/A | `0.5.0` | Monorepo | Planned in this branch |
## Release Output Expectations
diff --git a/packages/react-components/README.md b/packages/react-components/README.md
index e47e2245..6fae8f97 100644
--- a/packages/react-components/README.md
+++ b/packages/react-components/README.md
@@ -7,19 +7,27 @@ React component library for the OFH Design System.
Install from the monorepo using a package-specific Git tag and subdirectory.
```bash
-pnpm add @ourfuturehealth/react-components@github:ourfuturehealth/design-system-toolkit#react-v0.0.1:packages/react-components
+pnpm add @ourfuturehealth/react-components@github:ourfuturehealth/design-system-toolkit#react-v0.5.0:packages/react-components
```
or
```bash
-npm install @ourfuturehealth/react-components@github:ourfuturehealth/design-system-toolkit#react-v0.0.1:packages/react-components
+npm install @ourfuturehealth/react-components@github:ourfuturehealth/design-system-toolkit#react-v0.5.0:packages/react-components
```
## Usage
```tsx
-import { Button, ErrorSummary, Tag, TextInput } from '@ourfuturehealth/react-components';
+import {
+ Button,
+ Card,
+ CardCallout,
+ CardDoDont,
+ ErrorSummary,
+ Tag,
+ TextInput,
+} from '@ourfuturehealth/react-components';
import '@ourfuturehealth/react-components/styles/participant';
function App() {
@@ -36,6 +44,9 @@ function App() {
/>
Beta
+
+
+
);
@@ -92,6 +103,45 @@ An error summary component for page-level validation messages.
- `attributes`: object
- `idPrefix`: string
+### Card
+
+A content-presentation card for summary, status, and next-step content.
+
+**Props:**
+
+- `variant`: 'basic' | 'clickable'
+- `heading`, `headingHtml`, `headingLevel`
+- `description`, `descriptionHtml`
+- `icon`, `dismissButton`, `number`, `tag`
+- `metadataItems`, `helperText`, `helperHtml`, `actionLink`
+- `imgURL`, `imgALT`
+
+`tag` uses the React `Tag` component API, so nested tag content is passed with `children` plus optional Tag props such as `variant` and `className`.
+
+### CardCallout
+
+A feedback-style card for contextual info, warning, success, and error content.
+
+**Props:**
+
+- `variant`: 'info' | 'warning' | 'success' | 'error'
+- `heading`, `headingHtml`, `headingLevel`
+- `text` or `html`
+
+### CardDoDont
+
+A card for short do and don’t recommendation lists.
+
+**Props:**
+
+- `type`: 'do' | 'dont'
+- `heading`, `headingLevel`
+- `items`
+
+### Icons
+
+React components bundle the toolkit icon sprite automatically. Consumers do not need to copy `/assets/icons/icon-sprite.svg` into their own app to render Card icons.
+
### Tag
A status tag component with a simple React API that maps to the toolkit variants.
diff --git a/packages/react-components/package.json b/packages/react-components/package.json
index 71347589..7b783249 100644
--- a/packages/react-components/package.json
+++ b/packages/react-components/package.json
@@ -1,6 +1,6 @@
{
"name": "@ourfuturehealth/react-components",
- "version": "0.4.0",
+ "version": "0.5.0",
"type": "module",
"description": "React component library for OFH Design System",
"packageManager": "pnpm@10.29.2",
diff --git a/packages/react-components/src/components/Button/Button.stories.tsx b/packages/react-components/src/components/Button/Button.stories.tsx
index 084d67d8..64dfd58a 100644
--- a/packages/react-components/src/components/Button/Button.stories.tsx
+++ b/packages/react-components/src/components/Button/Button.stories.tsx
@@ -9,7 +9,7 @@ const meta: Meta = {
docs: {
description: {
component:
- 'A flexible button component based on the OFH Design System with multiple variants and states. Can render as a button or anchor element.',
+ 'A flexible button component based on the OFH Design System with multiple variants and states. If `href` is provided, the component renders as an anchor instead of a button. The `variant` changes the visual prominence only, not the semantic element.',
},
},
},
@@ -25,22 +25,52 @@ const meta: Meta = {
'text',
'text-inverted',
],
- description: 'Visual style variant of the button',
+ description:
+ 'Changes the visual style and prominence of the button. It does not change whether the component renders as a button or link.',
},
children: {
control: 'text',
- description: 'Button content/text',
+ description: 'Visible label content for the button or link.',
},
href: {
control: 'text',
- description: 'URL to navigate to (renders as anchor tag)',
+ description:
+ 'Navigation destination. When this is set, the component renders as an anchor (``) instead of a button.',
+ },
+ type: {
+ control: 'select',
+ options: ['button', 'submit', 'reset'],
+ description:
+ 'Button type for real `