- Job
- Commit an action
- Requirement
- must specify
- States / rules
- default / hover / focus / pressed / disabled; destructive variant if used
- Specified means
- Variants + verbs locked
- Hardest context
- Disabled with no why
“Publish”
“Click here”; FAB
Baseline vs product decision
Building Blocks baseline supplies
- The source job and required source states.
- Reusable anatomy and accessible interaction expectations.
- Responsive and theme behavior to exercise before code is considered complete.
- A stable place for executable Storybook states once implementation exists.
The consuming product still decides
- Whether a defer/conditional job is active for this product.
- Product copy, priority, information architecture, data policy, and placement.
- Theme values and any justified product exception.
- Whether this product is Specified, Designed, In code, or Missing in its Catalog.
Anatomy
This is documentation anatomy, not a public API shape.
Carries the action target and visual priority.
Uses a clear verb; the source row locks verbs as part of specification.
Supports the label; it does not replace an accessible name.
A separate visible state governed by the Foundation focus-ring contract.
Preview
Preview — not a published component API.
Usage
Job: Commit an action.
Variants + verbs locked
When not to use
Do not use a Button for navigation to another location; use a link. Do not give every action primary emphasis.
Variants
The checklist row does not authorize this page to invent a final component API. Where the source rule names a variant, preserve it; otherwise keep the implemented variant set minimal and job-driven.
States & behavior
default / hover / focus / pressed / disabled; destructive variant if used
Default, Hover, Focus, Active/Pressed, and Disabled apply to interactive controls. Error, Loading, Empty, and Success apply where the component takes or reports data.
Hardest-context test
Building Blocks baseline recommendation: When disabling blocks progress, pair the state with nearby product copy that explains what has to change. The exact message belongs to the product voice/content system.
Accessibility
- Use native semantics whenever they match the job.
- Keep keyboard focus visible and distinct from hover.
- Do not rely on color alone for state.
- Maintain touch-operable targets and no hover-only actions.
- For composite/overlay controls, document focus movement, Escape, and return focus as applicable.
Responsive behavior
Preserve the action hierarchy; full-width at sm is a product decision, not a universal rule.
Theme comparison
The component job and interaction contract stay stable while product expression changes.
Tokens
Bind the implementation to semantic roles for surface, text, border, focus, spacing, shape, and motion as needed. Actual token names must come from the implemented Foundation; this demo deliberately does not mint package-level token names.
Code / Storybook
When this component exists in code, this section should link to its source and Storybook stories for executable states, Controls, viewport, accessibility checks, and interaction tests. The documentation page remains responsible for job, guidance, source contract, product decisions, themes, and Catalog lineage.