wifi-densepose/frontend
ruv 858a3d9eb5 feat(homecore-ui): Dashboard page + seed script — UI is no longer empty
Before: `<hc-app-shell>` was a layout-only component with an empty
`<slot>` (the auditor flagged it as "scaffold + no dashboard page");
operators saw the appbar + nav + footer but nothing in `<main>`.

After: three small additions wire the existing components to real
backend data.

  frontend/src/pages/Dashboard.ts (~110 LOC) — new Lit `<hc-dashboard>`
    - Reads bearer from localStorage / ?token= / <meta name=> / falls
      back to "dev-token" (matches the DEV-token mode the backend
      reports when HOMECORE_TOKENS is unset)
    - Calls client.getConfig() + client.getStates() on mount
    - Renders a `.meta` line (location · version · entity count) plus
      a responsive grid of `<hc-state-card>` from the live state list
    - Polls /api/states every 5 s for live refresh
    - Surface a structured error block if the backend is unreachable
      so operators see WHAT broke rather than a blank page

  frontend/src/main.ts (+9 LOC) — appends `<hc-dashboard>` into the
    `<hc-app-shell>` slot on DOMContentLoaded

  scripts/homecore-seed.sh (+95 LOC, executable) — POSTs 10
    representative entities to the HA-compat `/api/states/<id>`
    endpoint so a fresh `homecore-server` boot has demo content.
    Live numbers from RuView's sensing-server when RUVIEW_URL is
    reachable (sensor.living_room_presence / bedroom_breathing_rate /
    bedroom_heart_rate); plausible defaults otherwise.

Empirical (after `bash scripts/homecore-seed.sh` against a fresh
homecore-server on :8123, browser at http://localhost:5173):

  .meta:  "Home | HOMECORE v0.1.0-alpha.0 | 10 entities"
  grid :  10 <hc-state-card> elements rendered, e.g.
            binary_sensor.front_door  off    updated 12:17:34
            switch.coffee_maker       off    updated 12:17:34
            sensor.living_room_motion_score  0.0  updated 12:17:33
            …
  curl :  GET /api/config  → 200
          GET /api/states  → 200 (returns array of 10)

The dashboard now provides real value-vs-empty-page proof that the
frontend ↔ HOMECORE-API chain is wired end-to-end.

Co-Authored-By: claude-flow <ruv@ruv.net>
2026-05-26 12:26:02 -04:00
..
src feat(homecore-ui): Dashboard page + seed script — UI is no longer empty 2026-05-26 12:26:02 -04:00
.gitignore HOMECORE: native Rust/WASM/TS port of Home Assistant — ADRs 125-134 implementation (#800) 2026-05-25 22:47:48 -04:00
README.md HOMECORE: native Rust/WASM/TS port of Home Assistant — ADRs 125-134 implementation (#800) 2026-05-25 22:47:48 -04:00
index.html HOMECORE: native Rust/WASM/TS port of Home Assistant — ADRs 125-134 implementation (#800) 2026-05-25 22:47:48 -04:00
package-lock.json HOMECORE: native Rust/WASM/TS port of Home Assistant — ADRs 125-134 implementation (#800) 2026-05-25 22:47:48 -04:00
package.json HOMECORE: native Rust/WASM/TS port of Home Assistant — ADRs 125-134 implementation (#800) 2026-05-25 22:47:48 -04:00
tsconfig.json HOMECORE: native Rust/WASM/TS port of Home Assistant — ADRs 125-134 implementation (#800) 2026-05-25 22:47:48 -04:00
vite.config.ts HOMECORE: native Rust/WASM/TS port of Home Assistant — ADRs 125-134 implementation (#800) 2026-05-25 22:47:48 -04:00
vitest.config.ts HOMECORE: native Rust/WASM/TS port of Home Assistant — ADRs 125-134 implementation (#800) 2026-05-25 22:47:48 -04:00

README.md

@ruvnet/homecore-frontend

HOMECORE web UI — built with Lit 3, TypeScript, and Vite. Design system mirrors the cognitum-v0 / v0-appliance dashboard (ADR-131).

Quick start

cd frontend
npm install
npm run dev          # http://localhost:5173

The Vite dev server proxies /apihttp://localhost:8123, so you need a homecore-api-server (or the wifi-densepose-sensing-server crate) running on :8123.

Scripts

Script Description
npm run dev Start Vite dev server on port 5173
npm run build TypeScript compile + Vite production bundle → dist/
npm run lint ESLint on src/
npm test Vitest unit tests (3 suites, jsdom)

Package layout

frontend/
  src/
    api/
      client.ts        # fetch + WebSocket client (REST + WS)
      types.ts         # TypeScript types matching homecore-api JSON shapes
    components/
      AppShell.ts      # <hc-app-shell> — header + nav + content slot
      StateCard.ts     # <hc-state-card> — single entity state card
    icons/
      lucide.ts        # Tree-shaken Lucide icon wrapper
    styles/
      tokens.css       # 16 CSS custom properties (--hc-*)
      base.css         # Typography reset, page shell, nav layout
    __tests__/         # Vitest unit tests
  index.html           # Shell loading src/main.ts
  vite.config.ts
  tsconfig.json
  vitest.config.ts

Design system

Colors, typography, and components mirror the cognitum-v0 dashboard (http://cognitum-v0:9000/). Dark-only; no light-mode. Key tokens:

  • --hc-primary #19d4e5 — teal (active nav, focus ring, CTA borders)
  • --hc-accent #26d867 — green (success, secondary CTA)
  • --hc-bg #0b0e13 — near-black navy page root
  • Font: Outfit (display) + JetBrains Mono (mono)
  • Icons: Lucide (SVG, stroke: currentColor, no icon font)

See docs/design/HOMECORE-FRONTEND-design-recon.md for the full recon.

Architecture notes

  • Components are standard Lit LitElement custom elements — compatible with any HTML page and with Home Assistant's Lit-based frontend.
  • The REST client uses fetch; the WS client uses WebSocket. Both accept a bearer token and are fully typed against the Rust homecore-api JSON shapes.
  • WASM: vite.config.ts enables .wasm asset import. Hook up via dynamic import('/path/to/module.wasm?init') when WASM bindings are ready.