The rail showed a frozen attention count over a worktree list backed by a crate that does not exist. What replaces it starts from a question rather than from a list of things we happened to know: what needs me, what am I running, what did I set aside, where does it run and what will stop me. Layout is data. sidebar/model.rs holds no renderer types, so which sections exist, what collapsing hides, what the filter keeps, and where the keyboard cursor lands are ordinary tests in CI; sidebar/view.rs renders and decides nothing. Eleven model tests, none of which need a window. The cursor is a RowKey rather than an index, because an index is wrong the moment a row above it disappears and silently pointing at a different row is worse than losing the cursor. Every header renders even when its section is empty, so positions never move under the pointer. The filter's empty state does not quote what was typed — the sidebar is the part of the window people screenshot. One selection language everywhere: before this, attention cards darkened on hover while worktree rows lightened, so the same gesture meant two different things a hundred pixels apart. Two defects the screenshots caught that review had not. Flexbox shrinks proportionally, so the longer string wins: the attention row rendered as "Te… Exited with code 7 · observed", having discarded the one word that says which pane to look at. And three quota rows all read "CLAUDE CODE" with the scope truncated away, naming the same thing three times and identifying none of them. Titles now have a floor and the harness name prints once per group. WORKSPACE is deliberately flat: a Repository → Worktree → Pane tree would need lumbridge-git, and every level above Pane would be a second fixture. The depth field and disclosure column are reserved for when it is real. HOSTS has two states, live or not — connecting and unreachable are unbuildable until lumbridge-remote exists, and shipping them would be the Buzz card again in a Rust enum. The rail drags between 200 and 480 px, applied live so the workspace reflows under the pointer; decision 0009 measures pane thresholds after the sidebar, so widening really can drop three panes to one. PTYs are resized on release only, or every mouse-move is a SIGWINCH storm through the runtime's bounded queues. While the sidebar owns the keyboard, on_key_down returns before encoding anything. Without that guard a bare `j` would be written into whatever pane happened to be selected while the user believed they were walking a list. Not persisted yet, not virtualised, and describe() has nothing to attach to until the accessibility adapter from decision 0017 lands. Recorded in 0021. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.