ci: cover the full supported Python and Django matrix on every PR

[imakecodes]

Why

Unit tests already ran on every pull request, but the matrix had drifted away from what the package actually promises.

pyproject.toml has allowed django>=4.2,<7.0 since dfcfd9f. The CI matrix stopped at Django 5.2. Django 6.0 and 6.1 have been released, so the package has been claiming support for a major series that CI never executed once.

I verified locally before touching the workflow. All four tests pass on Django 6.0.8 and 6.1.1, on every Python those series support:

	Python 3.12	Python 3.13	Python 3.14
Django 6.0.8	pass	pass	pass
Django 6.1.1	pass	pass	pass

So this is coverage that was missing, not a bug that was hiding.

What changed

The matrix is now the full intersection of what the package declares rather than a hand-maintained subset: each Python in project.classifiers crossed with each Django series the dependency specifier allows, minus the pairs upstream Django does not support. 11 legs become 17.

Python	Django series
3.11	4.2, 5.0, 5.1, 5.2
3.12	4.2, 5.0, 5.1, 5.2, 6.0, 6.1
3.13	5.1, 5.2, 6.0, 6.1
3.14	5.2, 6.0, 6.1

The gaps are upstream constraints, not omissions: Django 4.2 and 5.0 do not support Python 3.13, and Django 6.x requires Python 3.12 or newer.

The matrix no longer runs twice per PR. on: push had no branch filter, so every pull request from a same-repo branch started two identical runs. PR #57 showed 27 checks where 14 would have done. push is now limited to main, and superseded PR runs are cancelled. Release runs are never cancelled: cancel-in-progress is gated on the event being a pull_request, so the workflow_call from the publish workflows is unaffected.

Each leg now reports the versions it actually resolved into the job summary. make test-django layers uv run --with <constraint> over the locked environment, so a constraint that silently failed to apply would pass as a false green against whatever uv.lock pins. The step is continue-on-error, purely diagnostic, and can never mask a test result.

New Required Checks job aggregates the workflow into one stable check name. Branch protection should require that rather than 17 job names that change whenever a series is added or dropped, because a required check that no longer exists stops being enforced silently.

Added workflow_dispatch for manual runs, and timeout-minutes on every job.

Supporting changes

• Framework :: Django :: 4.2 through 6.1 classifiers, so the tested range is visible on PyPI. All six verified against the current trove list.
• README.md said Django >=4.2,<6.0, which was stale in both directions. Now <7.0, with a pointer to the matrix.
• docs/development.md and CLAUDE.md record the rule that caused this: widening requires-python, the django specifier, or the classifiers without adding the matching legs ships an untested claim of support.
• Removed five em dashes I left in .claude/commands/ in docs: add CLAUDE.md and shared .claude configuration #57, and pointed /extend-generator at both ends of the range instead of only the oldest.

Verification

make ci passes locally: Ruff clean, 4 tests, wheel and sdist build. Wheel metadata confirms Requires-Dist: django<7.0,>=4.2 alongside the new classifiers.

Follow-ups not in this PR

• Dependabot only watches github-actions. Adding the uv ecosystem would surface new Django series as PRs, which is the mechanism that would have caught this drift earlier.
• The suite only runs on SQLite, while get_db_type() branches on five backends and builder.py imports django.contrib.postgres.indexes.HashIndex. A PostgreSQL leg is a separate axis worth its own PR.

🤖 Generated with Claude Code