77 lines
4.6 KiB
Markdown
77 lines
4.6 KiB
Markdown
# Epic 1: Foundation & Core Services
|
|
|
|
## Epic Goal
|
|
Establish the project's foundational infrastructure, including the database, user authentication, the internal API, a system for managing custom domain mappings, and the initial CI/CD pipeline.
|
|
|
|
## Stories
|
|
|
|
### Story 1.1: Project Initialization & Configuration
|
|
**As a developer**, I want to set up the monorepo structure, initialize the Python project with core dependencies, and establish the .env and JSON configuration file handling, so that there is a stable foundation for all future development.
|
|
|
|
**Acceptance Criteria**
|
|
- A monorepo directory structure is created.
|
|
- A primary Python application is initialized with necessary libraries (e.g., Flask/FastAPI, SQLAlchemy).
|
|
- A .env.example file is created with placeholders for all required secrets (database path, cloud API keys).
|
|
- The application can successfully load and parse a master JSON configuration file.
|
|
- The project is initialized as a Git repository with an initial commit.
|
|
|
|
**User Tasks**
|
|
After this story is complete, copy .env.example to .env and populate it with the actual API keys and secrets for all required cloud services.
|
|
|
|
### Story 1.2: Database Setup & User Model
|
|
**As a developer**, I want to implement the SQLite database connection and create the data model for Users using a database-agnostic ORM/data access layer, so that user information can be stored and managed securely.
|
|
|
|
**Acceptance Criteria**
|
|
- The application successfully connects to a local SQLite database file specified in the .env file.
|
|
- A User model is created that includes fields for username and a hashed password.
|
|
- The data access layer (Repository Pattern) is implemented for the User model.
|
|
- A script can be run to create the initial database schema from the models.
|
|
- The User model correctly defines "Admin" and "User" roles.
|
|
|
|
### Story 1.3: User Authentication System
|
|
**As an Admin**, I want a secure system for user login, so that only authenticated users can access the application's functions.
|
|
|
|
**Acceptance Criteria**
|
|
- A function exists to securely hash and store user passwords.
|
|
- An authentication mechanism is implemented that validates a given username and password against the stored hash.
|
|
- Upon successful login, the system can identify the user's role (Admin or User).
|
|
- Authentication fails for incorrect credentials.
|
|
|
|
### Story 1.4: Internal API Foundation
|
|
**As a developer**, I want to create a basic, secured REST API endpoint, so that the foundation for inter-service communication is established.
|
|
|
|
**Acceptance Criteria**
|
|
- A basic REST API (using Flask/FastAPI) is created within the application.
|
|
- A simple health check endpoint (e.g., /health) is available and returns a 200 OK status.
|
|
- API endpoints require authentication to be accessed.
|
|
- The API is designed to be extensible for future internal use.
|
|
|
|
### Story 1.5: Command-Line User Management
|
|
**As an Admin**, I want command-line tools to add and remove users, so that I can manage system access for the MVP.
|
|
|
|
**Acceptance Criteria**
|
|
- A CLI command exists to create a new user with a specified username, password, and role (Admin or User).
|
|
- A CLI command exists to delete a user by their username.
|
|
- The commands can only be run by an authenticated "Admin".
|
|
- Appropriate feedback is provided to the console upon success or failure of the commands.
|
|
|
|
### Story 1.6: FQDN Bucket Mapping Management
|
|
**As an Admin**, I want a database table and CLI commands to map cloud bucket names to custom FQDNs, so that the system can generate correct public URLs for interlinking.
|
|
|
|
**Acceptance Criteria**
|
|
- A new database table, fqdn_mappings, is created with columns for bucket_name, provider, and fqdn.
|
|
- A CLI command exists for an Admin to add a new mapping (e.g., add-fqdn-mapping --bucket my-bunny-bucket --provider bunny --fqdn www.mycustomdomain.com).
|
|
- A CLI command exists for an Admin to remove a mapping.
|
|
- A CLI command exists for an Admin to list all current mappings.
|
|
- The commands are protected and can only be run by an authenticated "Admin".
|
|
|
|
### Story 1.7: CI/CD Pipeline Setup
|
|
**As a developer**, I want a basic CI/CD pipeline configured for the project, so that code changes are automatically tested and can be deployed consistently.
|
|
|
|
**Acceptance Criteria**
|
|
- A CI/CD configuration file (e.g., .github/workflows/ci.yml) is created in the repository.
|
|
- The pipeline automatically triggers on pushes or pull requests to the main branch.
|
|
- A pipeline stage successfully installs all project dependencies from requirements.txt.
|
|
- A subsequent stage runs all unit and integration tests.
|
|
- The pipeline accurately reports a success or failure status based on the test results.
|