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

.github/workflows/run_pytest.yml

@@ -18,6 +18,14 @@ jobs:
     steps:
     - name: Checkout repository
       uses: actions/checkout@v3
+      with:
+        # `fetch-depth: 0` for the TAGS, not the history. The default shallow checkout
+        # fetches none, so `git tag -l` is empty and BOTH guards in
+        # tests/test_release_version.py skip — the pair written because tag 1.1.0 was cut
+        # while pyproject.toml still said 1.0.0. A guard against mis-cutting a release
+        # that only ever runs on the maintainer's laptop is half a guard, and the half
+        # that is missing is the one watching the moment it matters.
+        fetch-depth: 0
 
     # ── sibling checkouts: what CI can verify that a bare checkout cannot ────────
     #

pyproject.toml

@@ -1,6 +1,6 @@
 [tool.poetry]
 name = "views-postprocessing"
-version = "1.1.0"
+version = "1.1.1"
 description = ""
 authors = [
     "Dylan Pinheiro <dylpin@prio.org>",

tests/test_release_version.py

@@ -7,8 +7,14 @@
 
 Measured 2026-08-13: tag `1.1.0` was cut at `main` while `pyproject.toml` still said
 `1.0.0`, so an install from that tag reported the previous release. Caught before any
-consumer pinned. Third time in this arc a version has been declared twice with a guard on
-one copy (register C-80, C-82).
+consumer pinned, and the tag was re-pointed.
+
+*(This docstring used to add "third time in this arc a version has been declared twice
+with a guard on one copy (register C-80, C-82)". Corrected 2026-08-15: neither entry says
+that. C-80 is the doc-accuracy scan exempting ADRs and CICs; C-82 is governance prose
+carrying numbers nothing checks — the same **class** as this, a number with no guard, but
+about the register and CIC front matter, not about a version declared twice. The claim was
+repeated into a release PR before anyone read the entries it cited.)*
 """
 
 import re
@@ -63,9 +69,18 @@ def test_the_newest_release_tag_is_not_ahead_of_the_declared_version():
 
     This is the direction that actually bit: the tag moved, the file did not. Runs on
     every commit, not only tagged ones, so the gap is visible the moment it opens.
+
+    **Tags reachable from HEAD, not every tag in the repository.** ``git tag -l`` lists
+    tags on every branch, which asks the wrong question: whether a release was cut
+    *anywhere*, rather than whether one was cut from *this line of history* without the
+    bump. The difference was invisible while CI fetched no tags at all, and would have
+    become a false alarm the moment it started: tag `1.1.1` on `main` would redden every
+    branch still declaring `1.1.0` — a long-lived feature branch, a hotfix cut from
+    `1.1.0` — none of which has done anything wrong. ADR-014 §3 prefers a false negative
+    to a false alarm, and a guard that reddens honest branches is one someone deletes.
     """
     out = subprocess.run(
-        ["git", "-C", str(_REPO), "tag", "-l", "--sort=-v:refname"],
+        ["git", "-C", str(_REPO), "tag", "--merged", "HEAD", "--sort=-v:refname"],
         capture_output=True, text=True, check=False, timeout=30,
     )
     releases = [t for t in out.stdout.split() if re.fullmatch(r"\d+\.\d+\.\d+", t)]