benchmatrix 0.2.1__tar.gz → 0.2.4__tar.gz

{benchmatrix-0.2.1 → benchmatrix-0.2.4}/CHANGELOG.md

@@ -12,12 +12,44 @@ additional pre-1.0 compatibility expectations described in
 
 ### Changed
 
+### Deprecated
+
+### Removed
+
+### Fixed
+
+### Security
+
+## 0.2.4 - 2026-06-24
+
+### Fixed
+
+* Check out repository for context of `release` workflow
+
+## 0.2.3 - 2026-06-23
+
+### Fixed
+
+* Ensure all assets uploaded to draft GitHub release
+
+## 0.2.2 - 2026-06-23
+
+### Changed
+
+* Change documentation site from built-in MkDocs theme to Material theme
+* Automate several steps of the release process
+
+### Fixed
+
+* Ensure all assets, including wheels and SBOMs attached to GitHub releases
+* Standardize Markdown formatting on four spaces for indentation
+
 ## 0.2.1 - 2026-06-22
 
 ### Changed
 
 * Fix release and release-verify workflow bugs preventing creation of PyPI
-  releases.
+    releases.
 
 ## 0.2.0 - 2026-06-22
 
@@ -26,31 +58,31 @@ additional pre-1.0 compatibility expectations described in
 * Initial benchmark matrix utilities.
 * pytest-benchmark JSON parsing and display utilities.
 * Automated linting, typing, security, dependency, test, coverage, and package
-  validation for local development and pull requests, including scheduled
-  audits of locked dependencies for known vulnerabilities.
+    validation for local development and pull requests, including scheduled
+    audits of locked dependencies for known vulnerabilities.
 * Pre-commit automation, secret scanning, Markdown linting, GitHub Actions
-  workflow linting, and repository text and binary file attributes.
+    workflow linting, and repository text and binary file attributes.
 * MkDocs documentation site with strict builds, generated API reference pages,
-  and operational maintainer runbooks.
+    and operational maintainer runbooks.
 * Reproducible CycloneDX SBOM generation for locked runtime dependencies.
 * uv-backed nox automation for supported-Python tests, quality checks, and
-  release artifact smoke testing.
+    release artifact smoke testing.
 * GitHub pull request auto-labeling and labels-as-code configuration for
-  maintainers.
+    maintainers.
 * Dependabot automation for Python, Node, pre-commit, GitHub Actions, Docker,
-  and devcontainer dependency updates.
+    and devcontainer dependency updates.
 * Repository settings-as-code plus external setup checklists for branch
-  protection, security features, Pages, environments, and PyPI publishing.
+    protection, security features, Pages, environments, and PyPI publishing.
 * Focused Python dependency groups for test, lint, type, docs, security,
-  release, and automation tooling, with `dev` as the aggregate group.
+    release, and automation tooling, with `dev` as the aggregate group.
 * Compatibility, lifecycle, security-fix, release-branch, and deprecation
-  policy documentation.
+    policy documentation.
 * GitHub Actions CI/CD workflows for quality checks, multi-version and
-  cross-OS tests, docs deployment, PyPI Trusted Publishing, artifact
-  attestations, CodeQL, dependency review, OpenSSF Scorecard, and workflow
-  linting.
+    cross-OS tests, docs deployment, PyPI Trusted Publishing, artifact
+    attestations, CodeQL, dependency review, OpenSSF Scorecard, and workflow
+    linting.
 * CI test and coverage report artifacts, documentation link checking, minimum-
-  dependency tests, and post-release PyPI installation verification.
+    dependency tests, and post-release PyPI installation verification.
 * Docker runtime and test images, local Docker targets, Docker-outside-of-Docker
-  devcontainer support, Dockerfile linting, GHCR publishing, image
-  SBOM/provenance, and critical-vulnerability image scanning.
+    devcontainer support, Dockerfile linting, GHCR publishing, image
+    SBOM/provenance, and critical-vulnerability image scanning.

{benchmatrix-0.2.1 → benchmatrix-0.2.4}/CITATION.cff

@@ -10,8 +10,8 @@ authors:
     given-names: "Ryan"
     email: "ryancswallace@gmail.com"
     alias: "ryancswallace"
-version: 0.2.1
-date-released: "2026-06-22"
+version: 0.2.4
+date-released: "2026-06-24"
 license: MIT
 repository-code: "https://github.com/ryancswallace/benchmatrix"
 url: "https://github.com/ryancswallace/benchmatrix"

