docs(verilog): fourteen was the flag count, not the site count

bootstrap/src/compiler.rs

@@ -16545,11 +16545,20 @@ impl VerilogCodegen {
             NodeKind::StmtBreak => {
                 // t27#2988: this emitted `disable fork;`. `disable fork` kills
                 // processes spawned by a `fork` in the CURRENT SCOPE, and the
-                // token `fork` occurs nowhere in the 581 generated .v files
-                // except inside that very line -- so all fourteen sites were
-                // no-ops, the loop ran to completion, and later iterations
-                // overwrote whatever the break was meant to preserve.
-                // `iverilog -g2012` accepts it silently.
+                // token `fork` occurred nowhere in the generated corpus except
+                // inside that very line -- so every site was a no-op, the loop
+                // ran to completion, and later iterations overwrote whatever
+                // the break was meant to preserve. `iverilog -g2012` accepts
+                // it silently.
+                //
+                // Two numbers stood here and both were scoped to a reading this
+                // fix superseded. The population is 643 generated .v files, not
+                // the 581 under specs/. And the sites are 17 in 8 files, not
+                // fourteen: `tri jumps census` reads 17 sites sharing 14 guard
+                // FLAGS, and fourteen was the count of `disable fork;` lines
+                // before the fix. The old wrong number equals a real current
+                // number of a different quantity, so checking it against the
+                // census confirms it. Quote the census, not this comment.
                 //
                 // It was also emitted at COLUMN 0: `write_line` without
                 // `write_indent`. Both are fixed here.

bootstrap/stage0/FROZEN_HASH

@@ -1 +1 @@
-c150ac8923c5f8e4db7df88fd06f9f28e628e47427b4f285f071659cd0f7196f
+9b8875f1c9d4b795404286445fdbe65cf1e233aa4113883244bd8ade33d24b11

docs/now/2026-09-03-fourteen-was-the-flag-count-not-the-site-count.md

@@ -0,0 +1,10 @@
+# NOW -- Fourteen was the flag count, not the site count (2026-09-03)
+
+## A wrong number that the instrument confirms (Refs #2988)
+
+- the `StmtBreak` comment in `compiler.rs` said *"the token `fork` occurs nowhere in the 581 generated .v files except inside that very line -- so all fourteen sites were no-ops"*
+- **both numbers are scoped to a reading the shipped fix superseded.** `tri jumps census` on master reads **643** generated .v files, not the 581 under `specs/`; and **17 sites in 8 files**, not fourteen
+- the second is the one worth recording: **14 is the current count of guard FLAGS**, which 17 sites share. Fourteen was also the count of `disable fork;` lines before the fix. So a reader checking `14` against the census finds `14` and concludes the comment is right -- **a wrong number of one quantity equal to a right number of another, and self-confirming**
+- second occurrence of this class in two passes: #3017 corrected a referee test's comment that carried patch C's 37 where the shipped change moves 7. Both are a comment inside the fix quoting the number from before the correction
+- control that the change is a comment: `tri seals drift` reads **zero** across the sealed corpus, so no generated byte moved. `FROZEN_HASH` resealed in this commit
+- and my first control was broken: comparing against a cached corpus at `/tmp/genv` reported 7 files differing. That corpus predates #3021 -- **zero** loop-condition return guards in it against 2 in a fresh one -- and all 7 diffs are #3021's guard and its iteration-tail barrier. A baseline of unknown provenance is a stale ruler