← Swink AgentShore
The TUI · one of two UIs

Same window, from the terminal

A Textual-based companion to the Dashboard. Same read-only posture, same walk-away promise, rendered in a single pane of glass that fits over SSH.

The posture

The TUI is a live monitor over the same session state the Dashboard renders. It does not let you assign work, retry a play, or steer an agent. The footer keys are navigation, inspection, and alarm-time escape hatches — not steering. The policy still picks every play.

Swink AgentShore ships two UIs: the Dashboard (the desktop GUI, with the pixel-art floorplan) and the TUI (this page). Both subscribe to the same audit log. Pick whichever fits where you're sitting — on the laptop after dinner, or over SSH from a hotel.

The Swink AgentShore TUI: header, agents panel, recent plays table, a bottom row of epic closure / budget / work queue, the session line, and a footer of key bindings.
The TUI mid-session. One agent on seed_project. Bottom row: Epic Closure with the global bar tracking against 665 tasks, Budget at $0.05 / $200, Work Queue showing 200 issues / 7 PRs / next up #181. The footer lists every binding the TUI exposes — the actual control surface.
Why a TUI at all

The Dashboard is the home, the TUI is the laptop on the train

The Dashboard is the default surface — pixel-art office floorplan, full theme system, the works. But sessions run for hours, and the Human Engineer isn't always on the machine that started them. The TUI exists so the same read-only window works over SSH, on a thin client, or on a laptop where you don't want a Tauri window resident in memory.

Both UIs read the same audit log. Closing one doesn't affect the run. Opening the other doesn't either. They are observers, not the orchestrator.

The breakdown

Eight regions, one screen

Each region renders a slice of the latest session snapshot. None of them are interactive in the steering sense — the footer keys let you navigate, inspect, pause, and end the session, but never assign a play or override the policy mid-tick.

Top · alert-only

1. The alert bar

Hidden by default. Only visible when something needs attention — a loop-detection escalation, a feedback-needed prompt, or a session-paused notice. The TUI surfaces the alarm; it does not auto-resolve it.

Shows when: loop_detected · feedback_requested · session_paused
Upper pane

2. Agents & Active Plays

Up to ten agents in a dense table: live status glyph, name, state, current play, target (issue or PR), elapsed time, context window in use, and dollar cost. The roster the Dashboard renders as sprites — in one screen of text.

Status: busy · idle · error · terminated
Middle pane

3. Recent Plays (last 5)

A scrollable DataTable of the most recent completed plays, newest first. Each row: play ID, play name, result, the reward delta (Δ) the policy received, cost, and duration. This is the trajectory the policy is learning from — surfaced read-only.

Columns: ID · Play · Result · Δ · Cost · Duration
Bottom row, 3-up

4. Epic Closure

Global closure ratio at the top, then per-epic bars showing closed / total tasks. The background tint shifts low / medium / high as the average alignment crosses thresholds. The same beads-graph signal that drives the policy's alignment reward.

Sources: beads project graph
Bottom row, 3-up

5. Budget

Spent and remaining against the cap. A 20-cell █░ bar with a percentage. The border tints green / amber / red as you cross 50% / 20% remaining. The headline number the Human Engineer set before walking away.

Reads: $3.61 / $200.00 · 98% remaining · avg/play $0.26
Bottom row, 3-up

6. Work Queue

Open issues, how many are ready, how many in progress. Open PRs, blocked, drafts. Reviews queued. The next-up issue title. This is the policy's working set rendered as numbers, not the policy's choice.

Sources: GitHub adapter · beads ready set
Lower bar

7. Session line

One row of RL telemetry: session state, policy mode, total plays, success counts, total cost, failure streak, last play, and how many of the 22 actions are eligible right now vs masked. The compact view of what the policy is doing.

Reads: state=running · policy=learning · plays=14 · eligible=4 masked=18
Footer

8. Key bindings

A single row of single-character bindings. Three end the session in different ways, two are escape hatches when the policy is stuck, the rest navigate to subscreens (epics, agent detail, help, palette). Every binding is enumerated below.

See below · navigation + escape hatches
The footer keys

Navigation, inspection, and the way out

Every binding the main TUI exposes is in the footer. Group them three ways: ending the session (graceful or hard), the single pause lever, and navigation into subscreens and inspection views. None of them assign a play, override a decision, or steer an agent.

End the session

^q End (graceful)
Tell the orchestrator to drain at the next safe boundary. In-flight plays finish, no new plays dispatch, then the session winds down cleanly.
shift + ^q End (hard)
Cut the session now. In-flight plays are aborted. Reserved for the cases where graceful drain isn't fast enough.

Once a drain starts, the shutdown screen adds q Quit and r Report — the only place those two keys are live.

Pause

p Pause / Resume
Holds the dispatcher. In-flight plays finish, no new plays start, the session sits idle until you resume. The one in-session lever — useful when the alarm is "let me look at this before another play fires."

Navigation & inspection

g Epics
Jump to the epics screen — the full per-epic closure breakdown the dashboard summarizes in three bars.
d Agent
Open the selected agent's detail screen. Trajectory, recent plays, context, spend. Read-only, like the rest.
i Issues
The issue backlog as Swink AgentShore sees it — the open work the policy is sequencing through GitHub.
l Learnings
Session learnings and agent handoffs — the notes carried forward into later plays' context.
? Help
The full keymap and screen index, so the footer doesn't have to.

Two exits, one pause, five inspection views. Nothing in the set lets you reassign a play, override a single decision, or steer an agent's prompt. If the binding you need isn't there, the answer is upstream — tighter spec, adjusted budget, a hard gate the catalog should have. Not a richer TUI.

Responsive layout

The same screen at 100, 60, and 40 columns

The TUI snaps between three layouts based on terminal width. At ≥100 columns you get the full mock above. At 60-99 the play history trims visible rows and the three-up bottom row stacks. At 40-59 only the essentials render. Below 40 the screen replaces itself with an alert telling you to resize. The contract is that the read-only window keeps working no matter where you're SSH'd in from.

What it is not

Things the TUI intentionally doesn't do

Same negative space as the Dashboard. Different rendering, same posture.

The shared rule

The Dashboard and the TUI render the same audit. They make the same promise: the run keeps going whether you're watching or not. The whole point of AgentShoring is the walk. The TUI is just the version of the window that fits over SSH.