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

method: 'it did nothing' and 'it never happened' look identical from outside

Browse Source 
An A press produced no screen change; the obvious reading was that the button did
nothing. The log said the press was never delivered -- two file-pad vk=5800 lines
across the whole run is ONE press -- because it was issued 0.8 s after a screen
appeared, while the guest was loading and not polling.

The pad driver reports what it emitted, so a script checking its own output sees
success either way. Confirm the receiving side.

Generalised: when an action produces no observable effect, the first hypothesis
is that the action did not occur, not that it had no effect. The corpus has paid
for this twice -- here, and in the sign-in swallow where thousands of delivered
keystrokes were discarded inside the emulator and looked exactly like a dead pad.

Companion to the control entries: a control proves the instrument reads
correctly; a delivery check proves the experiment happened at all.

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 10:31:12 +00:00
parent bbc167425f
commit e882900f85
2 changed files with 44 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
docs/re/METHOD.md
View File

@@ -1459,3 +1459,26 @@ the stale text **still present**, because the replacement *quotes* the refuted
sentences in order to name them — so a substring search matches them inside the
paragraph saying they are false. The match was real and meant the opposite of what
the search implied. This is "the tell is in the rows that agree" arriving as a grep.
## "It did nothing" and "it never happened" look identical from the outside
Driving the menu, an Ⓐ press produced no screen change and the obvious reading was
that the button did nothing. The log said otherwise: **two** `[file-pad] vk=5800`
lines across the whole run — one press, not two — and one `[RE-INPUT]` delivery. The
second press was **never delivered**. It was issued 0.8 s after a screen appeared,
while the guest was still loading and not polling, and a 120 ms press vanishes in
that window.
The pad driver reports what *it* emitted, so a script that checks its own output
sees success either way. **Confirm the receiving side**, not the sending side:
`[RE-INPUT] … -> user=0 vk=5800` is the guest saying it got one.
⚠️ Generalised: whenever an action produces no observable effect, the first
hypothesis is *"the action did not occur"*, not *"the action had no effect"* — and
those need different evidence. This corpus has now paid for it twice: here, and in
the sign-in swallow, where thousands of *delivered* keystrokes were being discarded
inside the emulator and looked exactly like a dead pad.
📌 Companion to the entry above about controls: a control proves your instrument
reads correctly; a **delivery check** proves the experiment happened at all. They
are different, and only the second one catches a null result that never ran.