method: a truncating instrument, and an unreachable stop condition

The UI draw capture printed 8 vertices = two quads per draw, so a batched draw
dropped the rest silently. Four EXTRAS elements therefore appeared in no draw on
any screen, which reads as 'the game does not draw these' -- and the port spent
an iteration measuring them as the worst on the screen and asking about them.
When an instrument says an element never appears, check its limits before
believing the game.

And 'press down until the cursor stops moving' is not a stop condition on a
menu that WRAPS: it was unreachable, the loop only exited by exhausting its
budget, and it landed on EXTRAS because a dropped press cancelled one lap. An
earlier version of the same loop pressed (A) on NEW GAME after two identical
readings caused by a dropped press.

What held throughout is the part worth keeping: verify the state you measured,
never the actions you took.

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

docs/re/METHOD.md

@@ -3338,3 +3338,49 @@ three withdrawn *"the title never appears"* claims for the same reason. And
 **leaving the emulator up after a failed script is worth doing**: the run above
 was rescued by attaching to it, gating on the plate pulse and tapping Ⓐ by hand,
 which cost one minute against a twenty-minute reboot.
+
+## A truncating instrument does not report that it truncated
+
+Canary's UI draw capture printed the first **8 vertices** of each draw. A UI quad
+is 4 vertices, so a batched draw showed **two** of its elements and dropped the
+rest — silently, with a well-formed line and no ellipsis.
+
+The consequence was not a missing row in a table. `EXTRAS`' 24-index additive
+draw holds **six** sprites, so `ptframe4`, `pteff21`, `pteff22` and `pteff23`
+appeared in **no draw on any screen**, which reads as *the game does not draw
+these*. The port then measured those four as the worst elements on that screen
+and asked what blend they used — and the answer had been inside a draw already
+captured, one line above the truncation.
+
+**A cap that hides data is worse than a long line.** The rule that would have
+caught it: when an instrument reports "this element never appears", check its
+limits before believing the game. And a cap should print that it capped.
+
+⚠️ The same log had already been used to write *"every element on the two screens
+is covered except one"*. That sentence was wrong by four, and it was wrong in the
+reassuring direction.
+
+## A stop condition that cannot be reached is not a stop condition
+
+Walking the main menu to `EXTRAS` by counting presses failed — a press was
+dropped and the cursor landed one item short. The fix was "press ⬇ until the
+cursor stops moving", which needs no item count.
+
+**The main menu wraps.** The cursor never stops moving, so the loop's termination
+condition was *unreachable* and it only ever exited by exhausting its iteration
+budget. It ended on `EXTRAS` anyway — because a second press was dropped, and the
+drop happened to cancel one lap of the wrap. Two independent accidents cancelling.
+
+⚠️ **The first version of that same loop was worse**: it compared two readings,
+got the same row twice because the first press was dropped, concluded "the cursor
+has stopped" while sitting on the **first** item, and pressed Ⓐ on `NEW GAME`.
+
+The general shape: a stop test that cannot distinguish *"at the end"* from *"the
+input was lost"* is the press-counting bug wearing a different hat, and on a
+wrapping list it is not a test at all. What saved both runs is worth stating
+separately, because it is the actual discipline:
+
+**Verify the state you measured, never the actions you took.** Every capture here
+was preceded by a screenshot that was looked at. The navigation was wrong twice
+and the measurement was never in doubt, because nothing downstream trusted the
+button presses.