9.5 KiB
Implementation Tasks: Dashboard Health Windows
Feature Branch: 026-dashboard-health-windows
Documentation: plan.md | spec.md | ux_reference.md | data-model.md | contracts/modules.md
Dependencies & Execution Order
- Phase 1 & 2: Setup and Foundation (DB changes, extending scheduler). Blocks all user stories.
- Phase 3: User Story 1 (Policies). Needs Phase 2.
- Phase 4: User Story 2 (Health Center). Can be built in parallel with Phase 3 on the frontend, but backend depends on data model changes in Phase 2.
- Phase 5: User Story 3 (Quick Nav). Depends on Phase 4 Health Center backend API.
- Phase 6: User Story 4 (Smart Notifications). Depends on Phase 2 (Profile schema) and Phase 3 (Policies).
- Phase 7: Polish. Depends on all previous phases.
Parallel Execution Opportunities:
[US1](Policies UI) can be built in parallel with[US2](Health Matrix UI) and[US4](Notification settings UI).- Backend and frontend tasks within a user story can generally be developed in parallel up to integration.
Implementation Strategy
We will deliver this feature incrementally:
- First, we establish the database schema for policies, profiles, and extended validation records.
- Then, we build the "Execution Window" logic in the scheduler (
[US1]). - Next, we build the Health Center projection API and UI (
[US2]), giving visibility into the tasks. - We weave the health data into the global app shell (Sidebar, Assistant) (
[US3]). - Finally, we implement the
NotificationServiceand integrate it into the task execution pipeline to shift to a "push" model ([US4]).
Phase 1: Setup
Goal: Initialize the project structure for the new feature modules.
- T001 Scaffold
health.pyrouter inbackend/src/api/routes/health.py - T002 Scaffold
health_service.pyinbackend/src/services/health_service.py - T003 Scaffold
HealthMatrix.sveltecomponent infrontend/src/lib/components/health/HealthMatrix.svelte - T004 Scaffold
PolicyForm.sveltecomponent infrontend/src/lib/components/health/PolicyForm.svelte - T005 Create empty
+page.sveltefor Health Center infrontend/src/routes/dashboards/health/+page.svelte - T006 Create empty
+page.sveltefor Automation Policies infrontend/src/routes/settings/automation/+page.svelte
Phase 2: Foundational
Goal: Implement the core data model and generic backend updates required by all stories.
- T007 [P] Create
ValidationPolicymodel and updateValidationRecordmodel with new fields inbackend/src/models/llm.py - T008 [P] Add
telegram_id,email_address, andnotify_on_failfields toUserDashboardPreferenceinbackend/src/models/profile.py - T009 [P] Create
NotificationConfigmodel for global provider settings inbackend/src/models/config.py(or as a JSON block inAppConfigRecord) - T010 Generate and apply Alembic migration for all DB changes in
backend/alembic/versions/ - T011 Update
TaskReportschema to support the extendedValidationRecordshape inbackend/src/models/report.py
Phase 3: User Story 1 - Create Validation Policy with Execution Window (P1)
Goal: Allow users to define validation policies with execution windows and have the backend distribute tasks within that window.
Independent Test: Can be tested by creating a policy with a 1-hour window for 60 dashboards and verifying that the system schedules 60 distinct validations spread roughly 1 minute apart.
- T012 [P] [US1] Create Pydantic schemas for
ValidationPolicy(Create/Update/Response) inbackend/src/schemas/settings.py(or new schema file) - T013 [US1] Implement CRUD endpoints for validation policies in
backend/src/api/routes/settings.py(or new automation router) - T014 [US1] Implement
ThrottledSchedulerConfiguratorlogic. (CRITICAL: PRE: active policies + time, POST: N tasks scheduled evenly. TESTS: window distribution, too small window fallback) inbackend/src/core/scheduler.py(or new core module) - T015 [P] [US1] Create
PolicyFormcomponent for editing/creating policies infrontend/src/lib/components/health/PolicyForm.svelte - T016 [US1] Implement Automation Policies page list and modal management in
frontend/src/routes/settings/automation/+page.svelte - T017 [US1] Add "Automation" tab to the global settings navigation in
frontend/src/routes/settings/+page.svelte - T018 [US1] Verify implementation matches
ux_reference.md(Happy Path & Errors) for the Automation Settings view.
Phase 4: User Story 2 - Dashboard Health Center Monitoring (P2)
Goal: Provide a traffic-light summary view of the latest validation status for all dashboards.
Independent Test: Can be tested by running several validation tasks (some pass, some fail) and viewing the Health Center to ensure it correctly aggregates and displays only the latest status for each unique dashboard.
- T019 [P] [US2] Implement
HealthService.get_health_summary. (CRITICAL: PRE: environment_id, POST: aggregated List[DashboardHealthItem]. TESTS: aggregation success, no-records fallback) inbackend/src/services/health_service.py - T020 [US2] Implement
GET /api/dashboards/healthendpoint inbackend/src/api/routes/health.py(or extenddashboards.py) - T021 [P] [US2] Implement
HealthMatrixUI component (Pass/Warn/Fail traffic lights) infrontend/src/lib/components/health/HealthMatrix.svelte - T022 [US2] Implement Health Center page fetching data and rendering the matrix and data table in
frontend/src/routes/dashboards/health/+page.svelte - T023 [US2] Link "View Report" button in Health Center table to the detailed LLM report route
frontend/src/routes/reports/llm/[taskId]/+page.svelte - T024 [US2] Verify implementation matches
ux_reference.md(Happy Path & Errors) for the Health Center view.
Phase 5: User Story 3 - Quick Navigation and Integrations (P3)
Goal: Integrate the failing dashboard counts into the sidebar and the AI Assistant.
Independent Test: Can be tested by having failing validations in the database and checking that the sidebar navigation displays a red badge with the correct count, and querying the assistant returns accurate results.
- T025 [US3] Create
SidebarHealthBadgestore (fetches or derives failing count) infrontend/src/lib/stores/health.js(or extendactivity.js) - T026 [US3] Update
Sidebarcomponent to display the red[🔴 N]badge next to the Dashboards menu item infrontend/src/lib/components/layout/Sidebar.svelte - T027 [US3] Update
backend/src/api/routes/assistant.py(or the underlying tool catalog) to resolve queries about "failing dashboards" by querying theHealthServiceand returning deep links. - T028 [US3] Verify implementation matches
ux_reference.md(Happy Path & Errors) for Sidebar and Assistant integration.
Phase 6: User Story 4 - Smart Notifications Routing (P2)
Goal: Implement the backend routing logic and external providers to send push notifications.
Independent Test: Can be tested by configuring a user profile with a Telegram ID, running a validation task that fails for a dashboard owned by that user in Superset, and verifying the NotificationService dispatches a payload to the Telegram provider.
- T029 [P] [US4] Update
frontend/src/routes/profile/+page.svelteto include Telegram ID and email override inputs. - T030 [P] [US4] Implement
NotificationProviderabstractions (SMTP, Slack, Telegram) inbackend/src/services/notifications/providers.py - T031 [US4] Implement
NotificationServicefor routing logic. (CRITICAL: PRE: ValidationResult, POST: Dispatches to providers via BackgroundTasks. TESTS: owner routing, missing profile resilience) inbackend/src/services/notifications/service.py - T032 [US4] Wire
NotificationService.dispatch_reportinto the end ofDashboardValidationPlugin.executeinbackend/src/plugins/llm_analysis/plugin.py - T033 [US4] Implement Global Settings UI for configuring Notification Providers in
frontend/src/routes/settings/notifications/+page.svelte - T034 [US4] Verify implementation matches
ux_reference.md(Happy Path & Errors) for Notification payloads and UI.
Phase 7: Polish & Cross-Cutting
Goal: Finalize styling, error handling, and end-to-end flow.
- T035 Ensure consistent Tailwind styling and dark mode support across
HealthMatrixandPolicyForm. - T036 Add comprehensive error toasts for policy creation failures (e.g., overlapping windows, invalid IDs).
- T037 Write/update unit tests for
ThrottledSchedulerConfiguratorbounds handling. - T038 Write/update unit tests for
HealthServicelatest-record aggregation logic.
Post-Review Fix Batch (2026-03-10)
- R001 Persist
task_idandenvironment_idinValidationRecordcreation path (llm_analysis/plugin.py). - R002 Align policy channel schema contract:
custom_channelsmigrated to structured objects{type,target}in settings schemas. - R003 Tighten health status regex to strict grouped anchors
^(PASS|WARN|FAIL|UNKNOWN)$. - R004 Resolve weekday convention drift to
0=Sunday ... 6=Saturdayconsistently across backend schema description and policy form UI. - R005 Add regression tests for schema contracts and plugin persistence context fields.
- R006 Make health report deletion resilient to linked task/log cleanup failures and cover the fallback with unit tests.
- R007 Align Health Center delete action with latest-record aggregation by deleting all validation reports for the selected dashboard/environment scope.