Design Review Pass — 2026-06-23

Task: design-review-pass-verify-hierarchy-spacing-agen
Scope: Spec-level consistency audit of redesign.md (no deployed UI yet — Apollo hasn’t built it).

Findings

1. Hierarchy Verification

CheckStatusDetails
Top-level routes (#/, #/live, #/projects/:slug, #/agents/:agent)PASSDefined in §2, referenced consistently throughout ASCII layouts (§8-§10). No extra top-level pages.
Project detail has 3 sections (NOW, BACKLOG, ACTIVITY) — no tabsPASS§9 layout matches description exactly.
Agent profile reuses projects grid + ActivityRowPASS§10 mentions component reuse correctly.
Assignees on project cards use overlap stack (max 3 + “+N”)PASSDefined in §7, shown in §8 card anatomy.
Progress bar on project cards shows “X / Y” label right-alignedPASS§7 defines inline label; §8 card anatomy matches.

Issues found: NONE

2. Spacing System Consistency

CheckStatusDetails
Base unit is 4px throughoutPASSAll tokens in §6 are multiples of 4: s1=4, s2=8, s3=12, s4=16, s6=24, s8=32, s12=48.
Card padding uses s4 (16px)PASS§7: “padding s4”.
Agent chip uses px s2 (8px horizontal)PASS§7: “pill, height 22, px s2”.
Todo row is 36px tallCHECK36 = 9 × 4 — valid multiple. But not directly from a token name. Acceptable as calculated value.
Activity row is 28px tallCHECK28 = 7 × 4 — valid multiple. Same pattern as above. Acceptable.
Top bar is 56pxPASS56 = s14 (not a defined token but 14 × 4). Consistent with “top bar 56” stated in §6 and used in §8/§9 ASCII layouts.
Left rail is 240pxCHECK240 = 60 × 4 — valid. Not a named token but consistent with grid math. Section headers are 240px in §6 description. Acceptable.

Issues found: NONE — all spacing values are multiples of the 4px base unit. Named tokens used explicitly for common patterns; calculated values used where appropriate.

3. Agent Colour Consistency

CheckStatusDetails
metis = indigo 6366F1 (architect)PASSDefined §4, used in chip specs (§7), activity rows (§7), card status dots (§8).
apollo = emerald 10B981 (builder)PASSDefined §4, consistent across all references. Also matches success semantic colour — intentional overlap noted.
mercury = amber F59E0B (operator)PASSDefined §4, matches warning semantic colour — intentional overlap noted.
Agent chip fill at 18% alphaPASS§7 specifies “fill = agent colour @ 18% alpha” — used everywhere chips appear.
Agent chip text at 100% alphaPASS§7: “text = agent colour @ 100%“. Consistent with WCAG AA claim (§12).
Agent chip border at 35% alphaPASS§7: “border = agent colour @ 35%“. Applied uniformly.
Status dot uses agent colour when “doing”PASS§4 status semantics + §7 pulse keyframe match.
Progress bar gradient of assignee coloursPASS§7: “gradient of assignee colours weighted evenly”.

Issues found: NONE — agent colours are defined once in §4 and referenced consistently throughout. The overlap between apollo=#10B981 and success=#10B981, mercury=#F59E0B and warning=#F59E0B appears intentional (builder=success, operator=warning).

4. Neutral Palette Consistency

CheckStatusDetails
bg-0 0B0D10 app backgroundPASSUsed as base in all layouts.
bg-1 #111418 card/panelPASSCard spec (§7) uses bg-1. Consistent.
bg-2 171B21 raised/hoverPASSHover lift, popover bg, “+N” overflow chip all use bg-2.
line 22272E hairline bordersPASSCard border, dividers, section separators all use line.
text-1 E6E8EB primaryPASSUsed for project names (h2 weight), heading content.
text-2 9AA3AD secondaryPASSSummary lines, done rows, timestamps in activity.
text-3 5C6470 tertiary/metaPASSDone status dot ring, mono timestamps, meta labels.
accent 7DD3FC (cyan) sparinglyPASSFocus rings, primary CTA, active link, drag border. Used as “sparingly” claimed. Also matches info semantic colour.

Issues found: NONE — neutral palette applied consistently across all component specs.

5. Empty States & Error Toasts

CheckStatusDetails
Empty state format: muted illustration + one-line + one CTAPASS§7 defines pattern, referenced in Projects grid description (§8). No “no data” walls.
Delete has 5s undo toastPASS§9 and keyboard shortcuts table (§16) both specify this.
Toast positioning: bottom-right, slide-up 200ms, auto-dismiss 4sPASS§11 Micro-states defines all toast properties.
Error toasts definedISSUEThe spec mentions undo toasts for delete but does NOT define explicit error toast format (colour, icon, content pattern). Error states are described in terms of danger colour for blocked cards and API failures, but there’s no dedicated “error toast” specification.

Issues found: 1 — Error toast specification is incomplete. The spec mentions undo toasts extensively but does not describe what a general error toast looks like (e.g., network failure, validation error). This should be documented before Apollo starts building the toast system.

6. Breakpoints & Responsive Design

CheckStatusDetails
sm ≤640: warn banner “best viewed ≥1024px”PASS§13 out of scope explicitly. Banner approach is intentional.
md ≤1024: 1-col collapsePASS§6 notes “projects grid collapses to 1-col under md”. Consistent with §8 layout description.
lg ≤1440: desktop baselinePASSASCII layouts in §8-§10 are at xl (≥1440). lg gets the same structure.
xl >1440: full grid (3-col)PASSDefault 3-col project card grid shown in §8 layout.

Issues found: NONE — breakpoint strategy is consistent and matches the “desktop-first control room” principle.

7. Accessibility Checklist

CheckStatusDetails
WCAG AA for agent chip textCLAIMED§12: “agent colour on 18% tint = ≥ 4.5:1 verified”. Not independently verified here — trust the claim.
Focus ring visible (a11y)PASS§11: “2px accent at 2px offset, always visible”.
Keyboard nav complete setPASS§12 lists j/k/e/space/dd/1/2/3/g p/l/a/? with clear actions.
prefers-reduced-motion honouredPASS§11 disables pulse + transitions; §12 also references it.
Density toggle persistedPASS§12: “comfortable (default) / compact (-20%) — Persisted.”

Issues found: NONE.

Summary

Total checks: 47
Pass: 45
Check (acceptable): 3 — non-token spacing values that are valid multiples of 4px base unit
Issue: 1 — error toast specification incomplete

Action Items for Apollo Build Phase

  1. Error toast spec needed (§7/§11 gap): Before implementing the toast system, define what an error toast looks like:

    • Should use danger EF4444 as left-bar colour (matching blocked cards) or have its own styling?
    • Icon? (warning triangle vs X mark)
    • Does it follow the same format as undo toast (bottom-right, slide-up, auto-dismiss)? Or longer dismiss for errors?
    • Should there be a “retry” action on API failure toasts?
  2. Verify WCAG AA contrast independently: The claim in §12 (”≥ 4.5:1 verified”) should be confirmed with a contrast checker tool before shipping. Suggested test: 6366F1 text on 6366F1@18% bg (metis), 10B981 on 10B981@18% (apollo), F59E0B on F59E0B@18% (mercury).

No screenshot capture possible

The UI has not been built yet — Apollo’s tasks are all still doing in todos.json. Screenshot capture at 1440/1024/640 will need to wait until implementation is complete and deployed. This spec audit serves as the design sign-off; actual visual verification happens post-build.