First CRUD increment. Click "+ Add entity" on the Dashboard
toolbar → modal opens → form with entity_id / state / attributes
fields → Create validates client-side then POSTs /api/states/<id>
→ modal closes, toast confirms, dashboard refreshes.
New components:
frontend/src/components/Modal.ts (~110 LOC) — reusable accessible
overlay. open property; closes on Escape and backdrop click.
Heading prop; default + footer slots.
frontend/src/components/EntityForm.ts (~130 LOC) — three-field form
with public requestSubmit()/requestCancel() methods. Client-side
validation:
- entity_id matches /^[a-z][a-z0-9_]*\.[a-z][a-z0-9_]*$/
- state non-empty
- attributes parses as a JSON object (rejects array/scalar)
Emits hc-entity-submit / hc-entity-cancel events for host to
handle. Footer buttons live in the host (modal slot=footer).
frontend/src/pages/Dashboard.ts (+60 LOC) — toolbar with
"+ Add entity" button, modal state, POST handler that wraps
fetch with bearer token, success toast (3 s), refresh().
Browser-verified end-to-end (real homecore-server :8123):
- Toolbar button visible: Y
- Modal opens: Y
- 3/3 validation paths fire correctly:
BadID → "entity_id must match domain.snake_case"
blank state → "state must not be empty"
[1,2,3] attrs → "attributes must be a JSON object"
- Successful create: light.test_bulb POSTed; modal closes; toast
"Created light.test_bulb = on"; grid count went 10 → 11
- Persistence: hard reload, count stays
- 0 console errors (Lit dev-mode notices excluded)
Note: TypeScript caught a name collision — `attributes` is reserved
on HTMLElement (NamedNodeMap). Renamed the Lit @property to
`entityAttrs` so the class extends LitElement cleanly.
Co-Authored-By: claude-flow <ruv@ruv.net>
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>
ruv