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 presents one, three, or five vertical panels, each with its
own 20/60/20 context/work/decision composition, while one terminal fixture is
replaced with a real actor-owned VT session and five deterministic surfaces keep
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.