lumbridge-code/docs/UI_SPIKE_SCORECARD.md

Native UI spike scorecard

The GPUI and Floem programs under spikes/ consume the same six-pane fixture. No product framework decision is accepted until both rows contain measurements from macOS and Linux and the hard gates pass.

Criterion	Hard gate	GPUI	Floem
Builds on macOS Apple Silicon	yes	pending	pending
Builds on Ubuntu	yes	conditional	pass
Builds on Omarchy/Arch	yes	pending	pending
Dependency/license closure permits Apache-2.0 distribution	yes	pending	pending
Keyboard navigation + AccessKit tree	yes	keyboard pass; current-GPUI semantics compile; platform AT pending	fail: no AccessKit integration at pinned revision
IME and composed Unicode input	yes	framework API exists; end-to-end pending	editor API exists; end-to-end pending
Isolated system browser child	yes	pending	pending
Cold startup, p50/p95	record	pending	pending
Idle RSS / six-stream RSS	record	pending	pending
Key-to-present p50/p95	record	pending	pending
Six-stream frame p95/p99	record	pending	pending
Release binary/package size	record	pending	pending
Native menu/window/clipboard/drag-and-drop	review	pending	pending
API clarity and maintenance burden	review	pending	pending

The current programs establish dependency, build, launch, and interaction baselines. GPUI now routes a real PTY through a VT engine and keyboard encoder, paints coalesced styled cell runs and cursor shapes, and derives PTY rows/columns from the 60% terminal region inside each responsive one/three/five-panel layout when the window or attached panel count changes. Retained-history page/top/bottom navigation is wired. Panel detach/reattach keeps background surface updates alive and exposes detached sessions in the sidebar. Text selection, mouse modes, a native Markdown editor, and one isolated browser child remain.

Ubuntu baseline — metal, 2026-08-31

Host: Ubuntu 24.04 x86_64, Rust 1.94.1. Both candidates used the same 1280×800 six-pane fixture and were launched under the active X11 desktop.

Observation	GPUI 0.2.2	Floem 778bb5f2
cargo check from downloaded dependency cache	20.76 s, 1.04 GiB max RSS	24.26 s first attempt + 4.06 s after enabling required editor feature, 753 MiB max RSS
Debug executable link	pass with a user-local linker symlink for installed libxkbcommon-x11.so.0	pass
Debug executable size	442 MiB	475 MiB
Native window launch and six-pane render	pass	pass
Root workspace CI	8/8 tests, strict Clippy and doctests pass in 10.79 s	shared result

These are cold-development baselines, not startup, release-size, or runtime performance numbers. GPUI's Ubuntu row remains conditional because the host has the runtime libxkbcommon-x11.so.0 but lacks the unversioned development linker name normally supplied by libxkbcommon-x11-dev. Floem current main also requires its editor feature for the style/label modules used by this shell; that feature is now explicit in the spike. Neither build result by itself decides the UI stack.

Accessibility gate and provisional direction

The published gpui 0.2.2 used by the visual shell has focus and keyboard actions but does not expose the current AccessKit element API. An isolated probe therefore pins GPUI directly to Zed commit ce48461eaadd16c65c31f835511ab96bd3b6e746 with its matching Rust 1.97.1 toolchain. The real element wiring compiles with stable accessibility IDs, workspace/pane/terminal roles, selected state, focus tracking, and a needs-input description. The same probe installs real EntityInputHandler and ElementInputHandler implementations and tests marked-text commit, a composed accent, and a multi-codepoint emoji without splitting UTF-8. Three deterministic tests pass. AT-SPI/OS IME on Linux and VoiceOver/IME on macOS remain end-to-end gates.

The pinned Floem revision has keyboard focus and editor IME plumbing but no AccessKit dependency or semantic tree. That fails Lumbridge's accessibility gate without a maintained framework fork or adapter. The provisional direction is therefore GPUI-first using current Zed GPUI behind a narrow Lumbridge UI adapter. The published GPUI shell remains the lightweight interaction and visual benchmark until the dependency/toolchain migration is accepted.

This is not the final cross-platform release decision. Current-GPUI validation on amd-server required a 624 MiB Rust 1.97.1 toolchain, a 691-package lockfile, and 4.4 GiB of debug artifacts across check, test, Clippy, and build. Packaging, license closure, IME, platform assistive technology, browser parenting, macOS, and Omarchy still have to pass.

The comparable Floem shell passes build, test, strict Clippy, live rendering, streaming, mouse selection, and numeric pane selection on metal. Its command palette opens through the visible clickable affordance and uses Floem's native TextInput, but Ctrl/Cmd+K did not reach the handler in the X11 automation probe. That unresolved focus/event-routing behavior is another current strike against adopting Floem; it is recorded rather than hidden behind the clickable fallback.

Measurement semantics

Both renderers retain the same all-deterministic six-surface action stream for comparison. GPUI now layers an unbounded, SQLite-snapshotted panel registry over that benchmark and presents one, three, or five vertical panels, each with its own 20/60/20 context/work/decision composition. The Add Panel chooser creates Terminal, Browser, Markdown, and Review panels beside the selection or reattaches an existing session. Every Terminal panel receives an independent actor-owned VT session; the three seed non-terminal surfaces keep deterministic updates running. Counters separate external PTY batches/lines from total model updates. The GPUI footer reports dispatch-to-element-build p50/p95 over a bounded 256-sample window. It is deliberately not called key-to-present or frame-present latency: neither candidate exposes a reliable public cross-platform post-present callback. True present latency requires an external platform probe.