irisandClaude Fable 5.1
d17040b601
I5's transcript screen now runs on-device against a real ai-server on iris-android-app's new transcript-screen feature (extends I2's shell rather than a third one), with real scrolling, real touch-drag panning and tap-by-name accessibility all confirmed by screenshot/log evidence. I4's own emulator-side check (tap-by-name on the tabs demo) closed the same session, so its box ticks [x] now. Still [~], not [x]: the render-time number RUST.md's recommendation wants for iris couldn't be produced this pass, for a precise and recorded reason rather than a vague one -- dumpsys gfxinfo cannot see a SurfaceView's own GPU-drawn frames at all (0 frames reported across a gesture loop that visibly scrolled), and a SurfaceFlinger --latency fallback gave no per-frame history either on this Android version. The Compose side of the same loop did produce a real number under identical conditions (8.96% janky, 99th percentile 150ms), so this is now a one-sided number rather than a missing one on both sides. Also found and recorded: the AVD's saved snapshot carries a GPU config across restarts, so switching between the documented Vulkan boot recipes needs a cold boot (clearing snapshots/) that the emu wrapper does not force -- cost three different-looking crashes before the pattern was the snapshot, not the code. DECISIONS.md's DEFERRED item is updated with the numbers Iris needs to weigh the iris-vs-Masonry call; the call itself stays hers. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
3.2 KiB
3.2 KiB
Decisions taken for Iris to review
Short list of design choices made by the design agent without asking, so they can be judged and reversed later. Detail lives in RUST.md (and IRIS.md for iris API changes); this file is only the summary. Newest first. Items marked DEFERRED are ones the agent chose not to decide alone.
2026-09-05
- Touch drag on a transcript row follows Android's own rule: a vertical
drag pans the list immediately; a stationary press held 500 ms starts a
text selection which further dragging extends; a horizontal drag while
something is already selected extends that selection without the wait.
One
DragArbiterper list decides it (iris/src/sense.rs). Chosen over a "text layer always wins" or "list always wins" rule because either loses one of the two gestures a reader expects. - E4's desktop shape is a new
iris/desktop-appcrate: a winit window holdingtranscript-ui's screen beside a session list, talking to a realai-serverthroughclient-core. It enrols by pasting the sameaiapp://enroll?…link a phone scans (client-core::config::EnrolledServer) and keeps it owner-only under$XDG_CONFIG_HOME/ai-app-desktop/. The pinned CA is a path given on the command line, not baked in. Chosen so the phone and desktop share one enrolment format and no second one is invented. - I5's Android integration extends
iris-android-app(I2's shell) behind a Cargo feature (transcript-screen), rather than a third shell crate. That project already has the Gradle module, theIrisView/MainActivityJava, and the JNI registration; the only thing a second screen needs on top is a differentAndroidAppState, the same axistabs_ui::build/transcript_ui::buildalready vary along on the winit side.tabs-screen/transcript-screenare mutually exclusive and each pulls in only its own deps, so the plain tabs build (I2/I4) is untouched. - Order of remaining work, updated 2026-09-05: the two in-flight pieces and I5's Android integration are all done; next is giving iris its own frame-timing report so item 3 below can be decided by a number.
- DEFERRED — whether to commit to iris over Masonry for
ai-app. Updated 2026-09-05 with what's now known: iris's Android integration is built and confirmed working on a real device (real server, real scrolling, real touch-drag pan, tap-by-name accessibility — RUST.md's I5 box), while Masonry's own touch-scroll on Android was already found entirely absent (E2). What's still missing on both sides is a render-time number — not because iris doesn't work, but becausedumpsys gfxinfocannot see aSurfaceView's GPU-drawn frames at all, so thetranscript-bench.sh-style comparison this recommendation wanted produced a real number for Compose (8.96% janky, 99th percentile 150ms, same emulator/session) and none at all for iris. The choice in front of Iris: decide now on the structural-plus-functional case already made (iris works end-to-end where Masonry's scroll gesture doesn't exist at all on Android), or wait for iris to grow its own frame-timing instrumentation first so the comparison can be a number rather than a qualitative one. RUST.md's "Recommendation" item 3 has the full account.