Clean, well-diagnosed fix. Replacing the hand-computed max-height: calc(cap - 0.5rem) with a flex column that distributes the capped height is the right structural move, and the min-height: 0 on the flex children is correctly load-bearing rather than incidental. The PR description is a model: it names the symptom, the root cause, and why flex is the fix. Five reviewers independently traced the flex chain against the real cmdk DOM and confirmed the mechanism holds.

Round 1, panel of 12. Findings: 1 P2, 1 P3, 1 Nit, plus notes.

The P2 is coverage. The mobile model-picker layout this PR rewrites has no regression test, even though MobileLongListScrolls in ChatMessageInput.stories.tsx already tests this exact class of bug for the skills menu in real Playwright chromium (it sets the above-composer geometry vars, mocks a coarse pointer, and asserts only [cmdk-list] scrolls). That story covers the shared class and passes at HEAD, so the skills menu is safe, but it has no pinned effort row, so the model picker's distinguishing scenario, the one that broke, stays uncovered. A future CSS tweak can silently reintroduce the clip with every check green.

The P3 is scope drift. Removing overflow-hidden from the ModelSelector className is unnecessary for the mobile fix (the mobile rule already forces overflow: hidden !important) and flips the desktop path's overflow-x from hidden to visible. Reviewers traced desktop and found no likely user-visible regression (Command clips its own content, list items truncate), so it is low-consequence, but it is an undisclosed change to an untested path.

Process: the commit subject fix(site): lay out mobile model picker with flexbox so pinned effort row and last model stay visible is 100 characters and leaks the mechanism ("with flexbox"); git and GitHub truncate it in --oneline, blame, and the PR list. Your own PR title, fix(site): keep mobile model picker effort row and last model visible (69 chars), is the better subject and keeps the mechanism for the body.

Out of scope, informational: several no-action notes are recorded in the inventory: the pathological short-viewport tradeoff (list flex-shrinks first, pinned row stays; intended and strictly better than before) and the fix's reliance on cmdk's DOM structure (already a codebase-wide coupling).

As Hisoka put it: "Pulled one thread on this diff and something moved two packages over." The fix is good; it just swung a touch wider than the description admits.

site/src/index.css:80

P2 [CRF-3] The mobile model-picker layout fix ships with zero regression coverage, even though the repo already has the harness to test it. (Bisky P2, Nami Note, Mafu-san Note)

None of the ModelSelector stories set enableMobileFullWidthDropdown, so none render the .mobile-full-width-dropdown-above-composer layout this PR rewrites. [...] ChatMessageInput.stories.tsx:601 MobileLongListScrolls already tests this class of bug for the skills menu [...] but never touches the model picker's distinguishing feature.

Verified: MobileLongListScrolls runs in real Playwright chromium, sets --mobile-dropdown-above-composer-* via setMobileDropdownGeometry, mocks a coarse pointer, and asserts the wrapper stays bounded and exactly [cmdk-list] scrolls. It covers the shared class (and passes at HEAD, so SkillsTriggerMenu is safe), but the skills menu has no pinned effort row, so the model picker's scenario, the one this PR fixes, is uncovered. Nami and Mafu-san rated this a Note on the premise that a media-query layout effect cannot be asserted; the existing chromium story refutes that premise, so the higher severity stands. Mirror MobileLongListScrolls for ModelSelector with enableMobileFullWidthDropdown, a reasoning model, and a set effort so the pinned row renders, then assert the effort row and last model stay inside the capped container. It should fail against base and pass against HEAD.

🤖

site/src/index.css:237

Note [CRF-2] Pre-existing en-dash (U+2013) in a CSS comment, outside this PR's diff. (Netero)

/* shadcn-compatible aliases – see :root block for details. */ contains U+2013. This line is not touched by the PR [...] Flagging only so the human knows make lint/emdash may already trip on it independently of this change.

Not introduced by this PR and no action required here; noting it because the repo bans en-dashes and a future edit near this line will trip the linter.

🤖

🤖 This review was automatically generated with Coder Agents.

Round 2. Solid turnaround on the round-1 feedback. Verified fixed: CRF-1 (the overflow-hidden removal was cleanly reverted, the file no longer differs from base), CRF-4 (commit subject is now 69 chars and intent-only), and CRF-6 (the min-height: 0 rule carries a behavior-describing comment). CRF-5 (shared-class coupling) was contested; the panel evaluated your defense against the current code and closed it accepting the reasoning, since MobileLongListScrolls already covers the skills-menu path and the shared layout is intended.

Findings this round: 1 P2 (re-raise), 1 Note, 1 Nit.

