style: pre-commit fixes

Author: pre-commit-ci[bot]

AGENTS.md

@@ -1,6 +1,8 @@
 # Agent Guide for scientific-python/cookie
 
-This repo has three distinct concerns: a **cookiecutter/copier template** for new Python projects (`{{cookiecutter.project_name}}/`), a **repo-review plugin** (`src/sp_repo_review/`), and a **Jekyll-based developer guide** (`docs/`).
+This repo has three distinct concerns: a **cookiecutter/copier template** for
+new Python projects (`{{cookiecutter.project_name}}/`), a **repo-review plugin**
+(`src/sp_repo_review/`), and a **Jekyll-based developer guide** (`docs/`).
 
 ## Key commands
 
@@ -17,41 +19,58 @@ Important: tests run with `PYTHONWARNDEFAULTENCODING=1`.
 
 ### Cookie template validation
 
-The noxfile generates temporary projects for **all 9 backends** × **vcs on/off** × **3 docs engines** (sphinx/mkdocs/zensical). These are slow.
+The noxfile generates temporary projects for **all 9 backends** × **vcs on/off**
+× **3 docs engines** (sphinx/mkdocs/zensical). These are slow.
 
 - `nox -s "tests(hatch)"` — run generated project tests for a single backend
 - `nox -s "lint(hatch)"` — run pre-commit (`prek`) on generated project
 - `nox -s "dist(hatch)"` — verify build output includes LICENSE
 - `nox -s "native(hatch)"` — test hatch/pdm/poetry native test runners
-- `nox -s compare_copier` — verify cookiecutter and copier produce identical files
+- `nox -s compare_copier` — verify cookiecutter and copier produce identical
+  files
 - `nox -s compare_cruft` — verify cookiecutter and cruft produce identical files
 - `nox -s gha_bump` — bump GitHub Actions versions across docs and templates
 - `nox -s pc_bump` — bump pre-commit hook versions across docs and templates
 
 ## Architecture notes
 
-- **Template directory**: `{{cookiecutter.project_name}}/` contains the cookiecuttter template. Copier reads `copier.yml`; cookiecutter reads `cookiecutter.json`. Keep them in sync; `compare_copier` checks this.
-- **Entry points**: `sp_repo_review` registers `repo-review` checks/families/fixtures via `[project.entry-points]` in `pyproject.toml`.
-- **Generated docs**: The README check list (line ~300+) is a cog block. Do not edit it by hand; run `nox -s readme` or cog will fail in CI.
-- **Cookie template `.pre-commit-config.yaml`** uses `prek` (a Rust-based pre-commit alternative), not `pre-commit`.
-- **Ruff hook ID**: `.pre-commit-config.yaml` uses `ruff-check` as the hook id (not `ruff`), for pre-commit 4.x compatibility.
+- **Template directory**: `{{cookiecutter.project_name}}/` contains the
+  cookiecuttter template. Copier reads `copier.yml`; cookiecutter reads
+  `cookiecutter.json`. Keep them in sync; `compare_copier` checks this.
+- **Entry points**: `sp_repo_review` registers `repo-review`
+  checks/families/fixtures via `[project.entry-points]` in `pyproject.toml`.
+- **Generated docs**: The README check list (line ~300+) is a cog block. Do not
+  edit it by hand; run `nox -s readme` or cog will fail in CI.
+- **Cookie template `.pre-commit-config.yaml`** uses `prek` (a Rust-based
+  pre-commit alternative), not `pre-commit`.
+- **Ruff hook ID**: `.pre-commit-config.yaml` uses `ruff-check` as the hook id
+  (not `ruff`), for pre-commit 4.x compatibility.
 
 ## Style and conventions
 
-- `tool.pytest.ini_options.norecursedirs` excludes `{{cookiecutter.project_name}}` so pytest does not descend into the template directory.
-- `tool.ruff.extend-exclude` also excludes `\{\{cookiecutter.project_name\}\}` (double-escaped in TOML).
-- `tool.mypy.python_version = "3.10"`; the `sp_repo_review.*` override enforces `disallow_untyped_defs=True`.
-- `tool.pylint.master.ignore-paths` ignores `src/sp_repo_review/_version.py` (auto-generated by hatch-vcs).
-- Ruff selects `ALL` with many ignores; notable: `S101` (assert) and `D` (docstrings) are globally disabled.
+- `tool.pytest.ini_options.norecursedirs` excludes
+  `{{cookiecutter.project_name}}` so pytest does not descend into the template
+  directory.
+- `tool.ruff.extend-exclude` also excludes `\{\{cookiecutter.project_name\}\}`
+  (double-escaped in TOML).
+- `tool.mypy.python_version = "3.10"`; the `sp_repo_review.*` override enforces
+  `disallow_untyped_defs=True`.
+- `tool.pylint.master.ignore-paths` ignores `src/sp_repo_review/_version.py`
+  (auto-generated by hatch-vcs).
+- Ruff selects `ALL` with many ignores; notable: `S101` (assert) and `D`
+  (docstrings) are globally disabled.
 
 ## CI quirks
 
