Specify what a layout actually does between breakpoints, not just at three fixed screen widths

LAYOUT / COMPONENT
A two-column article page: main content column plus a sticky related-articles sidebar.

DESIGNED BREAKPOINTS AND WIDTHS
Mobile (< 480px, single column, sidebar moves below content); tablet (480-1024px, single column, sidebar as horizontal strip); desktop (> 1024px, two-column with sticky sidebar).

CONTENT THAT VARIES IN LENGTH
Article headline can be one line or wrap to three; sidebar can show 2 to 15 related articles depending on the piece.

MINIMUM AND MAXIMUM SUPPORTED WIDTH
Minimum 320px (smallest supported phone), maximum unconstrained on desktop, but design intent assumes a max reading-column width regardless of monitor size.

For each named breakpoint in DESIGNED_BREAKPOINTS, specify: column count/grid structure, what elements reflow, stack, or hide, and the exact spacing/type-scale token used at that width. Then, critically, specify what happens in the width ranges BETWEEN the named breakpoints — real viewports land on every width, not just the three or four exact pixel values usually shown in a design file, and a spec that only covers the named breakpoints leaves the actual majority of real-world widths (everything in between) implicitly undefined. State whether the layout should hold its current breakpoint's structure until the next one triggers (a step function) or should scale/reflow continuously between breakpoints, and be explicit about which elements do which — some things (a fixed-width sidebar) plausibly hold steady while others (a text column) plausibly reflow continuously, and treating the whole layout as one uniform behavior is usually wrong.

For VARIABLE_CONTENT specifically, specify what happens when content is unusually long or short at each breakpoint, since breakpoint specs are almost always built and tested against one representative piece of sample content and silently assume every other case behaves the same way. At WIDTH_RANGE's absolute minimum and maximum, state explicitly what's guaranteed to still work — do not let the spec imply infinite scalability in either direction; every layout has a width below which it breaks and a width above which the design intent stops making sense (e.g., a reading-width text column that shouldn't stretch edge-to-edge on an ultrawide monitor even though nothing technically prevents it).

WHAT NOT TO DO
Do not describe responsive behavior only at the named breakpoints and leave the transitions between them to be "handled by the framework" — that phrase is where most real responsive bugs live, since flexbox/grid defaults rarely match actual design intent without explicit rules. Do not treat all breakpoints as equally important if MINIMUM_AND_MAXIMUM_SUPPORTED_WIDTH or real traffic data suggests one range gets far more real-world use than another.

OUTPUT FORMAT
1. Table per named breakpoint: width | grid/column structure | elements that change | tokens used.
2. Between-breakpoint behavior: step function vs. continuous, stated per element type.
3. Variable-content behavior at each breakpoint (truncation, wrapping, or scroll — named explicitly, not left implicit).
4. Minimum and maximum width guarantees, and what's explicitly out of scope beyond them.