test(backend): guard settings.VERSION against pyproject.toml drift (7 releases behind) - #63
Merged
Merged
Conversation
v1.0.7 added this guard on the frontend pair (site.ts::APP_VERSION vs package.json) after the UI shipped a stale version through three releases. The backend pair was never covered and drifted the same way: VERSION tracked releases up to 1.0.10 while pyproject.toml sat on 1.0.3, seven releases behind. VERSION is what /health and the OpenAPI doc report, so 1.0.10 is the truth and pyproject.toml is what was wrong. uv.lock records the root package version, so it is relocked to match -- required by the v1.0.10 manifest-drift guard, which would otherwise fail on uv lock --check. Confirmed the new guard is not vacuous by reintroducing the drift and watching it fail. requirements.txt deliberately not touched: uv export regenerates it byte-identically, so the only local difference was a line-ending artifact.
Shaan-alpha
added a commit
that referenced
this pull request
Jul 31, 2026
Browser verification showed the popover Activity leak is not a real bug -- main already reports painted:false after browser-back. The fix was reverted in #62 and the user-facing changelog line is removed rather than left claiming a fix for something that was never broken. Also records both process lessons: the first CDP run used Page.navigate (a full document load) and proved nothing, and a jsdom-only failure is not evidence of a product bug when portals, layout or paint are involved.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes the loose end noted while investigating #59:
backend/pyproject.tomlwas on 1.0.3 while every other version constant was on 1.0.10 — seven releases behind, unnoticed.Why it drifted
v1.0.7 existed because of this exact class of bug: the UI shipped a stale
v1.0.3badge through three releases becauseAPP_VERSIONwas a third constant nobody remembered to bump. That slice added a drift guard — but only over the frontend pair (site.ts::APP_VERSIONvspackage.json).The backend pair (
settings.py::VERSIONvspyproject.toml) was left unguarded, and promptly drifted the same way. The v1.0.7 spec explicitly names all four constants as the version ritual; only two of them are enforced, so the ritual was silently half-done from v1.0.4 onward.What is correct
VERSIONis what/healthand the FastAPI OpenAPI doc report, and it has tracked releases accurately. So1.0.10is the truth andpyproject.tomlis the file that was wrong — package metadata was describing a release that never shipped.Changes
tests/test_settings.py— assertpyproject["project"]["version"] == VERSION. Confirmed failing first (assert '1.0.10' == '1.0.3'), and confirmed not vacuous by reintroducing the drift afterwards and watching it fail again.pyproject.toml—1.0.3→1.0.10.uv.lock— relocked. It records the root package version (skill-issue-backend), so leaving it would fail v1.0.10's own manifest-drift guard atuv lock --check. One-line change;uv lockreportsUpdated skill-issue-backend v1.0.3 -> v1.0.10and re-resolves all 56 packages identically.requirements.txtdeliberately untouched —uv exportregenerates it byte-identically, so the only local difference was a CRLF artifact from regenerating on Windows. Verified withgit diff --exit-code.Verification
uv lock --checkclean,ruff checkclean,ruff format --checkclean on 164 files,uv run pytest -q→ 359 passed (358 + the new guard), 72 skipped.The one remaining failure on this branch is
test_repo_quality.py::test_oss_profile_scores_twenty_without_deployment_hint— the pre-existing fixture time bomb inherited frommain, fixed by #60. Merge that first and CI here goes green.Note on scope
This does not add a cross-stack guard — nothing asserts the backend pair and the frontend pair agree with each other. That is a bigger question (they are separately deployable, and there is a reasonable argument they need not move in lockstep), so it is left alone. What is enforced now is that each pair is internally consistent, which is what actually broke both times.