UI Interview — Round 1: Assumptions Manifest

Stage-zero interrogation · Branch V2 Card Mosaic (baseline / control) · Parent flow monitoring-start

Skill /ui-interview Mode full UI Round 1 of N Gate continue Status confirmed — answers consumed
What this is. Before designing V2's visual mockup, I'm surfacing the assumptions I'm carrying from the approved flow-map, the V2 variation spec, and the shared brief — so you can confirm, correct, or flag each one before it becomes a design decision. The four sections of source-tagged assumptions come first; the open questions at the end are the items the V2 spec explicitly left for this interview to resolve. Answer inline, then use Compile Responses at the bottom and paste the YAML back to me.

Contents

  1. A. Scope & branch role
  2. B. Pages, routes & navigation
  3. C. Components, density & hierarchy
  4. D. States, responsive & accessibility
  5. E. Prototype-first boundary & build order
  6. F. Open questions this interview must resolve
  7. Compile responses

A. Scope & branch role

A1 · from artifact
V2 is the baseline / control of the 5-variation set. The mockup should track the approved flow-map most literally and serve as the measuring stick for V1/V3/V4/V5 — it deliberately does not innovate on the four variant axes; "boringly competent" is the goal.
A2 · from spec
Screens in scope are exactly three: S3 Agent Board, S4 Start Agent (modal), and the folded S5/S6 Agent Detail. Flow covered = Happy Path steps 3–6 + Path C "Parallel Sprint." S9 diff review, S8 recap, S10 settings are linked but not designed in depth here.
A3 · from artifact
The four axes are fixed at the flow-map default for V2 and are NOT reopened by this interview: responsive card grid (board) · full-page detail route (connection) · modal overlay (launch) · co-equal responsive (device posture). If an axis needs to change, that's a /ux-variations matter, not this mockup.
A4 · from artifact + brief
Detail (S5/S6) is folded into one tool-adaptive route: terminal-primary (xterm.js over WebSocket) for CLI tools, structured-primary for API-native tools. There is no Mode A/B user toggle — rendering is decided by the tool's integration pattern. Mode C / IDE (code-server) is out of scope; the "drop to terminal" path covers manual intervention.
A5 · from brief + spec
Single-user personal workstation: sharing, collaboration, permissions, multi-tenant are N/A and will be documented as such. No sharing/permissions UI is designed. The only "handoff" is the same user across their own devices (server-canonical state), not collaboration.

B. Pages, routes & navigation

B1 · from artifact
Route map: / board (home/hub) · /agents/:id folded detail. S4 modal and S8 recap are overlays/interstitials over whatever route is active (not routes). Deep links resolve to a route and fall back to the board. Browser back is first-class (back from detail returns to board).
B2 · from artifact
The whole card is the click target → navigates to full-page detail; the board unmounts (this round-trip is V2's defining choice and its main risk). Back to Board returns to / and re-reads server-canonical state. Launch (modal) never navigates away.
B3 · from artifact
Persistent header carries: app name · approval-queue badge (count) · Start Agent button · QR / "Open on Mobile" · settings gear. Board default sort is error > waiting > running > idle, with waiting cards re-sorting toward the top.

C. Components, density & hierarchy

C1 · from artifact
The Agent Card stacks top→bottom: (1) name + status badge; (2) tool · repo (· branch); (3) elapsed · token usage; (4) live stdout preview (monospace, auto-scrolling, fade-truncated) — V2's signature region; (5) conditional error/completion strip ("Review diffs →").
C2 · from artifact
Density is comfortable, not dense — large, well-spaced cards. Grid: 3 columns >1024px · 2 columns ≤1024px · 1 column ≤640px, with columns capped at very large widths (cards stay readable rather than sprawling). Accepted tradeoff: ~12 agents scroll (no single-screen overview — that's V1's job).
C3 · from artifact
Color is reserved almost entirely for status (green/running, amber/waiting, red/error, grey/idle); chrome is grayscale; the accent #4dabf7 is used only for the primary CTA and links. House palette is the dark scheme (--bg:#1a1a2e; --card:#16213e; --accent:#4dabf7), with the terminal slightly darker to read as a console.

D. States, responsive & accessibility

D1 · from artifact
State coverage the mockup will show: card states (starting/running/waiting-with-pulse/ error/idle/completed, plus hover/focus); board states (empty "Start your first agent", connection-lost banner); modal states (loading skeleton, validation-gated Start, launching spinner, inline error, tool-unavailable + "Install tool"); detail states (reconnecting overlay, inline approval).
D2 · from artifact + inferred
Accessibility is baseline-by-default, not optional: logical keyboard order & focus management; ≥44px tap targets on mobile; color-blind-safe status (badge carries a shape/label, not color alone); reduced-motion support (the waiting-pulse and stdout scroll respect prefers-reduced-motion); screen-reader names on cards, badges, and controls.

E. Prototype-first boundary & build order

E1 · from artifact
Prototype scope = S3 board (6–8 mixed-state cards + empty state + connection-lost banner) · S4 modal end-to-end (incl. tool-unavailable path) · folded detail for both renderings (CLI xterm.js stub + API structured stream) · 3-breakpoint responsive proof · the approval round-trip. Data is fixture/fake; real tunnel/auth/push/terminal backend are visually mocked, not implemented.
E2 · from prompt + Gate D/H
Build order is UI-interview FIRST (this mockup + an approve/reject/retry decision), THEN /prototype (build all 5 variations serially), THEN /uat --variant-evaluation, then /consolidate. Downstream routing stays gated until V2's UI direction is approved here.

F. Open questions this interview must resolve

The V2 spec (§23) left these for the UI interview. Each carries a researched recommendation — accept it, override it in free text, or ask for clarification.

O1 · open input
Card dimensions & stdout-preview line count?

Recommendation: ~220–280px tall on desktop, 4-line stdout preview (range 3–5), monospace ~12px, fade-truncated at the bottom. Trades a touch of fleet density for richer per-card glance.

O2 · open input
Detail side-rail width & collapse behavior?

Recommendation: ~24% width on desktop (range 20–30%), collapsible on tablet, and collapses below the primary region at ≤640px (terminal/stream goes full-width on phone).

O3 · open input
Light filtering affordance on the board — yes/no, and how much?

Recommendation: a single optional chip row (status filter + repo filter) only — heavy/faceted filtering is V1's territory; V2 leans on big legible cards + sort. Alternative: sort-only, no filter chips to keep the control maximally simple.

O4 · open input
Mobile terminal ergonomics — the "open on desktop" handoff?

Recommendation: on phone the CLI terminal is read-mostly with a hint like "Heavy typing? Open on desktop →"; structured (API-native) detail stays fully usable on phone. Confirm the posture and the exact handoff copy.

O5 · open input (free text)
Anything the V2 mockup must nail or avoid — or any constraint the flow-map / V2 spec didn't capture?

Open floor. Examples: a reference dashboard whose feel you want matched (the spec names Vercel / Railway / Render / CI dashboards — override if you have a different north star), a pet peeve to avoid, a must-have interaction, or a real constraint I can't infer.

Interview areas this round touches

Compile responses

Aggregates every assumption decision (with corrections) and every open answer into one YAML payload. You don't have to answer all of them — partial is fine; round_status reflects whether everything was touched. Paste the result back to me.