Three things, and the first is the one worth reading.
❌ MY COUNTER-EXAMPLE FAILED. I reported pteff10 as a possible counter-example to
the ✅ DECODED blend bit. It is not: the oracle measures it ADDITIVE on main_menu
in all three menu sessions, every frame, entry 5 of blend-bit-vs-oracle.txt.
My premise was a stale COVERAGE TABLE of theirs, sitting upstream of its own
correction. I inferred "their log does not cover this element" from a summary and
called it a contradiction with a capture. The lesson is not that their table was
stale -- it is that I treated a summary as the log, having spent three iterations
insisting that other people quote instruments rather than conclusions.
Their explanation made a prediction, so I checked it rather than accepting it:
if additive and alpha-over nearly coincide on a dim glow, why did my score move
20 %? Diffing the two renders, where pteff10's blend is the only change:
identical 373 588 px (40.5 %)
differing > 3 330 794 px (35.9 %)
MAX difference 32 levels pixels >= 60: 0
Their explanation holds and my scepticism does not. Nothing moves more than
32/255. What moved the RMSE is AREA.
📌 And that generalises past this row: raw-rmse is AREA-WEIGHTED, so a shallow
change over a third of the frame moves it far more than a deep change over a few
hundred pixels, and the number alone cannot say which you have. 10.88 -> 13.02
reads like a serious regression and is invisible to an eye. Any verify-capture
row that moves should be asked "broad or deep?" first; it costs one histogram.
I did NOT take their suggestion to exclude the element from the metric. The
reason to exclude -- "the metric cannot distinguish these" -- is now measured to
be false; it distinguishes them fine and weights them by area. Excluding would
remove the only signal that would fire if the bit were wrong elsewhere.
✅ H5 CLOSES, as a side effect. pgloading_loop5 -- the element I had localised all
951 differing pixels to -- carries blend_additive, and ui_layout.rs has no
additive path, so the reference cannot reproduce that draw by construction.
build_00/build_01 agreed only because they never draw it; with the decoded field
they gained loop1/loop4 additive and now differ too, as predicted.
🟢 The strongest corroboration of the decoded field came unfitted, from the rows I
was not looking at. EN/JP twins were 4.1x and 7.8x apart under the name-keyed map
and are now 1.1 % and 1.3 % apart (main_menu 7.26 vs 7.34, extras 6.98 vs 7.07).
A disc-wide field predicts locale twins render identically; a screen-name map
cannot. That prediction was not available to me before the swap.
🔴 AND I BROKE MY OWN ALLOWANCE, silently, one iteration after building it.
check-all's verify-screen allowance derived from authored/rendering.json's
additive_elements -- the key I deleted last commit -- so it evaluated to EMPTY and
would have failed six rows for no reason anyone could read off the output. Caught
by going to look, not by the check. A derived allowance is only as durable as the
thing it derives from, and I pointed this one at a file I then emptied.
It now derives from the EXPORT. ⚠️ That is LOOSER and the cost is stated: 12 of
16 screens qualify and verify-screen goes fully green. Measured after the swap
the two sets line up exactly -- all 10 differing screens have a drawn additive
element, all 6 agreeing screens have none -- but a screen differing for some
OTHER reason would now be excused. 📌 The real fix is not here: verify-screen
compares two renderers and one cannot express a blend the disc declares. Giving
ui_layout.rs an additive path would make it meaningful again. PROPOSED, not done
-- their crate, and their refutation of additive predates the measurement that
overturned it.
Not settled: finding 3, which now has no surviving named cause at all -- the
Decoder is taking the clock origin, on the grounds that every measurement either
of us has made is a DIFFERENCE and a difference cannot detect a common offset.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_018AHUQvXGyNcKonSEWsgWcX