Stop the crate root counting the types that hold something, and anchor the command that counts the block

src/lib.rs

@@ -65,10 +65,24 @@
 //!
 //! What that bound is worth is stated rather than implied, and it has moved. THIS
 //! PARAGRAPH SAID THE TYPES BELOW HOLD NOTHING, SO NO ASSERTION COULD FAIL ON THE
-//! BYTES IN THIS TREE. One of them holds something now: `measurement::Measurement`
-//! carries a reference to a client's clock source, a reference to a client's
-//! subscriber and a counter, and the assertion on it is what refuses a facility
-//! that stopped being safe from any thread.
+//! BYTES IN THIS TREE. It stopped being true with `measurement::Measurement`,
+//! which carries a reference to a client's clock source, a reference to a
+//! client's subscriber and a counter, and the assertion on it is what refuses a
+//! facility that stopped being safe from any thread.
+//!
+//! IT THEN SAID ONE OF THEM HELD SOMETHING AND NAMED THAT ONE, WHICH WAS A COUNT
+//! OVER A BLOCK OF FIVE. The block held five assertion lines on 2026-08-26, when
+//! that sentence landed, and 145 at
+//! `f38bf7b101550664e06b9b8ee72c4dff5ad8e186`. Nine of the types asserted below
+//! are written with a borrowed parameter, so each of them holds a reference in
+//! exactly the sense this paragraph gives for `Measurement`, and nine is a floor
+//! rather than the population, since a type does not need a lifetime to hold a
+//! field. The count is deleted rather than corrected, for the reason the
+//! paragraph under it already gives about a count here: the next landing moves
+//! it again, and nothing in this tree reads a number written into a doc comment.
+//! `Measurement` stays as the example it was and is no longer named as the
+//! whole set. #434 is where it was found, by reading this paragraph against the
+//! block it is about.
 //!
 //! THE SENTENCE AFTER IT SAID THE OTHER FOUR STILL HOLD NOTHING, AND IT IS NOT
 //! REPLACED BY A NEW COUNT. It was written against a list of five and the list
@@ -77,13 +91,24 @@
 //! same reason this one did, and the list is one command away:
 //!
 //! ```text
-//! git grep -c 'any_thread::<' -- src/lib.rs
+//! git grep -c '^    any_thread::<' -- src/lib.rs
 //! ```
 //!
+//! THAT COMMAND CARRIED NO ANCHOR UNTIL THIS EDIT AND COUNTED THE LINE THAT HANDS
+//! IT OVER AS ONE OF THE ASSERTIONS. It answered 146 against 145 assertion lines
+//! at `f38bf7b101550664e06b9b8ee72c4dff5ad8e186`, and it answered 15 against 14
+//! on 2026-08-27, the day it arrived, so it has been one too many on every
+//! reading it has ever had. A derivation written here to replace a count that
+//! went stale was itself never run against the block. The anchor is what keeps
+//! the line above out of its own answer: an assertion is indented inside the
+//! block below and that line is not.
+//!
 //! What the sentence was for is unchanged and does not need the number: an
 //! assertion over a type holding nothing cannot fail on the bytes in this tree,
 //! and it is there so that the day the type holds something is the day the
-//! compiler starts judging it.
+//! compiler starts judging it. THAT DAY HAS COME FOR MORE THAN ONE OF THEM, and
+//! it is the half a reader sizing what a green build proves here should not take
+//! from the paragraph above: the block is not a list of empty names waiting.
 
 #![forbid(unsafe_code)]
 #![deny(missing_docs)]