re: count the in-range fallbacks -- and the control that failed is the answer

sylpheed-port pointed out that classifying defaults "by inspection" is exactly
the method that cannot see an in-range fallback, and that correction applies to
my own sweep from an hour ago: I waved 64 sites through by reading them.

Counted instead, disc-wide over 965 builds and 24 811 keyframes:
  ui_layout.rs:1681  untimed poses (would fabricate t=0):        0
  ui_layout.rs:1010  pose_at queries 168 264, None (reads a=0):  0

Two zeroes, which is the result this corpus now distrusts most, so the detector
was made to prove it can see a hit: ask pose_at for a time no build declares.
The control FAILED -- 10 906 out-of-range queries, 0 None -- so the detector was
blind and the :1010 zero measured nothing.

The failure is the finding. pose_at is TOTAL: reading the source, its only None
path is an `if ks.is_empty() { return None }` guard, and disc-wide there are 0
elements with zero keyframes out of 5 453. So :1010's unwrap_or(0) is unreachable
BY CONSTRUCTION, which is stronger than "0 in this corpus" -- and it was
established by the control failing rather than by the count passing. Without the
control this corpus would have recorded a true conclusion resting on a
meaningless number.

:1681 stands differently: 0 of 24 811, and time really is Option<u32> with the
stale reader demonstrably producing None (its screen info prints a trailing -),
so the state is representable and a detector would see it. :973 is not a hazard
-- guarded two lines later by `if tmax == 0 { return false; }`, where reading is
sufficient because the guard is the proof.

METHOD gains both: a zero is worth nothing until the detector is shown able to
report non-zero; and the habit under several of this week's errors, which is
reading a PROXY for the thing when the thing itself is one command away -- a line
count for an era, a type name's spelling for its default, an ordinal for an
entry, a fallback's text for its firing rate.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v

docs/re/data/fallback-fabrication-sweep.txt

@@ -66,3 +66,35 @@ GP_TUTORIAL.pak                    2 read       0 FABRICATED
 # number. Mine is 0, which is a LEGITIMATE keyframe time -- pose 0's time really
 # is 0 -- so a fabricated one would be indistinguishable from a real one in any
 # output. An in-range fallback cannot be caught downstream.
+
+################################################################################
+# COUNTED, not inspected -- 2026-08-30, after sylpheed-port pointed out that
+# classifying defaults "by inspection" is exactly the method that cannot see an
+# in-range fallback. That correction applies to this file's own first pass: 64
+# sites were waved through as sentinels by reading them.
+# instrument: examples/inrange_fallback_count.rs
+#
+#   965 builds, 24 811 keyframes
+#   :1681  untimed poses (fallback would fabricate t=0):            0
+#   :1010  pose_at queries 168 264, of which None (reads a=0):      0
+#
+# ⚠️ Two zeroes, which is the result this corpus distrusts most. So the detector
+# was made to prove it can see a hit -- ask pose_at for a time no build declares:
+#
+#   CONTROL  10 906 out-of-range queries, 0 None      <-- THE CONTROL FAILED
+#
+# The detector was BLIND, and the :1010 zero meant nothing. The failure is the
+# finding: pose_at is TOTAL. Reading the source, its only None path is an
+# `if ks.is_empty() { return None }` guard at line 217 -- and disc-wide there are
+# 0 elements with zero keyframes out of 5 453. So :1010's unwrap_or(0) is
+# unreachable by CONSTRUCTION, which is stronger than "0 in this corpus", and it
+# was established by the control failing rather than by the count passing.
+#
+# :1681 stands on a different footing: 0 of 24 811, and `time` really is
+# Option<u32>, with the STALE reader demonstrably producing None (its `screen
+# info` prints a trailing `-`). So the state is representable and a detector
+# would see it; the corrected reader simply never produces one.
+#
+# :973's unwrap_or(0) is NOT a hazard: it is guarded two lines later by
+# `if tmax == 0 { return false; }`. Read, not counted, and that is sufficient
+# because the guard is the proof.