S2 — The status banners stop claiming a publication they cannot verify (closes C-97) - #276
Merged
Merged
Conversation
…fy (closes C-97) S2 of epic #267. Closes #269. README said "v2.0.0 — published to PyPI" and CLAUDE.md said "released — v2.x on PyPI" while PyPI served 1.11.0 and no v2.0.0 tag existed. Both false, on main, and README is the PyPI long description. This is the bump-then-publish transient every prior release had, which is why sixteen releases never noticed it. It stopped being transient here: the tag is gated on C-13's adoption-issue requirement, which has no date. The version number was never the bug — the words were. A banner asserting *publication* makes a claim about the world the repository cannot check, and it is wrong in every cycle between the bump and the publish job. So the banner now states the version IN THIS TREE, links to PyPI for what is published, and says plainly that it is deliberately ahead in between. One edit, no recurring work. Softening before each release and re-asserting after was considered and rejected: it rebuilds the trap every cycle. validate_docs.sh check 6 is untouched and still pins the banner's MAJOR.MINOR to pyproject.toml — the part that IS checkable from inside the repo. **What this cost, stated rather than glossed.** The audit's own stub asserted `banner version == PyPI version`. That was right against the old wording and is wrong against the new one — it would contradict check 6, since the banner is now legitimately ahead between releases. Rewriting a failing test so it passes is an anti-pattern, so: the rewrite is a WEAKENING and the file says so in its own comment. It now asserts the banner makes no publication claim, which cannot catch a merely stale banner. Check 6 covers staleness; nothing inside this repo can know what PyPI serves without the network. Mutation-tested — restoring "published to PyPI" fails it. Register: 94 entries, 10 open, 84 resolved. Still 0 actionable. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.
S2 of epic #267. Closes #269.
The problem
README.mdsaid "v2.0.0 — published to PyPI";CLAUDE.mdsaid "released — v2.x on PyPI". PyPI served1.11.0, nov2.0.0tag existed. Both false, onmain— and README is the PyPI long description.Sixteen releases had this same transient and nobody noticed, because it normally lasts minutes. It stops being transient here: the tag is gated on C-13's adoption-issue requirement, which has no date.
The repair
The version number was never the bug — the words were. A banner asserting publication claims something about the world the repo cannot check, and it is wrong in every cycle between the bump and the publish job.
So the banner now states the version in this tree, links to PyPI for what is published, and says plainly it is deliberately ahead in between. One edit, no recurring work. Softening before each release and re-asserting after was considered and rejected — that rebuilds the trap every cycle.
validate_docs.shcheck 6 is untouched and still pins the banner's MAJOR.MINOR topyproject.toml— the part that is checkable from inside the repo.What this cost — stated, not glossed
The audit's own stub asserted
banner version == PyPI version. That was the right test against the old wording and is the wrong test against the new one: it would contradict check 6, since the banner is now legitimately ahead between releases.Rewriting a failing test so it passes is an anti-pattern, so this is explicit — the rewrite is a weakening, and the stub file says so in its own comment. It now asserts only that the banner makes no publication claim, which cannot catch a merely stale banner. Check 6 covers staleness against pyproject; nothing inside this repo can know what PyPI serves without network access.
Mutation-tested: restoring
published to PyPIfails the rewritten stub.Audit stub status
Verification
Register: 94 entries, 10 open, 84 resolved, 0 actionable.
🤖 Generated with Claude Code