Files
paperclip-harness/.pi/memory-vault/packs/paperclip-harness/50-decisions/paperclip-harness-ui-six-workspaces-spec-first-four-panel-li.md

5.9 KiB

type: decision id: decision.paperclip-harness.paperclip-harness-ui-six-workspaces-spec-first-four-panel-li title: Paperclip Harness UI: six workspaces, spec-first, four-panel limit status: active source_of_truth: false freshness: current last_reviewed: 2026-11-10 tags: - pack/paperclip-harness - agent-memory/decision - paperclip-harness - tui - ui-design - workspaces - architecture

Paperclip Harness UI: six workspaces, spec-first, four-panel limit

The Paperclip Harness TUI is grouped by user activity, not data source, into six workspaces:

Workspace Question Panels
Board state of the work / what needs me Task tree, Task summary, Needs you
Work what is happening / what changed Run log, Diff, Worktree facts
Conversation what was said / reply Thread, Composer, Task header
Author what am I asking / how judged Task form, Guidance, Preview
Project folder, machine, limits, cost Project facts, Costs, Settings
Repair layout sound / what broke Layout map, Health, Log

The shell workspace remains for moments needing a prompt.

Decision: maximum four panels per workspace (a fifth item becomes a view inside a panel or a new workspace). Spec-first workflow: every claim that "it works" is run once in TUIOS before relying on it, but no exploratory testing. The look/style system is established before the second panel exists so it does not drift per screen. Build order: Board first, in document order.

Rationale: more than four panels cannot be read at once; grouping by activity keeps related concerns together. Alternatives considered: fewer than six workspaces (rejected: switching views inside panels hides state).

Open questions before build: (1) does the tree drive other workspaces (proposal: Enter writes watching = AUD-163 into the project's .harness/harness.toml, asks TUIOS to show Conversation, panels reload on file change); (2) six workspaces or fewer; (3) glyph set must be checked against the actual machine font, not assumed; (4) diff as its own panel in Work or a tab beside run log.

Review caveat: all of this is a specification, not yet implemented.

Evidence

  • Confidence: 90%
  • Reason: Explicit design decision with rationale, alternatives, and open questions; durable for future build work.

Update (2026-11-10 02:26:18)

Decision: drop the previous hard rule of at most 4 panels per workspace. A workspace holds whatever its work needs; more than four side-by-side stops being readable, so extra items are expressed as (1) first-class tabs inside a panel (switched with '[' / ']' while focused, word-named), (2) tool panels that close when done (opened with 't', focus restored on close), or (3) TUIOS's native zoom key. The only remaining rule: everything in a workspace helps answer the same question, else it moves to another workspace.

Context: user said 4 panels was never a hard limit, is happy with tabs and zoom, and prioritizes well-grouped meaningful items and usability over arbitrary counts. User also rejected esoteric backend terminology in UI copy, so selection behavior is stated plainly ('choosing a task changes what the other panels show') with the mechanism (watching line in .harness/harness.toml) described afterward.

Consequences: responsive layouts by terminal width (>=150 wide, 110-149 two panels + tab, 80-109 one panel ordered Board, Work, Conversation, Author, <80x24 single message); rely on TUIOS zoom and workspace switching rather than reimplementing. Review caveat: Starship-style glyphs deferred until a Nerd Font is deliberately installed.

Evidence

  • Confidence: 90%
  • Reason: Architectural/convention decision with rationale, alternatives (tabs vs more panels), and consequences.