-- CI uses change detection to decide whether to run cookie tests or rr-tests. Both are required to pass for the `pass` job.
+- CI uses change detection to decide whether to run cookie tests or rr-tests.
+  Both are required to pass for the `pass` job.
 - rr-tests matrix runs on Python 3.10, 3.12, 3.14 across ubuntu/macos/windows.
 - Cookie tests reuse the same `reusable-cookie.yml` workflow.
 
 ## Docs site (Jekyll)
 
-- Ruby-based; uses `rbenv` + `bundle install` + `bundle exec jekyll serve --livereload`.
+- Ruby-based; uses `rbenv` + `bundle install` +
+  `bundle exec jekyll serve --livereload`.
 - There is a helper script `helpers/fetch_repo_review_app.sh`.
-- Docs pages in `docs/pages/` contain inline cog blocks that auto-generate config examples from the template.
+- Docs pages in `docs/pages/` contain inline cog blocks that auto-generate
+  config examples from the template.

docs/pages/guides/coverage.md

@@ -21,16 +21,14 @@ Tools and libraries used to calculate, read, and visualize coverage reports:
 - `GitHub Actions`: allows users to automatically upload coverage reports to
   `Codecov`
 
-:::{note} Are there any alternatives?
-Coveralls is an alternative coverage platform, but we recommend using Codecov
-because of its ease of use and integration with GitHub Actions.
-:::
+:::{note} Are there any alternatives? Coveralls is an alternative coverage
+platform, but we recommend using Codecov because of its ease of use and
+integration with GitHub Actions. :::
 
-:::{tip} Should increasing the coverage value be my top priority?
-A low coverage percentage will definitely motivate you to add more tests, but
-adding weak tests just for coverage's sake is not a good idea. The tests
-should test your codebase thoroughly and should not be unreliable.
-:::
+:::{tip} Should increasing the coverage value be my top priority? A low coverage
+percentage will definitely motivate you to add more tests, but adding weak tests
+just for coverage's sake is not a good idea. The tests should test your codebase
+thoroughly and should not be unreliable. :::
 
 ### Running your tests with coverage
 
@@ -43,10 +41,8 @@ directly is hidden away from normal use, so we recommend that, but will show
 both methods below. If you are not running `pytest`, but instead are running an
 example or a script, you have to use `coverage` directly.
 
-::::{tab-set}
-:::{tab-item} coverage
-:sync: coverage-tool
-Make sure you install `coverage[toml]`.
+::::{tab-set} :::{tab-item} coverage :sync: coverage-tool Make sure you install
+`coverage[toml]`.
 
 `coverage` has several commands; the most important one is `coverage run`. This
 will run any Python process and collect coverage, generating a `.coverage` file
@@ -65,11 +61,8 @@ coverage report
 ```
 
 This looks for a `.coverage` file and displays the result. There are many output
-formats for reports.
-:::
-:::{tab-item} pytest-cov
-:sync: coverage-tool
-Make sure you install `pytest-cov`.
+formats for reports. ::: :::{tab-item} pytest-cov :sync: coverage-tool Make sure
+you install `pytest-cov`.
 
 `pytest` allows users to pass the `--cov` option to automatically invoke
 `pytest-cov`, which then generates a `.coverage` file with the calculated
@@ -88,9 +81,7 @@ See the [docs](https://pytest-cov.readthedocs.io/en/latest/) for more options.
 
 Coverage pytest arguments can be placed in your pytest configuration file or in
 your task runner. It also will (mostly) respect the coverage configuration,
-shown below.
-:::
-::::
+shown below. ::: ::::
 
 ### Configuring coverage
 
@@ -149,9 +140,8 @@ manually produce multiple files from task runner jobs.
 
 Here's an example nox job:
 
-::::{tab-set}
-:::{tab-item} coverage
-:sync: coverage-tool
+::::{tab-set} :::{tab-item} coverage :sync: coverage-tool
+
 ```python
     session.run(
         "coverage",
@@ -162,18 +152,18 @@ Here's an example nox job:
         env={"COVERAGE_FILE": coverage_file},
     )
 ```
-:::
-:::{tab-item} pytest-cov
-:sync: coverage-tool
+
+::: :::{tab-item} pytest-cov :sync: coverage-tool
+
 ```python
         "--cov=<package_name>",
         "--cov-config=pyproject.toml",
         *session.posargs,
         env={"COVERAGE_FILE": coverage_file},
     )
 ```
-:::
-::::
+
+::: ::::
 
 #### Merging and reporting
 
@@ -207,7 +197,6 @@ uploading coverage reports easy for users. A minimal working example for
 uploading coverage reports through your workflow, which should be more than
 enough for a simple testing suite, can be written as follows:
 
-
 ```yaml
 - name: Upload coverage report
   uses: codecov/codecov-action@v6