Crate gwk_tui 

The GridWork terminal console — the thin client half.

Five lenses exist. The queue — the workday screen — the board — the task/attempt DAG and the A2A message flow — hall — the estate frame, a deterministic spatial layout over caller-normalized facts (the live projection/event join lives in estate, the terminal loop in runtime) — and config — the four-file git-backed reconciler — sit beside drilldown, the hosted session’s styled-cell view. Beneath the lenses sits the substrate they consume: theme, the one function that turns a resolved token into a renderer colour; probe, which measures what the drawing terminal does with the glyph inventory; and input, the session bracket, click hit-testing, and the OSC 52 copy path. Beside them sits seven_act: the phase lifecycle as client-side template data over the kernel’s generic tasks and gates — a convention the demonstration walks, not a domain object.

What the crate is

A client. It talks to the kernel over the UDS and consumes engine frames as wire data: the PTY sessions and the engine adapters live server-side in a separate host crate, and this one never links gwk-pty. That is what makes attach-from-anywhere fall out rather than needing to be built — a console that owned its own PTY could only ever show the sessions on the box it happens to be running on.

The invariant is asserted in CI (cargo tree -p gwk-tui carries no gwk-pty or libghostty) with a positive control, because an invariant nothing checks is a sentence in a doc comment.

src/workspace/

The multiplexer work — panes, layout, detach/reattach routing — lands under src/workspace, which is under the clean-room gate (CLEANROOM.md rule 2, .github/cleanroom-paths.txt). Its structural floor is in place: the workspace/tab/split-pane model with create/navigate/resize/close, its geometry solver, and the furniture painting that consumes chrome. The wire half holds session content in durable panes, multiplexes the active tab’s attaches on one bounded socket, and routes pane input. The rest of this crate is lens code and is deliberately outside the gate: the gate follows the risk, not the directory tree.

chrome is the demonstration of that sentence. It themes the workspace’s own furniture and is named for it, and it still sits outside the gated prefix — because rule 2 is a category test, not a directory test, and a table mapping a chrome role to a ratified colour token supervises no process and emits no terminal byte. Filing it under src/workspace/ would have gated it by path regardless of its category, which is exactly the directory-tree reading rule 2 rejects.

Modules

board

The Board lens — estate and activity summaries, workflow runs, work structure, message flow, terminal replay, the running fleet, cost/health, and audit receipts.

chrome

The workspace chrome’s theme slot — the one surface a user’s own colour preference reaches.

config

The Config lens — a git-backed reconciler over four policy files.

console

The five-lens console surface outside the clean-room multiplexer.

drilldown

The session drill-down lens: a hosted engine’s styled-cell wire frames.

estate

Live projection/event joining for the estate frame.

hall

The estate frame: deterministic spatial layout over caller-normalized facts.

input

Input plumbing: the session bracket, click hit-testing, and the copy path.

probe

Measuring what a terminal actually does with the inventory.

queue

The Queue lens — the workday screen.

replay

Reading persisted PTY recordings into deterministic console replay frames.

row

Shared list-row grammar.

runtime

Pure scheduling decisions for the production terminal loop.

seven_act

The seven-act phase lifecycle as a client-side template over generic tasks and gates.

shell

Shared state and chrome for the five-lens console.

tables

Plain-text table twins for list lenses.

theme

The one place a token becomes a renderer colour.

workspace

Workspace mode’s structural floor: the mux object model.