[oscarvalenzuelab]

Closes #11.

CI runs both linters with no configuration of its own — no [tool.ruff]
section, no ruff.toml anywhere in the tree, and ci.yml runs a bare
ruff check .. So the rules in force are whatever the installed version happens
to default to, and those defaults are not stable across releases. When they
grow, CI goes red on a pull request that changed nothing related to the new
rule.

-dev = ["pytest", "ruff", "mypy", "types-PyYAML", "lxml-stubs", "ospac>=1.4.3"]
+dev = [
+    "pytest",
+    "ruff>=0.16,<0.17",
+    "mypy>=2,<3",
+    "types-PyYAML",
+    "lxml-stubs",
+    "ospac>=1.4.3",
+]

One deviation from the issue

The issue suggested mypy>=1.11,<2. That bound would move CI backwards.
mypy 2.0 shipped 2026-05-06, three months before the issue was filed, and CI has
been installing 2.x on every run since. mypy 2.3.1 passes this codebase clean
today:

$ mypy            # unpinned, i.e. what CI installs right now
mypy 2.3.1 (compiled: yes)
Success: no issues found in 27 source files

Pinning <2 would have silently dropped CI to a two-major-versions-older
checker. The bound is >=2,<3, which keeps what is already running and guards
the next major.

ruff is pre-1.0, so its minor is the equivalent boundary and stays <0.17.

Not an explicit select list

Deliberately, per the issue. The broad defaults are doing real work: during #10
they caught an unparenthesized implicit string concatenation in a parametrize
list — the shape a missing comma takes, which silently turns a 2-tuple into one
string — and a datetime() built without tzinfo. A hand-written list would
risk losing that and leaves something to maintain.

Verified

Against the three commands CI actually runs, with the bounds in place:

resolved: ruff 0.16.5, mypy 2.3.1
ruff check .   ->  All checks passed!
mypy           ->  Success: no issues found in 27 source files
pytest         ->  1106 passed

Development tooling only; the published package is unaffected and this needs no
release of its own.