272 lines
6.6 KiB
Markdown
272 lines
6.6 KiB
Markdown
|
|
# syntaxis Best Practices
|
||
|
|
|
||
|
|
## Project-Specific Guidelines
|
||
|
|
|
||
|
|
### 1. Configuration Management
|
||
|
|
- All configuration in TOML files (never hardcoded)
|
||
|
|
- Support environment variable overrides
|
||
|
|
- Validate configuration at startup
|
||
|
|
- Document all configuration options
|
||
|
|
|
||
|
|
Example:
|
||
|
|
```rust
|
||
|
|
#[derive(Deserialize)]
|
||
|
|
pub struct WorkspaceConfig {
|
||
|
|
pub project_root: String,
|
||
|
|
pub database_url: String,
|
||
|
|
pub cache_ttl_secs: u64,
|
||
|
|
}
|
||
|
|
|
||
|
|
let config = WorkspaceConfig::from_file("workspace.toml")?;
|
||
|
|
```
|
||
|
|
|
||
|
|
### 2. Task State Tracking
|
||
|
|
syntaxis-core provides TaskStatus and TaskStateChange for tracking task evolution:
|
||
|
|
|
||
|
|
```rust
|
||
|
|
#[derive(Debug, Clone, Copy)]
|
||
|
|
pub enum TaskStatus {
|
||
|
|
Pending,
|
||
|
|
InProgress,
|
||
|
|
Blocked,
|
||
|
|
Completed,
|
||
|
|
Cancelled,
|
||
|
|
}
|
||
|
|
|
||
|
|
pub struct TaskStateChange {
|
||
|
|
pub id: String,
|
||
|
|
pub task_id: String,
|
||
|
|
pub from_state: TaskStatus,
|
||
|
|
pub to_state: TaskStatus,
|
||
|
|
pub changed_at: DateTime<Utc>,
|
||
|
|
pub changed_by: String,
|
||
|
|
pub reason: Option<String>,
|
||
|
|
pub metadata: serde_json::Value,
|
||
|
|
}
|
||
|
|
```
|
||
|
|
|
||
|
|
### 3. Phase-Based Project Orchestration
|
||
|
|
Projects follow distinct phases defined in PROJECT_RULES.md:
|
||
|
|
|
||
|
|
```rust
|
||
|
|
// Use PhaseManager for orchestration
|
||
|
|
let mut phase_manager = PhaseManager::new(project_id);
|
||
|
|
phase_manager.advance_phase(CurrentPhase::InitialSetup)?;
|
||
|
|
phase_manager.validate_prerequisites()?;
|
||
|
|
```
|
||
|
|
|
||
|
|
### 4. Multi-Interface Consistency
|
||
|
|
Ensure consistency across all interfaces (CLI, TUI, Dashboard, API):
|
||
|
|
|
||
|
|
- Same error messages and codes
|
||
|
|
- Consistent naming conventions
|
||
|
|
- Unified configuration
|
||
|
|
- Shared domain models (syntaxis-core)
|
||
|
|
|
||
|
|
### 5. Database Interaction
|
||
|
|
Use SQLx with proper connection pooling:
|
||
|
|
|
||
|
|
```rust
|
||
|
|
use sqlx::sqlite::SqlitePool;
|
||
|
|
|
||
|
|
let pool = SqlitePool::connect("sqlite:workspace.db").await?;
|
||
|
|
let project = sqlx::query!("SELECT * FROM projects WHERE id = ?", project_id)
|
||
|
|
.fetch_one(&pool)
|
||
|
|
.await?;
|
||
|
|
```
|
||
|
|
|
||
|
|
### 6. Error Responses
|
||
|
|
API and CLI errors should be consistent:
|
||
|
|
|
||
|
|
```rust
|
||
|
|
#[derive(Error, Debug)]
|
||
|
|
pub enum WorkspaceError {
|
||
|
|
#[error("Project not found: {0}")]
|
||
|
|
ProjectNotFound(String),
|
||
|
|
|
||
|
|
#[error("Invalid task state transition: {from} -> {to}")]
|
||
|
|
InvalidTransition { from: String, to: String },
|
||
|
|
|
||
|
|
#[error("Database error: {0}")]
|
||
|
|
Database(#[from] sqlx::Error),
|
||
|
|
}
|
||
|
|
```
|
||
|
|
|
||
|
|
### 7. Logging Best Practices
|
||
|
|
Use structured logging throughout:
|
||
|
|
|
||
|
|
```rust
|
||
|
|
use tracing::{info, error, span, Level};
|
||
|
|
|
||
|
|
let span = span!(Level::INFO, "project_creation", project_id = ?id);
|
||
|
|
let _enter = span.enter();
|
||
|
|
info!("Creating new project");
|
||
|
|
|
||
|
|
// Automatic context logging
|
||
|
|
```
|
||
|
|
|
||
|
|
### 8. Testing Strategy
|
||
|
|
- Unit tests for business logic
|
||
|
|
- Integration tests for workflows
|
||
|
|
- Property-based tests for edge cases
|
||
|
|
- Benchmark critical paths
|
||
|
|
|
||
|
|
```rust
|
||
|
|
#[cfg(test)]
|
||
|
|
mod tests {
|
||
|
|
use super::*;
|
||
|
|
|
||
|
|
#[test]
|
||
|
|
fn test_phase_transition() {
|
||
|
|
let mut manager = PhaseManager::new("test");
|
||
|
|
assert!(manager.advance_phase(Phase::InitialSetup).is_ok());
|
||
|
|
}
|
||
|
|
}
|
||
|
|
```
|
||
|
|
|
||
|
|
### 9. Documentation Standards
|
||
|
|
|
||
|
|
**Public APIs must have:**
|
||
|
|
- Clear description of purpose
|
||
|
|
- Parameter documentation
|
||
|
|
- Return type documentation
|
||
|
|
- Example usage
|
||
|
|
- Error conditions
|
||
|
|
|
||
|
|
```rust
|
||
|
|
/// Creates a new project with validation
|
||
|
|
///
|
||
|
|
/// # Arguments
|
||
|
|
/// * `name` - Project name (non-empty)
|
||
|
|
/// * `description` - Project description
|
||
|
|
///
|
||
|
|
/// # Returns
|
||
|
|
/// * `Ok(Project)` - Successfully created project
|
||
|
|
/// * `Err(WorkspaceError)` - If validation fails
|
||
|
|
///
|
||
|
|
/// # Errors
|
||
|
|
/// - `InvalidName` - If name is empty
|
||
|
|
/// - `Database` - If database operation fails
|
||
|
|
///
|
||
|
|
/// # Example
|
||
|
|
/// ```
|
||
|
|
/// let project = ProjectManager::create("my-project", "desc")?;
|
||
|
|
/// ```
|
||
|
|
pub fn create(name: &str, description: &str) -> Result<Project> {
|
||
|
|
// Implementation
|
||
|
|
}
|
||
|
|
```
|
||
|
|
|
||
|
|
### 10. VAPORA Integration Points
|
||
|
|
|
||
|
|
syntaxis is designed for VAPORA integration:
|
||
|
|
|
||
|
|
- Task state changes trigger VAPORA events
|
||
|
|
- Phase transitions notify orchestration engine
|
||
|
|
- Project metadata supports VAPORA requirements
|
||
|
|
- REST API (in progress) will provide integration hooks
|
||
|
|
|
||
|
|
### 11. Code Organization
|
||
|
|
|
||
|
|
Keep related functionality together:
|
||
|
|
|
||
|
|
```
|
||
|
|
syntaxis-core/
|
||
|
|
├── error.rs # Error types
|
||
|
|
├── types/
|
||
|
|
│ ├── project.rs # Project domain
|
||
|
|
│ ├── task.rs # Task domain
|
||
|
|
│ └── phase.rs # Phase domain
|
||
|
|
├── managers/
|
||
|
|
│ ├── project.rs # ProjectManager
|
||
|
|
│ ├── phase.rs # PhaseManager
|
||
|
|
│ └── task.rs # TaskManager
|
||
|
|
├── persistence/
|
||
|
|
│ ├── mod.rs # PersistenceLayer trait
|
||
|
|
│ ├── memory.rs # In-memory implementation
|
||
|
|
│ └── sqlite.rs # SQLite implementation
|
||
|
|
└── lib.rs # Module root & exports
|
||
|
|
```
|
||
|
|
|
||
|
|
### 12. Performance Considerations
|
||
|
|
|
||
|
|
- Use connection pooling for database
|
||
|
|
- Cache frequently accessed data
|
||
|
|
- Lazy load relationships
|
||
|
|
- Profile with flamegraph for hot paths
|
||
|
|
- Benchmark critical operations
|
||
|
|
|
||
|
|
```bash
|
||
|
|
# Profile performance
|
||
|
|
cargo flamegraph --bin syntaxis-cli -- --help
|
||
|
|
|
||
|
|
# Benchmark specific operation
|
||
|
|
cargo bench -p syntaxis-core
|
||
|
|
```
|
||
|
|
|
||
|
|
### 13. Security Practices
|
||
|
|
|
||
|
|
- Never log sensitive data
|
||
|
|
- Validate all user input
|
||
|
|
- Use environment variables for secrets
|
||
|
|
- Audit API access (when API is enabled)
|
||
|
|
- Regular dependency audits
|
||
|
|
|
||
|
|
```bash
|
||
|
|
# Check for vulnerabilities
|
||
|
|
cargo audit
|
||
|
|
|
||
|
|
# Check specific crate
|
||
|
|
cargo audit -p syntaxis-core
|
||
|
|
```
|
||
|
|
|
||
|
|
### 14. Dependency Management
|
||
|
|
|
||
|
|
- Keep dependencies minimal
|
||
|
|
- Use workspace.dependencies for consistency
|
||
|
|
- Pin security-critical versions
|
||
|
|
- Review breaking changes before updates
|
||
|
|
- Document why each dependency is needed
|
||
|
|
|
||
|
|
```toml
|
||
|
|
[workspace.dependencies]
|
||
|
|
serde = { version = "1.0", features = ["derive"] }
|
||
|
|
thiserror = "2.0"
|
||
|
|
tokio = { version = "1", features = ["full"] }
|
||
|
|
```
|
||
|
|
|
||
|
|
### 15. Backward Compatibility
|
||
|
|
|
||
|
|
- Avoid breaking public API changes
|
||
|
|
- Use feature flags for experimental features
|
||
|
|
- Deprecate gradually before removal
|
||
|
|
- Document migration paths for users
|
||
|
|
|
||
|
|
## Quick Reference: Common Tasks
|
||
|
|
|
||
|
|
### Adding a new feature to syntaxis-core
|
||
|
|
1. Create types in `syntaxis-core/src/types/`
|
||
|
|
2. Create manager in `syntaxis-core/src/managers/`
|
||
|
|
3. Add persistence layer support
|
||
|
|
4. Write 15+ unit tests
|
||
|
|
5. Add integration test to syntaxis-cli
|
||
|
|
6. Update documentation
|
||
|
|
|
||
|
|
### Adding a CLI command
|
||
|
|
1. Create handler in `syntaxis-cli/src/handlers/`
|
||
|
|
2. Wire up in `syntaxis-cli/src/main.rs`
|
||
|
|
3. Test with actual workspace project
|
||
|
|
4. Update help/documentation
|
||
|
|
|
||
|
|
### Adding Dashboard component
|
||
|
|
1. Create component in `syntaxis-dashboard/src/components/`
|
||
|
|
2. Integrate with state in `syntaxis-dashboard/src/state/`
|
||
|
|
3. Write HTML rendering tests
|
||
|
|
4. Test in browser at http://localhost:3000
|
||
|
|
|
||
|
|
## For Details
|
||
|
|
|
||
|
|
- [PROJECT_RULES.md](./.claude/PROJECT_RULES.md) - Architecture & standards
|
||
|
|
- [CODE_STANDARDS.md](./.claude/CODE_STANDARDS.md) - Testing & verification
|
||
|
|
- [DEVELOPMENT.md](./.claude/DEVELOPMENT.md) - Development workflow
|