Skip to content

HUE-054 — Implement the HUE Svelte component foundation with shadcn-svelte

Canonical source: docs/roadmap/issues.json · HUE-054

Specification status: TBI · Readiness: agent:ready

Establish an accessible, source-owned component and token foundation that feels native across HUE desktop and responsive surfaces without making the library the product identity.

  • Implement the accepted SvelteKit + Svelte 5 + shadcn-svelte direction from ADR-0001
  • Define HUE semantic color, typography, spacing, radius, elevation, density, motion and state tokens as CSS variables
  • Implement buttons, inputs, tabs, menus, tooltips, dialogs, sheets, popovers, command palette, badges, tables and toast primitives
  • Wrap source-owned shadcn-svelte primitives behind HUE component APIs so upstream library changes do not leak through product screens
  • Create dark, light, high-contrast and reduced-motion examples plus desktop and mobile visual-regression fixtures
  • Use the static prototype token and component mapping as the migration fixture
  • Proceed independently of TBD-001 packaging: every shell finalist must host or serve this accepted frontend foundation
  • Implementation follows ADR-0001 and documents source/update ownership
  • HUE tokens—not shadcn defaults—control product identity and semantic task/approval/notification states
  • Keyboard, focus return, screen-reader labels and 44px touch targets pass automated and manual checks
  • Dialogs, menus, sheets and command palette follow platform-appropriate interaction conventions
  • Representative shell, approval and notification fixtures pass dark/light desktop and 390px mobile visual regression
  • No screen imports low-level shadcn-svelte primitives directly outside the HUE component boundary
  • Static-to-Svelte fixture parity is documented before any static screen is retired
  • HUE-001
  • Finalize all screen layouts
  • Copy the stock shadcn theme unchanged
  • Claim OS-native controls where HUE renders web components
  • Select or reopen the TBD-001 application packaging and control-plane decision
  • Migrate all functional prototype screens before their flows stabilize
  • Preserve the documented security, project, memory and event boundaries.
  • Add or update automated tests for every observable acceptance criterion.
  • Provide real verification output; do not rely on a worker/agent self-report.
  • Update only the exact documentation sections whose status changed.
  • Include screenshots or a recording for user-interface changes.
  • Include migration, rollback and recovery notes for data/state changes.
  • Link the pull request to this issue with Closes #<issue-number>.