The P2 is the CRF-3 fix. The production CSS is correct and everyone confirmed it, but the MobileEffortRow story added to guard it never opens the dropdown: ModelSelector defaults its Popover closed and Radix only mounts PopoverContent (which holds the effort row, [cmdk-root], and [cmdk-list]) when open, and the story has no play function. So the chromatic snapshot at 320px captures a closed trigger button, and even if it opened, it sets no --mobile-dropdown-above-composer-* geometry and the four-model list is too short to overflow the fallback cap. Nine reviewers reached this independently. The coverage gap CRF-3 named is unchanged, but now recorded as covered, which is worse than a known gap. The fix is to mirror MobileLongListScrolls: mock the coarse-pointer media query, pin a tight cap via setMobileDropdownGeometry, open the picker, and assert the slider stays in bounds while only [cmdk-list] scrolls.

As Hisoka opened: "I came back for the fight the panel logged as won. It wasn't." Close the loop on the one real guard and this is done.

🤖 This review was automatically generated with Coder Agents.

Round 3. The production CSS fix remains correct (the panel confirmed it again, and a reviewer reproduced the exact clip, slider at 480 vs a 424 cap, once the test ran in a real mobile viewport), and the two comment findings are genuinely closed: CRF-7 (the min-height: 0 comment now explains both flex children) and CRF-8 (the story comment now states the invariant). Requesting changes on one finding.

The CRF-3 guard is still hollow, now for the third round. The rewrite is a real interaction test that opens the picker and asserts, which is progress over the R2 version that never opened it, but it runs at ~1200px in the Storybook Vitest runner, so the @media (max-width: 767px) rules that are the entire fix never apply. Six reviewers independently instrumented the play function and ran the litmus test the R2 panel spelled out: with the current story, reverting the flex CSS to base leaves the test green. It cannot tell the fix from the bug. The cause is that chromatic: { viewports: [390] } only sizes Chromatic snapshots; the interaction runner needs parameters.viewport.defaultViewport, and without it the Storybook Vitest addon defaults to 1200x900. The one-line fix (viewport: { defaultViewport: "mobile1" }) makes the test fail on a revert and pass with the fix, verified by multiple reviewers.

On severity: nine reviewers rated this P2 (its standing since R1) and one rated it P1, because this is the third consecutive round the finding has been marked fixed while ineffective and the R2 correction named an explicit revert-and-fail check that was not run before this was submitted. Reviewer disagreement resolves to the higher severity, so this is P1 and the review requests changes. The acceptance bar is mechanical: add the viewport parameter, revert the index.css flex rules, confirm the test goes red, then restore and confirm green. Two smaller items ride along (a magic-number cap and a weak assertion target) that are worth folding in while the test is being made real.

As Hisoka put it this round: "I came to fight the guard. It never raised its hands." The fix is right; it just needs a test that can actually fail when the fix is gone.

🤖 This review was automatically generated with Coder Agents.

Round 4. Real progress on the activator: viewport: { defaultViewport: "mobile1" } is exactly the fix the panel named, the runner is now at 320px during play, and the production CSS remains correct. CRF-9's magic-number comment is in. But the round has to request changes again, and the reason is a genuinely new discovery, not a repeat of the same note.

The CRF-3 guard is hollow for the fourth round, and this time it is because two changes in one commit cancel each other: adding the viewport pin (which the panel asked for) and removing the play-function DOM assertions (the CRF-10 pushback). About nine reviewers independently ran the standing litmus test on the committed code, and the story passes with the entire flex fix reverted. There is nothing left in the play function that the layout can break.

While verifying that, the panel established something the previous three rounds missed, and it is worth stating plainly because it partly corrects our own earlier guidance: neither CI gate actually protects this layout. The storybook interaction project is not run in CI (test:ci is unit-only; make test-storybook is never invoked by a workflow), so even a perfect assertion here would not gate CI as-is. And the CI visual gate is lost-pixel, not Chromatic, so the chromatic: { viewports: [390] } the author's CRF-10 defense relies on is dead config, and lost-pixel renders this story at desktop width where the mobile CSS is inert. So relying on "the snapshot" does not work here, and the assertion-only path we pushed for three rounds does not gate CI either. The effective fix is to add a real lost-pixel mobile breakpoint (so the visual job renders the mobile layout) and/or restore a retargeted relational assertion plus wire the storybook project into CI. Details and the exact acceptance bar are in the thread.

CRF-10 (contested) is not accepted: the defense misidentifies the repo's visual tooling, and deleting the assertion overcorrected a valid targeting complaint (measure the .mobile-full-width-dropdown-above-composer element, not the popper wrapper) into a coverage loss. New: CRF-11 (the dead chromatic config), and a commit-message note (CRF-12): the subject "pin mobile viewport" names the smaller change and hides the assertion removal, with no body carrying the rationale that lives only in a review thread.

As Hisoka put it: "The fix is correct; the guard around it is a paper wall painted to look like stone." The production change has been right since round 2. What is left is a guard that runs where the bug lives.

🤖 This review was automatically generated with Coder Agents.