Tests verify serialization and deserialization of RelayState enum with
"on" and "off" states. Red phase of TDD - tests define expected behavior
before implementation.
Ref: T019 (specs/001-modbus-relay-control/tasks.md)
Implement smart constructor that validates relay IDs are within valid
range (1-8 for 8-channel relay controller). Add accessor method as_u8()
for safe access to inner value. Add comprehensive documentation to satisfy
clippy requirements.
TDD green phase: Tests from T017 now pass.
Ref: T018 (specs/001-modbus-relay-control/tasks.md)
Add comprehensive CORS configuration section to CLAUDE.md including:
- Implementation patterns with From<CorsSettings> trait
- Development and production configuration examples
- Security constraints and fail-safe defaults
- Test coverage documentation (15 tests)
- Updated project structure showing CORS-related files
- Updated technology stack and active specification list
Updated tasks.md to reflect Phase 0.5 completion (T009-T016).
Phase: 0.5 - CORS Configuration & Production Security (Complete)
Replace Cors::new() with Cors::from(value.settings.cors.clone()) in the
From<Application> for RunnableApplication implementation to use CORS
settings from configuration instead of hardcoded defaults.
Changes:
- Use From<CorsSettings> for Cors trait to build CORS middleware
- Add unit test verifying CORS middleware uses settings
- Maintain correct middleware order: RateLimit → CORS → Data
Ref: T015
Implement From<CorsSettings> for Cors trait to configure CORS middleware
with production-ready security validation.
- Move CorsSettings to backend/src/settings/cors.rs module
- Validate wildcard + credentials constraint (browser security policy)
- Configure allowed methods, headers, credentials, and max_age
- Add structured logging for CORS configuration
- Move tests from settings/mod.rs and startup.rs to cors module
Ref: T014
Add failing test cases for the CORS configuration builder function.
Tests verify correct initialization of CorsSettings with allowed origins,
credentials, and max age configuration. These tests fail until build_cors()
is implemented in the green phase.
Ref: T013 (specs/001-modbus-relay-control)
Set up CORS policy to allow requests from frontend development server and
update development.yaml with proper frontend origin URL configuration.
Ref: T011 (specs/001-modbus-relay-control)
Implements CorsSettings struct with validation and deserialization support
for configuring Cross-Origin Resource Sharing in the application settings.
Ref: T010 (specs/001-modbus-relay-control)
Add comprehensive CORS planning documentation and task breakdown for
Phase 0.5 (8 tasks: T009-T016).
- Create research-cors.md with security analysis and decisions
- Add FR-022a to spec.md for production CORS requirements
- Update tasks.md: 94 → 102 tasks across 9 phases
- Document CORS in README and plan.md
Configuration approach: hybrid (configurable origins/credentials,
hardcoded methods/headers) with restrictive fail-safe defaults.
Create type-safe TypeScript API client automatically generated from the
OpenAPI specification. Includes generated schema types and documented client
wrapper for type-safe backend communication.
Ref: T008 (specs/001-modbus-relay-control)
Convert project from single backend to monorepo structure with separate
frontend (Vue 3 + TypeScript + Vite) and backend directories. Updates
all configuration files and build system to support both workspaces.
Ref: T007 (specs/001-modbus-relay-control)
- Add domain types: RelayId newtype and RepositoryError enum
- Implement SqliteRelayLabelRepository with in-memory test support
- Create relay_labels migration with SQLx compile-time verification
- Add comprehensive integration test suite (266 lines)
Ref: T006 (specs/001-modbus-relay-control)
Add ModbusSettings with host, port, slave_id, and timeout_secs fields.
Add RelaySettings with label_max_length field.
Integrate both into Settings struct and load from settings/base.yaml
with test Modbus TCP configuration.
Ref: T003 (specs/001-modbus-relay-control)
Switch from Modbus RTU over TCP to native Modbus TCP based on hardware
testing. Uses standard MBAP header (no CRC16), port 502, and TCP-only
tokio-modbus feature for simpler implementation.
Updated: Cargo.toml, plan.md, research.md, tasks.md
Establish foundational module hierarchy following hexagonal architecture
(clean architecture) patterns: domain, application, infrastructure, and
presentation layers. Each module includes comprehensive documentation
explaining its architectural role and responsibilities.
Ref: T002 (specs/001-modbus-relay-control)
Adds tokio-modbus 0.17.0 for Modbus RTU over TCP communication,
sqlx with runtime-tokio and sqlite features for async database operations,
mockall 0.13 for trait mocking in tests, and async-trait 0.1 for async trait support.
Ref: T001 (specs/001-modbus-relay-control)
Initialize project documentation structure:
- Add CLAUDE.md with development guidelines and architecture principles
- Add project constitution (v1.1.0) with hexagonal architecture and SOLID principles
- Add MCP server configuration for Context7 integration
Feature specification (001-modbus-relay-control):
- Complete feature spec for web-based Modbus relay control system
- Implementation plan with TDD approach using SQLx for persistence
- Type-driven development design for domain types
- Technical decisions document (SQLx over rusqlite, SQLite persistence)
- Detailed task breakdown (94 tasks across 8 phases)
- Specification templates for future features
Documentation:
- Modbus POE ETH Relay hardware documentation
- Modbus Application Protocol specification (PDF)
Project uses SQLx for compile-time verified SQL queries, aligned with
type-driven development principles.
