# Construct Code Style Guide

This style guide provides instructions for Gemini Code Assist when reviewing pull requests for the Construct project.

## Project Overview

Construct is a Rust-based security-focused project that handles encryption, secrets management, and secure configuration. Code reviews should prioritize security, memory safety, and Rust best practices.

## General Principles

### Priority Levels

- **CRITICAL**: Security vulnerabilities, memory safety issues, data leaks
- **HIGH**: Logic errors, incorrect error handling, API misuse
- **MEDIUM**: Code quality, performance concerns, non-idiomatic Rust
- **LOW**: Style issues, documentation improvements, minor refactoring

## Rust-Specific Guidelines

### Memory Safety

1. **Borrowing and Lifetimes**: Verify proper use of borrowing and lifetime annotations
2. **Unsafe Code**: Flag any `unsafe` blocks for careful review - they should be minimal and well-justified
3. **Clone Usage**: Identify unnecessary `.clone()` calls that could be replaced with borrowing
4. **Memory Leaks**: Watch for potential memory leaks in long-running processes

### Error Handling

1. **Result Types**: All fallible operations should return `Result` types
2. **Error Propagation**: Use `?` operator for clean error propagation
3. **Custom Errors**: Ensure custom error types implement appropriate traits
4. **Panic**: Flag any uses of `panic!`, `unwrap()`, or `expect()` in production code

### Security

1. **Cryptography**: Review all crypto code for:
   - Proper key generation and storage
   - Secure random number generation
   - No hardcoded secrets or keys
   - Use of well-vetted crypto libraries

2. **Secrets Management**:
   - Secrets should never be logged
   - Use secure memory wiping when appropriate
   - Validate encryption/decryption implementations

3. **Input Validation**: All external input must be validated

### Code Quality

1. **Documentation**: Public APIs should have doc comments with examples
2. **Tests**: Critical paths should have comprehensive test coverage
3. **Type Safety**: Prefer type-safe abstractions over primitive types
4. **Idiomatic Rust**: Follow Rust API guidelines and conventions

## Project-Specific Rules

### Configuration Management

- Configuration migrations must be backward compatible
- Validate all configuration before applying
- Test migration paths from legacy to new formats

### Dependencies

- Prefer well-maintained crates with security audit history
- Avoid unnecessary dependencies
- Check for known vulnerabilities in dependencies

## Review Focus Areas

When reviewing PRs, pay special attention to:

1. Changes in `src/security/` - highest security scrutiny
2. Configuration migration code - ensure data integrity
3. Error handling paths - verify all edge cases
4. Public API changes - check for breaking changes
5. Test coverage - ensure critical code is tested

## Common Issues to Flag

- Unhandled errors or generic error messages
- Missing input validation
- Hardcoded credentials or secrets
- Unsafe code without justification
- Missing documentation on public APIs
- Inadequate test coverage on security-critical code
- Performance issues (unnecessary allocations, inefficient algorithms)
- Breaking API changes without deprecation warnings
