feat: refactor sgclaw around zeroclaw compat runtime

third_party/zeroclaw/.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