chore: update from template v0.10.0

.copier-answers.yml

@@ -1,5 +1,5 @@
 # Managed by copier / make init; refreshed on every update. Do not edit.
-_commit: v0.9.1
+_commit: v0.10.0
 _src_path: https://github.com/OO-LD/coregraft
 benchmarks: false
 citation: false

CONTRIBUTING.md

@@ -0,0 +1,63 @@
+# Contributing to coregraft-test-python-min
+
+## Setup
+
+```bash
+make install
+```
+
+Creates the virtual environment and installs the git hooks. Run it once after cloning.
+
+## Before you push
+
+```bash
+make ci
+```
+
+Runs `check`, `test` and `docs-test` in the order CI does, so a green run here means a green run there. See the [README](README.md) for the individual targets.
+
+## Commit messages
+
+This repository uses [Conventional Commits](https://www.conventionalcommits.org/). This is not a style preference: the version number, the changelog and the release notes are **derived** from these messages, so a wrong type produces a wrong version.
+
+```text
+<type>(<optional scope>): <description>
+```
+
+| Type | Use for | Release effect |
+| --- | --- | --- |
+| `feat` | A new capability | Minor version bump |
+| `fix` | A bug fix | Patch version bump |
+| `docs` | Documentation only | None |
+| `test` | Tests only | None |
+| `refactor` | Behaviour-preserving restructuring | None |
+| `perf` | A performance improvement | Patch version bump |
+| `build` | Build system or dependencies | None |
+| `ci` | CI configuration | None |
+| `chore` | Anything else | None |
+
+A breaking change is either `feat!:` or a `BREAKING CHANGE:` footer, and bumps the major version.
+
+Write the description in the imperative and lowercase, with no trailing full stop:
+
+```text
+feat: add a retry policy to the client
+fix(parser): handle an empty payload
+docs: explain the release process
+```
+
+The `commit-msg` hook rejects anything else locally, before it reaches CI. If a commit is refused, fix the message and commit again; nothing was lost.
+
+## Pull requests
+
+Work on a branch and open a pull request. Keep the pull request title conventional too, since a squash merge turns it into the commit message that drives the release.
+
+## Releases
+
+Nothing to do by hand. On merge to `main`, [python-semantic-release](https://python-semantic-release.readthedocs.io/) reads the commits since the last tag, bumps the version, writes `CHANGELOG.md`, tags, and publishes a GitHub release with generated notes. Documentation is published per version at the same time.
+
+If the release workflow reports that it is skipping, this repository has no release App configured yet; see the README.
+
+## Updates from the template
+
+This repository was generated from [coregraft](https://github.com/OO-LD/coregraft) and records the version it came from in `.copier-answers.yml`. A scheduled workflow opens a pull request when the template moves on, replaying template changes on top of your own. Review it like any other pull request, and search for `<<<<<<<` before merging: anything the merge could not resolve is left there deliberately, for a human to decide.

README.md

@@ -25,17 +25,11 @@ Everything else, or `make help` for the full list:
 | `make install` | Creates the environment and installs the git hooks |
 | `make docs` | Serves the documentation locally |
 | `make build` | Builds a wheel into `dist/` |
-| `make benchmark` | Runs the performance benchmarks |
 
 `make check` lints untracked files on purpose: `pre-commit run -a` skips them, which is how a new file passes locally and then fails in CI the moment it is committed.
 
 Commits follow [Conventional Commits](https://www.conventionalcommits.org/); releases, the changelog and versioned documentation are automated on merge to main. Until a release App is configured, the release workflow skips itself instead of failing.
 
-## Benchmarks
-
-`make benchmark` runs the performance benchmarks in `tests/benchmarks/`. On pull requests they also run in CI and upload their results.
-
-To track them over time, create a project on [Bencher](https://bencher.dev) (free for public repositories), add a `BENCHER_API_TOKEN` secret and set `BENCHER_PROJECT` in `.github/workflows/main.yml`. Bencher then comments each pull request with a statistical comparison against the base branch. Without the secret the benchmarks still run; only the tracking step is skipped.
 
 ---