A command to validate environment configuration files without producing any side effects on the application state.
The main feature specification including:
- Overview and problem statement
- Feature goals
- Proposed solution
- Implementation details
- Definition of done
- Testing strategy
Clarifying questions that need to be answered before implementation:
- Scope and requirements
- Technical approach
- Priority and timeline
- Success criteria
- Risk assessment
Current Phase: Ready for Implementation
Completed:
- ✅ Create feature specification
- ✅ Create questions document
- ✅ Answer clarifying questions
- ✅ Update specification based on answers
- ⏳ Begin implementation
Next Steps:
- Extract validation logic from
CreateCommandHandler - Create
ValidateCommandHandler - Add CLI subcommand
- Write E2E tests
Users and AI agents need a way to validate environment configuration files without modifying application state or checking state-dependent conditions.
Key Points:
- Problem: The
createcommand validates config but also persists it to internal state - there's no way to validate without side effects - Solution: Standalone
validatecommand that checks config-intrinsic validity only - Command:
torrust-tracker-deployer validate --env-file envs/config.json - Status: Ready for implementation
Validation Scope (three levels):
| Level | Type | Included? |
|---|---|---|
| 1 | Syntactic (JSON valid, types correct) | ✅ Yes |
| 2 | Config-intrinsic semantics (e.g., Grafana requires Prometheus) | ✅ Yes |
| 3 | State-dependent semantics (e.g., name already exists) | ❌ No |
Design Decision: Chose validate command over --dry-run flag because:
validate= "Is this configuration intrinsically valid?" (pure, deterministic)--dry-run= "Willcreatesucceed right now?" (state-dependent - different promise)- The same config may be valid in one data directory but conflict in another
createhas minimal side effects (internal state only, easily reversible withdestroy)