Dashboard UX/UI design (design-only, merges into future implementation branch)

[m-aebrer]

Closes #311

UX/UI design pass for the dreb web dashboard: static HTML/CSS mockups with committed Playwright screenshots, a TUI feature parity checklist, the full design spec (flows, responsive layout, security UX for the two access modes, frontend architecture recommendation), and acceptance criteria for the future implementation PR.

Non-standard workflow: this branch is never merged to master. Design artifacts iterate here; when the design is accepted, this branch merges into the future implementation branch for the dashboard implementation issue.

Implementation plan posted as a comment below.

[m-aebrer]

Implementation Plan

This is a design PR. No production code will be written.

Problem

The dreb web dashboard (implementation issue 307) needs a UX/UI spec before another implementation attempt. The first attempt (closed draft PR 310) built backend scaffolding plus a vanilla-DOM client with no design pass — the server side was solid, the client was unusable. The assessment on the design issue inventoried TUI capabilities, identified RPC gaps (all since closed by merged sub-issue PRs 315, 316, 317), and the fleet-centric information architecture decision is made. What remains is the actual design work: mockups, the parity checklist, UX flows, security copy, a framework recommendation, and acceptance criteria for the future implementation PR.

Workflow (non-standard, agreed with maintainer)

• This branch (feature/issue-311-dashboard-ux-design) is never merged to master. We iterate here until the design is accepted.
• When done, the future implementation branch (for issue 307) is created and this branch merges into that one — intermediate design artifacts never land on master directly; the implementation PR decides what ships.
• The draft PR exists for review ergonomics: committed screenshots render inline, so the design can be reviewed from any device including mobile.

Deliverables (all under design/dashboard/ on this branch)

1. tokens.css — design-token file forked from the maintainer's pico8_carts/docs gallery CSS (the approved starting template): IBM Plex Mono everywhere, pure #000/#fff with automatic dark mode via prefers-color-scheme, single neutral gray for secondary text, 1px hairline borders as the only separator device, 3px max radius, hover = border-color swap, no shadows/gradients/glow. Explicit hex values, a spacing scale, and status-chip colors (the one place accent color is permitted: running / needs-attention / idle / error). Extended with theme awareness informed by dreb's existing TUI-theme-to-CSS-variable bridge (getResolvedThemeColors in export-html).

