Private Pro category · 11 compositions
Features
Capability explanation through comparisons, workflows, and evidence. 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 11 records currently carry implemented status. A dedicated detail becomes internally discoverable only after release readiness and a reviewed public preview.
Before and after
Capability chapters
Integration map
Collaboration loop
Security layers
Automation boundary
Responsive product tour
Role-based outcomes
Evidence ledger
Feature comparison
Category contract
- Purpose
- Capability explanation through comparisons, workflows, and evidence.
- Declared dependencies
- gummy-card, gummy-badge, gummy-typography, gummy-button, gummy-table
- Required review
- light, dark, responsive, keyboard-reviewed, rtl-reviewed, reduced-motion
How to evaluate Features blocks
Select a feature composition according to the evidence available: a workflow is best for sequence, a comparison for material differences, and an annotated example for concrete behavior. Avoid turning internal implementation details into benefits unless customers can actually experience them.
Replace placeholders with specific capabilities, prerequisites, and links to deeper documentation. Maintain a logical reading order across columns, keep screenshots current with the shipped product, and treat decorative marks separately from images that communicate state or instructions.
Ask product owners to prove each capability and qualifier in the current release. Exercise unavailable or plan-gated features, long translations, small screens, forced colours, and reduced motion. A polished section must never imply that an implemented private block is already purchasable.
Create a feature evidence sheet containing the supported plans, prerequisites, screenshots, limitations, documentation destination, and accountable product owner. Mark future or private work explicitly and keep it out of published claims. Implementation should receive content for unavailable and permission-restricted states instead of inventing a universal success example.
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.