6.3.5 Dashboards UI at /dashboard — list/create/switch, the grid (view/edit, layouts, dnd), widget add/config/remove, the three widget renderers + all states

Estimate: 38m · Depends on: 6.3.1, 6.3.2, 6.3.3, 6.3.4

The dashboard surface, per the 6.3.3 design, replacing the 1.1.2 smoke landing at /dashboard (its projects-empty branch moves with it — the page-comment contract).

Build: the dashboards home (list mine + workspace-shared with owner/access badges, create modal, empty state, switcher); the grid — view vs edit mode, the 1/2/3-column layout picker, widget Card chrome, drag between/within columns via the 3.2 dnd-kit vocabulary (server-computed fractional positions through the 6.3.1 move endpoint; optimistic with rollback — the board pattern), the add-widget picker, per-type config panels DRIVEN BY THE REGISTRY (the UI renders registry editor kinds — it never hard-codes the widget-type list; a registry addition appears with zero UI changes), remove w/ confirm, the 20-widget cap state. The three renderers consume the 6.3.2 reads: filter-results (the compact 2.5-vocabulary table + pager, ≤50/page), distribution (the 6.3.4 donut), created-vs-resolved (the 6.3.4 difference/area) — each wrapped in the designed loading / error / empty / no-access / stale states (per-widget isolation: one failing widget never takes down the grid). Owner-only edit affordances; viewers get the read-only grid. Strings via next-intl (the threading pattern).

A11y: widgets are labelled regions; the grid is keyboard-traversable; drag has the dnd-kit keyboard path (the 3.2 precedent); config panels are proper dialogs; charts expose their hidden tables; extends the strict sweep.

Acceptance criteria

• The surface matches the design panel-for-panel (home, grid view/edit, layouts, dnd, picker, all three config panels, all three renderers, every widget state); drag persists + survives reload; the cap + confirm flows work.
• Config panels render from the registry (asserted with a test-only registry entry); the data-source XOR is enforced in the UI; stale + no-access render per design (and never leak data).
• Owner/viewer affordance split holds; private dashboards invisible to others (route + UI).
• Axe-clean; token tiers only; next-intl; integration tests over the grid wiring, registry-driven panels, optimistic move + rollback; coverage ≥90%.

Context refs

• design/reports/dashboard.mock.html + notes (6.3.3) — THE authority
• 6.3.1 (CRUD/move API + registry UI contract); 6.3.2 (the widget reads); 6.3.4 (the chart forms)
• The 3.2 board dnd + optimistic-move pattern; portal-popover-breaks-in-radix-dialog (config-panel pickers)
• app/(authed)/dashboard/page.tsx (the smoke landing this replaces — keep the projects-empty branch); the i18n threading pattern