2. mockups/*.html — static HTML/CSS mockups (no framework, no build step; realistic fake data), sharing tokens.css:

   • fleet-overview.html + mobile variant behavior — the home screen: sessions grouped by project, per-session status chip, needs-attention items sorted first with visual weight (not color alone), live subagent activity indicators, resume/delete affordances, new-session entry point
   • session-view.html + mobile variant behavior — the drill-in: chat pane structurally modeled on the export-html renderer (markdown, collapsible thinking, per-tool-type tool-call formatting, compaction/branch summaries), composer with explicit mode vocabulary (steer / follow-up / interrupt), abort control that appears only while streaming, task list + suggest-next surfaces, model/thinking switchers
   • pairing.html — remote first-login PIN flow
   • files.html — project file browse, upload, download
   • settings.html — the settings tab over RPC get_settings/set_settings
   • tree.html — session tree inspection and navigation (get_tree/navigate_tree parity)
   • Mobile is designed per-screen (deliberate reduced control surface where warranted, e.g. read-and-steer priority in session view), not just reflowed.

3. capture.mjs — Node Playwright screenshot script (Playwright 1.56.1 + cached Chromium already available on this machine; committed so any future session can regenerate). Captures every mockup at desktop 1440x900 and mobile 390x844 into screenshots/.

4. screenshots/*.png — committed on each iteration so the PR renders the current design state inline.

5. PARITY.md — the TUI feature parity checklist (TUI capabilities mapped to dashboard equivalents — not merely RPC commands). Ground-truth enumeration re-verified against source (assessment inventory as starting point: 26 built-in slash commands, ~35 keybound behaviors, 9 message-stream component types, 9 session-level event types, ~15 TUI-only affordances). Every row gets a disposition: dashboard equivalent (with mockup/spec reference) or out-of-scope with reason. Known out-of-scope candidates: OAuth login flows, session import, JSONL export, reload, dream (no RPC surface).

6. SPEC.md — the design spec:

   • Information architecture and navigation model (fleet overview to session drill-in and back, per the decided direction)
   • UX flows: first launch, local-only use, remote pairing, project selection, session create/resume, chat interaction, subagent monitoring, file transfer, settings, tree operations
   • Responsive layout plan (desktop/mobile breakpoints, what changes per screen)
   • Interaction design: prompts, steering, follow-up, abort, live tool calls, task lists, suggest-next, background subagents, extension UI requests (select/confirm/input/editor rendered as modals) — including concrete definitions of the composer modes (steer vs follow-up vs interrupt)
   • Security UX copy for exactly two modes: (a) local-only — server binds loopback only, works with no Tailscale installed, no LAN access at all; (b) remote — requires Tailscale, identity/device allowlist plus short-lived PIN pairing. No third "LAN mode" exists. Dangerous-capability copy: file upload/download, filesystem browsing, agent control. (Per the maintainer's clarification comment on the implementation issue.)
   • Foundation scope: what the first implementation must establish (server skeleton, auth, event pipeline, chat renderer) vs what sequences later — explicitly carrying forward the closed draft PR's fail-closed auth, path-safe file API, and RPC runtime-pool design as endorsed server-side constraints, and the export-html renderer as the chat-pane structural reference
   • Frontend architecture recommendation with rationale and rejected alternatives
   • Acceptance criteria the implementation PR will be reviewed against

Design inputs already gathered (subagent research, this session)

• Closed draft PR postmortem: server side (auth tiers, file path-safety, runtime pool keyed by cwd+session, SSE fanout, typed event reducer) is good prior art the spec endorses; client (plain-pre chat, no markdown, full-DOM re-render, desktop-only CSS) is the failure the mockups replace.
• export-html renderer (packages/coding-agent/src/core/export-html/): mature rendering of every entry type with theming from TUI themes and vendored marked/highlight.js — the structural reference for the session-view chat pane, needing only live-event adaptation (an implementation concern, noted in foundation scope).
• Current RPC surface (post merged sub-issue PRs): a pure-RPC client covers all core flows — fleet listing, delete, tree, settings. No hybrid SessionManager import needed.
• External research: fleet IA patterns (group-by-project; needs-attention as a first-class boolean driving sort order and notification, per Omnara; status-as-column per Vibe Kanban), mobile steering vocabulary (Happy's three explicit modes: steer-now / queue / interrupt), abort-button state machine (claude-code-webui's input that swaps modes and shows abort only while streaming), anti-slop design guidance (explicit token file over prose; avoid Inter/purple-gradient/glassmorphism tropes).
• Framework shortlist for the recommendation: SolidJS (research favorite: fine-grained signals map to SSE streams, ~7KB, opencode-web precedent), React 19 + Vite (in-house precedent: mDraft is a production Express + dreb-RpcClient + SSE + React app), Svelte (comparable compiled option). Server-side pattern: Express + RpcClient from @dreb/coding-agent/rpc (mDraft-proven) vs the closed draft PR's zero-dependency node:http — spec decides with rationale. Styling: hand-written CSS from tokens.css, explicitly not Tailwind/shadcn (both the anti-slop research and the security-reviewability constraint point the same way).

Iteration stages

1. Skeleton: tokens.css + capture.mjs + fleet-overview mockups (desktop/mobile) → screenshots → review round with maintainer
2. Session view: chat-parity mockups → review round
3. Remaining screens: pairing, files, settings, tree → review round
4. Documents: PARITY.md + SPEC.md distilled from the approved mockups
5. Final pass: re-verify parity rows against source, mark PR ready for design acceptance; issue closed manually on acceptance

Each iteration: edit mockups → run capture → review screenshots with vision (self-correct before pushing) → commit mockups + screenshots → maintainer reviews inline on the PR.

Acceptance criteria (for this design PR)

• Every deliverable listed in the issue exists under design/dashboard/
• All six screens are mocked with committed screenshots at both viewports (where a mobile variant is meaningful)
• PARITY.md has an explicit disposition for every inventoried TUI capability — no unaccounted rows
• SPEC.md security flows present exactly the two modes (loopback-bind local, Tailscale remote + PIN) and include dangerous-capability copy
• SPEC.md recommends one frontend stack with rationale and rejected alternatives, and endorses/adjusts the carried-forward server-side designs
• Foundation scope separates "implementation must establish first" from "sequenced later"
• CI stays green (no production code touched; capture.mjs passes biome)

Testing approach

This is a design PR — no production code, so no unit tests. Verification is:

• The visual loop: Playwright captures at both viewports every iteration, reviewed with vision before each push (the webapp-testing skill is installed globally as a fallback for any dynamic checks; a Python venv can be created if ever needed, though the Node script should suffice for static mockups)
• Spec cross-checks: every PARITY.md row traced to the assessment inventory and re-verified against source; every designed flow checked against docs/rpc.md so nothing is designed against a nonexistent RPC command
• CI: existing lint/type-check/test jobs must stay green — the design directory adds no TS and no package.json changes

Risks and open questions

• Static mockups can't validate streaming feel (token-by-token rendering, spinner states, live reordering of the fleet grid). SPEC.md must flag which interactions need validation in the implementation phase rather than pretending the mockups settle them.
• Parity counts may shift during ground-truth re-verification — the assessment inventory is the starting point, not the authority; PARITY.md becomes the authority.
• Screenshot churn adds binary weight to this branch's history. Acceptable: this branch never merges to master directly, and the implementation PR controls what ships (it can prune screenshots or squash history).
• Framework re-litigation risk in the implementation phase — mitigated by recording the decision rationale and rejected alternatives in SPEC.md, per the assessment's recommendation.
• Design-token divergence from dreb TUI themes: tokens.css starts from the pico8 gallery template (single light/dark palette) while dreb has a full theme system. The spec must state whether the dashboard MVP is fixed light/dark (recommended, simpler) or theme-following (later work), so implementation doesn't guess.

---

Plan created by mach6

[github-actions]

Vitest coverage

Metric	Covered	Total	Coverage
Statements	18518	34610	53.5%
Branches	10095	21478	47%
Functions	2917	5437	53.65%
Lines	16368	30783	53.17%

View full coverage run

[m-aebrer]

Progress Update — all design deliverables complete

Every deliverable from the plan now exists under design/dashboard/. All five iteration stages were completed in one pass; the screenshots below render the current design state for inline review.

What landed

• tokens.css — the design language: IBM Plex Mono, pure #000/#fff with automatic dark mode, one neutral gray, hairline borders as the only separator, 3px max radius, hover = border-color swap, status chips as the sole accent surface (glyph + color, never color alone)
• Six mockups (desktop + mobile behavior each, sharing tokens.css)
• capture.mjs — Playwright script, 18 committed screenshots (6 screens × light desktop / mobile / dark desktop), each vision-reviewed before commit
• PARITY.md — the parity checklist, ground-truth re-verified against source rather than trusting the assessment inventory. Corrected counts: 21 built-in slash commands (not 26 — /exit was removed in v0.52.6), ~74 keybound behaviors (not ~35), 15+ stream component types (not 9), 19 session event types (not 9), 39 RPC commands. Every row has an explicit disposition.
• SPEC.md — IA (fleet-centric with explicit live-vs-disk boundary), UX flows, responsive plan (700px breakpoint, per-screen mobile reduction), composer mode definitions (steer / follow-up / interrupt), security UX for exactly two modes with verbatim dangerous-capability copy, foundation-vs-later scope, frontend recommendation (SolidJS + Vite; Express + RpcClient server, with rejected alternatives), and 10 acceptance criteria for the implementation PR

Fleet overview

Home screen: sessions grouped by project, needs-attention sorts first with filled chip + colored border, live subagent lines, on-disk inventory with resume/delete.

Session view

Chat pane structurally modeled on the export-html renderer: collapsible thinking, per-tool-type cards (edit renders diffs), compaction summaries, streaming cursor. Dock: tasks panel, status line with stop (visible only while streaming, 1 steer queued shown), composer with explicit steer/follow-up toggle and suggest-next chip.

Dark mode:

Mobile (read-and-steer priority — switchers collapse to overflow, tasks default collapsed):

Pairing (remote first login)

Identity echo, single-use expiring PIN, and the two security copy blocks ("why a PIN", "what pairing grants").

Files, settings, tree

Tree with navigate-confirm modal (docked so the tree stays reviewable; bottom sheet on mobile):

Remaining mobile/dark captures are in design/dashboard/screenshots/.

Notable findings (doc bugs found during ground-truth verification, for follow-up outside this PR)

1. Root README and package README still list /quit, /exit — /exit was removed in v0.52.6
2. The events table in the RPC doc omits 5 event types (background agent lifecycle, parent-pause, tasks update, suggest next) that the JSON-mode doc documents correctly
3. buddy_hatch / buddy_reroll RPC commands exist in code but are undocumented

Verification

• CI-safe: no production code, no package.json changes; biome ignores design/ (checked with --error-on-warnings); pre-commit hooks passed (4060 tests green)
• Every screenshot vision-reviewed; layout fixes applied for grid min-width overflow, table column wrapping, and modal placement before commit

Commit: a65fc2b

---

Progress tracked by mach6

[m-aebrer]

Feedback round 1 addressed

Both notes are in, commit 2d1c119.

1. Host-wide file browsing

The files screen is no longer project-jailed. It now browses anywhere the dreb process can read, with:

• places chips for quick jumps (~, /tmp, known project roots)
• breadcrumbs all the way to /
• + new folder on every directory
• ▸ new session here — the make-a-folder-then-start-a-session flow is now first-class: create the folder, then spawn a session with that cwd in two clicks

SPEC.md documents the trust rationale explicitly: a paired device already equals terminal access, so a project jail would be security theater. Paths are still canonicalized (symlink/percent-decode confusion rejected) so the API can't be tricked, and file operations are logged — the boundary is "what the dreb process can read as its Unix user," enforced honestly.

2. Subagent observability — three levels + the RPC gap named for implementation scope

• Fleet card: running/done counts + live agent lines (already present, counts refined)
• Session subagent strip (new, in session-view): one clickable chip per background agent above the status line, plus "all subagents →"
• Subagent drill-in view (new mockup, subagent-view.html): read-only live session view — parent task as first entry, streaming transcript, tool cards, elapsed/status in the bar, and no composer. A fixed note says: "viewing live — subagents can't be steered yet; the parent session controls this agent."

On the plumbing gap — verified against source before designing: background_agent_start events carry only agentId/type/task-summary (no session path), the background registry has no RPC command, and the child's JSONL event stream is consumed privately by the parent and discarded. Per your note, SPEC.md now prescribes the sane architecture as implementation-PR scope rather than a workaround:

1. Registry exposure — extend the background-agent registry with the child's session path (derivable at spawn: the parent creates the session dir itself) and expose it over RPC (list_background_agents; enriched start events)
2. Event relay — the parent already parses every child JSONL event in its stdout reader; re-emit them namespaced by agentId on the parent's event stream, fanned out over the same SSE pipeline as everything else. One transport, no file tailing, no polling — file tailing is explicitly rejected in the spec (races the writer, no path to control)
3. Steering (future, post-MVP) — child stdin is currently "ignore"; steering means opening a control channel and forwarding steer commands down. The relay's agentId addressing is designed so steering reuses it — the read-only note in the drill-in view gets replaced by a composer at that point, and only at that point

Acceptance criteria updated: subagents get their own criterion (item 6), files criterion reworked (item 5), and the §5a section includes an honest-degradation rule — if the relay slips, chips lose their click target rather than shipping a broken viewer.

---

Progress tracked by mach6

[m-aebrer]

Code Review

Design-only PR: review focused on factual accuracy of design-doc claims against source, internal consistency, mockup/CSS quality, and simplification. Error-auditor and test-reviewer were not run (no error-handling logic or testable production code in scope).

Critical

None.

Important

None.

Suggestions

Finding 1 — Needs-attention status chip fails the WCAG AA contrast the spec itself promises (medium, confidence 90)
design/dashboard/tokens.css (.chip-attention / light-mode --status-attention), asserted by SPEC.md section 9 criterion 9. The spec requires "WCAG AA contrast for text and status pairings," but the one filled chip — needs-attention, the highest-priority status — renders white text on #b36e00 at 4.08:1. The chip text is 12px at weight 600, which does not qualify as WCAG large text, so the threshold is 4.5:1. Since criterion 9 also says tokens.css is "adopted unmodified," this ships as-is and violates the same document's own acceptance criterion. Light-mode running-chip green (#00871f, 4.68:1) clears AA only narrowly. Dark-mode pairings all pass comfortably (10.5–12:1). Fix: darken light-mode --status-attention to ~#8a5400 (≈5.3:1) or use --text as the filled-chip foreground.

Finding 2 — Session-event count arithmetically wrong: claims 19, source has 21 (low, confidence 90)
design/dashboard/PARITY.md ground-truth table + section 5 header. PARITY states "19 (12 AgentEvent + 7 session)". Source: AgentEvent has 12 members (correct), but AgentSessionEvent in agent-session.ts adds 9 session-specific types, not 7 (auto_compaction_start/end, auto_retry_start/end, background_agent_start/end, parent_paused_for_background_agents, tasks_update, suggest_next). Total is 21. The "7 session" parenthetical also contradicts PARITY's own section 5 table, which enumerates all 9. Coverage is unharmed — every event is dispositioned — but a doc whose headline is "ground-truth counts re-verified against source" carries a wrong headline number.

Finding 3 — Tree screen classified ✅ dashboard in PARITY but "sequenced later" in SPEC section 7 (low, confidence 85)
PARITY.md marks every tree-related row ✅ (/tree, double-escape → tree/fork, session tree/fork keys, get_tree/navigate_tree), but SPEC section 7 lists the tree screen under "Sequenced later (non-blocking)." PARITY's legend defines 🔜 precisely for this case and uses it correctly for other section-7-deferred items (scoped-models, multi-select copy, shell passthrough); tree is the outlier. This bites because acceptance criterion 4 says every PARITY ✅ row must be implemented or re-dispositioned in the implementation PR — an implementer following it would build the tree screen in the foundation PR, directly contradicting section 7. Fix: reclassify the tree rows as 🔜, or move tree into foundation scope.

Finding 4 — RPC command count off by one: claims 39, request union has 40 (low, confidence 82)
design/dashboard/PARITY.md ground-truth table. The RpcCommand request union in modes/rpc/rpc-types.ts has 40 distinct request types — the count of 39 misses get_version, which PARITY section 8 itself lists as used ("get_version | Footer"). Trivial, but another "re-verified count" that disagrees with source.

Finding 5 — Inert hint class on the tree modal's footnote paragraph (low, confidence 85)
design/dashboard/mockups/tree.html line 304: <p class="hint muted small"> — no .hint rule matches this element (the only .hint selectors require .field or .option ancestors, absent here). All rendered styling comes from muted and small. Every other .hint in the mockups sits correctly inside a matching container; this is the one stray token. Removing it changes nothing visually.

Below-threshold note (a11y, non-blocking): the composer send-mode role="radiogroup" in session-view.html wraps plain <button>s without role="radio"/aria-checked — cosmetic in a static mockup, worth fixing when it becomes real components.

Strengths

• The factual spine of both design docs checked out against source. Verified correct: 21 built-in slash commands with /exit genuinely gone; buddy_hatch/buddy_reroll exist over RPC and are genuinely undocumented in docs/rpc.md; get_last_assistant_text exists; navigate_tree has the label? param; the prompt RPC carries images?. Every SPEC section 5a subagent-plumbing claim verified: BackgroundAgentInfo has no session path, getBackgroundAgents() has no RPC command, subagent stdin is "ignore", child JSONL is consumed privately in the stdout reader, getSubagentSessionsDir()/discoverSessionFile() exist.
• Security copy in pairing.html/files.html matches SPEC section 6 verbatim; the subagent drill-in correctly has no composer; the two-mode security model is presented with no third mode anywhere.
• Mockups are clean semantic HTML (lang, title, viewport, real <button>s, <details>/<summary>, ARIA roles) and honor the "glyph + color, never color alone" promise throughout.
• Completeness: every deliverable delivered. All nine issue deliverables, all plan-comment promises (including feedback round 1's host-wide files and three-level subagent observability), and all seven issue acceptance criteria verified present and substantive. 7 mockups × 3 captures = 21 screenshots, all present.
• tokens.css has no dead tokens (all 24 custom properties used); unused primitives (.card, .input, .field, …) are deliberate provisioned design-system surface for the implementation. CSS duplication between session-view and subagent-view was diffed — identical, deliberate reduction, no accidental divergence. capture.mjs is clean and portable.

Agents run: code-reviewer, completeness-checker, simplifier

---

Reviewed by mach6

[m-aebrer]

Review Assessment

Assessing the review posted above: #320 (comment)

The assessor independently re-verified every finding against source — recomputing the WCAG contrast ratios from relative luminance, recounting the event and RPC unions, and checking selector matching in the mockup CSS.

Classifications

Finding	Classification	Reasoning
Finding 1 — needs-attention chip fails WCAG AA that the spec promises	genuine	Independently computed: white on #b36e00 = 4.08:1; 12px/600 text is not WCAG large text, so 4.5:1 applies — it fails. Criterion 9 promises AA for status pairings AND declares tokens.css immutable downstream, so the implementer is told the palette is AA-clean and unmodifiable, which is false. Must be resolved in the design, not deferred.
Finding 2 — session-event count 19 vs actual 21	genuine	Source is unambiguously 12 AgentEvent + 9 session = 21. PARITY's own section 5 table enumerates all 9 session events, contradicting its "7 session" parenthetical. In a PR whose headline is "re-verified against source," a wrong headline count directly misleads.
Finding 3 — tree rows ✅ in PARITY but "sequenced later" in SPEC section 7	genuine	By PARITY's own legend, 🔜 is literally the marker for section-7-deferred items, and acceptance criterion 4 couples ✅ to "implement in foundation PR or re-disposition." The two ground-truth docs disagree on whether tree is foundation scope. Low severity, real contradiction.
Finding 4 — RPC count 39 vs actual 40	genuine	Recounted the RpcCommand request union: 40 distinct request types; get_version is the 40th and PARITY section 8 itself lists it as used. Same class of source-verified-count error as finding 2.
Finding 5 — inert hint class in tree.html	nitpick	Confirmed inert (no .hint selector matches the element), but muted small on the same element supply the exact intended styling — rendering is correct, nothing misleads. Trivial one-word cleanup at most.

Counts: 4 genuine · 1 nitpick · 0 false positives · 0 deferred

Action Plan

1. Fix the needs-attention chip contrast (finding 1 — the one medium). Preferred: darken light-mode --status-attention so white-on-fill reaches ≥4.5:1 (a slightly darker amber, e.g. ~#8a5400, clears it while preserving the filled-chip look); alternatives: dark text on the filled chip, or an explicit justified carve-out in criterion 9. Re-capture screenshots after the token change.
2. Correct the session-event count (finding 2). "19 (12 AgentEvent + 7 session)" → "21 (12 AgentEvent + 9 session)" in the ground-truth table, and update the section 5 heading; sweep for any other "19".
3. Correct the RPC command count (finding 4). "39" → "40" in the ground-truth table.
4. Reconcile the tree disposition (finding 3). Either re-mark the tree rows 🔜 (consistent with the legend and SPEC section 7), or move tree into foundation scope — make PARITY and SPEC agree either way.
5. (Optional, while touching files) Drop the redundant hint class in tree.html (finding 5).

No tracking issues needed — everything is in-scope for this design PR and cheap to fix now. Note the review also independently confirmed the docs' three claimed upstream doc bugs (stale /exit in READMEs, missing event types in the RPC doc events table, undocumented buddy_hatch/buddy_reroll) — those are follow-ups outside this PR as already noted in the progress comment.

---

Assessment by mach6

[m-aebrer]

Progress Update — all 5 review findings fixed

All four genuine findings plus the nitpick from the assessment are addressed:

• Finding 1 (AA contrast): light-mode --status-attention darkened #b36e00 → #8a5400 in tokens.css. Verified by computing all 11 status pairings against WCAG relative luminance: all pass — the filled needs-attention chip is now 6.27:1 (was 4.08:1, below the 4.5:1 threshold for 12px/600 text); running green stays at 4.68:1; dark mode untouched (10.5–12:1). The token comment now states the AA guarantee explicitly.
• Finding 2 (event count): PARITY ground-truth table and section 5 heading corrected to 21 (12 AgentEvent + 9 session), matching source.
• Finding 4 (RPC count): corrected to 40 (get_version was uncounted).
• Finding 3 (tree disposition): tree rows re-marked 🔜 later per PARITY's own legend, consistent with SPEC section 7's "sequenced later"; the mixed fork/tree rows annotated so fork stays ✅ while the tree screen follows the section 1 /tree sequencing; the section 8 RPC table notes "RPC ready, sequenced later." Acceptance criterion 4 no longer forces the tree screen into the foundation PR.
• Finding 5 (inert class): stray hint class dropped from the tree modal footnote.

Screenshots re-captured for the affected screens (fleet-overview, pairing, tree at all three variants). Only the four light-mode captures using the attention amber actually changed; the tree captures came back pixel-identical, confirming the removed class was truly inert. Both changed screens vision-reviewed — the darker amber keeps the filled-chip weight and reads clearly.

Pre-commit hooks green (4050 tests passed, biome clean).

Commit: 6a8ae69

---

Progress tracked by mach6

[m-aebrer]

Design accepted — handing off to implementation

Review round complete: the multi-agent review found four genuine issues (WCAG AA contrast on the needs-attention chip, two stale ground-truth counts, a tree-disposition contradiction between the two docs) plus one nitpick — all fixed in commit 6a8ae69. The completeness check verified every deliverable from the design issue, every plan promise, and all acceptance criteria present and substantive.

This design is now the accepted baseline for the dashboard implementation issue (#307).

What happens to this branch and PR:

• feature/issue-311-dashboard-ux-design is frozen as the design source — no further iteration here.
• Per the non-standard workflow in the PR description: the implementation branch merges this branch as its first act. Design artifacts iterate there from then on; the implementation PR decides what ships to master (pruning screenshots or squashing history is sanctioned).
• Cleanest mechanics: once the implementation branch exists, retarget this PR's base to it and merge — that gives a proper merge record. (Alternative: merge the branch directly and close this PR unmerged.)
• This PR goes back to draft now so it can't be accidentally merged to master in the meantime.
• Any post-acceptance change to SPEC.md / PARITY.md / tokens.css happens on the implementation branch — including re-dispositioning parity rows per acceptance criterion 4 (no silent scope shrink).

Handoff brief for the implementation planning session is posted on the implementation issue. The design issue (311) is closed as completed.

---

Progress tracked by mach6