fix(templates): stop the panel grid overflowing below 336px - #31
Merged
Conversation
metrics-dashboard scrolls sideways at narrow widths: 16px of horizontal overflow at 320, 8px at 328, clear by 336. Reproduced on the live frame and locally at 16 widths, 320-335. An auto-fit minmax floor wider than the content box cannot shrink, so the grid item overflows the page rather than the track collapsing. .panels used minmax(20rem,1fr) = 320px inside a 288px content box. min(20rem,100%) lets it shrink to fit. Guarded every auto-fit floor >= 14rem across the seven research and status templates, not only the one that fails today. Only metrics-dashboard is live; the other five are latent -- their floors are narrower than the box at present, so they depend on padding and content not changing. Measured at every width 320-420: metrics-dashboard overflows on main, none of the other six do. Height-neutral for six of seven, verified by sweeping 320-1920 before and after: identical peaks. metrics-dashboard moves 2573 -> 2601 at 320, because content that was spilling sideways now wraps inside the viewport -- that 28px is the honest height of the panel, and it was previously hidden by the defect it is being measured against. This carries no height work. It is separated from the halted 2,900 threshold question deliberately: horizontal overflow is a defect at any threshold, and the one-line fix for it should not wait on a number nobody is currently prepared to defend. Co-Authored-By: CRHQ <noreply@crhq.ai>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The defect
metrics-dashboardscrolls sideways at narrow widths. Reproduced locally and matching the production measurement exactly:An
auto-fitminmaxfloor wider than the content box cannot shrink, so the grid item overflows the page rather than the track collapsing..panelsusedminmax(20rem,1fr)— 320px inside a 288px content box.Scope: one live, five preventive
Guarded every
auto-fitfloor ≥14rem across the seven research and status templates. Swept all seven frommainat every width 320–420:mainmetrics-dashboardSo only one is live. The other five floors are narrower than the box at present and depend on padding and content not changing — they are guarded because it is the same defect and the fix is one line each, not because they fail today.
Height-neutral, verified rather than assumed
Swept 320–1920 before and after:
The one change is real and expected: content that was spilling sideways now wraps inside the viewport, so 28px of genuine panel height appears. It was previously hidden by the defect it is being measured against. I would rather report that than claim height-neutrality that is true of six sevenths.
Deliberately carries no height work
Horizontal overflow is a defect at any threshold — nobody chooses to scroll sideways. This is split out of #30 so the one-line fix does not wait on the 2,900 re-derivation. #30 is parked, not abandoned.
Verified with builder-1's
width-sweep.cjs, which assertsinnerWidthbefore every recorded value and refuses rather than records, and reports overflow as a first-class failure — which is the only reason this was findable at all, sincemetrics-dashboardpasses every height check comfortably.🤖 Generated with Claude Code