busya
2d8cae563f
- Added plugin base and loader for backend extensibility - Implemented application settings management with config persistence - Created Svelte-based frontend with Dashboard and Settings pages - Added API routes for plugins, tasks, and settings - Updated documentation and specifications - Improved project structure and developer tools
77 lines
3.5 KiB
Markdown
Executable File
77 lines
3.5 KiB
Markdown
Executable File
# Implementation Plan: Plugin Architecture & Svelte Web UI
|
|
|
|
**Branch**: `001-plugin-arch-svelte-ui` | **Date**: 2025-12-19 | **Spec**: [spec.md](spec.md)
|
|
**Input**: Feature specification from `specs/001-plugin-arch-svelte-ui/spec.md`
|
|
|
|
## Summary
|
|
|
|
This feature introduces a dual-layer architecture: a Python backend exposing core tools (Backup, Migration, Search) via API, and a Svelte-based Single Page Application (SPA) for user interaction. It also implements a dynamic plugin system allowing developers to extend functionality by adding Python modules to a specific directory without modifying core code.
|
|
|
|
## Technical Context
|
|
|
|
**Language/Version**: Python 3.9+ (Backend), Node.js 18+ (Frontend Build)
|
|
**Primary Dependencies**:
|
|
- Backend: Flask or FastAPI [NEEDS CLARIFICATION: Choice of web framework], Pydantic (validation), Plugin loader mechanism (importlib)
|
|
- Frontend: Svelte, Vite, TailwindCSS (likely for UI)
|
|
**Storage**: Filesystem (plugins, logs, backups), SQLite (optional, for job history if needed)
|
|
**Testing**: pytest (Backend), vitest/playwright (Frontend)
|
|
**Target Platform**: Windows/Linux (Hosted Service)
|
|
**Project Type**: Web Application (Backend + Frontend)
|
|
**Performance Goals**: UI load < 1s, Log streaming latency < 200ms
|
|
**Constraints**: Must run in a hosted environment with ADFS authentication.
|
|
**Scale/Scope**: ~5-10 concurrent users, Extensible plugin system.
|
|
|
|
## Constitution Check
|
|
|
|
*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*
|
|
|
|
- [x] **Causal Validity**: Do all planned modules have defined Contracts (inputs/outputs/invariants) before implementation logic? (Will be enforced in Phase 1)
|
|
- [x] **Immutability**: Are architectural layers and constraints defined in Module Headers? (Will be enforced in Phase 1)
|
|
- [x] **Format Compliance**: Does the plan ensure all code will be wrapped in `[DEF]` anchors? (Will be enforced in Phase 1)
|
|
- [x] **Belief State**: Is logging planned to follow the `Entry` -> `Validation` -> `Action` -> `Coherence` state transition model? (Will be enforced in Phase 1)
|
|
|
|
## Project Structure
|
|
|
|
### Documentation (this feature)
|
|
|
|
```text
|
|
specs/001-plugin-arch-svelte-ui/
|
|
├── plan.md # This file
|
|
├── research.md # Phase 0 output
|
|
├── data-model.md # Phase 1 output
|
|
├── quickstart.md # Phase 1 output
|
|
├── contracts/ # Phase 1 output
|
|
└── tasks.md # Phase 2 output
|
|
```
|
|
|
|
### Source Code (repository root)
|
|
|
|
```text
|
|
backend/
|
|
├── src/
|
|
│ ├── app.py # Entry point
|
|
│ ├── api/ # REST API endpoints
|
|
│ ├── core/ # Plugin loader, Task manager
|
|
│ ├── plugins/ # Directory for dynamic plugins
|
|
│ └── services/ # Auth (ADFS), Logging
|
|
└── tests/
|
|
|
|
frontend/
|
|
├── src/
|
|
│ ├── components/ # Reusable UI components
|
|
│ ├── pages/ # Route views
|
|
│ ├── lib/ # API client, Stores
|
|
│ └── App.svelte
|
|
└── tests/
|
|
|
|
superset_tool/ # Existing core logic (refactored to be importable by backend)
|
|
```
|
|
|
|
**Structure Decision**: Adopting a standard "Web Application" structure with separated `backend` and `frontend` directories to maintain clean separation of concerns. The existing `superset_tool` library will be preserved and imported by the backend to execute actual tasks.
|
|
|
|
## Complexity Tracking
|
|
|
|
| Violation | Why Needed | Simpler Alternative Rejected Because |
|
|
|-----------|------------|-------------------------------------|
|
|
| N/A | | |
|