Private Pro category · 15 compositions
Cards
Reusable product, project, content, metric, and action compositions. These records are manifest-derived and source-free; an implemented status does not imply manual verification, release readiness, entitlement protection, or availability for purchase.
Manifest items
All 15 records currently carry implemented status. A dedicated detail becomes internally discoverable only after release readiness and a reviewed public preview.
Metric reservoir
Release readiness
Activity current
Member signal
Integration status
Plan outline
Article pocket
Task handoff
File preview
Event brief
Contact route
Usage threshold
Approval checkpoint
Empty collection
Category contract
- Purpose
- Reusable product, project, content, metric, and action compositions.
- Declared dependencies
- gummy-card, gummy-badge, gummy-button
- Required review
- light, dark, responsive, keyboard-reviewed, rtl-reviewed, reduced-motion
How to evaluate Cards blocks
Card compositions are useful for comparing sibling objects such as products, projects, articles, actions, or metrics. Choose a variant whose hierarchy matches the data; do not force unrelated fields into a card merely to make a page look busier.
Map every visible value from a typed source of truth and decide whether the whole card or one explicit control is interactive. Avoid nested interactive elements, preserve heading order, constrain unpredictable media, and let descriptions wrap rather than truncating the only context a customer receives.
Exercise missing images, long names, zero and very large values, unavailable actions, keyboard focus, and stacked mobile layout. Ensure repeated links remain distinguishable, status is not conveyed by colour alone, and fictional sample data cannot be mistaken for a testimonial or business result.
Give each card type a field contract that separates required identity, optional context, live status, and actions. Document sorting and truncation rules, along with the destination or mutation behind each control. A card that cannot render truthfully with missing optional data should be redesigned before it becomes a reusable product pattern.
Boundary
Public pages contain only approved names, purposes, dependency aliases, requirements, status, and any future reviewed image preview. Editable paid source, test paths, release locations, and entitlement details remain private.