# Contributing to Dense-Evolution

Thanks for considering a contribution. This is a single-maintainer project — response times may vary, but every issue and PR gets read.

## Before you start

Dense-Evolution is released under the [Business Source License 1.1](https://github.com/tatopenn-cell/Dense-Evolution/blob/main/license.md) — free for non-commercial use, with commercial-production terms defined in the license itself (converting to Apache 2.0 on the Change Date stated there). By submitting a contribution, you agree it's licensed under the same terms as the rest of the project.

## Reporting bugs

Open an [issue](https://github.com/tatopenn-cell/Dense-Evolution/issues) with:
- A minimal circuit/script that reproduces the problem
- What you expected vs. what actually happened
- `python -c "import dense_evolution; print(dense_evolution.__version__)"` output, plus your Python version and OS

If it's a correctness bug (wrong probabilities, wrong statevector, silently dropped gates), include a comparison against a known-correct reference if you have one — that's usually the fastest way to confirm and fix it.

## Reporting security issues

**Don't open a public issue for security vulnerabilities.** See [SECURITY.md](https://github.com/tatopenn-cell/Dense-Evolution/blob/main/SECURITY.md).

## Development setup

```bash
git clone https://github.com/tatopenn-cell/Dense-Evolution.git
cd Dense-Evolution
pip install -e .[full]
```

## Running tests

```bash
pytest test_dense_evolution.py test_ia_healing.py test_dashboard_core.py test_ai_middleware.py test_interop.py test_autodiff.py test_quantum_scars.py test_mitigation.py test_mps.py test_mitigation_runner.py test_interactive_panel.py test_docs_examples.py -v
```

`test_interop.py` needs `qiskit`/`pennylane` installed (skips cleanly via `pytest.importorskip` if they aren't). CI (`.github/workflows/ci.yml`) runs the full suite on Python 3.10/3.11/3.12 on every push/PR to `main` — check it's green before asking for a review.

## Making changes

- Match the existing code style — no comments explaining *what* code does (names should do that); comments only for non-obvious *why* (a workaround, an invariant, a hard-won bug fix).
- Add tests for anything you fix or add — especially anything numerical (statevector/probability outputs). A test that would have caught the bug you just fixed is worth more than a description of the fix.
- Update `README.md`'s changelog section if your change is user-visible.
- Keep PRs focused — one fix or one feature per PR is easier to review than a bundle of unrelated changes.

## Submitting a PR

Push to a branch on your fork, open a PR against `main`, and describe *why* the change is needed, not just what it does — the "why" is what a reviewer (and future you) actually needs.