Interface spec: workspaces grouped by question, tabs and tool panels, plain-language task selection

.pi/memory-vault/packs/paperclip-harness/60-observations/tmp-repository-structure-and-configuration-patterns.md

@@ -92,3 +92,84 @@ Say which layout you want, and I will build it — starting with the width-drive
 - session: [[packs/paperclip-harness/80-sessions/rich-discovery-tmp-2026-11-10-01-47-01|Rich discovery: tmp 2026-11-10 01:47:01]]
 - context: [[packs/paperclip-harness/20-context/tmp|tmp]]
 - observation: [[packs/paperclip-harness/60-observations/tmp-repository-structure-and-configuration-patterns|tmp repository structure and configuration patterns]]
+
+
+---
+
+## Update (2026-11-10 02:04:26)
+
+## Structural/configuration observations (2026-11-10 02:04:26)
+
+You are right to call it, and I will not push back on the substance: the last few turns drifted into proving commands rather than designing the thing. Here is the line I would hold, briefly — when a claim reaches you as "it works", it gets run once in TUIOS, because a spec built on an unproven assumption is the failure that cost you three restarts. One check per claim. Not exploratory testing. Everything else, spec first.
+
+I have rewritten `docs/UI-LAYOUT.md` as the single interface document (348 lines, replacing the earlier layout note rather than adding a second one).
+
+## How it is grouped
+
+By what you are doing, not by which system the data came from:
+
+| Workspace | Question it answers | Panels |
+|---|---|---|
+| **Board** | what is the state of the work, what needs me | Task tree · Task summary · Needs you |
+| **Work** | what is happening now, what changed | Run log · Diff · Worktree facts |
+| **Conversation** | what was said, what do I say back | Thread · Composer · Task header |
+| **Author** | what am I asking for, how will it be judged | Task form · Guidance · Preview |
+| **Project** | which folder, machine, limits, cost | Project facts · Costs · Settings |
+| **Repair** | is the layout sound, what broke | Layout map · Health · Log |
+
+Six, not sixteen. Four panels maximum per workspace, and the shell workspace stays for the moments you need a prompt. More than four panels cannot be read at once, so a fifth thing becomes a view inside a panel or a new workspace.
+
+## The interface items
+
+Twenty-seven, each with a purpose, its Charmbracelet component, and its empty, loading and failed behaviour. The ones that matter most:
+
+- **Panel frame** — rounded border and bright edge when focused, plus the word `focus` in the title, so focus never depends on colour alone.
+- **Footer key hints** — built from `help` and `key.Binding`, so a key that would do nothing is not shown.
+- **Stale marker** — the time of the last successful read, in the panel title. A wrong panel is visibly stale instead of quietly wrong.
+- **Blocker badge** — `waits on AUD-163`, read per task; when the blocker finishes but the task is still marked blocked the badge changes to `ready`, because that is our most confusing state.
+- **Needs-you card** — one per decision: a refused merge, a task waiting on an answer, a task ready but stuck. Each says what happened and the one key that acts.
+- **Composer** — `textarea`, Enter sends, Shift-Enter new line, stated in the footer because a text area normally does the opposite.
+- **Diff view** — file headers, hunks, line numbers, additions and deletions marked by a leading character as well as colour; a large diff says how many lines it left out and offers a key for all of it.
+- **Result receipt** — the server's own words on failure, never a paraphrase.
+- **Health row** — pass, fail, or **not run**, three states, because "not run" is not "pass".
+
+Components: `list` for rows and decisions, `table` for figures, `viewport` for anything scrollable, `textarea` for the composer, `textinput` for single-line fields, `help` and `key` for the footer, `spinner` and `progress` for feedback. One honest note: there is no tabs component in this collection, so a view switcher inside a panel is Lipgloss and `help` styling, not a Bubbles widget.
+
+## Styling
+
+One theme with semantic roles (text, muted, accent, success, warning, error, surface) and a light and dark variant from the start. One cell of horizontal padding, one blank line between sections, no blank line between rows. Columns computed from the content in view, never a hardcoded width. Truncation always ends visibly and the full text is one key away. Only two things animate: the spinner and the selection cursor. No colour that does not mean a state.
+
+## Sizes
+
+Every panel declares a smallest useful size (the task tree needs 30 by 10, the diff 40 by 12, the form 50 by 14). Below it, the panel draws its own short message naming what it has and what it needs — never a broken layout, never a scrollbar to hide the problem. The workspace needs 80 by 24.
+
+## Layout follows the width
+
+150 columns and wider: tree beside summary with Needs you under the tree; run log beside diff. 110 to 149: two panels per workspace, the third becomes a tab inside the panel of the same kind. 80 to 109: one panel per workspace, full width, in the order Board, Work, Conversation, Author. Below 80 by 24: one message.
+
+## Four decisions before I build
+
+1. **Does the tree drive the other workspaces?** Proposal: Enter writes `watching = AUD-163` into the project's `.harness/harness.toml` and asks TUIOS to show Conversation; the other panels reload when that file changes. One fact, one owner, survives a restart.
+2. **Six workspaces, or fewer?** Fewer means switching views inside panels, which hides state.
+3. **Which glyph set?** Must be checked against the font on the machine you actually sit at, not assumed.
+4. **Diff: its own panel in Work, or a tab beside the run log?**
+
+Answer those four and I will build Board first, in the order the document lists, with the styling system established before the second panel exists — so the look is settled once instead of drifting per screen.
+
+## Source paths observed
+
+- `home/sam/paseo/projects/paperclip-harness/docs/UI-LAYOUT.md`
+
+## Evidence
+
+- Confidence: 82%
+- Reason: Captured factual repo structure/configuration patterns from rich discovery
+
+## Related learned memories <!-- same-turn-2026-11-10 02:04:26 -->
+
+- decision: [[packs/paperclip-harness/50-decisions/paperclip-harness-ui-six-workspaces-spec-first-four-panel-li|Paperclip Harness UI: six workspaces, spec-first, four-panel limit]]
+- context: [[packs/paperclip-harness/20-context/paperclip-harness-interface-spec-docs-ui-layout-md|Paperclip Harness interface spec (docs/UI-LAYOUT.md)]]
+- action: [[packs/paperclip-harness/40-actions/2026-11-10-wrote-docs-ui-layout-md-and-three-live-layout-mockups|Wrote interface specification to docs/UI-LAYOUT.md]]
+- session: [[packs/paperclip-harness/80-sessions/rich-discovery-home-2026-11-10-02-04-26|Rich discovery: home 2026-11-10 02:04:26]]
+- context: [[packs/paperclip-harness/20-context/home|home]]
+- observation: [[packs/paperclip-harness/60-observations/tmp-repository-structure-and-configuration-patterns|home repository structure and configuration patterns]]