fabi/Sylpheed
1
0
Fork 0
Code Issues 9 Pull Requests Actions Packages Projects Releases Wiki Activity

method: a control that only checks differences cannot fail on the origin

Browse Source 
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Wuu56cE8vJGTBtn1ppsk8v
This commit is contained in:
sylph-decoder
2026-08-30 21:57:00 +00:00
parent ec9ab203af
commit 04e8c6d8a7
1 changed files with 27 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
docs/re/METHOD.md
View File

@@ -2389,3 +2389,30 @@ reads prose against a register, the port's checks read numbers against a tree, a
a comment that contradicts the function under it is invisible to both. It is an a comment that contradicts the function under it is invisible to both. It is an
untested surface we both keep writing to, and the correction that creates it is untested surface we both keep writing to, and the correction that creates it is
always a *good* correction, which is why it goes unnoticed. always a *good* correction, which is why it goes unnoticed.
## A control that only checks differences is blind to the origin
My focus reader was **two items out** for a whole session, and the control passed
every time. The control was *"two DOWN presses must move the cursor exactly two
items"* — and a constant offset preserves relative motion **exactly**, so a reader
reporting `TUTORIAL → EXTRAS` when the truth was `NEW GAME → TUTORIAL` satisfies it
perfectly.
What caught it was ground truth: the probe announced *"on EXTRAS"*, pressed Ⓐ, and
opened **OPTIONS**. I looked at the frame.
The cause is worth naming because it is invisible in a diff: `menu_focus.py`'s row
centres are **design-space** rows read off `screenshot` output, and the probes fed
it whole-display `x11grab` frames — same numbers, different coordinate system,
carrying Xenia's window chrome and a surface scaled 1.060.
⚠️ **So: a differential control validates a differential claim only.** Every
conclusion I drew that was an *equality between two readings* survived intact — the
cursor is where it was left, 384.0 vs 385.5 — because a constant offset cancels.
Every conclusion that was a *name* was wrong. Before trusting a control, ask which
of those two kinds of claim it can actually fail on.
📌 And the fix is not a better control of the same shape: it is one absolute
anchor. `ring_row.py` now reports the ring's **measured row** and refuses to name
an item when the row is not within half a step of a calibrated centre — refusing is
the point, because a wrong name is what it exists to prevent.