CONTRIBUTING.md

Rama main · réplica de lectura del repositorio original.

# Contributing to Iris Core

Thank you for your interest in contributing to Iris Core! This document provides guidelines and instructions for contributing.

## Code of Conduct

By participating in this project, you agree to maintain a respectful and inclusive environment for all contributors.

## How to Contribute

### Reporting Bugs

If you find a bug, please create an issue with:
- Clear description of the problem
- Steps to reproduce
- Expected vs actual behavior
- Environment details (OS, provider, model)
- Relevant logs or error messages

### Suggesting Features

Feature suggestions are welcome! Please create an issue describing:
- The use case or problem it solves
- Proposed solution or API
- Alternative approaches considered
- Impact on existing functionality

### Submitting Pull Requests

1. **Fork the repository** and create a branch from `main`
2. **Make your changes** following our coding standards
3. **Test thoroughly** - run `npm test` in `iris-runtime/`; for bootstrap/skill changes, verify on a clean VM
4. **Update the changelog and docs** - behavior-changing PRs must update `iris-runtime/CHANGELOG.md` (under `[Unreleased]`) and the relevant `docs/` page or README **in the same PR**. The docs-guard CI workflow fails PRs that don't; maintainers can apply the `changelog-not-needed` / `docs-not-needed` labels when a change is genuinely invisible to operators.
5. **Write clear commit messages** - explain what and why
6. **Submit a PR** with:
   - Description of changes
   - Related issue numbers
   - Testing performed
   - Screenshots (for UI changes)

### Development Setup

```bash
# Clone your fork
git clone https://github.com/your-username/iris-core.git
cd iris-core/iris-runtime

npm install
npm test          # dispatch/secrets/transport regression suite (also run in CI)
npm run build     # type-check + compile

# Iterate locally with a Docker bash sandbox (tsx watch mode):
./dev.sh
```

For end-to-end testing of `bootstrap.sh` or install-path changes, use a clean
Ubuntu 22.04 VM: `bash bootstrap.sh --setup --no-keyvault` (see
[docs/SETUP.md](docs/SETUP.md) for all install paths).

Enable the repo's git hooks (runs `gitleaks` on staged changes before each
commit, same scanner CI runs on the full history):

```bash
git config core.hooksPath scripts/hooks
```

### Coding Standards

**Shell Scripts:**
- Use `#!/usr/bin/env bash` shebang
- Enable strict mode: `set -euo pipefail`
- Quote variables: `"${VARIABLE}"`
- Use meaningful function names
- Add comments for complex logic

**Skills (SKILL.md):**
- Follow existing skill structure
- Include clear usage examples
- Document all parameters
- Specify required secrets/permissions

**Documentation:**
- Keep README.md accurate and up-to-date
- Use clear, concise language
- Include examples for new features
- Update CLAUDE.md for repo-level conventions

### Testing

Before submitting a PR:
- [ ] `npm test` passes in `iris-runtime/` (CI runs it on every PR)
- [ ] Bootstrap script works on a clean Ubuntu VM (for bootstrap/install changes)
- [ ] Skills load without errors
- [ ] No hardcoded secrets or company-specific references
- [ ] `iris-runtime/CHANGELOG.md` and the relevant docs page are updated (docs-guard CI enforces this for behavior changes)
- [ ] Commit messages are clear

### Generalization Guidelines

Iris Core must remain provider-agnostic and company-neutral:
- **No hardcoded infrastructure:** Use environment variables; cloud (Azure/Terraform) is an opt-in profile, never a requirement of the default path
- **No company names:** Replace with `example.com` or `<your-company>`
- **No secrets:** Resolve via env vars / the `get-secret` skill (`GET /secrets/:name`); Azure Key Vault and external brokers are opt-in backends
- **Support multiple providers:** Anthropic, OpenAI, Azure AI Foundry, AWS Bedrock, plus custom OpenAI-compatible endpoints via `data/models.json`

### Skill Development

When adding new skills:
1. Create `skills/your-skill/` directory
2. Add `SKILL.md` with full documentation (YAML frontmatter: `name`, `description`)
3. Test skill loads and executes correctly (skills hot-reload — no restart needed)
4. Ensure skill works across providers (if applicable)
5. Document required secrets by name; resolve them via the `get-secret` skill, not direct env/Key Vault reads
6. Core ships **platform skills only** (operate/extend/heal). Domain and business skills belong in an install's overlay, not in this repo

### Sub-Agent Development

When adding agent templates:
1. Create `agents/agent-name/` scaffold
2. Add agent-specific `MEMORY.md` and `README.md`
3. Keep templates generic (no company-specific logic)
4. Document deployment and testing

## Review Process

1. Maintainers will review your PR for:
   - Code quality and standards compliance
   - Test coverage and documentation
   - Alignment with project goals
2. Address review feedback promptly
3. Once approved, maintainers will merge

## Questions?

- Create a discussion in GitHub Discussions
- Check existing issues and PRs
- Read the full documentation in README.md

## License

By contributing, you agree that your contributions will be licensed under the Apache License 2.0.