UI Interview — Round 2: Coverage Checkpoint
Stage-zero interrogation · exit gate · Branch V2 Card Mosaic (baseline / control) · Parent flow monitoring-start
Where we are. Round 1 (the assumptions manifest) is answered and consumed — you confirmed
14 assumptions, corrected the build-scope (E2), and accepted all four open-question recommendations
(O1–O4) with a free-text note (O5). The confidence gate has passed: every interview area is covered.
This page is the exit gate — it restates everything I'm now locking in, with the scope correction
called out first. Confirm it's complete (or flag a gap) and I advance to designing V2's visual mockup.
Nothing here reopens the four UX axes — those stay fixed at the flow-map default per A3.
Contents
Coverage status
Interview areas covered
17 / 17 — 100% Covered
Product & user context · parent flow & branch role · sibling coordination · pages/routes · navigation · hierarchy · grid & density · component inventory · control/link semantics · form/validation · empty/loading/error/success states · responsive · accessibility · visual language · prototype-first boundary · card/rail sizing · filtering & mobile-terminal copy. No area left open.
The scope correction (E2) — please confirm my reading
You corrected E2. Here is how I'm interpreting it.
What E2 originally assumed: build order is UI-interview first, then /prototype
builds all five variations serially, then /uat --variant-evaluation, then
/consolidate.
Your correction — "build just this variation": this run is scoped to V2 Card Mosaic only.
Concretely, that means:
- This
/ui-interviewproduces V2's visual mockup + one approve/reject/retry decision — and stops there. - I will not plan, spec, or build V1/V3/V4/V5 in this run, and I will not auto-route into a
five-variation
/prototypesweep,/uat, or/consolidate. - Per your O5 note, V2 is the calibration case: "this v2 mockup will calibrate how I deal with all the other variations." Once you see V2's mockup land, you decide how (and whether) the siblings follow — each sibling gets its own treatment later, informed by what V2 teaches us.
- The four UX axes still stay fixed at the flow-map default (A3); narrowing scope does not reopen them.
Is that the right reading of "build just this variation"?
What's locked in (round-1 decisions)
Everything you confirmed in round 1, restated as the decisions the mockup will honor.
A · Scope & branch role
| Item | Locked decision | Status |
|---|---|---|
| A1 Branch role | V2 is the baseline / control — tracks the flow-map most literally, "boringly competent," the yardstick the other four are measured against. | confirmed |
| A2 Screens in scope | Exactly three: S3 Agent Board, S4 Start Agent (modal), folded S5/S6 Detail. S9/S8/S10 linked but not designed in depth. | confirmed |
| A3 Four axes fixed | Card grid · full-page detail route · modal launch · co-equal responsive — fixed at flow-map default, not reopened here (axis changes = /ux-variations). | confirmed |
| A4 Folded detail | One tool-adaptive route: terminal-primary (xterm.js) for CLI, structured-primary for API-native. No Mode A/B toggle. Mode C / IDE out of scope. | confirmed |
| A5 Single-user | Sharing / collaboration / permissions / multi-tenant are N/A, documented as such. Only "handoff" is the same user across their own devices. | confirmed |
B · Pages, routes & navigation
| Item | Locked decision | Status |
|---|---|---|
| B1 Route map | / board (hub) · /agents/:id folded detail. S4 modal & S8 recap are overlays, not routes. Deep links fall back to board. Browser back is first-class. | confirmed |
| B2 Card → detail | Whole card is the click target → full-page detail; board unmounts (V2's defining choice + main risk). Back to Board re-reads server-canonical state. Launch never navigates. | confirmed |
| B3 Header & sort | Persistent header: app name · approval-queue badge · Start Agent · QR/"Open on Mobile" · settings gear. Default sort error > waiting > running > idle; waiting re-sorts to top. | confirmed |
C · Components, density & hierarchy
| Item | Locked decision | Status |
|---|---|---|
| C1 Agent Card anatomy | Top→bottom: name + status badge · tool·repo(·branch) · elapsed·tokens · live stdout preview (monospace, auto-scroll, fade-truncated) · conditional error/completion strip. | confirmed |
| C2 Density & grid | Comfortable, not dense. 3 cols >1024 · 2 cols ≤1024 · 1 col ≤640, columns capped at large widths. Accepted tradeoff: ~12 agents scroll. | confirmed |
| C3 Color discipline | Color reserved almost entirely for status (green/amber/red/grey); chrome grayscale; accent #4dabf7 only for primary CTA + links. Dark house palette; terminal slightly darker. | confirmed |
D · States, responsive & accessibility
| Item | Locked decision | Status |
|---|---|---|
| D1 State coverage | Cards (starting/running/waiting-pulse/error/idle/completed + hover/focus); board (empty, connection-lost banner); modal (loading skeleton, validation gate, launching spinner, inline error, tool-unavailable); detail (reconnecting overlay, inline approval). | confirmed |
| D2 Accessibility | Baseline-by-default: logical keyboard order & focus mgmt; ≥44px targets; color-blind-safe status (shape/label, not color alone); reduced-motion respected; SR names on cards/badges/controls. | confirmed |
E · Prototype-first boundary & build order
| Item | Locked decision | Status |
|---|---|---|
| E1 Prototype scope | S3 board (6–8 mixed-state cards + empty + connection-lost) · S4 modal end-to-end (incl. tool-unavailable) · folded detail for both renderings · 3-breakpoint proof · approval round-trip. Fixture data; tunnel/auth/push/terminal backend mocked, not built. | confirmed |
| E2 Build order / scope | Build just V2. This run = V2 mockup + approve/reject/retry, then stop. No five-variation sweep, /uat, or /consolidate here. V2 calibrates the siblings (see §scope above). | corrected |
Open questions — now resolved (O1–O5)
| Q | Resolution (your decision) | Status |
|---|---|---|
| O1 Card size & preview lines | ~220–280px tall desktop, 4-line stdout preview (3–5 range), ~12px monospace, fade-truncated. | accepted |
| O2 Detail side-rail | ~24% desktop (20–30%), collapsible on tablet, collapses below primary region ≤640px (terminal/stream full-width on phone). | accepted |
| O3 Filtering affordance | Single optional chip row (status + repo filter) only — no faceted filtering. Board leans on big legible cards + sort. | accepted |
| O4 Mobile terminal | Phone CLI terminal is read-mostly with "Heavy typing? Open on desktop →" handoff; structured (API-native) detail stays fully usable on phone. | accepted |
| O5 Open floor | "All looks good, this v2 mockup will calibrate how I deal with all the other variations." → folded into the E2 scope reading above. | free-text |
Carried-forward risks (not blockers)
These are flagged as evaluation criteria, not resolved here, and they travel with V2 into the mockup and prototype:
- Cards waste space at scale — ~10–12 agents scroll; no single-screen overview (the reason V1's dense table exists). Mitigated by column cap + sort-to-top.
- Route-switch drops board context — drilling in unmounts the board. Mitigated by fast back + lossless server state + deep links.
- stdout-preview reliability — leans on Multica-style stdout parsing (flow-map Open Q #2); treated as best-effort tail, not a structured promise.
- Terminal latency — sub-100ms keystroke echo over the tunnel unproven (Open Q #1); phone detail is read-mostly with desktop handoff.
- "Generic" risk — being the familiar control, V2 can lose an evaluation by being merely fine. That's accepted; its job is to be the yardstick.
Exit gate — confirm or flag gaps
Is the coverage above complete and correct — ready to design V2's visual mockup?
Open floor before the mockup (optional) — anything to add, emphasize, or constrain?
Compile responses
Aggregates the scope-confirmation, the exit-gate decision, and any free-text into one YAML payload. Paste the result back to me. If you confirm, I advance to designing V2's mockup; if you flag a gap, the loop continues with another round.