Automation layer is duplicated per platform: one testableClickable and one Ktor server in commonMain instead of three actuals

[emooreatx]

The pattern

Three defects, three platforms, one shape — each fixed (or not) separately:

	desktop	Android	iOS
Modifier.testableClickable / testableWithHandler	fixed with rememberUpdatedState	stale closure (#32)	no click-handler registration at all (hasClickHandler returns false)
test-automation HTTP server	Ktor CIO	a second Ktor CIO copy	hand-rolled POSIX socket/bind/listen/accept
TestAutomationHandler (11 routes, JSON), TestAutomationState (registry)	commonMain	← shared	← shared

testableClickable is expect in commonMain with three actuals. It is pure Compose over TestAutomationState, which is already common — there is nothing platform-specific in it. The desktop actual got the rememberUpdatedState fix; Android's didn't, so #32 exists; iOS's registers nothing.

The server is the same story one layer down. Desktop and Android are both Ktor CIO — two copies of the same code. iOS is its own HTTP implementation, and every iOS-only automation bug so far lives there: the starved accept loop (#28), and now responses the driver cannot parse (Invalid control character at: line 1 column 77, run 33777943107 — the first run in which the iOS server ever answered /health in CI). Ktor CIO runs on Kotlin/Native.

The ask

Don't fix #32 on Android. Delete the three actuals and put one testableClickable/testableWithHandler in commonMain, with the rememberUpdatedState indirection desktop already has. Android and iOS get the fix by not having their own copy.

Then the same for the server: one Ktor CIO TestAutomationServer in commonMain, delete the Android duplicate and the iOS POSIX server. The framing/JSON class disappears structurally rather than by finding each instance.

Why now

Adopting 0.5.199 through CIRISAgent's five-platform gate found #30 (desktop), #32 (Android), and the iOS server issues in sequence — each a platform-specific copy of behaviour the other platforms already had right. A gate can only find these one platform and one release at a time. A single implementation means the next fix is the last one.

Refs #28, #30, #31, #32.

[emooreatx]

Evidence from run 33780331440 — the first run where the iOS server answered in CI and the driver parsed leniently enough to quote what it got back.

Every POST fails; every GET works. The response body for POST /click and POST /wait is not JSON but a kotlinx error message:

Expected start of the object '{', but had 'EOF' instead at path: $

EOF at path $ means the server decoded an empty request body. TestAutomationServer.ios.kt does a single recv() and parses whatever arrived; the client (httpx → httpcore) writes headers and body as two separate write()s, so the body lands in a second TCP segment the server never reads. The handler then returns the exception text as the response, which is why the driver reported "Invalid control character" — it was parsing an error string.

This is not a serialization bug and not something to patch in the POSIX server; it is the reason the POSIX server should not exist. Ktor CIO reads the body to Content-Length on every platform it runs on, including Kotlin/Native. One server in commonMain (this issue) fixes it by construction; #28's starved accept loop was the same class one layer down.

We'll drive iOS through a one-segment transport in the gate meanwhile, labelled as a workaround for this issue, so the wizard is at least exercised on iOS until the consolidation lands.

[emooreatx]

One more copy-specific defect, with a tree dump as evidence — and it's the iOS actual again.

TestAutomation.ios.kt's Modifier.testableClickable calls TestAutomation.registerElement(...) from onGloballyPositioned and never unregisters: no DisposableEffect, no onDispose. The desktop and Android copies have both. Consequence: the iOS registry accumulates every element ever composed. /tree at the YOU step of the setup wizard, on the simulator (run 33784560419):

elements=31  login_language_selector btn_apple_signin btn_local_login btn_privacy_policy …
             step_indicator_you age_band_minor age_band_adult age_band_declined input_username input_password …
             toggle_announce_ownership toggle_trace_opt_in btn_federation_identity

That is the login chooser, the YOU step and the Join Federation step reported as simultaneously on screen. Any harness asserting on the absence of an element — "the wizard advanced" — can never pass on iOS; ours waited its full budget while the next step's toggle had been findable for 30 seconds.

Same fix as everything else in this issue: one testableClickable in commonMain, with the DisposableEffect unregister the other two copies already have. On our side we've switched the advance check to a positive signal (the next step's control appearing), which is a better assertion regardless — but /tree reporting three screens at once will mislead every other consumer until the copy is gone.

[emooreatx]

The symptom this issue predicted is gone in 0.5.200.

The concrete evidence was iOS's /tree reporting 31 elements across three screens at once, because testableClickable registered elements and never unregistered them. With 0.5.200 the iOS setup wizard runs 6/6 (run 33825230656) — including the step that had failed because the gate could not tell "the wizard advanced" from "the registry still lists the previous screen". Both Android and iOS now carry DisposableEffect + unregisterElement and rememberUpdatedState, matching desktop.

Leaving this open, because it asks for something behaviour cannot demonstrate: one testableClickable and one Ktor server in commonMain rather than three actuals and two server implementations. Three of the four defects the gate found this cycle (#30, #32, #35) were each a per-platform copy missing a fix another copy already had, and #30 is still open on exactly that pattern — the iOS login panel registering elements without sinks, on a surface where Android is fine.

Your call whether to keep it open as the structural ask or close it as superseded by the per-platform fixes.

[emooreatx]

Half done — the modifiers are one implementation as of 86208cd. 460 lines of per-platform duplication deleted, 105 written.

Your diagnosis was exactly right, including the part I'd rather not gloss over: #30 was this pattern catching me while I was fixing #32. I added rememberUpdatedState to iOS's two clickable variants and left the plain testable() alone — one rule, four copies, a fix landing in two of the three that needed it. Your table predicted that a week before it happened.

What moved

testable / testableClickable / testableWithHandler were expect with four actuals, and every one was pure Compose over TestAutomationState — which is already common. There was never anything platform-specific in them.

The only genuinely per-platform thing stays an expect: isEnabled(). wasmJs returns false unconditionally, so the common body no-ops there exactly as its hand-written actual did, rather than registering elements nothing can read. That's what made the collapse safe rather than a behaviour change for the browser bundle.

One deliberate behaviour change. Desktop measured with positionInWindow() + size; Android and iOS with boundsInWindow(). They agree for a fully visible element and differ for a clipped one, where boundsInWindow reports the rect actually on screen — the correct answer for a click target, since an unclipped rect can hand you a coordinate outside the window for a partially scrolled row. Two of three already did this. Desktop's /mouse-click is the only consumer and e2e-desktop exercises it on every push.

The check nearly went silent

Worth flagging because it's the same class of failure as the bug being fixed. check_ui_drivable.py's disposal check globbed the four platform actuals. Deleting them would have left it scanning nothing and passing — having checked nothing, at precisely the moment the rule it guards was being moved.

It now reads the common file, refuses a denominator of zero, and a sibling check fails the build if a per-platform Modifier.testable* ever comes back. Both mutation-verified: dropping the disposal, and re-adding an iOS actual, each fail with the file and variant named.

So "the next fix is the last one" is now enforced rather than intended.

The server half is not done

Deliberately. Desktop Ktor CIO, a second Ktor CIO copy on Android, and the hand-rolled POSIX server on iOS where every iOS-only automation bug so far has lived — #28's starved accept loop, #35's unread POST body, the unescaped control character in /health.

You're right that Ktor CIO runs on Kotlin/Native, but I want that proven on the iOS target in CI before deleting a server that currently works, rather than discovering it at the point where the iOS leg has no automation surface at all. It's the larger and more valuable half, and it isn't a change to make the same day as a release. Landing in .203.

Leaving this open for that half.

[emooreatx]

Concrete cost of this from the agent side, in case it helps prioritise: /tree reporting elements that are not drivable cost a full CI cycle tonight, and on Android rather than iOS.

Driving logout on Android (CIRISAgent#1150), the dump at the failure was:

[tree:reset:menu_logout] screen='Interact' elements=30

and that element list contains menu_logout, btn_login_reset_device, btn_governance_menu and btn_menu — while none of them was reachable. The real path was btn_nav_drawer_open first; the nav is behind a drawer on mobile, and the tags from the desktop layout were present only because they had been composed at some point. The registration has no DisposableEffect, so the registry never forgets.

The known write-up of this was iOS-specific ("assert presence of the next screen's control, never absence of the previous one"). It is not iOS-specific — the same read on Android produced a 20s timeout on an element the tree said was there, and the failure message named the wrong cause until we dumped the tree and read it properly.

Two things that would help whichever way #33 lands:

1. Drop registrations on dispose, so /tree describes the current screen rather than the union of every screen visited. The /undrivable endpoint suggests the distinction already exists somewhere; if /tree could carry it per element, a harness could tell "present" from "usable" without a second call.
2. Say what is drivable when a wait fails. We already have the element list at that moment. Printing "you asked for menu_logout; this screen exposes btn_nav_drawer_open, …" turns this class of bug into a line of output rather than a log dig. Same ask as CIRISClient#39's last section.

Not asking for a fix here specifically — recording it against #33 so the consolidation carries it.

🤖 Generated with Claude Code

[emooreatx]

The Android read is fixed on main at 22b8b14 (0.5.204), and the cause is slightly different from the write-up: the registry does unregister on dispose (since 0.5.201). Those entries never dispose. On a phone the nav rail lives inside ModalNavigationDrawer, whose drawerContent is composed always and translated off screen when closed — so menu_logout, btn_governance_menu and the rest are positioned, have live handlers, and have no pixels. /tree was reporting the truth about composition and nothing about usability.

boundsInWindow() clips to the window, so a fully off-screen element registers with zero size; that is now read as ElementInfo.visible, by one function in both the shared registry and desktop's copy. Semantics:

• /tree still lists it, and says visible: false
• /wait resolves only on usable — a positioned element must be visible; handler-only popup content keeps its allowance
• /click and /input refuse an off-screen element rather than fire a handler for a control no one can see
• every refusal names what is usable, which was your ask 2 and Specify the shape of a UI-flow spec: tags are guaranteed, composition is not #39's:

menu_logout is composed but off screen (inside a closed drawer or sheet?); on screen and drivable now: [btn_nav_drawer_open, btn_send, input_message, …]

Ask 1 (per-element present-vs-usable in one call) is the visible + canClick pair on each /tree element. Desktop's own server is still its own copy — that remains the consolidation this issue is for.

[emooreatx]

The visible / refusal-lists-what-is-usable change is in v0.5.204 (tagged, publishing). Your Android logout step should now fail fast with on screen and drivable now: [btn_nav_drawer_open, …] instead of a 20s wait — or pass, if the driver opens the drawer first.

[emooreatx]

Correction: v0.5.204 / v0.5.205 never published — both failed the release gate (vendoring digest) after building, so pip resolves neither; their GitHub releases carry mobile assets only. The fix ships in v0.5.206 (24c1b07), publishing now: https://github.com/CIRISAI/CIRISClient/actions/runs/34091580591. Retarget the gate to 0.5.206.

[emooreatx]

v0.5.206 is published: all five wheels on PyPI, AAR + XCFramework + localization bundle on the GitHub release. pip install ciris-client==0.5.206.