576c2e13e3
Root cause of the simultaneous lane-shas failures on PRs #46 and #47: workflows installed with unlocked 'uv pip install -e .' against floor-only specs (numpy>=1.26, ...) while the repo maintains uv.lock — so a PyPI release landing between runs shifts the runner's resolved set, and the byte-exact lane SHA pins move with it. Timeline: main lane run green at 23:40Z, both PR runs (diffs no lane executes) red after 00:02Z; the identical trees verify 9/9 locally against the locked venv, and 'uv lock --check' is clean. All six workflows now 'uv sync --locked' (--extra dev where [dev] was installed) — CI tests the locked universe, so lane pins can only move when code moves. Locked-sync also fails loudly on a stale lock instead of silently resolving fresh. Self-validating: this PR's own lane-shas run uses this branch's workflow. [Verification]: smoke suite passed locally (175 passed); lane repro on the failing PRs' tree: 9/9 pinned SHAs; uv lock --check clean. |
||
|---|---|---|
| .. | ||
| workflows | ||
| CODEOWNERS | ||
| copilot-instructions.md | ||
| FUNDING.yml | ||