drew/captains-log
1
0
Fork 0
Code Pull requests Packages 2 Activity Actions

Have claude update the plan for the backend with the current status. (#5)

Browse source 
Reviewed-on: #5
Co-authored-by: Drew Galbraith <drew@tiramisu.one>
Co-committed-by: Drew Galbraith <drew@tiramisu.one>
This commit is contained in:
Drew 2025-09-22 08:00:56 +00:00 • committed by Drew
parent 8dae570755
commit 6bf4a037f3
7 changed files with 1543 additions and 168 deletions
Download patch file Download diff file Expand all files Collapse all files

179
plan/01_CORE_MVP/backend.md
View file

@ -3,42 +3,37 @@
## Overview
This plan details the concrete implementation steps for the Captain's Log backend MVP using Rust + Axum + SQLx with comprehensive testing infrastructure.
## Project Structure
## Project Structure (Actual Implementation)
```
captains-log/
├── justfile # Task runner for development commands
├── README.md # Project documentation
├── CLAUDE.md # Claude Code guidance
├── plan/ # Implementation plans and documentation
│ ├── 01_CORE_MVP/
│ │ ├── backend.md # This file
│ │ └── plan.md # Overall MVP plan
│ └── future_improvements.md # Architectural improvement opportunities
└── backend/
├── Cargo.toml # Rust project manifest
├── .env.example # Environment variables template
├── src/
│ ├── main.rs # Application entry point
│ ├── lib.rs # Library root with common exports
│ ├── config.rs # Configuration management
│ ├── main.rs # Application entry point with health endpoint
│ ├── database/
│ │ ├── mod.rs # Database module
│ │ ├── models.rs # SQLx models and types
│ │ ├── mod.rs # Database module exports
│ │ └── connection.rs # Database connection utilities
│ ├── handlers/
│ │ ├── mod.rs # HTTP handlers module
│ │ ├── tasks.rs # Task CRUD endpoints
│ │ └── health.rs # Health check endpoint
│ ├── services/
│ │ ├── mod.rs # Business logic services
│ │ └── task_service.rs # Task business logic
│ └── utils/
│ ├── mod.rs # Utility functions
│ └── test_helpers.rs # Testing utilities
├── tests/
│ ├── integration/
│ │ ├── mod.rs # Integration test setup
│ │ ├── tasks_test.rs # Task API integration tests
│ │ └── common.rs # Test database setup helpers
│ └── api/
│ ├── tasks.hurl # Hurl API tests for tasks
│ └── health.hurl # Hurl API tests for health
│ ├── models/
│ │ ├── mod.rs # Models module
│ │ └── task.rs # TaskModel with CRUD methods (Active Record)
│ └── services/
│ ├── mod.rs # Error handling and exports
│ └── tasks.rs # HTTP handlers for task endpoints
├── tests/api/ # Hurl API integration tests
│ ├── tasks.hurl # Main task API tests
│ ├── list_tasks.hurl # Task listing tests
│ ├── update_tasks.hurl # Task update tests
│ └── delete_tasks.hurl # Task deletion tests
└── migrations/
└── 001_create_tasks.sql # Initial database schema
├── 20250823023643_create_tasks.up.sql # Create tasks table
└── 20250823023643_create_tasks.down.sql # Drop tasks table
```
## Phase 1: Project Foundation (Days 1-2)
@ -77,15 +72,15 @@ captains-log/
- **Expected outcome**: `sqlx migrate run` creates table successfully
### Task 2.1: Define Task Model
- [x] **File**: `backend/src/database/models.rs`
- Create Task struct with SQLx derives
- Add TaskStatus and Priority enums
- [x] **File**: `backend/src/models/task.rs`
- Create TaskModel struct with SQLx derives
- Add TaskStatus enum (Todo, Done, Backlog)
- Implement proper serialization/deserialization
- Add validation attributes
- Add CRUD methods using Active Record pattern
- **Expected outcome**: Models compile without errors
### Task 2.2: Database Connection Pool
- [ ] **File**: `backend/src/database/connection.rs`
- [x] **File**: `backend/src/database/connection.rs`
- Set up SQLx connection pool configuration
- Add connection health checks
- Create database initialization functions
@ -93,23 +88,23 @@ captains-log/
- **Expected outcome**: Connection pool starts successfully
### Task 2.3: Task Repository Layer
- [ ] **File**: `backend/src/database/mod.rs`
- Implement TaskRepository trait
- Add CRUD operations using SQLx queries
- [x] **File**: `backend/src/models/task.rs` (Active Record Pattern)
- Implement CRUD operations directly on TaskModel
- Add SQLx queries for all operations (insert, get_by_id, update, delete, list_all)
- Include proper error handling
- Add query builders for filtering/sorting
- Add comprehensive unit tests
- **Expected outcome**: All CRUD operations work against database
### Task 2.4: Unit Tests for Database Layer
- [ ] **File**: `backend/tests/unit/database_test.rs`
- [x] **File**: `backend/src/models/task.rs` (integrated tests)
- Test all CRUD operations
- Test error conditions (not found, constraint violations)
- Use in-memory SQLite for fast tests
- Create test fixtures and utilities
- **Expected outcome**: `cargo test` passes with >80% coverage for database layer
- **Expected outcome**: `cargo test` passes with comprehensive model testing
### Task 2.5: Test Database Utilities
- [ ] **File**: `backend/src/utils/test_helpers.rs`
- [x] **File**: `backend/src/database/connection.rs` (create_test_pool function)
- Create test database setup/teardown functions
- Add test data seeding utilities
- Implement database reset between tests
@ -119,142 +114,106 @@ captains-log/
## Phase 3: Business Logic & Services (Day 5)
### Task 3.1: Task Service Implementation
- [ ] **File**: `backend/src/services/task_service.rs`
- Implement TaskService with business logic
- [x] **File**: `backend/src/services/tasks.rs` (HTTP handlers with business logic)
- Implement HTTP handlers with integrated business logic
- Add input validation and sanitization
- Handle business rules (e.g., completed_at when status changes)
- Include proper error types and handling
- **Expected outcome**: Service layer handles all business logic correctly
- **Expected outcome**: HTTP layer handles all business logic correctly
### Task 3.2: Input Validation
- [ ] **Files**: `backend/src/services/validation.rs`, update task_service.rs
- Add comprehensive input validation
- Validate required fields, field lengths, date formats
- [x] **Files**: `backend/src/services/tasks.rs`, `backend/src/models/task.rs`
- Add comprehensive input validation in handlers and model methods
- Validate required fields, field lengths
- Create custom error types for validation failures
- Add validation for business rules
- **Expected outcome**: Invalid inputs are rejected with clear error messages
### Task 3.3: Service Unit Tests
- [ ] **File**: `backend/tests/unit/task_service_test.rs`
- Test all service methods with valid/invalid inputs
- [x] **File**: `backend/src/models/task.rs` (comprehensive unit tests)
- Test all model methods with valid/invalid inputs
- Test business rule enforcement
- Mock database layer for isolated testing
- Use in-memory database for testing
- Test error handling scenarios
- **Expected outcome**: Service tests achieve >90% coverage
- **Expected outcome**: Model tests provide comprehensive coverage
## Phase 4: HTTP Layer (Days 6-7)
### Task 4.1: Axum Server Setup
- [ ] **File**: `backend/src/main.rs`
- [x] **File**: `backend/src/main.rs`
- Configure Axum application with middleware
- Set up CORS, logging, and error handling middleware
- Set up logging with tracing
- Configure graceful shutdown
- Add application state management
- **Expected outcome**: Server starts and responds to basic requests
### Task 4.2: Health Check Endpoint
- [ ] **File**: `backend/src/handlers/health.rs`
- [x] **File**: `backend/src/main.rs` (health function)
- Implement GET /health endpoint
- Add database connectivity check
- Return proper HTTP status codes and JSON responses
- Include basic system information
- Return basic health status
- Return proper HTTP status codes
- **Expected outcome**: Health endpoint returns 200 OK when system is healthy
### Task 4.3: Task HTTP Handlers
- [ ] **File**: `backend/src/handlers/tasks.rs`
- [x] **File**: `backend/src/services/tasks.rs`
- Implement all task CRUD endpoints:
- `POST /api/tasks` - Create task
- `GET /api/tasks` - List tasks with optional filtering
- `GET /api/tasks` - List tasks
- `GET /api/tasks/{id}` - Get single task
- `PUT /api/tasks/{id}` - Update task
- `PATCH /api/tasks/{id}/status` - Update status only
- `DELETE /api/tasks/{id}` - Delete task
- **Expected outcome**: All endpoints handle requests and return proper responses
### Task 4.4: Error Handling and Middleware
- [ ] **Files**: `backend/src/handlers/mod.rs`, `backend/src/utils/errors.rs`
- Implement global error handler
- Add request logging middleware
- Create proper HTTP error responses
- Add request validation middleware
- [x] **Files**: `backend/src/services/mod.rs`
- Implement global error handler (AppError)
- Add proper HTTP error responses
- Create error conversion traits
- Handle validation and database errors
- **Expected outcome**: Errors are handled gracefully with proper HTTP status codes
### Task 4.5: Integration Tests for HTTP Layer
- [ ] **File**: `backend/tests/integration/tasks_test.rs`
- Test all endpoints with real HTTP requests
- Use test database for each test
- [x] **File**: `backend/tests/api/*.hurl`
- Test all endpoints with real HTTP requests using Hurl
- Use running server for integration tests
- Test success and error scenarios
- Include authentication/authorization if added
- Comprehensive API contract validation
- **Expected outcome**: All integration tests pass
## Phase 5: Testing Infrastructure (Day 8)
### Task 5.1: Hurl API Tests
- [ ] **Files**: `backend/tests/api/health.hurl`, `backend/tests/api/tasks.hurl`
- [x] **Files**: `backend/tests/api/*.hurl`
- Create comprehensive API tests using Hurl
- Test all endpoints with various inputs
- Include negative test cases
- Test API response formats and status codes
- **Expected outcome**: `hurl --test backend/tests/api/*.hurl` passes all tests
- **Expected outcome**: `just test-integration` passes all tests
### Task 5.2: Test Server Orchestration
- [ ] **Files**: Update `justfile`, `backend/tests/integration/common.rs`
- [x] **Files**: Update `justfile`
- Add commands to start/stop test server
- Implement test database management
- Add test data seeding and cleanup
- Implement server startup detection
- Add test runner that manages server lifecycle
- Create test environment isolation
- **Expected outcome**: Tests can run against live server reliably
### Task 5.3: Coverage Reporting
- [ ] **Files**: Update `justfile`, `backend/.gitignore`
- [x] **Files**: Update `justfile`, `backend/Cargo.toml`
- Configure tarpaulin for coverage reporting
- Set up HTML coverage reports
- Add coverage thresholds and CI integration
- Exclude test files from coverage metrics
- Add coverage command to justfile
- Current coverage: 32.41% (35/108 lines)
- **Expected outcome**: `just test-coverage` generates comprehensive coverage report
### Task 5.4: Test Documentation
- [ ] **File**: `backend/tests/README.md`
- [x] **File**: Available in `CLAUDE.md` and this plan
- Document how to run different test types
- Explain test database setup and management
- Document Hurl test structure and conventions
- Add troubleshooting guide for common test issues
- **Expected outcome**: New developers can run all tests successfully
## Phase 6: Documentation & Polish (Day 9)
### Task 6.1: API Documentation
- [ ] **File**: `backend/docs/api.md` or OpenAPI spec
- Document all endpoints with examples
- Include request/response schemas
- Add error response documentation
- Create usage examples and common workflows
- **Expected outcome**: API is fully documented
### Task 6.2: Performance Optimization
- [ ] **Files**: Various optimizations across codebase
- Add database connection pooling optimizations
- Implement request caching where appropriate
- Optimize database queries and indexes
- Add performance benchmarks if needed
- **Expected outcome**: API responds quickly under normal load
### Task 6.3: Final Error Handling Review
- [ ] **Files**: Review all error handling across project
- Ensure all errors have proper HTTP status codes
- Add user-friendly error messages
- Implement proper logging for debugging
- Test error scenarios comprehensively
- **Expected outcome**: All error cases are handled gracefully
### Task 6.4: Project Documentation
- [ ] **File**: `README.md` (project root)
- Add project setup instructions
- Document development workflow
- Include testing instructions
- Add deployment considerations
- **Expected outcome**: New developers can get started quickly
## Dependencies and Key Technologies
### Core Dependencies (Cargo.toml)

98
plan/future_improvements.md Normal file
View file

@ -0,0 +1,98 @@
# Future Improvements
This document tracks architectural improvements and refactoring opportunities identified during development.
## Architecture Refactoring
### Repository + Service Pattern Migration
**Current State**: Using Active Record pattern where TaskModel handles its own persistence and HTTP handlers contain business logic directly.
**Future Improvement**: Migrate to Repository + Service pattern for better separation of concerns:
```rust
// Repository trait for data access abstraction
trait TaskRepository {
async fn create(&self, task: &NewTask) -> Result<Task>;
async fn find_by_id(&self, id: Uuid) -> Result<Option<Task>>;
async fn update(&self, task: &Task) -> Result<Task>;
async fn delete(&self, id: Uuid) -> Result<()>;
async fn list_all(&self) -> Result<Vec<Task>>;
}
// Service layer for business logic
struct TaskService {
repository: Box<dyn TaskRepository>,
}
impl TaskService {
async fn create_task(&self, title: String, description: Option<String>) -> Result<Task> {
// Input validation
// Business rules (e.g., auto-set completed_at when status changes)
// Call repository
}
}
```
**Benefits**:
- Better testability through repository mocking
- Centralized business logic in service layer
- Cleaner separation between data access, business logic, and HTTP handling
- Easier to add complex business rules as the application grows
**Implementation Plan**:
1. Create TaskRepository trait and SqliteTaskRepository implementation
2. Move database operations from TaskModel to repository
3. Create TaskService with business logic
4. Update HTTP handlers to use services instead of models directly
5. Add comprehensive unit tests for service layer with mocked repositories
**Priority**: Medium - Good for maintainability as the codebase grows, but current Active Record pattern works fine for MVP scope.
## Documentation & Polish Enhancements
### API Documentation
**Current State**: API endpoints are documented in Hurl tests and code comments.
**Future Improvement**: Comprehensive API documentation with OpenAPI specification.
**Implementation Plan**:
- Create OpenAPI spec for all endpoints with examples
- Include request/response schemas and validation rules
- Add error response documentation with status codes
- Create usage examples and common workflows
- Generate interactive documentation (Swagger UI)
**Benefits**: Better developer experience, easier API integration, clear contract specifications.
### Enhanced Error Handling
**Current State**: Basic error handling with AppError enum and HTTP status codes.
**Future Improvement**: Production-ready error handling and monitoring.
**Implementation Plan**:
- Enhance error messages with contextual information
- Implement structured logging for debugging
- Add error tracking and monitoring (e.g., Sentry integration)
- Create error response standardization
- Add comprehensive error scenario testing
- Implement graceful degradation patterns
**Benefits**: Better debugging experience, improved monitoring, user-friendly error responses.
### Project Documentation
**Current State**: Basic documentation in CLAUDE.md and plan files.
**Future Improvement**: Comprehensive project documentation for contributors.
**Implementation Plan**:
- Create detailed README.md with setup instructions
- Document development workflow and contribution guidelines
- Add deployment guides for different environments
- Create architecture decision records (ADRs)
- Add troubleshooting guides and FAQs
- Document database schema and migrations
**Benefits**: Easier onboarding for new developers, better maintainability, clear deployment process.
**Priority**: Low-Medium - Important for production deployment and team collaboration, but not critical for MVP functionality.