feat: add interactive VT and workspace command plane

docs/ARCHITECTURE.md

@@ -41,8 +41,10 @@ messages should be real from the beginning.
 - `lumbridge`: installable application entry point.
 
 The scaffold currently contains `lumbridge-core`, `lumbridge-storage`,
-`lumbridge-buzz`, `lumbridge-pty`, `lumbridge-runtime`, and the entry point.
-Larger runtime crates are added after their architecture spikes pass.
+`lumbridge-buzz`, `lumbridge-pty`, `lumbridge-runtime`, `lumbridge-terminal`, and
+the entry point. `lumbridge-core` also contains the first typed workspace
+command reducer. Larger runtime crates are added after their architecture spikes
+pass.
 
 ## Terminal path
 
@@ -55,19 +57,41 @@ scrollback. The terminal engine turns output into immutable render snapshots and
 bounded deltas for the UI. Scrollback is chunked and persisted separately from
 the live screen to prevent large agent transcripts from blocking input.
 
+The first `lumbridge-terminal` implementation wraps `alacritty_terminal` behind
+a Lumbridge-owned input and immutable snapshot contract. It parses styled cells,
+cursor state, alternate screen, terminal modes, title events, keyboard input,
+bracketed paste, resize, and terminal-generated protocol replies. OSC 52
+clipboard writes are disabled by default. The renderer never imports the
+upstream terminal type, and protocol replies return through the same actor input
+queue as human input. See decision 0005.
+
 The first `lumbridge-runtime` actor now owns one `PtySession` on a dedicated
 thread. Bounded command and event queues serialize input, resize, close, and
-shutdown against ordered raw-byte output. The GPUI slice consumes one actor
-session while five surfaces retain deterministic comparison output. This actor
-still runs in-process; moving the same framework-neutral contract behind local
-authenticated IPC is the next durability step. See decision 0004.
+shutdown against ordered raw-byte output. The GPUI slice feeds one actor session
+through the terminal engine while five surfaces retain deterministic comparison
+output. Its current text adapter intentionally renders plain rows and does not
+yet paint cell styles, selection, or the cursor; the next rendering slice owns
+that work. This actor still runs in-process; moving the same framework-neutral
+contract behind local authenticated IPC is the next durability step. See
+decisions 0004 and 0005.
 
 We should evaluate, not blindly copy, WezTerm, Zellij, RMUX, tmux, and cmux. The
 first spike must compare a reusable terminal crate with a small first-party layer.
-Correctness cases include alternate screen, bracketed paste, OSC 8 links, Kitty
+Remaining correctness cases include OSC 8 links, Kitty
 keyboard/graphics negotiation, Unicode width, IME, mouse modes, shell integration,
 and simultaneous automation plus human input.
 
+## Workspace command plane
+
+Human UI, local automation, remote clients, and agents reduce the same typed
+workspace commands. Stable request IDs make retries idempotent; validated pane
+IDs, split ratios, launch intents, and close dispositions prevent untyped JSON
+from becoming the product API. A multi-command setup plan is reduced atomically.
+Observe, Configure, and Execute capabilities are checked before mutation, and a
+layout-only agent cannot smuggle an executable or arbitrary arguments into a
+split request. Current code is an in-process reducer; serialization, durable
+events, and authenticated IPC are subsequent layers. See decision 0006.
+
 ## UI decision gate
 
 Do not lock the project to a webview or to Zed's application implementation
@@ -129,6 +153,19 @@ available because terminal fidelity and arbitrary CLI compatibility are product
 requirements. Harness-specific adapters translate both paths into the same event
 model without pretending a PTY has capabilities it cannot prove.
 
+Lumbridge Harness is a separate optional orchestrator, not a UI framework. The
+DeepSeek Harness snapshot is a useful MIT-licensed reference for plugin seams,
+durable session events, approvals, ACP, and agent lifecycle, but its developer-
+preview Node/TypeScript/web composition is not embedded into the Rust desktop
+process. If we maintain a fork, it lives in its own repository and communicates
+through a versioned, capability-scoped protocol. A first-party Rust service may
+later replace that implementation without changing the desktop contract.
+
+The Harness can consume redacted workspace projections and emit suggestions or
+typed command plans. Suggestions have no authority. Plan execution is routed
+through the same command plane as human actions, and trace export to a hosted
+model requires explicit scope and destination consent. See decision 0007.
+
 ## Usage model
 
 Usage is an append-only observation stream, not a mutable percentage field.