Contributing

The canonical contribution guide lives in the repository: CONTRIBUTING.md. This page summarises it.

Development setup

git clone https://github.com/Lexsi-Labs/CuratorKIT.git
cd CuratorKIT
pip install -e ".[dev]"
pre-commit install

Both checks must pass before a PR can merge:

ruff check .            # lint
pytest tests/unit -q    # unit tests; run without heavy extras, external deps are mocked

Strict mypy is configured and adopted incrementally; it is encouraged, not gating.

Adding a component

Every pipeline stage implements one of four small ABCs in curatorkit/interfaces.py:

ABC	Contract	Implementations
BaseReader	read() -> (samples, rejected)	curatorkit/connectors/
BaseGate	run(samples) -> (passed, rejected)	curatorkit/gates/, curatorkit/hygiene/
BaseNormalizer	run(samples) -> samples	curatorkit/normalizers/
BaseExporter	export(samples, output_dir)	curatorkit/exporters/

Read the architecture reference before starting. A complete change includes the implementation, wiring through CuratorConfig or the YAML config, unit tests, and an update to the matching guide, in particular the configuration reference for any CuratorConfig change.

Conventions

• PR titles follow Conventional Commits (feat:, fix:, docs:, …).
• Behaviour changes need tests.
• Add a changelog entry under the Unreleased heading.
• Docs pages use British spelling; keep each file internally consistent.

Where to ask

Questions go to GitHub Discussions; bugs to Issues. Security issues are never filed publicly; see SECURITY.md. Participation is governed by the Code of Conduct.