test: the version gate could not fail, so it is gone (C-341, C-346, #425)

[Polichinel]

Closes #425 and #363. Part of #421, Story 4.

The instruction was "delete F1". It turned out not to be one deletion, and the investigation changed the shape twice.

The gate could not fail, and that was structural

TestF1VersionBumped asserted "the current version is not already tagged". Version here is bumped only at release time, so from the moment a release lands until the next bump the version is a tag that exists — the entire inter-release period. Hence its unconditional xfail: not a temporary concession, the only way it could coexist with this workflow.

Measured in both states rather than argued:

state	result	suite exit
version tagged (steady state, all but release day)	XFAIL	0
version untagged (just bumped)	XPASS	0

It asked "have you bumped yet?" — unanswerable from repo state, because "about to release" is not knowable from the repo, only from the tag that triggers a release.

Replaced by the two halves that are answerable

TestVersionMatchesItsTag — if HEAD is on a v* tag, the version must equal it. Skips with a reason otherwise (C-320 idiom: do not guess). Drilled to a genuine failure in an isolated worktree checked out at v1.11.0:

HEAD not on a tag                          rc=0   skipped
on v1.11.0, version 1.11.0                 rc=0   passed
on v1.11.0, version 1.11.1                 rc=1   FAILED
  "HEAD is on tag v1.11.0 but pyproject.toml declares version 1.11.1
   (expected tag v1.11.1). ... v* tags are immutable under the tag ruleset,
   so the fix is to bump pyproject.toml — the tag cannot be moved."

A guard in publish_package.yml comparing github.ref_name to the version, before the build. Unlike the test it cannot be skipped — the triggering tag is known there and nowhere else. Drilled with the body extracted from the workflow, not retyped:

TAG=v9.9.9     rc=1  FAIL (want FAIL)  OK
    ::error::Tag/version mismatch — refusing to publish.
      tag that triggered this run : v9.9.9
      pyproject [project].version : 1.11.0  (expected tag v1.11.0)
TAG=v1.11.0    rc=0  PASS (want PASS)  OK

C-341's last residue was exactly this gate, so C-341 resolves.

Grepping for the deletion found four more

test_version_not_already_tagged also lives in test_falsification_{deploy_v130,ghspop_deploy_v2,ghsbuilts_deploy_v2} and test_falsification_vdem_deploy. They use a conditional xfail that reads as more rigorous and is worse:

@pytest.mark.xfail(condition=_version_already_tagged(), ...)
def test_version_not_already_tagged(self):
    assert not _tag_exists(f"v{version}")

It runs only when the version is untagged, then asserts the version is untagged — asserting the condition that selected it. Green in every reachable state.

Registered as C-346 (Tier 4) and deliberately left in place: removing four classes across unrelated suites, plus the meta-test in deploy_v130 that enforces the marker, is its own change — and the replacement now exists, so this is cleanup rather than a gap. The entry notes the v1.2.29 post-mortem item that whoever removes them should close.

A real bug the drill caught

The publish guard first read the version with bare python3 -c "import tomllib". tomllib needs ≥ 3.11; local python3 is 3.10 and the runner's is whatever the image ships. Pinned to uv run --no-project --python 3.12, matching the guard beside it.

That one would have surfaced at a release, against an immutable tag — the single worst moment for a guard to fail.

Two of my own drills were wrong first, the same way both times

1. git checkout v1.11.0 was silently refused (uncommitted changes), so the "want FAIL" case ran off-tag, skipped, and returned rc=0 — which I nearly recorded as a result.
2. After moving to a worktree, pytest was invoked from the main repo while the test shells out to git describe in the current directory — still answering about the wrong tree.

Fourth and fifth instances this week of a drill whose setup did not happen while the exit code looked fine. Both redone with the setup verified (HEAD tag=v1.11.0, version=1.11.0) before the assertion ran.

Verification

• ruff check . → All checks passed
• pytest → PYTEST_EXIT=0, FAILED count: 0 (unpiped, two readers)
• docs/validate_docs.sh → PASSED
• publish_package.yml checked semantically: every step has exactly one of run/uses; the tag guard precedes the build
• TestF1VersionBumped confirmed absent as a class (the one remaining mention is the replacement's docstring); 6 tests collect in that file
• Register: 346 IDs, 304 resolved, 39 open (0 T1, 4 T2, 10 T3, 19 T4, 6 deferred), 120 struck

🤖 Generated with Claude Code

[Polichinel]

Ritual complete — /code-review medium → /review-diff → /register-risk

The review found a fails-green in the test written to close a fails-green, and in the only direction that matters.

_head_tag() skipped when it should have failed

It used git describe --tags --exact-match HEAD. That returns exactly one tag — the lexicographically smallest — and a commit can carry several. Reproduced in a throwaway repo:

tags on HEAD:                            checkpoint v1.11.0
git describe --tags --exact-match HEAD   checkpoint
_head_tag()                              None      <- the test SKIPS

A stray non-v tag on a release commit hides the release tag, and the test goes quiet precisely when a real mismatch is sitting on that commit.

Switched to git tag --points-at, which lists all of them, and drilled the multi-tag case that had no drill before:

A. single tag, version matches               rc=0
B. multi-tag (checkpoint + v1.11.0), matches rc=0
C. multi-tag, MISMATCH                        rc=1  "HEAD is on tag(s) ['v1.11.0'] but
                                                    pyproject.toml declares version 1.10.0"

Where it was not a problem is the useful part. publish_package.yml compares github.ref_name directly and never shells out to git describe, so the unskippable half was immune. The two halves failing differently is the argument for having both — which I would have asserted without evidence if the review had not produced it.

Verified and left alone

• set -euo pipefail aborts the guard when uv run fails — it never compares against an empty string. Tested by simulating a bad --python.
• Step order — the guard runs after setup-uv, so uv exists when invoked, and before both the PyPI-version guard and uv build.
• The deletion breaks nothing. Exactly four test_version_not_already_tagged definitions remain, matching C-346's claim. The deploy_v130 meta-test that enforces the marker was run in a state where its early-return does not short-circuit — it greps and checks each sibling for real, non-vacuously.
• _head_tags() edge cases — no tags, not a git repo, git absent: the first two skip correctly; git absent raises a loud pytest ERROR rather than a silent pass.
• Register/changelog numerics — max ID is C-346 matching "346 concern IDs"; cluster table has 12 rows, 4 struck, matching "eight open members of twelve rows".

/register-risk — 0 new, 0 merged

An in-changeset defect, found and fixed here. The pattern — a guard narrower than the property it claims — is C-336, which already carries two addenda from this week, and C-345 covers the verification half. A third entry for a self-corrected instance would be noise rather than signal.

Verification

• ruff check . → All checks passed
• pytest → PYTEST_EXIT=0, FAILED count: 0 (unpiped, two readers)
• docs/validate_docs.sh → PASSED
• Drills re-run in an isolated worktree with the setup verified (HEAD tags, version) before each assertion — twice this story the setup had silently not happened