diff --git a/.gitea/workflows/checks.yml b/.gitea/workflows/checks.yml
index 425738e..0d7d692 100644
--- a/.gitea/workflows/checks.yml
+++ b/.gitea/workflows/checks.yml
@@ -110,6 +110,18 @@ name: checks
 # trigger` step below then keeps it that way mechanically rather than by asking
 # the next editor to read this comment.
 #
+# ⚠️ READ THE BLIND SPOTS ON THAT STEP BEFORE TRUSTING THE SENTENCE ABOVE.
+# "Mechanically" holds only for a reintroduced filter that still names the
+# PR's own base. For blind spots 1 and 3 the defence IS this comment, because
+# the guard lives inside the workflow that a filter makes Gitea skip. Blind
+# spot 3 is the one that matters: a filter naming a branch nothing targets
+# (`branches: [main]` from a template - this repo has no `main`, and no pull
+# request in 99 has ever targeted `master`) is itself skipped, lands green and
+# untested, and then every subsequent pull request is skipped too. That is the
+# gate off for everything, silently. Closing it needs a SECOND permanently
+# unfiltered workflow posting its own context, with that context added to
+# `release/1.0`'s `status_check_contexts` - a forge change, with the owner.
+#
 # THE MEASUREMENT, because the obvious guess is wrong and was nearly written
 # here as fact. A skip-ci keyword in a commit message (`[skip ci]`, `[ci skip]`,
 # `[no ci]`, `[skip actions]`, `[actions skip]`) does NOT behave like a filter