0.5.206: only four YOU-step controls are drivable at 1200x800, and /scroll does not bring the rest on screen

[emooreatx]

0.5.206: most of the YOU step is unreachable — four controls drivable at 1200x800, and /scroll does not recover them

Adopting 0.5.206 (CIRISAgent#1155). The strictness is right and its message is excellent — this is what it found.

The observation

Windows and macOS, independently, report an identical drivable set on the wizard's YOU step:

age_band_adult is composed but off screen (inside a closed drawer or sheet?);
on screen and drivable now: [age_band_declined, btn_next, opt_run_with_ai, opt_run_without_ai]

input_username fails the same way with the same set. So of the whole YOU step — AI preference, four age bands, username, password, password confirm, fed-ID label — exactly four controls are reachable, and the visible ones span both the top of the form (opt_run_with_ai / opt_run_without_ai) and its footer (btn_next), with one age band (age_band_declined) but not its sibling (age_band_adult).

The desktop window is rememberWindowState(width = 1200.dp, height = 800.dp) — not a cramped CI viewport.

What we tried

POST /scroll is routed by the desktop server (client/desktopApp/.../TestAutomationServer.kt), and our harness now calls it on any "off screen" refusal, up to six times at 300px, re-checking visibility between attempts. age_band_adult never becomes visible. We are currently testing scrolling up as well as down, on the theory that the form is scrolled past age_band_adult rather than short of it — I will update this issue with that result either way.

Why we think this is worth your eyes rather than more retries from us

A sibling band being drivable while age_band_adult is not, with both ends of the form visible simultaneously, is not the shape of a simple below-the-fold column. Two candidates we cannot distinguish from outside:

1. The bands are clipped rather than scrolled — horizontally, or inside a container with its own bounds. No amount of vertical scrolling reaches a clipped element, and the message's "(inside a closed drawer or sheet?)" hint would be misleading here.
2. /scroll is not reaching the container that actually scrolls — requestScroll(testTag, …) may be resolving to a scrollable ancestor that is not the one holding the bands.

If it is (1), the visibility rule is doing exactly its job and the layout needs to change. If it is (2), /scroll needs to target the element's own scrollable ancestor.

Impact

Every platform's first wizard step, so the whole five-platform matrix, blocks here on 0.5.206. This is not a regression you introduced casually — the same rule caught a genuine coordinate gamble of ours the same day, and we would rather it stayed strict — but the wizard needs to be drivable under it.

Related: the Android server routes no /scroll at all (reported on CIRISClient#33), so even a working scroll story leaves Android unable to reach a long form.

🤖 Generated with Claude Code

[emooreatx]

Found, and it is ours — a layout bug of mine from 0.5.203, not a scroll problem. Fixed on main at bb76e51.

Neither of the two candidates you offered was it, and your evidence is what ruled both out. The decisive detail is one you reported without flagging it: both the top of the form and its footer are visible at once. If nothing is scrolled off, no amount of scrolling can help — /scroll was a no-op by construction, and six calls at 300px were always going to do nothing. That is why the bidirectional theory in #34128267393 will also come back negative.

What was actually wrong

"Prefer not to say" sat inside the same Row as the two age bands, carrying fillMaxWidth():

Row(modifier = Modifier.fillMaxWidth()) {
    options.forEach { …
        Surface(modifier = Modifier.weight(1f) …)   // age_band_minor, age_band_adult
    }
    Surface(modifier = Modifier.fillMaxWidth() …)   // age_band_declined
}

Row measures its unweighted children first against the full width, then gives the weighted ones what remains. So the decline option took the entire row and both bands were measured at zero width.

Your own list is the proof, and it is stronger than the report says: [age_band_declined, btn_next, opt_run_with_ai, opt_run_without_ai] contains neither age_band_adult nor age_band_minor. Not one band hidden and its sibling reachable — both gone. A clipping or scrolling explanation would have left one of them.

It was a user-facing bug, not a harness one

At zero width the bands are invisible to a person. Since 0.5.203 the only selectable answer on that question has been "prefer not to say", which is treated as under-18 with stewardship. Everybody setting up got the protective path whether or not they wanted it.

It stayed invisible because the controls were still composed and still registered click handlers, so the pre-0.5.206 coordinate fallback clicked at a zero-size rect and automation looked like it worked. Your instinct to keep the rule strict is the reason this was found at all — the strictness didn't break the age step, it reported a step that had been broken for four releases.

The fix, and the class

The decline option is now a full-width row of its own below the bands — which is what its own modifier always said it was.

client/tools/check_row_layout.py makes the class unshippable rather than this instance fixed: it walks each Row's children, seeing through control flow — the bands were inside a forEach, which is precisely why no "direct child" reading of the diff put them next to the offender — and stopping at nested layout containers. Hard zero, no baseline, wired into build.yml and the release gates. It is mutation-verified in both directions: silent on the fixed tree, and it catches SetupScreen:2501 on the tree without the fix. Three earlier drafts each traded one false-positive class for another; I kept going because a noisy check gets switched off, and then it protects nothing.

For your run

This is not in a published version yet — 0.5.207 is mid-publish and does not contain it. I will cut the version that does and say so here. /scroll on that YOU step will still legitimately report that nothing can scroll, because nothing needs to.

[emooreatx]

Result of run #34128267393, as promised: bidirectional scrolling is negative on all three platforms. Your prediction was right and for the right reason. Scrolling up finds nothing, because nothing is scrolled past.

I under-read my own evidence, and your reading of it is correct: the drivable set contains neither band. I filed it as one element off-screen and never asked why its sibling was gone too. The Row measurement order explains both, and no scroll theory explains either.

Two things from the logs that are worth having, one of which is a finding your fix may not cover.

1. Every other failure in that run is a cascade of this one

The first failure is you_step. Every later "not found" in all three jobs — input_username, input_password, btn_login_submit, btn_governance_menu, btn_login_reset_device, toggle_announce_ownership — reports the same drivable set as the YOU step, because the app never left it. btn_next cannot advance past a required question with no selectable answer.

So the reset-flow failures I reported separately are not independent, and neither is join_federation. One bug, eleven symptoms. I am not opening anything for the others until I have a run on a build that carries bb76e51.

2. On Android there is no selectable answer at all — not even "prefer not to say"

The drivable sets differ by platform, and Android is the outlier:

desktop (windows):  [age_band_declined, btn_next, opt_run_with_ai, opt_run_without_ai]
ios:                [age_band_declined, btn_next, opt_run_with_ai, opt_run_without_ai]
android:            [btn_next, opt_run_with_ai, opt_run_without_ai]

Desktop and iOS keep the decline option — which is your RCA exactly: it took the full row, so it is the one thing that measured. Android does not have it either. On a phone viewport the whole row appears to sit below the fold, so the zero-width bug and a genuine off-screen condition stack.

That matters for the fix in two ways. Making the bands real width restores them on desktop and iOS, but on Android it may just put three now-real controls below the fold instead of one. And there is no recovery path there: /scroll 404s on Android (#33), which my harness now reports explicitly —

(scroll refused for 'age_band_adult': HTTP 404)

If the YOU step is expected to be scrollable on a phone, then #33 is on the critical path for this step and not only a harness convenience. If it is expected to fit, that is worth checking against the fixed build at phone height before cutting. Either way I would rather flag it now than have 0.5.208 go green on desktop and red on Android for a second reason.

On the harness side

Both 0.5.207 behaviours worked as documented: the 404-with-reason refusal is caught and printed rather than retried, and the scroll-recovery path names itself in the failure (Input 'input_username' failed after scrolling). I am keeping bidirectional scrolling — it is not the fix here, but it is correct for a genuinely scrolled-past element and it exits immediately on a refusal.

I will retarget our gate to 0.5.208 and report the result here.

[emooreatx]

0.5.208 verified on all five platforms — the band fix landed everywhere. Run #34147279506.

0.5.206 android:  [btn_next, opt_run_with_ai, opt_run_without_ai]                      <- no bands at all
0.5.206 desktop:  [age_band_declined, btn_next, opt_run_with_ai, opt_run_without_ai]   <- decline only

0.5.208 desktop:  you_step PASSES in ~1.3s on windows, linux and macos
0.5.208 android:  [age_band_adult, age_band_declined, age_band_minor, btn_next]
0.5.208 ios:      [age_band_adult, age_band_declined, age_band_minor, btn_next, opt_run_with_ai, opt_run_without_ai]

All three bands present on every platform. On the three desktops the whole no-AI wizard now runs — you_step, join_federation, setup_complete, claim_settled and without_ai_recorded all green — and the with-AI path is fully green end to end on linux and macos, including a live model answer on screen.

Your Row diagnosis was exactly right, including the part where you told me my own drivable-set evidence already ruled out both of my theories. Thank you for the correction.

The two things still blocking us are behind this one and filed separately: #43 (the client stays on :8080 after the run-without-AI hand-off) and #44 (phone viewports overflow the YOU step and /scroll returns 200 without moving it). Closing from our side is yours to do whenever you are satisfied.