# 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 `DragArbiter` per 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-app` crate**: a winit window
  holding `transcript-ui`'s screen beside a session list, talking to a real
  `ai-server` through `client-core`. It enrols by pasting the same
  `aiapp://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, the
  `IrisView`/`MainActivity` Java, and the JNI registration; the only
  thing a second screen needs on top is a different `AndroidAppState`,
  the same axis `tabs_ui::build`/`transcript_ui::build` already vary
  along on the winit side. `tabs-screen`/`transcript-screen` are
  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 because
  `dumpsys gfxinfo` cannot see a `SurfaceView`'s GPU-drawn frames at all,
  so the `transcript-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.