- 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.
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