[Phase 4] Implement dashboard manifests, panel registry, and layout persistence #27

New issue

Closed

opened 2026-07-25 21:56:00 +00:00 by lost-rob0t · 0 comments

lost-rob0t commented

2026-07-25 21:56:00 +00:00

(Migrated from github.com)

Parent: #2
Depends on: #12, #23, #24, #25, #26

Scope

Define versioned dashboard manifests for layout, active variant, time range, panels, map state, and revision.
Build a declarative panel registry with stable IDs, sizing rules, inputs, projection requests, refresh policy, view states, drill-down targets, and cleanup.
Add resizable, collapsible, and reorderable panel layouts.
Provide generic panels for saved results, source freshness, action status, metrics, and event streams.

Acceptance criteria

Dashboard layout and panel parameters survive refresh and schema migration.
Panels do not own canonical graph data or independent timers.
Loading, cached, partial, stale, empty, disabled, error, and offline states are distinct.
Every panel exposes a clear drill-down path.
Variants configure shared registries rather than fork the application.

Parent: #2 Depends on: #12, #23, #24, #25, #26 ## Scope - Define versioned dashboard manifests for layout, active variant, time range, panels, map state, and revision. - Build a declarative panel registry with stable IDs, sizing rules, inputs, projection requests, refresh policy, view states, drill-down targets, and cleanup. - Add resizable, collapsible, and reorderable panel layouts. - Provide generic panels for saved results, source freshness, action status, metrics, and event streams. ## Acceptance criteria - Dashboard layout and panel parameters survive refresh and schema migration. - Panels do not own canonical graph data or independent timers. - Loading, cached, partial, stale, empty, disabled, error, and offline states are distinct. - Every panel exposes a clear drill-down path. - Variants configure shared registries rather than fork the application.