tasks ready

2026-01-22 23:59:16 +03:00
parent 26ba015b75
commit e9d3f3c827
13 changed files with 776 additions and 21 deletions
--- a/specs/011-git-integration-dashboard/plan.md
+++ b/specs/011-git-integration-dashboard/plan.md
@@ -0,0 +1,102 @@
+# Implementation Plan: Git Integration Plugin for Dashboard Development
+
+**Branch**: `011-git-integration-dashboard` | **Date**: 2026-01-22 | **Spec**: [spec.md](specs/011-git-integration-dashboard/spec.md)
+**Input**: Feature specification from `/specs/011-git-integration-dashboard/spec.md`
+
+## Summary
+
+Implement a Git integration plugin that allows dashboard developers to version control their Superset dashboards. The plugin will support GitLab, GitHub, and Gitea, enabling branch management, committing/pushing changes (as unpacked Superset exports), and deploying to target environments via the Superset API.
+
+## Technical Context
+
+**Language/Version**: Python 3.9+ (Backend), Node.js 18+ (Frontend)
+**Primary Dependencies**: FastAPI, SvelteKit, GitPython (or CLI git), Pydantic, SQLAlchemy, Superset API
+**Storage**: SQLite (for config/history), Filesystem (local Git repositories)
+**Testing**: pytest (Backend), SvelteKit testing utilities (Frontend)
+**Target Platform**: Linux server
+**Project Type**: Web application (Frontend + Backend)
+**Performance Goals**: Branch switching < 5s, Search/Filter history < 2s
+**Constraints**: Offline mode support, Superset API dependency for deployment, PAT-based authentication
+**Scale/Scope**: 1 repository per dashboard, support for up to 1000 commits per repo
+
+## Constitution Check
+
+*GATE: Must pass before Phase 0 research. Re-check after Phase 1 design.*
+
+1. **Semantic Protocol Compliance**: All new modules must include headers, `[DEF]` anchors, and `@RELATION` tags as per `semantic_protocol.md`.
+2. **Causal Validity**: API contracts and data models must be defined in `specs/` before implementation.
+3. **Everything is a Plugin**: The Git integration must be implemented as a `PluginBase` subclass in `backend/src/plugins/`.
+4. **Design by Contract**: Use Pydantic models for request/response validation and internal state transitions.
+
+## Project Structure
+
+### Documentation (this feature)
+
+```text
+specs/[###-feature]/
+├── plan.md              # This file (/speckit.plan command output)
+├── research.md          # Phase 0 output (/speckit.plan command)
+├── data-model.md        # Phase 1 output (/speckit.plan command)
+├── quickstart.md        # Phase 1 output (/speckit.plan command)
+├── contracts/           # Phase 1 output (/speckit.plan command)
+└── tasks.md             # Phase 2 output (/speckit.tasks command - NOT created by /speckit.plan)
+```
+
+### Source Code (repository root)
+<!--
+  ACTION REQUIRED: Replace the placeholder tree below with the concrete layout
+  for this feature. Delete unused options and expand the chosen structure with
+  real paths (e.g., apps/admin, packages/something). The delivered plan must
+  not include Option labels.
+-->
+
+```text
+backend/
+├── src/
+│   ├── api/routes/git.py      # Git integration endpoints
+│   ├── models/git.py          # Git-specific Pydantic/SQLAlchemy models
+│   ├── plugins/git_plugin.py  # PluginBase implementation
+│   └── services/git_service.py # Core Git logic (GitPython wrapper)
+└── tests/
+    └── plugins/test_git.py
+
+frontend/
+├── src/
+│   ├── components/git/        # Git UI components (BranchSelector, CommitModal, ConflictResolver)
+│   ├── routes/settings/git/   # Git configuration pages
+│   └── services/gitService.js # API client for Git operations
+└── tests/
+
+**Structure Decision**: Web application structure as the project has both FastAPI backend and SvelteKit frontend.
+
+## Complexity Tracking
+
+> **Fill ONLY if Constitution Check has violations that must be justified**
+
+| Violation | Why Needed | Simpler Alternative Rejected Because |
+|-----------|------------|-------------------------------------|
+| [e.g., 4th project] | [current need] | [why 3 projects insufficient] |
+[e.g., Repository pattern] | [specific problem] | [why direct DB access insufficient] |
+
+## Implementation Phases
+
+### Phase 2: Backend Implementation (Plugin & Service)
+1.  **Git Service**: Implement `GitService` using `GitPython`. Focus on:
+    *   Repo initialization and cloning.
+    *   Branch management (list, create, checkout).
+    *   Stage, commit, push, pull.
+2.  **Git Plugin**: Implement `GitPlugin(PluginBase)`.
+    *   Integrate with `superset_tool` for exporting/importing dashboards.
+    *   Handle unpacking ZIP exports into the repo structure.
+3.  **API Routes**: Implement `/api/git/*` endpoints.
+
+### Phase 3: Frontend Implementation
+1.  **Configuration UI**: Settings page for `GitServerConfig`.
+2.  **Dashboard Integration**: Add Git controls to the Dashboard view.
+    *   Branch selector.
+    *   Commit/Push/Pull buttons.
+3.  **Conflict Resolution UI**: Implementation of "Keep Mine/Theirs" file picker.
+
+### Phase 4: Deployment Integration
+1.  **Environment Management**: CRUD for `DeploymentEnvironment`.
+2.  **Deployment Logic**: Trigger Superset Import API on target servers.