# Contributing to dove-core
Thanks for your interest in improving `dove-core`.
## AI contributions are welcome
This project is built with AI in the loop, and **AI-assisted and AI-authored
contributions are explicitly welcome.** How a change was written makes no
difference to how it's evaluated — the bar is the same for everyone:
- The change is correct and does what it claims.
- It's covered by tests where that makes sense.
- It doesn't weaken the security model (see below and
[docs/DESIGN.md](docs/DESIGN.md)).
- You understand and stand behind what you're submitting. If an AI wrote it,
you're still the one vouching for it — review it as if you'd written it by
hand.
You don't need to disclose that AI was involved. Please **don't** open
low-effort, unreviewed, machine-generated PRs in bulk — that wastes maintainer
time regardless of who or what authored them.
## Security-sensitive by nature
dove-core is a cryptographic library. Changes to the encryption/chunking
scheme, key handling, the URL-fragment boundary, the access-policy gate, or
provisioned IAM deserve **extra care and a clear explanation in the PR** of
why they're safe. When in doubt, open an issue first. Never report a
vulnerability in a public PR or issue — see [SECURITY.md](SECURITY.md).
## It's a library, not a binary
`dove-core` does **no terminal I/O of its own** — no `println!`, no
`eprintln!`, no reading from stdin. It takes fully-resolved inputs and
reports progress through the [`Progress`](src/progress.rs) trait instead.
`tests/no_io.rs` enforces this with a grep test that fails the build if
terminal I/O creeps back in — keep it passing.
This crate is consumed by the [`dove`](https://github.com/boomctl/dove) CLI
and by the Dove desktop app. Both drive the exact same logic through this
library, so:
- Don't add anything that assumes a terminal, a prompt, or a specific front
end. If a change needs user interaction, that interaction belongs in the
caller; `dove-core` should take the resolved answer as an argument.
- Keys and secrets never leave a function as raw values on their own —
operations that produce a shareable artifact return the *finished* thing
(e.g. `share` returns the complete link with the key already in the
fragment), so no caller has to know where secret material lives.
## Ground rules
- **Never commit secrets.** No credentials, tokens, private keys, or real
`config.toml`. The `.gitignore` guards the common cases, but check your
diff.
- **Keep it generic.** No personal hostnames, account IDs, bucket names, or
domains in source — those belong in config.
- **Tests:** add or update tests for behavior changes; make sure the suite
passes. Crypto and parity changes especially need a test that would have
caught the bug — see `tests/parity.rs` and `tests/browser_crypto_compat.rs`
for the shape golden/parity tests take here.
## Before you open a PR
The CI gate mirrors what you should run locally:
```sh
cargo fmt --check
cargo clippy --all-targets -- -D warnings
cargo test
cargo deny check # supply-chain: licenses + advisories
```
## Getting started
1. Read [docs/DESIGN.md](docs/DESIGN.md) for the architecture, the module
map, and the `Transfer`/backend-registry design, and
[docs/REQUEST.md](docs/REQUEST.md) for the file-request design. Both cover
the threat model.
2. Open an issue to discuss anything non-trivial before you build it.
3. Fork, branch, and open a PR with a clear description of the change and how
you verified it.
By contributing, you agree that your contributions are licensed under the
project's [Apache-2.0](LICENSE) license.