What
A spatial, 3D desktop GUI for Kleos -- a "control deck" where every Kleos capability is a visible, clickable tile inside a navigable environment. Two parallel renderer tracks consume a shared bridge and tile catalog.
The current CLI + web dashboard covers Kleos's 348+ HTTP routes and 55+ MCP tools, but discovery is poor. You forget commands between sessions. The Deck fixes that: you see the tile, you know the capability exists. More than that -- the Deck has an embedded terminal, so agents run inside the environment. You never leave. Coding, searching, storing, reviewing -- all in one window.
A conventional web dashboard (#57) solves the data-display problem. The Deck solves the experience problem. Using Kleos should be enjoyable, not a chore of remembering CLI flags.
Architecture: one bridge, two renderers
Bridge (kleos-deck-bridge, Rust crate in the Kleos workspace)
Local process on the operator's machine. Connects upstream to kleos-server
GET /catalog -- tile catalog JSON (domains, tiles, intent modes, state sources)POST /intent -- renderer pushes { tile_id, mode, payload }
active mode: writes to the embedded PTY stdin (Claude Code runs inside the deck)spawn mode: launches an isolated agent task, surfaces result in a notifications drawer
WS /pty -- bidirectional PTY stream (xterm.js connects here)WS /state -- streams { tile_id, state } deltas from Kleos event sources
The embedded terminal is central to the design. The deck IS the terminal host -- click a tile and the intent lands in the PTY's stdin, right where the agent is running. No alt-tabbing, no copy-pasting commands. The deck and the coding session are the same window.
Track A: Three.js + Tauri (ships first)
~/projects/kleos-deck-tauri -- Svelte 5 + Tauri 2.x + Three.js. Tauri's Rust side imports the bridge library in-process (no extra binary).
Current state: v1 scaffold with a dark base and placeholder cube confirming the Tauri/Vite/Three.js pipeline end-to-end.
Track B: Unreal Engine 5.4+
~/projects/kleos-deck-ue -- Blueprint-first, C++ where Blueprint can't reach. Lumen + Nanite + Megascans. Bridge runs as a standalone binary; UE's CEF widget loads the xterm.js terminal page.
Current state: repo created, First Person template not yet initialized.
Visual concept
- Outside: dawn temple courtyard. Cracked masonry, one strong light source. Six visible doors (one per domain) plus a hidden seventh (admin).
- Inside: warm chamber per domain. Candle and lantern light, brass instruments, leather, polished wood.
- Memory = library (shelves, reading stand, inkwell, hourglass)
- Skills = workshop (workbench, racks, vises)
- Approvals = quiet chamber with a brass dial
- Jobs = wall of running gauges
- Handoffs = archive (scrolls, sealed boxes)
- Identity = crypto altar (plinth, key, sigils)
- Admin (hidden) = engine room
v1 scope
One chamber (Memory) working end-to-end in both renderers. Six tiles: Store, Recent, Inbox, Ingest, Recall-due, Browse-by-category. Plus the embedded terminal (obsidian slab with xterm.js) -- the always-on coding/search/command surface that makes the whole thing a single-window workflow.
Other chambers are visible doors leading to "under construction" interiors.
What exists today
- Implementation plan (
~/projects/plans/)
kleos-deck-bridge crate added to the Kleos workspace (commit 8dda9504)kleos-deck-tauri repo scaffolded with working Tauri + Three.js pipelinekleos-deck-ue repo created, awaiting UE project init- kleos-server already has the Axon pub/sub,
watch::Sender, and activity router plumbing the bridge needs to subscribe to
Known risks
- Two prior UE attempts failed at bootstrap (black screen, no assets rendered). Mitigated: always start from First Person template, render before code.
- The bridge protocol is unproven.
- UE on Linux (cachyOS) is rough.
Relationship to #57
The web GUI rebuild (#57) gives a conventional dashboard -- good for quick data lookups and monitoring. The Deck is the primary interface -- the place where you actually work. The embedded terminal means you code, search, store, and review without leaving the environment. Both will coexist: the web dashboard for lightweight browser access, the Deck for real sessions.
What
A spatial, 3D desktop GUI for Kleos -- a "control deck" where every Kleos capability is a visible, clickable tile inside a navigable environment. Two parallel renderer tracks consume a shared bridge and tile catalog.
The current CLI + web dashboard covers Kleos's 348+ HTTP routes and 55+ MCP tools, but discovery is poor. You forget commands between sessions. The Deck fixes that: you see the tile, you know the capability exists. More than that -- the Deck has an embedded terminal, so agents run inside the environment. You never leave. Coding, searching, storing, reviewing -- all in one window.
A conventional web dashboard (#57) solves the data-display problem. The Deck solves the experience problem. Using Kleos should be enjoyable, not a chore of remembering CLI flags.
Architecture: one bridge, two renderers
Bridge (
kleos-deck-bridge, Rust crate in the Kleos workspace)Local process on the operator's machine. Connects upstream to kleos-server
GET /catalog-- tile catalog JSON (domains, tiles, intent modes, state sources)POST /intent-- renderer pushes{ tile_id, mode, payload }activemode: writes to the embedded PTY stdin (Claude Code runs inside the deck)spawnmode: launches an isolated agent task, surfaces result in a notifications drawerWS /pty-- bidirectional PTY stream (xterm.js connects here)WS /state-- streams{ tile_id, state }deltas from Kleos event sourcesThe embedded terminal is central to the design. The deck IS the terminal host -- click a tile and the intent lands in the PTY's stdin, right where the agent is running. No alt-tabbing, no copy-pasting commands. The deck and the coding session are the same window.
Track A: Three.js + Tauri (ships first)
~/projects/kleos-deck-tauri-- Svelte 5 + Tauri 2.x + Three.js. Tauri's Rust side imports the bridge library in-process (no extra binary).Current state: v1 scaffold with a dark base and placeholder cube confirming the Tauri/Vite/Three.js pipeline end-to-end.
Track B: Unreal Engine 5.4+
~/projects/kleos-deck-ue-- Blueprint-first, C++ where Blueprint can't reach. Lumen + Nanite + Megascans. Bridge runs as a standalone binary; UE's CEF widget loads the xterm.js terminal page.Current state: repo created, First Person template not yet initialized.
Visual concept
v1 scope
One chamber (Memory) working end-to-end in both renderers. Six tiles: Store, Recent, Inbox, Ingest, Recall-due, Browse-by-category. Plus the embedded terminal (obsidian slab with xterm.js) -- the always-on coding/search/command surface that makes the whole thing a single-window workflow.
Other chambers are visible doors leading to "under construction" interiors.
What exists today
~/projects/plans/)kleos-deck-bridgecrate added to the Kleos workspace (commit8dda9504)kleos-deck-taurirepo scaffolded with working Tauri + Three.js pipelinekleos-deck-uerepo created, awaiting UE project initwatch::Sender, and activity router plumbing the bridge needs to subscribe toKnown risks
Relationship to #57
The web GUI rebuild (#57) gives a conventional dashboard -- good for quick data lookups and monitoring. The Deck is the primary interface -- the place where you actually work. The embedded terminal means you code, search, store, and review without leaving the environment. Both will coexist: the web dashboard for lightweight browser access, the Deck for real sessions.