Responsive Gate Size Not Platform Agent Skill

Gate on the window's shape, not on the platform

A screen that has two headers picks between them from one line, and that line reads the window:

val screenInfo = getScreenSizeInfo()
val isPortrait = screenInfo.wDP < screenInfo.hDP

"Portrait" here means *this window is taller than it is wide* — nothing about the device. The size

accessor is per-platform (window metrics on mobile, container size on desktop) but it reports the

window, so split-screen, a half-width desktop window and a rotated phone all move the same value

and a recomposition follows each. A platform check answers none of those.

Everything that is not a choice *between* the two layouts stays outside the branch: the palette-derived

page background and the blur source are applied to the list itself, unconditionally. Inside the branch

is the header — and, where the wide header carries its own play/shuffle cluster, where that sits.

Traps

One boolean answering two questions. The gate here started life as `platform == Mobile &&

wDP < hDP` and controlled both "use the immersive treatment" and "which header". Someone forcing it

to true to see the wide header on desktop got the wide header *on mobile portrait too*, and the

other orientation lost its layout entirely — the same flag still answered the treatment question. The

split is the fix: the treatment applies to both orientations unconditionally, and the gate owns

exactly one decision. Before adding a condition to an adaptive flag, name every question it answers.

platform && shape is the same bug wearing a shape gate. Another screen still carries it. Its

comment opens on the device — *two columns only on a phone held upright* — then gives the real reason

in width terms: anywhere wider, two columns stretch each tile to half the window and the fixed 2:1

tile ratio makes it absurdly tall.

val isMobilePortrait = getPlatform() == Platform.Android && screenInfo.wDP < screenInfo.hDP
val moodGridColumns = if (isMobilePortrait) 2 else 4

Only the first sentence names a device, and it is the half doing no work. The code still fails the

platform half on a narrow desktop window and hands it the four-column layout the comment was written

to avoid. If the *justification* never needs the platform, the condition must not.

The gate owns more than the branch you are looking at. When the frame changes shape, the scaling

and the scrim have to change with it or the result is worse than the un-adapted layout:

// adapted: three sites in one screen, pulled together
Box(
    Modifier.fillMaxWidth().then(
        if (isPortrait) Modifier.aspectRatio(1f) else Modifier.height((screenInfo.hDP / 2).dp),
    ),
) {
    AsyncImage(contentScale = if (isPortrait) ContentScale.FillWidth else ContentScale.Crop, /* … */)
    Box(
        Modifier.fillMaxWidth().align(Alignment.BottomCenter)
            .height(if (isPortrait) (screenInfo.wDP * 0.7f).dp else (screenInfo.hDP * 0.35f).dp)
            .background(scrimBrush(pageBackground)),
    )
}

Each pair has its own reason. aspectRatio(1f) on a wide window makes a frame as tall as the window

is wide, so the artwork (or a video in it) swallows the page — hence a fraction of the viewport

height. FillWidth fits a square source into a square frame, but scales that same source to a *wide*

frame's width and shows only the band the frame is tall enough to hold: the middle band, since

Alignment.Center is the default, so head and feet are lost (the in-repo comment says *top* slice —

wrong band, right idea). Hence Crop when wide. The two scrim figures are one rule twice: 70% of the

frame's own height, which is 70% of the width while square and 35% of the viewport height once not.

Measure the wide branch off the width and the scrim outgrows the artwork it fades.

Inside the wide branch, measure the remainder — not the column. A later screen here was designed

to split its landscape body by each block's *natural* width: a fixed ~600dp column for blocks that

stop improving past it, the rest for blocks that keep using width. Sound reasoning, and the recorded

design did not survive contact with real window widths — a fixed column is really a claim about every

*other* width. The in-code note records the outcome: right at 1400dp, and at 986dp the remainder came

out 202dp, narrow enough to wrap a legend one letter per line. What shipped is two sibling Columns

at Modifier.weight(1f) in one Row. Two decisions lived in that block and only one was wrong:

*what goes in which column* — grouped by kind rather than by height, so related blocks stay together

near the top — was right and is unchanged; *how wide each is* needed measuring, and the figure to

measure is the narrowest supported window's leftover, never the widest window's column.

Two gates that disagree about a square window. wDP < hDP is strictly-taller; a collapsing-header

component here uses hDP >= wDP, taller-or-square. A square window takes different branches in

the two, and square windows are reachable on desktop by dragging. Pick one comparison, use it

everywhere.

Chrome that floated on the artwork has nowhere to float. In the edge-to-edge branch back, like,

search and overflow are overlays on a full-bleed image. The wide branch has a fixed artwork block on

page background, so those become a real top row and the action cluster moves beside it — which is why

the branch keeping it underneath is gated too. Move that code verbatim; each has its own view model.

Platform checks that legitimately survive are never about layout. Two remain in these screens,

both asking a capability question no window measurement can answer: whether the renderer supports a

particular blur path (a progressive-blur effect whose signature does not resolve against the pinned

desktop drawing backend), and whether the pointer is a mouse or a finger (click-and-drag reorder

versus long-press-then-drag). Layout is not on that list.

Five screens carrying the same gate by hand, and counting. The declaration is duplicated per

screen — a rule change has to land in each, and step 1 is how you find them. Same shape as

guard-on-every-trigger-path: a condition present in some of its homes and not others errors

nowhere.

Verifying it

# 1. Every shape gate in the codebase, in one shot. Read the operator and the operands of each hit:
#    a `>=` next to a `<` disagrees about square windows, and an `&&` next to a platform call is
#    the contaminated gate.
grep -rn --include="*.kt" -E "\.(wDP|width) *< *[A-Za-z]+\.(hDP|height)|\.(hDP|height) *>= *[A-Za-z]+\.(wDP|width)" . | grep -v "/build/"

# 2. Every platform check left in UI code, comments excluded — 22 hits here; unscoped it returns 27,
#    the extra five being app-shell branches and a view model picking a default. Each must answer a
#    capability question (does this renderer, input device or system integration exist), never a
#    layout one. Exactly one is expected to fail that test: the contaminated gate from step 1.
find . -path "*/ui/*" -name "*.kt" -not -path "*/build/*" -exec grep -Hn -E "getPlatform\(\) *[!=]=" {} + \
  | grep -vE ":[0-9]+: *//"

# 3. Everything one screen's gate owns. Read all of the hits together: they must flip as a set.
find . -path "*/ui/screen/*" -name "*.kt" -not -path "*/build/*" -exec grep -Hn "isPortrait" {} +

# 4. Sizing inside the branches a shape gate owns — 27 hits, 9 of them fixed widths. Each fixed dp
#    is a claim about the leftover at EVERY other window size: read what shares its Row, then
#    compute the remainder at the narrowest window you support.
grep -rl --include="*.kt" "isPortrait" . | grep -v "/build/" \
  | xargs grep -n -E "\.width\([0-9]+\.dp\)|Modifier\.weight\("

Then resize rather than rotate, continuously: drag a desktop window wide-to-narrow and back,

watching the leftover column rather than the one you sized. The header must swap mid-drag, and each

branch must hold its own size rule. Portrait, the artwork is a square measured off the *width*,

so on any window less than twice as tall as it is wide — a 16:9 phone, a portrait tablet, most

split-screen halves — it legitimately covers more than half the viewport. Wide, it is exactly half

the viewport *height*. Only the scrim rule is shared: 70% of a frame that is wDP tall, 35% of a

viewport whose half *is* the frame — so a single "never past half the viewport" check fails the

portrait branch on correct code and sends you to the wrong side. Finish in split-screen at half

height: a landscape-shaped window on a portrait device, the case a platform check always gets wrong.