port: my pteff10 counter-example failed, H5 closes as additive, and I broke my own allowance

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

tools/port/check-all

@@ -176,10 +176,50 @@ differs=$(grep -c DIFFERS "$OUT/verify-screen.log" || true)
 # the map it is derived from. main_menu_jp, extras_jp, build_12 and build_15 are
 # NOT in that map, are NOT diagnosed, and still fail.
 # docs/port/verify-screen-blend-divergence.md
+# 🔴 THIS DERIVED FROM authored/rendering.json AND I DELETED THAT KEY MYSELF.
+# The blend is decoded now and the map is gone, so the lookup silently returned
+# an EMPTY allowance -- which would have failed main_menu and extras too, six
+# rows instead of four, for no reason anyone could have read off the output. A
+# derived allowance is only as durable as the thing it derives from, and I
+# pointed this one at a file I then emptied one iteration later.
+#
+# It now derives from the EXPORT, which is what the port actually draws from: a
+# screen may differ if any of its elements -- or any nested focus/leaf element --
+# carries `blend_additive: true`, because `ui_layout.rs` has no additive path at
+# all and cannot reproduce those draws by construction.
+#
+# ⚠️ THIS ALLOWANCE IS LOOSER THAN THE ONE IT REPLACES AND THAT IS A REAL COST.
+# The old map covered 3 screens because it was a transcription of what somebody
+# had driven the game to; the bit is disc-wide, so 12 of 16 screens now qualify
+# and verify-screen goes fully green. Measured after the swap, the two sets line
+# up exactly -- all 10 screens that DIFFER have a drawn additive element, and all
+# 6 that agree have none -- so nothing is being excused that does not have the
+# cause. But a screen that starts differing for some OTHER reason will now be
+# excused if it happens to carry an additive element anywhere, and this check
+# will not say so.
+#
+# 📌 THE REAL FIX IS NOT HERE. `verify-screen` compares two renderers and one of
+# them cannot express a blend mode the disc declares, so the comparison is
+# structurally incapable on 12 screens. Giving `ui_layout.rs` an additive path
+# would make it meaningful again -- that is the Decoder's crate and their
+# refutation of additive predates the RB_BLENDCONTROL0 measurement that overturned
+# it, so it is PROPOSED here and not done.
 additive_screens=$(python3 -c "
-import json
-d=json.load(open('authored/rendering.json')).get('additive_elements') or {}
-print('\n'.join(k for k,v in d.items() if v))" 2>/dev/null)
+import json, glob, os
+out = []
+for p in sorted(glob.glob('export/screens/*/*.json')):
+    d = json.load(open(p))
+    def any_add(els):
+        for e in els:
+            if e.get('blend_additive'):
+                return True
+            for k in ('focus', 'leaf'):
+                if any_add((e.get(k) or {}).get('elements', [])):
+                    return True
+        return False
+    if any_add(d.get('elements', [])):
+        out.append(os.path.basename(p)[:-5])
+print('\n'.join(out))" 2>/dev/null)
 allow_args=(-e title -e title_jp)
 for sc in $additive_screens; do allow_args+=(-e "$sc"); done
 printf '  %-24s allowing %s (additive set + 2 legacy)\n' verify-screen \