{benchmatrix-0.2.1 → benchmatrix-0.2.4}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: benchmatrix
-Version: 0.2.1
+Version: 0.2.4
 Summary: A pytest-benchmark matrix, metadata, and JSON results layer.
 Project-URL: Homepage, https://github.com/ryancswallace/benchmatrix
 Project-URL: Changelog, https://github.com/ryancswallace/benchmatrix/blob/main/CHANGELOG.md
@@ -119,11 +119,16 @@ For local development from this repository:
 make ready
 ```
 
-To try the package from another project before the first PyPI release, install
-from GitHub:
+To install the latest release from PyPI:
 
 ```bash
-uv add "benchmatrix @ git+https://github.com/ryancswallace/benchmatrix"
+uv add benchmatrix
+```
+
+or
+
+```bash
+pip install benchmatrix
 ```
 
 ## Documentation

{benchmatrix-0.2.1 → benchmatrix-0.2.4}/README.md

@@ -88,11 +88,16 @@ For local development from this repository:
 make ready
 ```
 
-To try the package from another project before the first PyPI release, install
-from GitHub:
+To install the latest release from PyPI:
 
 ```bash
-uv add "benchmatrix @ git+https://github.com/ryancswallace/benchmatrix"
+uv add benchmatrix
+```
+
+or
+
+```bash
+pip install benchmatrix
 ```
 
 ## Documentation

benchmatrix-0.2.4/RELEASING.md

