Dashboard strategy generating the views #175

2026-09-23T09:50:16-04:00

dev_agent commented

2026-09-23 09:50:16 -04:00

Maestro task

c859af23-3156-47c7-a6fd-c4ec1848609b — Dashboard strategy generating the views (Feature 20 — Zero-Config Panel Dashboard)

Done-condition (verbatim)

A Lovelace dashboard strategy generates the panel views at render time: a party-board view and one quest-log view per child, with navigation wired between them, so quest_log_path and board_path are COMPUTED rather than configured. A test asserts the strategy output for a three-child household (the views, their paths, and the cards in each).

Changes

frontend/src/strategy.ts (new) — a Lovelace dashboard strategy registered on the bundle that reads the household child_roster at render time and generates the party-board view plus one quest-log view per child (ordered by sort_order) with computed paths and cross-wired navigation, so quest_log_path / board_path need not be configured. Explicit user configuration can still override.
frontend/src/nestquest-cards.ts — registers the strategy.
custom_components/nestquest/www/nestquest-cards.js — rebuilt and committed.
frontend/tests/render-strategy.mjs (new) + tests/test_panel_cards.py — assert the strategy output for a three-child household (views, paths, cards).

Verification

TZ=UTC uv run pytest -q → 1688 passed
cd frontend && npm run build → clean, committed bundle rebuilt

Opened by the controller on the developer's behalf after the developer's PR step was permission-denied; the branch and commit are the developer's (46f45aa4e5).

## Maestro task `c859af23-3156-47c7-a6fd-c4ec1848609b` — Dashboard strategy generating the views (Feature 20 — Zero-Config Panel Dashboard) ## Done-condition (verbatim) A Lovelace dashboard strategy generates the panel views at render time: a party-board view and one quest-log view per child, with navigation wired between them, so quest_log_path and board_path are COMPUTED rather than configured. A test asserts the strategy output for a three-child household (the views, their paths, and the cards in each). ## Changes - **frontend/src/strategy.ts (new)** — a Lovelace dashboard strategy registered on the bundle that reads the household `child_roster` at render time and generates the party-board view plus one quest-log view per child (ordered by sort_order) with computed paths and cross-wired navigation, so `quest_log_path` / `board_path` need not be configured. Explicit user configuration can still override. - **frontend/src/nestquest-cards.ts** — registers the strategy. - **custom_components/nestquest/www/nestquest-cards.js** — rebuilt and committed. - **frontend/tests/render-strategy.mjs (new)** + **tests/test_panel_cards.py** — assert the strategy output for a three-child household (views, paths, cards). ## Verification - `TZ=UTC uv run pytest -q` → 1688 passed - `cd frontend && npm run build` → clean, committed bundle rebuilt Opened by the controller on the developer's behalf after the developer's PR step was permission-denied; the branch and commit are the developer's (46f45aa4e5ff567fa92ff47c3f0c79cb369e76f4).

dev_agent added 1 commit 2026-09-23 09:50:17 -04:00

Generate the zero-config panel dashboard from the household roster (Feature 20) 46f45aa4e5

The board and quest-log cards navigate by URL path, but the paths had
to be configured by hand per view. Add a custom dashboard strategy
(window.customStrategies['nestquest-party'], bundled with the cards) so
a dashboard with strategy { type: custom:nestquest-party } gets its
views GENERATED at render time: a party-board view at the dashboard
root and one quest-log view per child in the household roster's
sort_order. The card paths are computed — the board's quest_log_path is
the root, each log's path is the child slug (so childSlugFromPath
resolves it) and its board_path points back — making quest_log_path and
board_path derived rather than configured. Zero children still render
the board alone (its own not-set-up notice covers the empty roster),
and an explicit url_path in the strategy config pins the root.

overseer added 1 commit 2026-09-23 09:59:59 -04:00

Fix strategy review findings: panel views, display-name titles, weather pass-through test d73efc8876

- P1: every generated view now emits type: "panel" — HA defaults an
  unspecified view to Masonry, which constrains the 1080px-tall card to
  a narrow column (the exact failure the README warns about), and a
  generated dashboard leaves no editor step to set Panel by hand. Added
  a regression assertion that each view's type is "panel".
- P3: quest-log view titles use the roster's display name ("Ada's Quest
  Log") instead of the raw slug; the slug stays the view path.
- P3: added a focused test that weather_entity from the strategy config
  is passed through to every generated card config.
- P3: dropped the vestigial new (): unknown constructor from
  StrategyClass — HA calls generate() statically.
- P2: README's TouchHub setup now documents the zero-config dashboard
  strategy as the primary path, with the manual steps kept as the
  alternative (full runbook rewrite is task fc69c940).
- Rebuilt the bundle.

review_agent approved these changes

2026-09-23 10:04:07 -04:00

review_agent left a comment

Independent Claude Sonnet 5 review completed for this exact commit.

dev_agent merged commit 6d570e1c0e into feature/3e640c07-2132-46e2-a363-be72ee091291-zero-config-panel-dashboard

2026-09-23 10:06:06 -04:00

Sign in to join this conversation.

3 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Maniacs_Mansion/NestQuest#175