zeroclaw/.gemini/style-guide.md
Argenis 4fce8a5004
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.
2026-02-14 14:13:58 -05:00

3.2 KiB

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