Every agent working on this Commander project MUST follow these standards. No exceptions.
<<<<<<< HEAD We use bun run tauri dev to run the app.
You always work on features that are configurable via the Settings Panel in the app. Every feature must be toggleable or adjustable through user preferences. Before you write any code, you will write the PRD and save in the docs/ directory.
Every prompt or request by the user you will create a PRD and store it in the PRD/ folder with a filename that matches the feature name. You will then follow the TDD and architecture patterns below to implement the feature.
f5183e6 (fixing the ui for chat to be default)
src-tauri/src/
├── models/ # Data structures only
├── services/ # Business logic only
├── commands/ # Tauri handlers only (planned)
├── tests/ # Comprehensive tests (MANDATORY)
├── lib.rs # Minimal entry point
└── error.rs # Error types (planned)
-
WRITE TESTS FIRST
⚠️ - Write failing tests that cover your feature
- Include success scenarios
- Include failure scenarios
- Include edge cases
-
RUN TESTS
⚠️ cargo test # Must show new tests failing
For frontend you usually get stuck here, but put a timelimit
bun run test -
IMPLEMENT FEATURE
⚠️ - Write minimal code to pass tests
- Follow modular architecture
- Use proper error handling
-
VERIFY ALL TESTS PASS
⚠️ cargo test # ALL 12+ tests must pass
These tests cover critical functionality and MUST remain passing:
- Git repository validation
- Project creation workflows
- File system operations
- Command integrations
- Error handling
BREAKING ANY EXISTING TEST IS UNACCEPTABLE
For New Features:
- Create test in
tests/commands/ortests/services/ - Implement business logic in
services/ - Add data structures in
models/ - Keep command handlers minimal (when commands/ exists)
For Bug Fixes:
- Write failing test that reproduces bug
- Fix in appropriate service layer
- Verify test passes and no regressions
Code Quality:
- Single responsibility principle
- Proper error handling with Result types
- Clear function documentation
- No business logic in lib.rs
- ❌ Breaking existing tests
- ❌ Adding code without tests
- ❌ Creating monolithic functions
- ❌ Mixing layers (business logic in commands)
- ❌ Skipping
cargo testverification - ❌ Changing modular structure
Before submitting ANY change:
# 1. All tests must pass
cargo test
# ✅ Result: 12+ tests passed
# 2. Code must compile without errors
cargo check
# ✅ Result: No compilation errors
# 3. Application must run
bun tauri dev
# ✅ Result: Application starts successfully- Focus on native integrations in services layer
- Write tests for platform-specific behavior
- Keep Tauri commands minimal - delegate to services
- Apply same TDD principles to any CLI tools
- Integrate with existing test patterns
- Maintain architectural consistency
- Follow frontend standards (preserve dialog widths)
- Test frontend-backend integrations
- Coordinate with Rust backend architecture
- Verify TDD compliance
- Check architectural adherence
- Ensure all tests pass
- Validate modular structure
Every change MUST meet ALL criteria:
- Tests: New tests written and passing ✅
- Architecture: Follows modular pattern ✅
- Quality: No compilation errors ✅
- Regression: All existing tests pass ✅
- Documentation: Changes documented ✅
// Step 1: Write test
#[tokio::test]
async fn test_new_feature_handles_edge_case() {
let result = new_feature_service::handle_edge_case().await;
assert!(result.is_err());
assert_eq!(result.unwrap_err(), "Expected error message");
}
// Step 2: Implement in service
pub async fn handle_edge_case() -> Result<Output, String> {
// Business logic here
Err("Expected error message".to_string())
}
// Step 3: Add command handler (when commands/ exists)
#[tauri::command]
async fn new_feature(input: Input) -> Result<Output, String> {
new_feature_service::handle_edge_case().await
}If you encounter broken tests:
- STOP - Do not proceed with changes
- IDENTIFY - Which test is broken and why
- FIX - Address the root cause
- VERIFY - Ensure all tests pass before continuing
If you need to change architecture:
- DISCUSS - Propose changes in documentation
- PLAN - Ensure migration maintains test coverage
- IMPLEMENT - Follow TDD throughout migration
- VERIFY - All functionality preserved
NO AGENT MAY IGNORE THESE STANDARDS
Every agent is responsible for:
- Writing comprehensive tests
- Following modular architecture
- Ensuring all tests pass
- Maintaining code quality
- Preserving existing functionality
Failure to comply will result in rejected changes and potential system instability.
The Commander project's reliability depends on EVERY agent following these standards without exception.