provisioning/CONTRIBUTING.md

Contributing to provisioning\n\nThank you for your interest in contributing! This document provides guidelines and instructions for contributing to this project.\n\n## Code of Conduct\n\nThis project adheres to a Code of Conduct. By participating, you are expected to uphold this code. Please see CODE_OF_CONDUCT.md for details.\n\n## Getting Started\n\n### Prerequisites\n\n- Rust 1.70+ (if project uses Rust)\n- NuShell (if project uses Nushell scripts)\n- Git\n\n### Development Setup\n\n1. Fork the repository\n2. Clone your fork: git clone https://repo.jesusperez.pro/jesus/provisioning\n3. Add upstream: git remote add upstream https://repo.jesusperez.pro/jesus/provisioning\n4. Create a branch: git checkout -b feature/your-feature\n\n## Development Workflow\n\n### Before You Code\n\n- Check existing issues and pull requests to avoid duplication\n- Create an issue to discuss major changes before implementing\n- Assign yourself to let others know you're working on it\n\n### Code Standards\n\n#### Rust\n\n- Run cargo fmt --all before committing\n- All code must pass cargo clippy -- -D warnings\n- Write tests for new functionality\n- Maintain 100% documentation coverage for public APIs\n\n#### Nushell\n\n- Validate scripts with nu --ide-check 100 script.nu\n- Follow consistent naming conventions\n- Use type hints where applicable\n\n#### Nickel\n\n- Type check schemas with nickel typecheck\n- Document schema fields with comments\n- Test schema validation\n\n### Commit Guidelines\n\n- Write clear, descriptive commit messages\n- Reference issues with Fixes #123 or Related to #123\n- Keep commits focused on a single concern\n- Use imperative mood: "Add feature" not "Added feature"\n\n### Testing\n\nAll changes must include tests:\n\n\n# Run all tests\ncargo test --workspace\n\n# Run with coverage\ncargo llvm-cov --all-features --lcov\n\n# Run locally before pushing\njust ci-full\n\n\n### Pull Request Process\n\n1. Update documentation for any changed functionality\n2. Add tests for new code\n3. Ensure all CI checks pass\n4. Request review from maintainers\n5. Be responsive to feedback and iterate quickly\n\n## Review Process\n\n- Maintainers will review your PR within 3-5 business days\n- Feedback is constructive and meant to improve the code\n- All discussions should be respectful and professional\n- Once approved, maintainers will merge the PR\n\n## Reporting Bugs\n\nFound a bug? Please file an issue with:\n\n- Title: Clear, descriptive title\n- Description: What happened and what you expected\n- Steps to reproduce: Minimal reproducible example\n- Environment: OS, Rust version, etc.\n- Screenshots: If applicable\n\n## Suggesting Enhancements\n\nHave an idea? Please file an issue with:\n\n- Title: Clear feature title\n- Description: What, why, and how\n- Use cases: Real-world scenarios where this would help\n- Alternative approaches: If you've considered any\n\n## Documentation\n\n- Keep README.md up to date\n- Document public APIs with rustdoc comments\n- Add examples for non-obvious functionality\n- Update CHANGELOG.md with your changes\n\n## Release Process\n\nMaintainers handle releases following semantic versioning:\n\n- MAJOR: Breaking changes\n- MINOR: New features (backward compatible)\n- PATCH: Bug fixes\n\n## Questions?\n\n- Check existing documentation and issues\n- Ask in discussions or open an issue\n- Join our community channels\n\nThank you for contributing!