# 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.