72 lines
4.4 KiB
Markdown
72 lines
4.4 KiB
Markdown
# Feature Specification: Plugin Architecture & Svelte Web UI
|
|
|
|
**Feature Branch**: `001-plugin-arch-svelte-ui`
|
|
**Created**: 2025-12-19
|
|
**Status**: Draft
|
|
**Input**: User description: "Я хочу перевести проект на плагинную архитектуру + добавить web-ui на svelte"
|
|
|
|
## User Scenarios & Testing *(mandatory)*
|
|
|
|
### User Story 1 - Web Interface for Superset Tools (Priority: P1)
|
|
|
|
As a user, I want to interact with the Superset tools (Backup, Migration, Search) through a graphical web interface so that I don't have to memorize CLI commands and arguments.
|
|
|
|
**Why this priority**: drastically improves usability and accessibility of the tools for non-technical users or quick operations.
|
|
|
|
**Independent Test**: Can be tested by launching the web server and successfully running a "Backup" task from the browser without touching the command line.
|
|
|
|
**Acceptance Scenarios**:
|
|
|
|
1. **Given** the web server is running, **When** I navigate to the home page, **Then** I see a dashboard with available tools (Backup, Migration, etc.).
|
|
2. **Given** I am on the Backup tool page, **When** I click "Run Backup", **Then** I see the progress logs in real-time and a success message upon completion.
|
|
3. **Given** I am on the Search tool page, **When** I enter a search term and submit, **Then** I see a list of matching datasets/dashboards displayed in a table.
|
|
|
|
---
|
|
|
|
### User Story 2 - Dynamic Plugin System (Priority: P2)
|
|
|
|
As a developer, I want to add new functionality (e.g., a new migration type or report generator) by simply dropping a file into a `plugins` directory, so that I can extend the tool without modifying the core codebase.
|
|
|
|
**Why this priority**: Enables scalable development and separation of concerns; allows custom extensions without merge conflicts in core files.
|
|
|
|
**Independent Test**: Create a simple "Hello World" plugin file, place it in the plugins folder, and verify it appears in the list of available tasks in the CLI/Web UI.
|
|
|
|
**Acceptance Scenarios**:
|
|
|
|
1. **Given** a valid plugin file in the `plugins/` directory, **When** the application starts, **Then** the plugin is automatically registered and listed as an available capability.
|
|
2. **Given** a plugin with specific configuration requirements, **When** I select it in the UI, **Then** the UI dynamically generates a form for those parameters.
|
|
3. **Given** an invalid or broken plugin file, **When** the application starts, **Then** the system logs an error but continues to function for other plugins.
|
|
|
|
---
|
|
|
|
## Requirements *(mandatory)*
|
|
|
|
### Functional Requirements
|
|
*All functional requirements are covered by the Acceptance Scenarios in the User Stories section.*
|
|
|
|
- **FR-001**: System MUST provide a Python-based web server (backend) to expose existing tool functionality via API.
|
|
- **FR-002**: System MUST provide a Single Page Application (SPA) frontend built with Svelte.
|
|
- **FR-003**: System MUST implement a plugin loader that scans a designated directory for Python modules matching a specific interface.
|
|
- **FR-004**: The Web UI MUST communicate with the backend via REST or WebSocket API.
|
|
- **FR-005**: The Web UI MUST display real-time logs/output from running tasks (streaming response).
|
|
- **FR-006**: System MUST support multi-user hosted deployment with authentication via ADFS (Active Directory Federation Services).
|
|
- **FR-007**: The Plugin interface MUST allow defining input parameters (schema) so the UI can auto-generate forms.
|
|
|
|
### System Invariants (Constitution Check)
|
|
|
|
- **INV-001**: Core logic (backup/migrate functions) must remain decoupled from the UI layer (can still be imported/used by CLI).
|
|
- **INV-002**: Plugins must not block the main application thread (long-running tasks must be async or threaded).
|
|
|
|
### Key Entities
|
|
|
|
- **Plugin**: Represents an extension module with metadata (name, version), input schema, and an execution entry point.
|
|
- **Task**: A specific execution instance of a Plugin or Core tool, having a status (Running, Success, Failed) and logs.
|
|
|
|
## Success Criteria *(mandatory)*
|
|
|
|
### Measurable Outcomes
|
|
|
|
- **SC-001**: A new plugin can be added and recognized by the system without restarting (or with a simple restart) and without code changes to core files.
|
|
- **SC-002**: Users can successfully trigger a Backup and Migration via the Web UI with 100% functional parity to the CLI.
|
|
- **SC-003**: The Web UI loads and becomes interactive in under 1 second on local networks.
|
|
- **SC-004**: Real-time logs in the UI appear with less than 200ms latency from the backend execution. |