Description
The Wave 3 currency pass found uv.lock pinning the transitive mypy dependency ast-serialize 0.8.0 while 0.9.0 is available. Mypy 2.3.1 permits versions below 1.0, but the publisher exposes no usable changelog for 0.9.0, so the update was deliberately deferred instead of treating a minor-version change with unknown behavior as safe. Validate the serialization and cache behavior that this repository exercises before changing the lock.
Acceptance Criteria
- #1 ast-serialize 0.9.0 release contents and compatibility risk are established from authoritative package artifacts or direct behavior
- #2 Mypy and repository type-check behavior are compared on 0.8.0 and 0.9.0, including cache creation and reuse
- #3 The lock update is accepted only if the focused comparison and the full repository gate pass
Definition of Done
- #1 just check (ruff format –check, ruff check, mypy, generated-doc drift, offline API conformance, and the marker-filtered pytest run with the 80% coverage floor — this is exactly what the CI
testjob runs) - #2 just gen, when metrics, config, endpoints, collectors, the settings schema or the chart config changed —
just checkincludes the drift gate and CI fails the build on it - #3 Grafana queries in grafana/dashboards/*.json and grafana/alerts/ updated, if a metric or label name changed
Implementation Plan
Compare ast-serialize 0.8.0 and 0.9.0 release artifacts plus mypy cache creation/reuse and type-check results; update the lock only if compatibility and the full gate pass.
Final Summary
Accepted ast-serialize 0.9.0 in 030318c after authoritative artifact inspection and an isolated 0.8.0 versus 0.9.0 comparison. Both versions produced Success: no issues found in 122 source files twice and 18 cache files; the applied checkout repeated the 0.9.0 result and just check passed 2,958 selected tests at 91.49% coverage. Added a documented single-package dependency-update recipe so unrelated lock pins remain untouched.