Вроде работает
This commit is contained in:
@@ -88,23 +88,34 @@ As a Developer, I want the system to suggest commit messages based on changes di
|
||||
### Functional Requirements
|
||||
|
||||
- **FR-001**: System MUST allow configuration of multiple LLM providers, specifically supporting OpenAI API, OpenRouter, and Kilo Provider.
|
||||
- **FR-002**: System MUST securely store API keys for these providers.
|
||||
- **FR-002**: System MUST securely store API keys for these providers using AES-256 encryption. [Security]
|
||||
- **FR-028**: The system MUST mask all API keys in the UI and logs, displaying only the last 4 characters (e.g., `sk-...1234`). [Security]
|
||||
- **FR-003**: System MUST implement a `DashboardValidationPlugin` that integrates with the existing `PluginBase` architecture.
|
||||
- **FR-004**: `DashboardValidationPlugin` MUST accept a dashboard identifier as input.
|
||||
- **FR-005**: `DashboardValidationPlugin` MUST be capable of retrieving a visual representation (screenshot) of the dashboard.
|
||||
- **FR-005**: `DashboardValidationPlugin` MUST be capable of retrieving a visual representation (screenshot) of the dashboard. The visual representation MUST be a PNG or JPEG image with a minimum resolution of 1280x720px to ensure legibility for the LLM. [Clarity]
|
||||
- **FR-016**: System MUST support configurable screenshot strategies: 'Headless Browser' (default, high accuracy) and 'API Thumbnail' (fallback/fast).
|
||||
- **FR-006**: `DashboardValidationPlugin` MUST retrieve recent execution logs associated with the dashboard.
|
||||
- **FR-007**: `DashboardValidationPlugin` MUST combine visual and text data to prompt a Multimodal LLM for analysis.
|
||||
- **FR-006**: `DashboardValidationPlugin` MUST retrieve recent execution logs associated with the dashboard, limited to the last 100 lines or 24 hours (whichever is smaller) to prevent token overflow. [Reliability]
|
||||
- **FR-007**: `DashboardValidationPlugin` MUST combine visual and text data to prompt a Multimodal LLM for analysis. The analysis output MUST be structured as a JSON object containing `status` (Pass/Fail), `issues` (list of strings), and `summary` (text) to enable structured UI presentation. [Clarity]
|
||||
- **FR-008**: System MUST implement a `DocumentationPlugin` (or similar) for documenting datasets and dashboards.
|
||||
- **FR-009**: `DocumentationPlugin` MUST retrieve schema and metadata for the target asset.
|
||||
- **FR-017**: `DocumentationPlugin` MUST apply generated descriptions directly to the target object's metadata fields (dataset description, column descriptions).
|
||||
- **FR-017**: `DocumentationPlugin` MUST apply generated descriptions directly to the target object's metadata fields (dataset description, column descriptions). It MUST handle schema changes by only updating fields that exist in the current schema and ignoring hallucinated columns. [Data Integrity]
|
||||
- **FR-023**: The system MUST use optimistic locking or version checks to prevent overwrites during concurrent documentation updates. [Data Integrity]
|
||||
- **FR-024**: Generated documentation MUST be plain text or Markdown, strictly avoiding executable code blocks or active HTML. [Security]
|
||||
- **FR-025**: The system MUST validate that generated commit messages follow the conventional commits format (e.g., `feat:`, `fix:`) and do not exceed 72 characters in the subject line. [Data Integrity]
|
||||
- **FR-026**: If a metadata update fails partially, the system MUST rollback all changes to preserve data consistency. [Data Integrity]
|
||||
- **FR-027**: The system MUST reject documentation requests for empty or null schemas with a clear error message. [Edge Case]
|
||||
- **FR-010**: All LLM interactions MUST be executed as asynchronous tasks via the Task Manager.
|
||||
- **FR-018**: System MUST implement automatic retry logic (3 attempts with exponential backoff) for failed LLM API calls.
|
||||
- **FR-018**: System MUST implement automatic retry logic (3 attempts with exponential backoff: 2s, 4s, 8s) for failed LLM API calls. [Reliability]
|
||||
- **FR-029**: The system MUST filter sensitive data (PII, credentials) from logs and screenshots before sending them to external LLM providers. [Privacy]
|
||||
- **FR-011**: Task execution logs and results MUST be streamed via the existing WebSocket infrastructure.
|
||||
- **FR-012**: System SHOULD expose an interface to generate text summaries for Git diffs, utilizing the diff, file list, and recent commit history as context.
|
||||
- **FR-012**: System SHOULD expose an interface to generate text summaries for Git diffs, utilizing the diff, file list, and recent commit history as context. If the generated message is empty or invalid, the system MUST display a user-friendly error toast and retain the manual entry capability. [Edge Case]
|
||||
- **FR-013**: System MUST support scheduling of validation tasks for dashboards (leveraging existing scheduler architecture).
|
||||
- **FR-014**: System SHOULD support notification dispatch (Email, Pulse) upon validation failure or completion.
|
||||
- **FR-015**: Notifications MUST contain a summary of results (Status, Issue Count) and a direct link to the full report, avoiding sensitive full details in the message body.
|
||||
- **FR-019**: The "Validate" button MUST display a loading spinner and be disabled during active execution to prevent multiple triggers. [UX]
|
||||
- **FR-020**: The system MUST provide immediate visual feedback (Toast notifications) for successful or failed connection tests in LLM Settings. [UX]
|
||||
- **FR-021**: New LLM actions (Validate, Generate Docs) MUST use standard system icons (e.g., `heroicons:beaker` for validate, `heroicons:document-text` for docs) and follow existing button placement patterns. [Consistency]
|
||||
- **FR-022**: Error messages for LLM failures MUST follow the standard `ss-tools` error format, including a clear title, descriptive message, and troubleshooting link if applicable. [Consistency]
|
||||
|
||||
### Key Entities
|
||||
|
||||
|
||||
Reference in New Issue
Block a user