iris is the framework alone; the app is one crate in app-rust/

Iris: "the organization of the rust rewrite is a mess right now... there
shouldn't be anything related to the app inside of iris. Iris is supposed
to be the UI framework alone." And, on the crate count: "I'm confused why
the app only code needs more than one crate though."

Nine cargo workspaces become three, and the port's project code -- which
sat in five places, four of them inside the framework -- becomes one crate,
`ai-app`, in `app-rust/`:

  client-core                -> app-rust/src/client
  iris/transcript-ui         -> app-rust/src/ui
  iris/transcript-fixture    -> app-rust/src/ui/fixture.rs + tests/ + touch/
  iris/desktop-app           -> app-rust/src/desktop + src/bin_desktop.rs
  iris/android-app           -> app-rust/src/android + android-project/
  android-shell              -> app-rust/src/shell

iris/ keeps core, macro, the iris crate, tabs-ui and rig-input, and now
mentions no session, transcript, setup or server anywhere.

Only two of the old splits had a reason that survived reading. event-model
stays a crate at the repo root because server/ depends on it too, so a
crate is what makes the backend and the app agree by construction. The two
Android .so names looked like a hard constraint -- a package produces one
library artifact -- until P2 turned out to already plan merging those two
Android apps into one; both faces now come out of libai_app.so, picked
apart by features so `--no-default-features --features shell` keeps wgpu,
parley and iris out of the Compose app's APK. docs/RUST.md's "One app
crate" has the rest, including what each remaining feature is for.

DECISIONS.md and SUBAGENTS.md move into docs/ with everything else.

Verified: ./run-tests.sh and `cd iris && cargo test` green, clippy and fmt
clean in all five workspaces, `cargo ndk -t x86_64` links libai_app.so,
build-apk.sh produces an APK that installs and launches on this checkout's
emulator (Gl ... virgl, as expected), and the phone-sized headless
screenshot renders the transcript unchanged.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/CLIENT_CORE.md

@@ -1,21 +1,26 @@
-# client-core
+# `app-rust`'s `client` module
 
-`client-core/` is the app's pure logic held once instead of twice, per
-RUST.md's recommendation item 1. It is a plain Rust library crate with no UI
-framework dependency of any kind, so it can outlive whichever one the app
-ends up drawing with (Masonry, iris, or something else -- see RUST.md).
-`event-model/` is its sibling: the wire shape both this crate and `server/`
-share, extracted from `server/src/session/driver.rs` and
-`session/transcript.rs` on 2026-09-04.
+**Renamed 2026-09-08.** This was the `client-core` crate; it is now
+`app-rust/src/client/`, a module of the one app crate rather than a crate
+of its own (docs/RUST.md's "One app crate"). Nothing about what it *is*
+changed: it is still the app's pure logic held once instead of twice, per
+RUST.md's recommendation item 1, and still has **no UI framework
+dependency of any kind** -- the `iris` dependency sits behind the `screens`
+feature and nothing under `src/client` may reach it. That independence is
+what lets it outlive whichever framework the app draws with, and it is now
+an invariant of a module rather than of a manifest, so it is worth stating
+plainly: a `use iris::` under `src/client/` is a defect.
 
-Neither crate is wired into anything yet. `server/` re-exports `event-model`
-so its own behaviour is unchanged (`./run-tests.sh` covers it); `client-core`
-has no caller -- it exists for whichever experiment in RUST.md picks it up
-next (a Masonry or iris transcript screen, most likely).
+`event-model/` stayed a crate, and is the one split in the port that was
+never optional: it is the wire shape both this app and `server/` depend on,
+extracted from `server/src/session/driver.rs` and `session/transcript.rs`
+on 2026-09-04, so a crate is what makes the two agree by construction.
+
+Paths below are written as `src/client/…`, relative to `app-rust/`.
 
 ## What's here, and what Kotlin file it replaces
 
-| `client-core/src/…`                     | Kotlin original                          | Status |
+| `src/client/…`                            | Kotlin original                          | Status |
 |------------------------------------------|-------------------------------------------|--------|
 | `event-model/src/lib.rs` (shared crate)   | `Events.kt` (the enum mirror)             | Done   |
 | `ansi.rs`                                 | `Ansi.kt`                                 | Done, ported test-for-test |
@@ -118,7 +123,7 @@ has no `Unknown`/catch-all variant, unlike `Events.kt`'s hand-kept mirror.
 A server newer than this build that adds an event type will fail to parse
 that line rather than degrading to a placeholder row. Closing this means
 deciding how `event_model` itself represents "a shape I don't recognise"
--- a shared-model decision affecting `server/` too, not a `client-core`-only
+-- a shared-model decision affecting `server/` too, not a `client`-only
 fix, so it is recorded here rather than silently worked around.
 
 ## `config.rs`: `EnrolledServer`
@@ -130,11 +135,11 @@ parses on the phone -- so any Rust client enrols from the same text a
 phone would scan as a QR, with no second format invented for it (RUST.md's
 E4, DECISIONS.md 2026-09-05). Deliberately does not decide where it is
 persisted or under what file permissions -- a phone seals its token in the
-Android Keystore, `iris/desktop-app/src/config.rs` writes it to
+Android Keystore, `src/desktop/config.rs` writes it to
 `$XDG_CONFIG_HOME/ai-app-desktop/enrollment.json` at 0600 -- since that is
 caller-specific (the code rules' "ask for the least you need"). Its only
-caller today is `desktop-app`; a future Android build of this crate would
-be a second one, not a reason to move the type.
+caller today is `src/desktop`; the Android entry point is a second one, not
+a reason to move the type.
 
 ## What `transcript_source.rs` covers, and what it does not
 
@@ -184,7 +189,7 @@ thread. Both are wall-clock/thread-lifetime policy that belongs to
 whichever runtime embeds this crate (iris's own timers, a Tokio task, a
 Kotlin coroutine scope), not to this pure logic -- `follow` is the same
 "write to the cache, then hand the frame to the caller" decorator
-`iris/desktop-app/src/app.rs` and `iris/android-app/src/transcript_client.rs`
+`src/desktop/app.rs` and `src/android/transcript_client.rs`
 already hand-wrote around `event_stream::follow_session_events` before this
 existed; the cache write moved into one shared place so a third caller
 does not repeat it again by hand.
@@ -198,7 +203,7 @@ does not repeat it again by hand.
   block instead of the message (docs/RUST.md's Task B). What it
   deliberately does **not** build is the tree below that: nested list
   items, table cells, inline spans. Inline styling is still the renderer's
-  own job per block (`iris/transcript-ui/src/markdown.rs`), and nothing
+  own job per block (`src/ui/markdown.rs`), and nothing
   has needed the rest yet. `CodeFence.kt`'s use of `org.intellij.markdown`
   for a full CommonMark AST is Compose rendering plumbing, not something
   to port as-is.
@@ -209,8 +214,8 @@ does not repeat it again by hand.
 
 ## Verifying
 
-`./run-tests.sh` from the repo root now runs `event-model`, `client-core`
-and `server` in that order (each `cargo test`, forwarding arguments the
-same way it always has). From `client-core/` directly: `cargo test`
-(119 tests), `cargo clippy --all-targets`, `cargo fmt` -- all clean as of
-this writing (2026-09-06).
+`./run-tests.sh` from the repo root runs `event-model`, `server` and
+`app-rust` in that order (each `cargo test`, forwarding arguments the same
+way it always has). From `app-rust/` directly: `cargo test`, `cargo clippy
+--all-targets`, `cargo fmt` -- all clean as of 2026-09-08, 229 tests across
+the crate and its headless harness suites.