код написан

2026-03-10 12:00:18 +03:00
parent 82435822eb
commit 31717870e3
57 changed files with 53951 additions and 4909 deletions
--- a/specs/026-dashboard-health-windows/plan.md
+++ b/specs/026-dashboard-health-windows/plan.md
@@ -0,0 +1,88 @@
+# Implementation Plan: Dashboard Health Windows
+
+**Branch**: `026-dashboard-health-windows` | **Date**: 2026-03-10 | **Spec**: [spec.md](./spec.md)
+**Input**: Feature specification from `/specs/026-dashboard-health-windows/spec.md`
+
+## Summary
+
+Implement automated LLM validation policies with "Execution Windows" to distribute database load, and create a centralized "Health Center" UI to monitor the latest validation status (Pass/Warn/Fail) of all dashboards, integrating status badges into the main sidebar and AI assistant.
+
+## Technical Context
+
+**Language/Version**: Python 3.9+ (Backend), Node.js 18+ / Svelte 5.x (Frontend)
+**Primary Dependencies**: FastAPI, SQLAlchemy, APScheduler (Backend) | SvelteKit, Tailwind CSS, existing UI components (Frontend)
+**Storage**: PostgreSQL / SQLite (existing database for `ValidationRecord` and new `ValidationPolicy`)
+**Testing**: pytest (Backend), vitest (Frontend)
+**Target Platform**: Linux server (Docker), Web Browser
+**Project Type**: Full-stack web application (Internal Tool)
+**Performance Goals**: Schedule and distribute 100+ validation tasks within a 1-hour window without database CPU spikes > 80%; Health Center loads in < 2 seconds.
+**Constraints**: Must integrate with existing `TaskManager` and `LLMAnalysisPlugin`; UI must reuse existing Tailwind patterns.
+**Scale/Scope**: Dozens of policies, hundreds of dashboards, generating daily validation records.
+
+## Constitution Check
+
+*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*
+
+- **Semantic Protocol Compliance**: `[DEF]`, `@PRE`, `@POST`, `@UX_STATE` tags will be strictly used for new modules and components.
+- **Modular Plugin Architecture**: The validation logic will continue to reside in the existing `DashboardValidationPlugin`. The scheduling logic (`ThrottledScheduler`) will be integrated into the core `SchedulerService` or built as a specialized orchestrator.
+- **Unified Frontend Experience**: The new Health Center will use Tailwind CSS and standard API wrappers (`fetchApi`/`requestApi`). No native `fetch`.
+- **Security & RBAC**: The Health Center and Settings will use existing permission guards (e.g., Admin or specific dashboard view rights).
+- **Independent Testability**: The scheduler logic (time distribution calculation) and Health Center API data aggregation will be independently testable.
+- **Asynchronous Execution**: The background validation tasks are inherently async via `TaskManager`.
+
+## Project Structure
+
+### Documentation (this feature)
+
+```text
+specs/026-dashboard-health-windows/
+├── plan.md
+├── research.md
+├── data-model.md
+├── quickstart.md
+├── contracts/
+│   └── modules.md
+└── tasks.md
+```
+
+### Source Code
+
+```text
+backend/
+├── src/
+│   ├── api/
+│   │   └── routes/
+│   │       └── health.py          # New endpoint for Health Center data
+│   │       └── settings.py        # Update for validation policies CRUD
+│   ├── core/
+│   │   └── throttled_scheduler.py # NEEDS CLARIFICATION: Should this be a standalone orchestrator or extend APScheduler?
+│   ├── models/
+│   │   └── llm.py                 # Update ValidationRecord, add ValidationPolicy
+│   └── services/
+│       └── health_service.py      # Aggregation logic for Health Center
+
+frontend/
+├── src/
+│   ├── lib/
+│   │   ├── api/
+│   │   │   └── health.js          # API client for Health Center
+│   │   └── components/
+│   │       └── health/
+│   │           ├── HealthMatrix.svelte
+│   │           └── PolicyForm.svelte
+│   ├── routes/
+│   │   ├── dashboards/
+│   │   │   └── health/
+│   │   │       └── +page.svelte   # Health Center view
+│   │   └── settings/
+│   │       └── automation/
+│   │           └── +page.svelte   # Validation policies view
+```
+
+**Structure Decision**: A standard full-stack slice adding a new feature view (Health Center) and a settings view (Automation Policies), supported by backend API routes, models, and a custom scheduling component.
+
+## Complexity Tracking
+
+| Violation | Why Needed | Simpler Alternative Rejected Because |
+|-----------|------------|-------------------------------------|
+| Custom Scheduler wrapper | APScheduler handles strict cron, but we need dynamic, distributed execution within a window. | Writing a monolithic cron job that sleeps/loops blocks the worker thread and is hard to observe. |