Skip to content

S2 — The status banners stop claiming a publication they cannot verify (closes C-97) - #276

Merged
Polichinel merged 1 commit into
developmentfrom
docs/s2-state-neutral-banners
Aug 18, 2026
Merged

Polichinel merged 1 commit into
developmentfrom
docs/s2-state-neutral-banners

Conversation

@Polichinel

Copy link
Copy Markdown
Contributor

S2 of epic #267. Closes #269.

The problem

README.md said "v2.0.0 — published to PyPI"; CLAUDE.md said "released — v2.x on PyPI". PyPI served 1.11.0, no v2.0.0 tag existed. Both false, on main — 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.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, 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 PyPI fails the rewritten stub.

Audit stub status

3 passed  (S1's package-count stub + these two)
3 failed  — all `test_every_pinned_consumer_has_an_adoption_issue[...]`, which is S4 (#271), the maintainer's story

Verification

validate_docs.sh   PASSED — check 6 OK (banner v2.0 ~ pyproject 2.0.0)
ruff check         All checks passed!
pytest --cov       100.00%

Register: 94 entries, 10 open, 84 resolved, 0 actionable.

🤖 Generated with Claude Code

…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>
@Polichinel
Polichinel merged commit b3f8dd5 into development Aug 18, 2026
11 checks passed
@Polichinel
Polichinel deleted the docs/s2-state-neutral-banners branch August 18, 2026 12:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

S2 — Make the status banners state-neutral, permanently (Epic #267)

1 participant