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

handoff+method: land the ordinal retraction where the claims live

Browse Source 
Marks the two void splash rows in the capture-comparison data file, withdraws the
three claims in HANDOFF, and corrects the METHOD entry -- whose 'a gradient across
buckets is not a mechanism' near-miss was itself resolved by a counter-example
taken with the wrong index.

General form recorded: an index that silently means something else produces
well-formed output for the wrong object, and this project has now been bitten
twice from opposite directions with 'everything still validates' both times.

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 12:59:58 +00:00
parent 3356343cad
commit f102cf9209
3 changed files with 59 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
docs/re/METHOD.md
View File

@@ -1685,7 +1685,17 @@ settles, so `rest_vs_settle` filtered on it. Reasonable, documented, and wrong i
ran it only after the port agent produced a counter-example.
📌 And the near-miss on top: the census made "narrow window ⇒ bad settle pose" look
obvious — 45.1 % against 15.0 % — and it is **refuted by two screens inside the
filtered-out band**, which win by 75× and 33×. **A gradient across buckets is not a
mechanism.** Say what the mechanism would be and check it against the extreme cases,
which here point the opposite way.
obvious — 45.1 % against 15.0 % — and I thought it **refuted** by two screens that
appeared to sit in the filtered-out band while winning 75×.
🔴 **That refutation was itself wrong**, and the correction is the sharper entry.
Those two screens were addressed by **build ordinal** where I believed I was giving
a **pak entry** — `[10] → entry 12` — so I had rendered the loading screens. Their
real windows are the *widest* of the five. **A counter-example is a measurement too,
and mine was taken with the wrong index.**
⚠️ **The general form: an index that silently means something else produces
well-formed output for the wrong object.** This project has now been bitten twice
from opposite directions, and both times "everything still validates". When a
counter-example arrives that overturns a gradient, check *what it is a measurement
of* before you believe it — the same scrutiny the gradient got.

10
docs/re/data/settle-vs-rest-against-captures.txt
View File

@@ -1,3 +1,13 @@
# 🔴 THE TWO SPLASH ROWS BELOW ARE VOID (retracted 2026-08-30).
# They used `screen render --build 10/11`, which takes a BUILD ORDINAL:
# `screen list` says [10] entry 12, [11] entry 15. Those are the LOADING
# screens. The rows scored loading-screen renders against SPLASH captures.
# I discarded them at the time for a railed gamma fit; the real reason is
# that they were the wrong screens, and the railing was that mismatch
# surfacing in the only place the instrument could report it.
# The `title` row is unaffected -- ordinal 4 is entry 4.
# See splash-settle-window-retraction.txt.
#
# Does UiBuild::settle_time() itself beat rest() against the GAME?
#
# The port ran my PROPOSAL against captures and favoured it 3/3, but tested