Skip to content

R7 · UI review

Done 2026-10-26 · 40 findings: 0 blockers, 22 majors, 18 minors · 0 dropped · 10 questions for Thomas

What changed

  • New review file: docs/reviews/R7-ui.md. It holds:
    • the 40 findings UX-201 to UX-240, ranked by severity, each with its evidence (board lines, render crops, spec passages), a proposal and Status: open;
    • a findings table with the boards and specs each finding touches, and the reviewers' draft IDs;
    • 10 questions for Thomas;
    • 4 proposed spikes (S-R7-1 board lint, S-R7-2 shared board fixture, S-R7-3 live data on a phone, S-R7-4 summary endpoints at scale), plus a pointer to the existing spike T2.
  • No spec and no board was edited. This is a review round (see the review rules in docs/reviews/README.md). The prompt asked the reviewers to propose the missing sign-in boards; the proposals are in UX-203, UX-204 and UX-202, not as new boards.
  • The file was committed on autopilot/integration in ad6bc9b, together with the other W1 review files, the nav entry and map.md.

Why

The UI boards in design/ui-canvas/ are the reference for the future front end. Before any code, they need the states the specs define (loading, empty, error, no permission, degraded), accessible controls, and one consistent set of colours and words. The sign-in flows of authentication §5 had no boards at all.

Prompt: next-phase.md · R7. It asks for three ux-reviewer instances in parallel, every board rendered before it is judged, and proposals for the missing sign-in boards. Decisions:

Evidence

How the round ran (from the round's header in the review file):

Item Value
Commit read autopilot/integration at 3b209d3; every line number in the file refers to it
Reviewers ux-reviewer, three instances in parallel. All three returned a full report; none failed.
Scope (a) desktop core boards (Overview, Runs, RunDetail, RunScheduler, Review*, Launch*) and the sign-in flows: 64 boards rendered at 1440×1180, RunScheduler also at 1440×2000
Scope (b) Workflows*, Environments, EnvStorage, EnvKubernetes, EnvCapacity and the Administration boards, with tall renders of 8 boards
Scope (c) the 13 phone boards (M*.dc.html) and the shared MobileTopbar and MobileTabbar, rendered at 390×844
Read the 106 files in design/ui-canvas/, design/tokens/spectio-tokens.css, the UI, auth, API, admin, schedulers and checking specs, decision 0001, the decision log, and the depictio auth research note
Renders scratch PNGs in /tmp/w1-scratch/, not committed; the file gives the command to re-render them
Merge 61 raw findings (16 + 24 + 21); 21 merged as duplicates within the round, giving 40. Renumbered UX-201 to UX-240 in rank order, after R12's UX-101 to UX-129; draft IDs (a2nn, b2nn, c3nn) kept in the table's last column.
Merger's check every quoted board line and spec passage of every major was opened at 3b209d3. All reproduced, so 0 findings were dropped. The nine contrast ratios were recomputed with the WCAG 2.x formula; all match.
Corrections during the merge 7 Merge notes, mostly severity disagreements between reviewers (for example UX-202, UX-213), one moved part (UX-215 to UX-201) and one scope cut (UX-222: no docs/assets/shots/ media comes from the five boards)
Earlier rounds open findings of R1, R5 and R12 are cited, not repeated (for example R12 UX-103, R1 SR-041, R5 SEC-104 and SEC-117). Findings that touch them carry a Related line, so both are triaged together.

Counts, checked against the file's headings:

$ for s in blocker major minor; do printf "%s " $s; grep -c "^### UX-[0-9]* · $s ·" docs/reviews/R7-ui.md; done
blocker 0
major 22
minor 18
$ grep -c '^| UX-' docs/reviews/R7-ui.md
40
$ grep -c '^- \*\*Status:\*\* open' docs/reviews/R7-ui.md
40

These match the summary table in the file (total 40, dropped 0) and the merge summary returned by the step's workers (0 blockers, 22 majors, 18 minors, 0 dropped).

Exit criterion. R7 is done when its review file exists, so that TRIAGE1 can read it:

$ ls docs/reviews/R7-ui.md
docs/reviews/R7-ui.md

Figures and media

None required (review step).

Findings and open questions

The five findings that matter most (as ranked in the review file's summary):

  1. UX-222 · major: five boards (RunScheduler, RunObserved, Profile, WorkflowsCatalog, WorkflowDiscovered) still show the Tower protocol or -with-tower, contrary to decision 0001, including copyable commands. Only the boards need changing: none of the docs/assets/shots/ media comes from them.
  2. UX-203 · major: the sign-in page, the magic-link "Continue as" confirmation and their error states have no board, on phone or desktop. API §5 does not name the exchange or logout endpoints. Wording parity with depictio for single mode is [to be validated].
  3. UX-204 · major: share links have no landing page and no "Create link" tab, and the API cannot list or revoke them. ShareDialog's "Copy link" is a plain URL that only members can open. Related to R5 SEC-117.
  4. UX-201 · major: no viewer, launcher, guest, link-guest, unnamed-reviewer or non-admin variant exists. The finding proposes a hide-or-disable-with-reason rule and allowed_actions on runs and gates. Related to R5 SEC-104.
  5. UX-205 and UX-211 · major: no board has a loading, error, stale or empty state, including a fresh single-user spectio serve and the degraded states the specs define (head silent, stale layer, runner offline, SSE reconnect). The UI spec §10.2 fix is already in R1 SR-041.

Questions for Thomas. The full wording is in the review file. In short:

# Topic Question
1 Launch flow (UX-216) One parameters page with a progress stepper and a final "Review and launch" step, or a true wizard as UI spec §2 says?
2 Workflow catalogue (UX-217) Per project (recommended for the MVP) or per instance with workflow_grants?
3 Share links (UX-204, R5 SEC-117) May only owners create them, or owners and editors? Can a link guest decide a gate whose policy names a group?
4 OIDC phasing (UX-202) Is OIDC in 0.1? Profile says "SSO via OIDC in phase 2"; auth §0 has no phasing.
5 MVP scope on boards (UX-227) Is a manual "Send to depictio" in 0.1? Should boards carry phase chips for 1b features?
6 Phone notifications (UX-210) Web Push through a PWA, or only email and Slack?
7 Maintenance (UX-229) Remove the board's "Keep runners executing" option, or add a "stop clusters" mode to admin §4.4?
8 New endpoints (UX-202, UX-208) Do the session, sign-in-test, outbox and audit endpoints go in API §5 or admin §5? R1 SR-013 raises the same duplication.
9 Phone launch (UX-234) MLaunch "Next" with an open issue: disabled with the reason, or allowed with a warning?
10 Canvas conventions (UX-219) May the keyboard rules for boards be added to the canvas conventions in CLAUDE.md? That change needs Thomas's approval.

Next. TRIAGE1 sorts these findings with the triage policy, together with the related R1, R5 and R12 findings. It moves the questions it cannot settle to the inbox. APPLY1 then changes the specs and adds the decision-log entries; the board changes follow in a later UI step.