# CLAUDE.md This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository. ## Project Overview NimbusFlow is a comprehensive scheduling system with a **monorepo structure** containing separate backend and frontend applications designed for church music ministry scheduling. The system handles round-robin member scheduling with sophisticated algorithms for fair distribution and availability management. ### Architecture Overview - **Backend**: Python-based scheduling service with FastAPI REST API, SQLite database, and comprehensive CLI - **Frontend**: .NET 8 Blazor Server application with Bootstrap UI for web-based management ## Backend Architecture The backend follows a **layered architecture** with clear separation of concerns: ``` backend/ ├── api/ # FastAPI REST API server ├── cli/ # Command-line interface ├── db/ # Database connection layer ├── models/ # Data models and enums ├── repositories/ # Data access layer (Repository pattern) ├── services/ # Business logic layer ├── tests/ # Comprehensive test suite ├── utils/ # Utility functions ├── requirements.txt # Python dependencies └── schema.sql # Database schema ``` ### Key Components #### API Layer (`api/`) - **app.py**: FastAPI application with comprehensive REST endpoints - **__main__.py**: Uvicorn server entry point with auto-reload - Supports CORS for frontend communication on `localhost:5059` - Pydantic models for request/response validation with C# naming convention compatibility #### CLI Layer (`cli/`) - **main.py**: Command-line interface coordinator with subcommands - **interactive.py**: Interactive mode for user-friendly operations - **commands/**: Modular command implementations (members, schedules, services) - **base.py**: Base CLI class with common functionality #### Database Layer (`db/`) - **connection.py**: SQLite wrapper with context manager support - **base_repository.py**: Abstract base repository with common CRUD operations - Thread-safe connection handling for FastAPI #### Repository Pattern (`repositories/`) - **MemberRepository** (`member.py`): Member CRUD operations - **ScheduleRepository** (`schedule.py`): Schedule management with status updates - **ServiceRepository** (`service.py`): Service instance management - **ClassificationRepository** (`classification.py`): Member role management - **ServiceTypeRepository** (`service_type.py`): Time slot definitions - **ServiceAvailabilityRepository** (`service_availability.py`): Member eligibility #### Business Logic (`services/`) - **SchedulingService** (`scheduling_service.py`): Core scheduling algorithms - Round-robin scheduling based on `LastAcceptedAt` timestamps - 5-day decline boost for recently declined members - Same-day exclusion rules - Multi-classification support - Status-aware scheduling (pending/accepted/declined) #### Data Models (`models/`) - **dataclasses.py**: Core data models with SQLite row conversion utilities - **enums.py**: Enumerated types for system constants - Models: Member, Service, Schedule, Classification, ServiceType, etc. ### Database Schema (`schema.sql`) SQLite-based with comprehensive relational design: **Core Tables:** - `Members`: Member information with scheduling timestamps - `Services`: Service instances with dates and types - `Schedules`: Member-service assignments with status tracking - `Classifications`: Member roles (Soprano, Alto, Tenor, Baritone) - `ServiceTypes`: Time slots (9AM, 11AM, 6PM) - `ServiceAvailability`: Member eligibility for service types **Audit Tables:** - `AcceptedLog`, `DeclineLog`, `ScheduledLog` for comprehensive tracking - Foreign key constraints and indexes for performance ## Frontend Architecture .NET 8 Blazor Server application with the following structure: ``` frontend/ ├── Components/ │ ├── Layout/ # Layout components (NavMenu, MainLayout) │ ├── Pages/ # Razor pages (Members, Schedules, Services) │ ├── App.razor # Root application component │ └── _Imports.razor # Global imports ├── Models/ # C# models matching backend structure ├── Services/ # HTTP client services for API communication ├── Properties/ # Launch settings and configuration ├── wwwroot/ # Static files and assets └── Program.cs # Application startup and DI configuration ``` ### Key Components #### Services Layer - **ApiService.cs**: HTTP client implementation with JSON serialization - **IApiService.cs**: Service interface for dependency injection - Configured for `http://localhost:8000/api/` backend communication - Camel case JSON handling for API compatibility #### Models (`Models/`) - **Member.cs**: Complete data models matching backend structure - Models: Member, Classification, Service, ServiceType, Schedule - Navigation properties for related data - Compatible with FastAPI Pydantic models #### Razor Components (`Components/Pages/`) - **Members.razor**: Member management interface - **Schedules.razor**: Schedule management and workflow - **Services.razor**: Service administration - **Home.razor**: Dashboard and overview - Bootstrap 5 styling with responsive design #### Dependency Injection (`Program.cs`) - HTTP client configuration for backend API - Service registration with scoped lifetime - HTTPS redirection and static file serving ## Development Commands ### Backend Development **Environment Setup:** ```bash cd backend # Virtual environment is pre-configured in .venv/ source .venv/bin/activate ``` **Dependencies:** ```bash # Install from requirements.txt pip install -r requirements.txt ``` **API Server:** ```bash cd backend source .venv/bin/activate python -m api # Starts FastAPI server on http://localhost:8000 # API documentation at http://localhost:8000/docs ``` **CLI Usage:** ```bash cd backend source .venv/bin/activate python -m cli --help python -m cli members list python -m cli schedules schedule --help ``` **Demo/Development Data:** ```bash cd backend source .venv/bin/activate python main.py # Runs demo data population ``` **Testing:** ```bash cd backend source .venv/bin/activate pytest # Run all tests pytest tests/repositories/ # Run repository tests pytest --cov # Run with coverage ``` ### Frontend Development **Setup:** ```bash cd frontend dotnet restore ``` **Development Server:** ```bash cd frontend dotnet watch # Hot reload development # Or: dotnet run ``` **Build & Deploy:** ```bash cd frontend dotnet build # Development build dotnet build -c Release # Production build dotnet publish -c Release # Publish for deployment ``` **Access:** - Development: http://localhost:5059 - Expects backend API at http://localhost:8000/api/ ## Core Business Logic ### Scheduling Algorithm The **SchedulingService** implements sophisticated member scheduling: 1. **Round-robin fairness**: Based on `LastAcceptedAt` timestamps 2. **Decline boost**: 5-day priority for recently declined members 3. **Same-day exclusion**: Members cannot serve multiple services per day 4. **Classification matching**: Multi-classification support for flexible roles 5. **Availability filtering**: Service type eligibility checking 6. **Status management**: Prevents double-booking across pending/accepted states **Key Methods:** - `schedule_next_member(classification_ids, service_id)`: Core scheduling with multi-role support - `decline_service_for_user(member_id, service_id, reason)`: Decline handling with boost logic ### API Endpoints **Member Management:** - `GET /api/members` - List all members - `GET /api/members/{id}` - Get member details - `POST /api/members` - Create new member - `PUT /api/members/{id}` - Update member - `DELETE /api/members/{id}` - Delete member **Scheduling Operations:** - `GET /api/schedules` - List all schedules - `POST /api/schedules/schedule-next` - Schedule next available member - `POST /api/schedules/{id}/accept` - Accept assignment - `POST /api/schedules/{id}/decline` - Decline with reason - `DELETE /api/schedules/{id}` - Remove schedule **Service Management:** - `GET /api/services` - List services - `POST /api/services` - Create new service - `GET /api/service-types` - List service types ## Database Management **Schema Location:** `backend/schema.sql` **Database File:** `backend/db/sqlite/database.db` (auto-created) **Key Features:** - Automatic database creation from schema if missing - Foreign key constraints enforced - Comprehensive indexing for performance - Audit logging for all schedule operations ## Testing **Backend Testing with pytest:** - Repository layer unit tests with in-memory SQLite - Service layer business logic tests - Fixtures for database setup and test data - Comprehensive coverage of scheduling algorithms **Test Structure:** ``` tests/ ├── conftest.py # Shared fixtures ├── repositories/ # Repository layer tests └── services/ # Business logic tests ``` ## Development Workflow 1. **Backend First**: Start with API development and testing 2. **Database Schema**: Modify `schema.sql` for data model changes 3. **Repository Layer**: Update repositories for new database operations 4. **Service Layer**: Implement business logic in services 5. **API Layer**: Add FastAPI endpoints with Pydantic models 6. **Frontend Models**: Update C# models to match API 7. **Frontend Services**: Extend ApiService for new endpoints 8. **Frontend UI**: Create/update Razor components 9. **Testing**: Add tests for new functionality 10. **Integration**: Test full stack communication ## Color Palette & Design System The NimbusFlow brand uses a sophisticated color palette inspired by the logo's golden cloud and deep navy background, creating a professional yet warm aesthetic suitable for church ministry applications. ### Primary Colors ```css :root { /* Primary Brand Colors */ --nimbus-navy: #1a2332; /* Deep navy background */ --nimbus-navy-light: #2a3441; /* Lighter navy variant */ --nimbus-navy-dark: #0f1419; /* Darker navy variant */ /* Golden Accent Colors */ --nimbus-gold: #ffd700; /* Primary gold */ --nimbus-gold-light: #ffed4e; /* Light gold highlight */ --nimbus-gold-dark: #e6c200; /* Dark gold shadow */ --nimbus-amber: #ffb347; /* Warm amber accent */ /* Neutral Colors */ --nimbus-white: #ffffff; /* Pure white */ --nimbus-gray-100: #f8f9fa; /* Light gray */ --nimbus-gray-300: #dee2e6; /* Medium light gray */ --nimbus-gray-600: #6c757d; /* Medium gray */ --nimbus-gray-800: #343a40; /* Dark gray */ } ``` ### Bootstrap Integration ```css /* Override Bootstrap variables */ :root { --bs-primary: var(--nimbus-navy); --bs-primary-rgb: 26, 35, 50; --bs-secondary: var(--nimbus-gold); --bs-secondary-rgb: 255, 215, 0; --bs-success: #28a745; --bs-warning: var(--nimbus-amber); --bs-info: #17a2b8; --bs-danger: #dc3545; } ``` ### Usage Guidelines **Primary Navy (`--nimbus-navy`):** - Navigation bars and headers - Card backgrounds in dark mode - Button primary states - Footer backgrounds **Golden Accent (`--nimbus-gold`):** - Call-to-action buttons - Active states and highlights - Icons and accent elements - Success indicators **Amber (`--nimbus-amber`):** - Warning states - Pending status indicators - Hover effects on interactive elements ### Accessibility Considerations All color combinations meet WCAG 2.1 AA standards: - **Navy on White**: 12.6:1 contrast ratio - **Gold on Navy**: 4.8:1 contrast ratio - **White on Navy**: 12.6:1 contrast ratio - **Dark Gray on Light Gray**: 7.2:1 contrast ratio ### Implementation Example ```razor Pending ``` ## Important Notes - **Thread Safety**: FastAPI uses custom DatabaseConnection for thread safety - **JSON Compatibility**: Backend uses PascalCase/camelCase aliasing for C# compatibility - **Error Handling**: Comprehensive HTTP status codes and error responses - **CORS**: Configured for frontend origins on localhost:5059 - **Virtual Environment**: Pre-configured Python environment in `backend/.venv/` - **Auto-reload**: Both backend (Uvicorn) and frontend (dotnet watch) support hot reload - **Brand Colors**: Use the defined color palette consistently across all UI components