- Job
- What changes at sm/md/lg
- Requirement
- must specify
- States / rules
- Project declares mobile-first vs responsive vs adaptive; per component: reflow, collapse, or hide — never “it’ll scale”
- Specified means
- Per-component behavior written
- Hardest context
- Overlay + shell at 375
List stacks; editor density drops
Desktop screenshot only
How this lives in Building Blocks
Representation: Shared guidance + product-local policy.
Building Blocks should provide shared guidance, semantic roles, examples, and reusable implementation hooks where appropriate. Each product maps those roles to its own theme and documents any justified exceptions.
Write what changes, not “responsive.”
Content keeps meaning while order/layout changes.
Chrome condenses into an explicit alternative such as a drawer or disclosure.
Only secondary information may disappear, and the product must justify it.
Touch targets and reading order survive a tighter layout.
State, focus, and navigation origin survive transitions between contexts.
- Overlay + shell at 375
- Long content at 200% zoom
- Keyboard navigation after a rail becomes an overlay
Do not specify the easy case only.
The source checklist’s hardest-context test is part of what “specified” means: Overlay + shell at 375.
On-spec signal
List stacks; editor density drops
Failure signal
Desktop screenshot only
Catalog connection
The product-local Catalog should show this row’s actual state for that product using the Catalog contract. Building Blocks documentation can define the baseline, but it does not make a product’s row Specified, Designed, or In code by itself.