Metal AgentandClaude Opus 5
4b5d92249e
Decision 0017 chose published gpui 0.2.2 over a Zed git revision, accepted that the crate has no AccessKit API at all, and said the mitigation was "a narrow `a11y` adapter trait, introduced now while there are few call sites" so that moving off 0.2.2 would be "a swap rather than a rewrite". No such trait, module, or file was ever written. Decision 0023 records what that cost: `apps/lumbridge/src` now builds 147 elements and gives 20 of them a stable identity, and the only trace of the promise is a `describe()` in the sidebar model that produces the screen-reader sentence, is tested, is called by nothing, and carries an `#[allow(dead_code)]` naming a record it outlived. `apps/lumbridge/src/a11y.rs` is that adapter, landed on 0.2.2 as stage 1 of decision 0023 and before the dependency moves, so the dependency change is paid for on its own. The trait carries the five operations `spikes/gpui-accessibility-probe` proves compile at Zed `ce48461e` -- role, label, description, selected state, and a stable accessibility identity -- implemented for `Div` and `Stateful<Div>`, which are the only two builders the shell constructs. Every body drops the value it is given and returns `self`. That is the whole point: 0.2.2 has nothing to hand the value to, so the file is a vocabulary and a set of call sites, not a feature. What it is not is a blanket `#[allow]` -- the arguments are consumed by a `discard` helper so `clippy::pedantic` passes on the code's merits, and the next real mistake in this file is still caught. Two choices exist only to keep stage 5 confined to this file. The methods are prefixed `a11y_` because GPUI's own builders at the target revision are named `role`, `aria_label`, `aria_description`, `aria_selected` and `accessibility_id`, and a trait of ours carrying those names would make every call site ambiguous the moment both are in scope -- which is the rewrite the adapter exists to avoid. `Role` is Lumbridge's own enum rather than an alias, because `gpui::Role` does not exist to alias and because the enum should name what the product claims, not what today's dependency happens to spell. The derivations sit here too, and are the testable part: `PaneSemantics` derives the four facts `UX_VERTICAL_SLICE.md`'s hard gate names -- which pane, its selected state, its execution target, its waiting state -- from strings the pane header already prints, so an assistive technology cannot announce a machine the screen is not showing. The gate is not met and this does not move it. No accessibility tree is produced, nothing reaches AT-SPI or VoiceOver, and no test here is an assistive-technology claim. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01SPYebLiN2w4TqnHUYGdECq
Lumbridge
Lumbridge is a fast, local-first workspace and terminal multiplexer for agentic engineers. It will run coding harnesses side by side, preserve their sessions, connect rich agents through ACP, and show trustworthy account and usage context without forcing users into one model vendor.
The first supported desktop platforms are:
- macOS (Apple Silicon first, Intel when CI capacity is available)
- Ubuntu Linux
- Omarchy and compatible Arch Linux systems
Lumbridge is free and open source under Apache-2.0. Releases will be published as installable binaries; building from source will remain supported.
Status
This repository is in architecture and vertical-slice phase. The installable binary is still a scaffold, while the isolated native UI spikes now exercise an interactive 20/60/20 workspace backed by six live comparison surfaces, and the root workspace contains the first bounded local PTY, runtime actor, VT engine, and capability-gated workspace command boundaries. The GPUI slice shows a responsive one-, three-, or five-panel workspace—five on a 3440 px ultrawide— where every panel owns its own context, work surface, and decision shelf. One panel contains a styled actor-owned VT session and five comparison surfaces remain deterministic. Retained-history navigation is wired. The usage footer is a live strip over an append-only ledger with provenance, fed by two real adapters: Codex's documented quota surface and Claude Code's session transcripts. A harness with no adapter renders an explicit gap rather than a zero. We are still validating terminal text selection and mouse input, standalone runtime IPC/durability, ACP integration, and packaging before a large implementation.
Product shape
- A native desktop shell with tabs, panes, workspaces, worktrees, diffs, and an agent-aware footer.
- A Rust session runtime that survives UI restarts and can later run headless.
- ACP-native integrations where available, with supervised PTYs as the universal fallback for any CLI harness.
- First-class harnesses for Claude Code, Codex, DeepSeek Harness, Pi, Hermes, OpenClaw, Goose, Gemini CLI, and OpenCode.
- Subscription login owned by the upstream harness, plus separate BYOK provider profiles for OpenAI, Anthropic, Gemini, Groq, Cerebras, DeepSeek, and more.
- Usage history, burn rate, reset windows, and forecasts with visible data provenance instead of invented precision.
- Optional first-class Buzz channels, messages, agents, and confirmed redacted pane sharing without making Buzz a requirement.
- An optional Lumbridge Harness that can suggest, coordinate, and—with explicit execution capability—manage agents through the same audited command plane as the human UI. Lumbridge remains useful without it.
Start with the product spec, architecture, research map, and captured upstream revisions. The native UI choice is intentionally open; see the measured decision plan.
Scaffold
bacon # continuous check; t tests, c lints, v runs the full gate
cargo xtest # fast isolated tests with nextest
./scripts/ci.sh # format + strict Clippy + tests + doctests
cargo run -p lumbridge
See the testing strategy for fake harnesses, ACP replay, terminal conformance, UI driving, recovery, performance, and packaging tests.
The accepted local/remote boundary is recorded in
decision 0003. The two
native shell candidates live in spikes/, with results tracked in
the UI scorecard.
The signed-protocol and pane-sharing boundary is in
the Buzz integration design.
Brand masters, platform-ready raster exports, and usage rules are in
assets/brand/ and the brand guide.