@@ -0,0 +1,28 @@
+# Release policy
+
+benchmatrix uses [Semantic Versioning](https://semver.org/).
+
+## Compatibility
+
+While the project is pre-1.0:
+
+* patch releases contain compatible fixes and documentation improvements;
+* minor releases may introduce breaking API changes;
+* breaking changes should be called out clearly in the changelog.
+
+Starting with 1.0, incompatible public API changes require a major release.
+The supported public API is the set of names exported from
+`benchmatrix.__init__`. Private modules and names beginning with an underscore
+are not covered by the compatibility guarantee.
+
+Python version support may change in a minor release before 1.0 and in a major
+release after 1.0. Dropping a Python version will be documented in advance when
+practical.
+
+Release branches are not maintained as standing support branches. The active
+support branch is `main`; temporary release or security branches may be used for
+coordination and retired after release.
+
+## Release process
+
+See the detailed operational checklist in `docs/runbooks/release.md`.

{benchmatrix-0.2.1 → benchmatrix-0.2.4}/docs/explanation/architecture.md

@@ -14,7 +14,7 @@ replace its calibration, timing, statistics, terminal reporting, or JSON export.
 * `bench_results.py` parses and displays saved benchmark results.
 * `exceptions.py` contains package-specific exceptions.
 * `_schema.py` is a private schema constant module shared by implementation
-  code.
+    code.
 * `__init__.py` defines the public package exports.
 
 ## Design constraints

{benchmatrix-0.2.1 → benchmatrix-0.2.4}/docs/explanation/deprecations.md

@@ -15,7 +15,7 @@ Deprecation is not required for:
 * private names beginning with `_`;
 * undocumented implementation details;
 * behavior that is removed immediately for security or serious correctness
-  reasons.
+    reasons.
 
 ## Timing
 
@@ -39,7 +39,7 @@ major release unless release notes document a narrower exception.
 
 1. confirm the changelog mentioned the deprecation;
 2. confirm the removal timing has arrived or the security/correctness exception
-   applies;
+     applies;
 3. remove the behavior and tests together;
 4. update API docs, tutorials, examples, and compatibility notes;
 5. run `make check` and `make test-matrix`.

{benchmatrix-0.2.1 → benchmatrix-0.2.4}/docs/explanation/first-release.md

@@ -14,11 +14,11 @@ structure to support users after publication.
 * the built wheel can be installed and imported in a clean environment;
 * changelog has a dated version section;
 * `pyproject.toml`, `CITATION.cff`, the Git tag, and release notes use the same
-  version;
+    version;
 * security and support policies are present;
 * the GitHub `pypi` environment exists with trusted maintainer reviewers;
 * PyPI Trusted Publishing is configured for `release.yml` and the `pypi`
-  environment;
+    environment;
 * a maintainer knows how to verify the package after PyPI publication.
 
 If any item is missing, fix it before uploading artifacts. A delayed first

{benchmatrix-0.2.1 → benchmatrix-0.2.4}/docs/explanation/github-actions-security.md

@@ -7,21 +7,21 @@ CI should verify project health without granting unnecessary write access.
 * Default workflow permissions are read-only.
 * Checkout does not persist credentials unless a job needs to push.
 * The pull request labeler uses `pull_request_target` without checkout and only
-  receives the permission needed to add existing pull request labels.
+    receives the permission needed to add existing pull request labels.
 * Workflow actions use carefully versioned refs and Dependabot updates. The
-  `.github/zizmor.yml` policy records this choice and disables only zizmor's
-  SHA-pinning audit until the project adopts full action SHA pinning.
+    `.github/zizmor.yml` policy records this choice and disables only zizmor's
+    SHA-pinning audit until the project adopts full action SHA pinning.
 * Scheduled audits are separated from normal pull request validation.
 * Documentation deployment uses the `github-pages` environment with `pages:
-  write` and OIDC only in the deployment job.
+    write` and OIDC only in the deployment job.
 * Package publishing uses the `pypi` environment and PyPI Trusted Publishing
-  instead of long-lived publishing tokens.
+    instead of long-lived publishing tokens.
 * Release artifacts are attested with GitHub artifact attestations before they
-  are published.
+    are published.
 * Docker images are built in a dedicated workflow, scanned with Trivy, and only
-  pushed from non-pull-request events with `packages: write`.
+    pushed from non-pull-request events with `packages: write`.
 * Artifacts should be limited to build outputs such as distributions, container
-  images, SBOM files, and attestation metadata.
+    images, SBOM files, and attestation metadata.
 
 ## Pull requests
 

{benchmatrix-0.2.1 → benchmatrix-0.2.4}/docs/explanation/lifecycle.md

@@ -27,14 +27,14 @@ of truth.
 ## Change stages
 
 * **Experimental**: behavior may change without deprecation. This includes
-  undocumented internals, private modules, and private names.
+    undocumented internals, private modules, and private names.
 * **Documented**: behavior appears in docs or examples and should receive a
-  changelog note when changed.
+    changelog note when changed.
 * **Stable public API**: exported from `benchmatrix.__init__`, documented in the
-  API reference, and covered by tests.
+    API reference, and covered by tests.
 * **Deprecated**: retained temporarily with migration guidance.
 * **Removed**: no longer available after the documented removal release or after
-  an urgent security/correctness removal.
+    an urgent security/correctness removal.
 
 ## Public API stability
 

{benchmatrix-0.2.1 → benchmatrix-0.2.4}/docs/explanation/performance.md

@@ -39,14 +39,14 @@ metadata with saved runs.
 Common pitfalls:
 
 * A target returning a generator, coroutine, future, query plan, or other lazy
-  object may only measure object creation. Resolve lazy work inside the
-  synchronous target wrapper.
+    object may only measure object creation. Resolve lazy work inside the
+    synchronous target wrapper.
 * Fresh-input factories and copying run outside the timed target body. Put
-  construction inside the target only when setup cost is part of the operation
-  being measured.
+    construction inside the target only when setup cost is part of the operation
+    being measured.
 * Reused mutable inputs can drift across invocations. Use `fresh_inputs=True`,
-  `deep_copy`, or a domain-specific copier when targets mutate their inputs.
+    `deep_copy`, or a domain-specific copier when targets mutate their inputs.
 * Small differences need repeated runs, distribution checks, and controlled
-  environments before they become conclusions.
+    environments before they become conclusions.
 * A faster implementation still needs ordinary correctness tests. Benchmark
-  tests should not be the only proof that two implementations do the same work.
+    tests should not be the only proof that two implementations do the same work.

{benchmatrix-0.2.1 → benchmatrix-0.2.4}/docs/explanation/publishing.md

@@ -13,22 +13,39 @@ make build
 
 This command builds the source distribution and wheel, checks metadata with
 Twine, installs the built wheel into a temporary environment, imports the public
-package, and generates the runtime CycloneDX SBOM at `dist/benchmatrix.cdx.json`.
+package, generates the runtime CycloneDX SBOM at `dist/benchmatrix.cdx.json`,
+and fails unless the release artifact files in `dist/` are the expected
+wheel, source distribution, and SBOM for the package version in `pyproject.toml`.
 
 The release workflow runs the same command before publishing, so local release
 checks and CI release checks exercise the same path.
 
 ## Version metadata
 
-The project currently uses static package metadata. A release version must be
-updated in these files:
+The project uses static package metadata, but release preparation is automated.
+After the `CHANGELOG.md` entries under `## Unreleased` are ready, export the
+release version without a leading `v`, then run the release pull request
+preparation target:
 
-* `pyproject.toml`, `[project] version`;
-* `CITATION.cff`, `version`;
-* `CITATION.cff`, `date-released` once the release date is known;
-* `CHANGELOG.md`, a versioned section with the release date.
+```bash
+export BENCHMATRIX_RELEASE_VERSION=X.Y.Z
+make release-pr-ready
+```
+
+This command checks release prerequisites, updates `pyproject.toml`,
+`CITATION.cff`, and `CHANGELOG.md`, sets `date-released` in `CITATION.cff`,
+creates the dated changelog section, runs `uv lock` after the `pyproject.toml`
+version changes, runs the full local `make check` suite, and creates or reuses
+the standardized release branch, commit, and GitHub pull request. Use
+`RELEASE_DATE=YYYY-MM-DD` when the release date should be explicit.
 
-The Git tag must be named `vX.Y.Z` and must match the package version `X.Y.Z`.
+After the release pull request is merged, create the Git tag with:
+
+```bash
+make release-tag
+```
+
+The tag must be named `vX.Y.Z` and must match the package version `X.Y.Z`.
 Do not publish if the tag and metadata disagree.
 
 ## Changelog and release notes
@@ -44,6 +61,14 @@ changes before routine maintenance items.
 
 ## GitHub Release publishing flow
 
+Pushing an annotated tag named `vX.Y.Z` starts `.github/workflows/draft-release.yml`.
+That workflow validates release metadata, extracts notes from `CHANGELOG.md`,
+builds the source distribution, wheel, and SBOM, creates or updates a draft
+GitHub Release for the pushed tag, attaches those files to the draft, and
+verifies that the package assets are present before the workflow succeeds. The
+workflow also supports manual dispatch for rerunning draft creation and asset
+attachment for an existing tag.
+
 `.github/workflows/release.yml` publishes when a GitHub Release is published.
 The workflow listens for:
 
@@ -54,11 +79,15 @@ release:
 ```
 
 That means creating or editing a draft release is safe. Publishing the release is
-the deployment action. The publish job is guarded with `startsWith(github.ref,
-'refs/tags/v')`, so PyPI publication only runs from version tags such as
-`v0.2.0`. The workflow builds from the tagged source, uploads package
-distributions and the SBOM as separate release artifacts, attests them, and
-publishes only the distributions to PyPI from the `pypi` environment.
+the deployment action. The draft-release workflow uses `GITHUB_TOKEN`, so it
+intentionally stops before publication; GitHub suppresses most follow-on
+workflow runs caused by that token to avoid recursive automation.
+
+The publish job is guarded with `startsWith(github.ref, 'refs/tags/v')`, so PyPI
+publication only runs from version tags such as `v0.2.0`. The workflow rebuilds
+from the tagged source, uploads package distributions and the SBOM as separate
+Actions artifacts, refreshes those files on the GitHub Release, attests them,
+and publishes only the distributions to PyPI from the `pypi` environment.
 
 The workflow also has manual dispatch. Treat `publish=false` as a build smoke
 check. Treat `publish=true` as a real publication and only run it from an exact
@@ -89,10 +118,10 @@ GitHub repository settings:
 1. Create an environment named `pypi`.
 2. Add trusted maintainer reviewers.
 3. Restrict deployment branches or tags to release refs if the repository plan
-   supports that control.
+    supports that control.
 4. Do not add PyPI secrets when Trusted Publishing works.
 5. If a temporary token is unavoidable, use a project-scoped token, store it only
-   in the `pypi` environment, and remove it after Trusted Publishing succeeds.
+    in the `pypi` environment, and remove it after Trusted Publishing succeeds.
 
 ## Documentation artifacts
 
@@ -120,6 +149,5 @@ rm -rf "$verify_env"
 
 The command should print `BenchmarkCase`. The release workflow's verification
 job runs that same post-publication smoke check after a GitHub Release is
-published. Also
-inspect the PyPI project page, release workflow logs, uploaded artifacts, SBOM,
-and attestations.
+published. Also inspect the PyPI project page, release workflow logs, GitHub
+Release assets, Actions artifacts, SBOM, and attestations.

{benchmatrix-0.2.1 → benchmatrix-0.2.4}/docs/explanation/repository-settings.md

@@ -10,12 +10,12 @@ The repository includes `.github/settings.yml` for the GitHub Settings app. If
 the app is installed, changes merged to the default branch sync these settings:
 
 * repository description, homepage, topics, issues/projects/wiki flags, and
-  branch deletion after merge;
+    branch deletion after merge;
 * allowed merge strategies: squash and rebase enabled, merge commits disabled;
 * Dependabot alerts and automated security fixes;
 * `main` branch protection, including required reviews, code owner review,
-  stale review dismissal, last-push approval, required status checks, linear
-  history, blocked force pushes, blocked deletions, and conversation resolution;
+    stale review dismissal, last-push approval, required status checks, linear
+    history, blocked force pushes, blocked deletions, and conversation resolution;
 * deployment environments and their branch or tag deployment policies.
 
 Install the Settings app only after branch protection is active enough that
@@ -106,7 +106,7 @@ The GitHub Settings app syncs these environments from `.github/settings.yml`:
 
 * `github-pages` for documentation deployment, restricted to `main`;
 * `pypi` for package publishing, restricted to `v*` tags and requiring
-  approval from project maintainer(s).
+    approval from project maintainer(s).
 
 Keep secrets out of the environment when using PyPI Trusted Publishing because
 OIDC should provide a short-lived publishing token.
@@ -138,7 +138,7 @@ Set these repository profile fields:
 * description: `Build pytest-benchmark matrices and parse benchmark results with lightweight Python utilities.`;
 * homepage: `https://ryancswallace.github.io/benchmatrix/` once Pages is live;
 * topics: `benchmark`, `benchmarking`, `performance`, `pytest`,
-  `pytest-benchmark`, `python`.
+    `pytest-benchmark`, `python`.
 
 Disable the wiki and projects unless the project starts using them deliberately.
 Keep issues enabled.

{benchmatrix-0.2.1 → benchmatrix-0.2.4}/docs/how-to/run-with-docker.md

@@ -8,10 +8,10 @@ convenience images for reproducible local use, CI smoke checks, and examples.
 The repository builds two images:
 
 * `ghcr.io/ryancswallace/benchmatrix` is the runtime image. It installs the
-  package with runtime dependencies only and defaults to a safe import smoke
-  test.
+    package with runtime dependencies only and defaults to a safe import smoke
+    test.
 * `ghcr.io/ryancswallace/benchmatrix-test` is the test image. It includes the
-  project test and release tooling and defaults to `python -m pytest -q`.
+    project test and release tooling and defaults to `python -m pytest -q`.
 
 Both images run as a non-root user.
 
@@ -65,7 +65,7 @@ The default command should print `BenchmarkCase`. To run a custom command:
 
 ```bash
 docker run --rm ghcr.io/ryancswallace/benchmatrix:latest \
-  python -c "from benchmatrix import BenchmarkCase; print(BenchmarkCase.__name__)"
+    python -c "from benchmatrix import BenchmarkCase; print(BenchmarkCase.__name__)"
 ```
 
 ## Tag policy

{benchmatrix-0.2.1 → benchmatrix-0.2.4}/docs/index.md

@@ -9,13 +9,13 @@ Use this site by task type:
 
 * **Tutorials** teach the first complete workflow from zero to a benchmark run.
 * **How-to guides** solve focused tasks such as creating a benchmark matrix or
-  parsing saved JSON results.
+    parsing saved JSON results.
 * **Reference** records exact APIs, compatibility commitments, and automation
-  commands.
+    commands.
 * **Explanation** describes architecture, policy, security posture, and design
-  tradeoffs.
+    tradeoffs.
 * **Maintainer runbooks** are operational checklists for releases, incidents,
-  dependency updates, and repository administration.
+    dependency updates, and repository administration.
 
 ## Quick start
 

{benchmatrix-0.2.1 → benchmatrix-0.2.4}/docs/reference/compatibility.md

@@ -90,7 +90,7 @@ true:
 
 * the issue is high impact for installed users;
 * a safe, minimal patch can be prepared without carrying substantial branch
-  maintenance cost;
+    maintenance cost;
 * the affected release still has meaningful user adoption;
 * the maintainer has capacity to validate and publish the backport.
 

{benchmatrix-0.2.1 → benchmatrix-0.2.4}/docs/reference/configuration.md

@@ -60,31 +60,37 @@ The repository uses focused workflows that call the same Make targets used
 locally:
 
 * `.github/workflows/ci.yml` runs quality checks, supported-Python tests,
-  coverage and JUnit report artifact upload, minimum-dependency tests,
-  packaging smoke checks, SBOM generation, and scheduled dependency audits.
+    coverage and JUnit report artifact upload, minimum-dependency tests,
+    packaging smoke checks, SBOM generation, and scheduled dependency audits.
 * `.github/workflows/docs.yml` builds docs, checks generated-site links, uploads
-  the link-check report, and deploys the MkDocs site from `main` through GitHub
-  Pages.
+    the link-check report, and deploys the MkDocs site from `main` through GitHub
+    Pages.
+* `.github/workflows/draft-release.yml` validates release metadata when a `v*`
+    tag is pushed, extracts release notes from `CHANGELOG.md`, builds and
+    verifies release assets, and creates or updates the draft GitHub Release
+    with the package source distribution, wheel, and SBOM attached; it also
+    supports manual dispatch for retrying an existing tag.
 * `.github/workflows/release.yml` builds release artifacts, uploads package
-  distributions and the SBOM as separate artifacts, attests them, publishes the
-  distributions to PyPI through Trusted Publishing, and verifies installation
-  from PyPI after publication.
+    distributions and the SBOM as separate Actions artifacts, attaches them to
+    the GitHub Release, attests them, publishes the distributions to PyPI through
+    Trusted Publishing, and verifies installation from PyPI after publication.
 * `.github/workflows/release-verify.yml` manually re-runs post-release
-  installation verification from PyPI.
+    installation verification from PyPI.
 * `.github/workflows/docker.yml` builds runtime and test Docker images, scans
-  them for critical vulnerabilities, and publishes them to GHCR from `main` and
-  `v*` tags.
+    them for critical vulnerabilities, and publishes them to GHCR from `main` and
+    `v*` tags.
 * `.github/workflows/workflow-lint.yml` runs actionlint and zizmor for workflow
-  configuration changes, using `.github/zizmor.yml` for project-specific audit
-  policy.
+    configuration changes, using `.github/zizmor.yml` for project-specific audit
+    policy.
 * `.github/workflows/codeql.yml`, `.github/workflows/dependency-review.yml`,
-  and `.github/workflows/scorecard.yml` provide GitHub-native security and
-  supply-chain checks.
+    and `.github/workflows/scorecard.yml` provide GitHub-native security and
+    supply-chain checks.
 
 Standalone SBOM and artifact-attestation workflows are intentionally not added:
 `make build`, CI packaging, and the release workflow already generate SBOMs and
-release provenance without an extra scheduler. Release drafting is also left out
-until the project has enough release volume to justify another automation path.
+release provenance without an extra scheduler. Release drafting is limited to a
+small tag-triggered workflow so the deployment action remains publishing the
+reviewed GitHub Release.
 
 ## Pull request labels
 
@@ -93,7 +99,7 @@ Pull request labels are applied automatically by GitHub Actions:
 * `.github/labeler.yml` maps changed files and branch names to labels.
 * `.github/workflows/labeler.yml` runs `actions/labeler` on pull requests.
 * `.github/labels.yml` documents the repository's recommended label set for
-  maintainers.
+    maintainers.
 
 Labels are not synced automatically. Create or update labels manually in GitHub
 when the recommended label set changes.

{benchmatrix-0.2.1 → benchmatrix-0.2.4}/docs/reference/index.md

@@ -6,11 +6,11 @@ on stable facts.
 ## Available reference material
 
 * [API reference](api/index.md), generated from package docstrings by
-  mkdocstrings during the MkDocs build.
+    mkdocstrings during the MkDocs build.
 * [Compatibility](compatibility.md), covering supported Python versions and API
-  compatibility expectations.
+    compatibility expectations.
 * [Configuration and automation](configuration.md), covering local development
-  commands and generated artifacts.
+    commands and generated artifacts.
 
 Use tutorials and how-to guides when learning a workflow. Use this section when
 checking names, options, and support boundaries.