These disposable applications render the same fixture through GPUI and Floem. They are a decision instrument, not product code. The root workspace excludes this nested workspace so normal Lumbridge CI does not download or compile both UI frameworks.

The GPUI spike uses published gpui 0.2.2. The Floem spike pins upstream commit 778bb5f2aa08429e579ee2e6ac97e84fbf18b618; the crates.io floem 0.2.0 package lags the current API substantially enough that comparing it to current GPUI would not be representative.

Both spikes must preserve the same information architecture:

workspace/sidebar and remote host state;
two rows of three busy surfaces;
local and remote terminal/agent panes;
native Markdown editor/preview and browser placeholders;
connection, harness, usage, and burn context in the footer.

GPUI also has an integration mode with one real local PTY owned by lumbridge-runtime; the other five surfaces remain deterministic. Floem and the shared model retain the all-deterministic mode for like-for-like framework comparison. The PTY display is plain byte line-framing, not terminal emulation.

Build independently:

cargo build --release --manifest-path spikes/gpui-shell/Cargo.toml
cargo build --release --manifest-path spikes/floem-shell/Cargo.toml

Each candidate is an independent Cargo workspace. GPUI pins taffy 0.9.0 while current Floem requires taffy 0.9.2; putting them in one comparison workspace creates an artificial resolver conflict and would let one candidate's dependency decisions distort the other candidate's build.

The comparison records release build time, binary size, startup, idle RSS, six-pane streaming frame time, key-to-present latency, accessibility/IME, window behavior, browser-child integration, packaging, dependency count, and license closure on macOS, Ubuntu, and Omarchy. A build is not adoption: GPUI's complete dependency-license closure remains a hard gate.