From 4fce8a5004324df7797be4ff34482d8026089aac Mon Sep 17 00:00:00 2001 From: Argenis Date: Sat, 14 Feb 2026 14:13:58 -0500 Subject: [PATCH] Add ZeroClaw Code Style Guide This document outlines the code style guide for the ZeroClaw project, focusing on security, memory safety, and Rust best practices during code reviews. --- .gemini/style-guide.md | 89 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 89 insertions(+) create mode 100644 .gemini/style-guide.md diff --git a/.gemini/style-guide.md b/.gemini/style-guide.md new file mode 100644 index 0000000..013f3c1 --- /dev/null +++ b/.gemini/style-guide.md @@ -0,0 +1,89 @@ +# ZeroClaw Code Style Guide + +This style guide provides instructions for Gemini Code Assist when reviewing pull requests for the ZeroClaw project. + +## Project Overview + +ZeroClaw 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