diff --git a/.claude/skills/ci-gates/SKILL.md b/.claude/skills/ci-gates/SKILL.md
index 1657aea3ab..7fff33148b 100644
--- a/.claude/skills/ci-gates/SKILL.md
+++ b/.claude/skills/ci-gates/SKILL.md
@@ -7888,3 +7888,46 @@ compiler ACCEPTS -- the instruction that made them look in the right
 place.
 
 Related: §262, what the comment was hiding.
+
+## 312. The match arm's own comment named the case it was missing
+
+    NodeKind::StmtForRange | NodeKind::StmtWhile | NodeKind::StmtFor => {
+        // Control flow in a test block: a `for`/`while`/`if` was dropped
+        // as `// (stmt: StmtForRange)`, silently voiding loop bodies that
+        // accumulate assertions (t27#1948).
+
+`if` is named in the sentence and is not in the arm. Someone fixed
+`for` and `while`, wrote all three into the comment, and stopped.
+
+The cost: `if (es_prestandard(8) != 0) { ok = false; }` at the top of a
+test block became `// (stmt: StmtIf)`, so `ok` was set true and never set
+false. **The test could not fail and reported PASSED.**
+
+This is §253 again — a comment describing behaviour the code does not
+have — with the sharper edge that the comment is an ENUMERATION. When a
+comment lists cases, the list is checkable against the arm above it in
+one glance, and nobody had glanced.
+
+**Read a match arm and its comment as two independent claims and diff
+them.** Where the comment names N constructs and the pattern names N−1,
+the missing one is a defect with a name already attached.
+
+## 313. Two probes disagreed and the first one was mine
+
+Checking that same finding, my first probe read `lucas_accumulator.t27`,
+found the `if` fully emitted, and I nearly recorded the report as not
+reproducing. It was reproducing — in `posit_ladder_control.t27`, where
+the `if` sits at the TOP LEVEL of the test body. In `lucas_accumulator`
+it is nested inside a `while`, which routes through a path that handles
+it.
+
+The claim said "top-level `if`". I tested an `if`. Those are different
+statements, and only one of them is what was reported.
+
+**When a report names a position — top level, module scope, inside a
+loop — the position is part of the claim and a probe that ignores it
+tests something else.** The cost of getting this wrong is not a missed
+defect; it is a CONFIDENT REFUTATION of a true finding, which is worse
+than never having checked.
+
+Related: §262, what the comment was hiding.
diff --git a/docs/now/2026-08-30-the-arms-comment-named-the-missing-case.md b/docs/now/2026-08-30-the-arms-comment-named-the-missing-case.md
new file mode 100644
index 0000000000..fe4a195c52
--- /dev/null
+++ b/docs/now/2026-08-30-the-arms-comment-named-the-missing-case.md
@@ -0,0 +1,10 @@
+# NOW -- The arm's own comment named the case it was missing (2026-08-30)
+
+## Two lessons from the dropped `if` (Refs #2871)
+
+- the match arm covers StmtForRange / StmtWhile / StmtFor and its own comment says "a `for`/`while`/`if` was dropped" -- `if` named in the sentence, absent from the pattern
+- cost: a top-level `if` in a test block became a comment, so the flag was set true and never false and the test reported PASSED
+- when a comment ENUMERATES cases, that list is checkable against the pattern above it in one glance, and nobody had glanced
+- my first probe read the wrong spec: `lucas_accumulator.t27` nests its `if` inside a `while`, which routes through a path that handles it, and I nearly recorded the report as not reproducing
+- the claim said "TOP-LEVEL if" and I tested an if; the position was part of the claim
+- getting that wrong costs more than a missed defect: it produces a confident refutation of a true finding