Severity: Medium
CI's Python version matrix and packaging validation don't match the project's declared support surface, and there's no protection against dependency drift.
1. Version matrix gap — .github/workflows/ci.yml:25
Matrix tests only Python 3.10/3.11, while pyproject.toml:29 declares open-ended requires-python = ">=3.10". 3.12/3.13 are never exercised in CI, so a version-specific regression (e.g. a dataclass/typing behavior change — exactly the fragile area behind the Problem pickling bug) could ship silently to the majority of new installs. (Verified the suite currently passes locally on 3.13.1 / numpy 2.3.2 / scipy 1.16.1: 548 passed.)
2. Built wheel never smoke-tested — .github/workflows/ci.yml:36-42
Lint/typecheck/pytest all run against the editable src tree; uv build is the last step and its artifacts are never installed or imported, so a wheel-packaging mistake (dropped package data, bad packages config) would merge green.
3. No lockfile / no canary — .gitignore:10 + pyproject.toml:18
uv.lock is gitignored and sdist-excluded, so CI resolves latest dependencies on every run with nothing pinned; a bad upstream joblib/numpy/scipy release breaks all PRs simultaneously with no way to bisect "our change" vs. ecosystem drift, and there's no scheduled canary job to separate the two.
Fix direction
Extend the CI matrix to include 3.12 and 3.13. Add a step that installs the built wheel into a clean venv and runs an import/export smoke test against it. Either commit uv.lock for CI reproducibility (while keeping loose metadata for downstream consumers), or add a scheduled cron CI job to catch dependency drift independently of PR activity.
Severity: Medium
CI's Python version matrix and packaging validation don't match the project's declared support surface, and there's no protection against dependency drift.
1. Version matrix gap —
.github/workflows/ci.yml:25Matrix tests only Python 3.10/3.11, while
pyproject.toml:29declares open-endedrequires-python = ">=3.10". 3.12/3.13 are never exercised in CI, so a version-specific regression (e.g. a dataclass/typing behavior change — exactly the fragile area behind theProblempickling bug) could ship silently to the majority of new installs. (Verified the suite currently passes locally on 3.13.1 / numpy 2.3.2 / scipy 1.16.1: 548 passed.)2. Built wheel never smoke-tested —
.github/workflows/ci.yml:36-42Lint/typecheck/pytest all run against the editable src tree;
uv buildis the last step and its artifacts are never installed or imported, so a wheel-packaging mistake (dropped package data, badpackagesconfig) would merge green.3. No lockfile / no canary —
.gitignore:10+pyproject.toml:18uv.lockis gitignored and sdist-excluded, so CI resolves latest dependencies on every run with nothing pinned; a bad upstream joblib/numpy/scipy release breaks all PRs simultaneously with no way to bisect "our change" vs. ecosystem drift, and there's no scheduled canary job to separate the two.Fix direction
Extend the CI matrix to include 3.12 and 3.13. Add a step that installs the built wheel into a clean venv and runs an import/export smoke test against it. Either commit
uv.lockfor CI reproducibility (while keeping loose metadata for downstream consumers), or add a scheduled cron CI job to catch dependency drift independently of PR activity.