Release prep 1.1.1 — the bump, and the release guard made live in CI

[Polichinel]

Two changes, no package code. Step 1 of Bump → Merge → Tag → Release → Verify.

The version: 1.1.1, a patch

Measured rather than assumed. The only external imports of this package anywhere in the org are UNFAOPostProcessorManager and CRAFDPostProcessorManager, from views-models' un_fao/main.py and un_crafd/main.py — both paths unchanged. Nothing outside this repo imports track_a_source, frames_for_target, store_port or _ContractStorePort, so #269's frames_for_target signature change breaks no consumer.

Review independently re-ran that search across every sibling repo on disk and confirmed it, adding one fact that lowers the stakes further: consumers pin this package by git tag in shell launchers, not by a semver range in a lockfile — so no resolver acts on this number at all.

No new capability; two bug fixes (#268, #269) and an internal refactor. That is a patch. There is no stated versioning policy to violate: docs/ADRs/004 explicitly defers the question.

The version has exactly one home, pyproject.toml:3 — no __version__, no CHANGELOG.

The guard was inert exactly where it mattered

tests/test_release_version.py exists because tag 1.1.0 was cut at main while pyproject.toml still said 1.0.0. But run_pytest.yml checked out with no fetch-depth, so CI fetched no tags and both of its tests skipped there — verified against a real CI log (run 31844578627, the last development push before this branch, shows tests/test_release_version.py ss).

fetch-depth: 0 fixes it. Confirmed from actions/checkout@v3's own source rather than its README: on the fetchDepth <= 0 path it fetches +refs/tags/*:refs/tags/* unconditionally, and --no-tags is only appended when the refspec lacks that. fetch-tags is irrelevant here — it only applies when depth > 0. This branch's own CI run now shows s. instead of ss.

What review caught, and it was worth catching

The guard asked the wrong question. git tag -l lists tags on every branch, so the check was "has a release been cut anywhere", not "has one been cut from this line of history without the bump". That was invisible while CI fetched no tags — and would have become a false alarm the instant it stopped being. Reproduced in a clone: with 1.1.1 tagged on the release line, an honest branch still declaring 1.1.0 fails with "the newest release tag is 1.1.1 but pyproject.toml declares 1.1.0". It has done nothing wrong; the tag is simply not on its history.

Now git tag --merged HEAD. Same clone, same branch: tags anywhere are 1.0.0 1.1.0 1.1.1, tags reachable are 1.0.0 1.1.0, and it passes — while on the tagged line it still bites both ways. ADR-014 §3 prefers a false negative to a false alarm, and I was about to switch on a guard whose first act would have been to redden unrelated work.

Two false claims of mine, both corrected:

• "C-80 and C-82 were both a version declared twice with a guard on one copy" — neither says that. C-80 is the doc-accuracy scan exempting ADRs and CICs; C-82 is governance prose carrying numbers nothing checks. Same class, different subject. The claim originated in the test's own docstring on 2026-08-13 and I repeated it without reading either entry; corrected at the source.
• "three merged stories changed code under views_postprocessing/" — two did (_ContractStorePort.download fails open where upload refuses — C-79's untreated sibling #268, _ShardLease.load holds every shard of a target in memory at once — the forecast leg's #126 #269). C-89's two orphaned deferrals: relocate the leak guards, and point the rename proof at its subject #265 touched tests and the register only. Three stories merged; two changed package code. The patch conclusion is unaffected.

And one in the second commit message itself: it says "Suite 458 passed". The run in that same turn printed 457, and that commit adds no test. 457 is correct — recorded here because the commit message cannot be corrected without a force-push, and because a PR about false numbers should not quietly carry one.

Verification

ruff clean; 457 passed, 1 skipped, 39 xfailed.

The release guard locally: the newest-tag check passes (1.1.0 <= 1.1.1), the tagged-commit check skips because HEAD is not tagged yet — the correct state before the tag is cut.

Refs #125.