re: the blend bit was challenged on pteff10 and SURVIVES; finding 3 loses its second candidate

The port isolated main_menu's 10.88 -> 13.02 regression to pteff10 and
asked whether the per-draw log shows it alpha-over, which would be a
counter-example to ui-blend-mode-decoded.md.

It does not. blend-bit-vs-oracle.txt has pteff10 ADDITIVE on entry 5 (main
menu) AND entry 6 (extras), both labels read out of the guest command
stream, and HANDOFF states it from three independent menu sessions, every
frame.

The premise came from a stale coverage table of mine that the same HANDOFF
entry had already corrected in place. Recording that: a correction which
leaves the wrong table visible upstream of it has not landed.

And the regression was predicted on this exact element before adoption --
HANDOFF flagged pteff10 as the one row the port's renderer would not
corroborate, because for a dim wholly-semi-transparent glow (max alpha 130)
over a dark background additive and alpha-over nearly coincide. A renderer
metric getting worse while the render gets more correct is the standing
rule with a number on it.

Separately, the port answered my finding-3 candidate: a frozen sweep of the
plate region rises monotonically across the declared 214->236, so the port
fades rather than pops and its t=236 is a completion. That kills the onset
branch.

Two of the play-test's four named candidates for finding 3 are now dead --
units/s (measured at 60) and the ramp. Finding 3 has no surviving named
cause. The clock origin is the one to take next, because every measurement
so far is a DIFFERENCE between two events and a difference cannot detect a
common offset.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Jc4pciRArGHfxGGhEbwp5t

docs/re/guest-frame-rate-measured.md

@@ -144,6 +144,24 @@ when it *starts*.
 port raising the plate at `t = 236`; whether that is its onset or its completion
 is the port's to check. What is decoded here is the disc fact and the arithmetic.
 
+### 🔴 ANSWERED same day, and this branch is dead too
+
+The port checked and reports a frozen sweep of the plate region across the
+declared ramp — `210u → 0.1457`, `216u → 0.1573`, `222u → 0.1727`, `228u →
+0.1900`, `236u → 0.2142`. **A clean monotone rise across `214 → 236`: the port
+fades, it does not pop**, and its `t = 236` is its completion, not its onset.
+
+So the onset branch is eliminated as well. Of the four candidates the play-test
+named for finding 3 — the unit→seconds constant, the clock origin, `rest.t`, the
+record layout — **two are now dead**: units/s is measured at 60 here, and the
+plate's ramp is being drawn. **Finding 3 has no surviving named cause.**
+
+The remaining two are the **clock origin** (does the port's shared clock start
+when the game's does?) and **`rest.t`**, and the origin is the one worth taking
+first: everything measured so far is a *difference* between two events, and a
+difference is exactly what cannot detect a common offset. `REFUTED.md` already
+records that believing `rest.t` put a port's plate **3.97 s late once**.
+
 ## Reach
 
 ⟨capture⟩ over **one** boot, English locale, one machine, and the movie region of

docs/re/structures/ui-blend-mode-decoded.md

@@ -118,3 +118,52 @@ that it is **not** "the name contains `eff`" (`P(eff|set) = 0.468` against
 `P(eff|clear) = 0.144`) and **not** premultiplied-alpha storage — both refuted
 disc-wide, and both remain refuted. Those were readings of the bit's *meaning*;
 this is its *effect*.
+
+## Challenged 2026-09-01 as a possible counter-example — and it SURVIVES
+
+The port reported that adopting the bit moved `main_menu` **10.88 → 13.02**
+against its oracle capture, isolated the only newly-additive top-level element as
+**`pteff10`**, and asked whether the per-draw log shows `main_menu`'s `pteff10`
+drawn **alpha-over** — which would put a counter-example on one element.
+
+**It does not. The oracle measures it ADDITIVE on that screen.**
+
+```
+data/blend-bit-vs-oracle.txt
+  5   pteff10.t32   +0x04 = 00008832   bit 0x02 = true   ADDITIVE
+  6   pteff10.t32   +0x04 = 00008832   bit 0x02 = true   ADDITIVE
+```
+
+Entry 5 is the main menu and entry 6 is `EXTRAS`; the element is additive on
+**both**, and every label there is an `RB_BLENDCONTROL0` value read out of the
+guest command stream. `HANDOFF.md` states it directly and from three sessions:
+*"Is `pteff10` additive on the MAIN MENU too? — **YES.** … additive, **in all
+three menu sessions, every frame**."*
+
+⚠️ **The premise came from a stale table of mine.** The port's *"your own map
+lists `pteff10` additive on `extras` and not on `main_menu`"* is reading a
+coverage table that the same HANDOFF entry had already corrected in place —
+*"My coverage table listing `pteff10` as uncovered on the menu is corrected."*
+A correction that leaves the wrong table visible upstream of it is a correction
+that has not landed.
+
+### 📌 The regression was PREDICTED, on this exact element, before adoption
+
+`HANDOFF.md`, flagged as 🟡 at the time the port was told to take the bit:
+
+> *"One flag on `pteff10` before you adopt it. You measure it as nearly exact
+> under alpha-over, and the game draws it additive. Both can be true for a dim
+> wholly-semi-transparent glow (max alpha 130) over a dark background, where the
+> two nearly coincide — but it is the one row here your renderer does **not**
+> independently corroborate."*
+
+So `main_menu` getting *worse* on a renderer metric while getting *more correct*
+against the GPU is the flagged case arriving on schedule, not a new fact. It is
+the corpus's standing rule with a number attached: **a claim resting on our
+renderer is a claim about our renderer**, and here the renderer and the oracle
+disagree on the one element where the two blends are known to nearly coincide.
+
+The port shipped the decoded bit anyway and recorded the movement as a known
+regression. That was the right call for a better reason than the one it used:
+not merely that `+2.14` sits inside the screen's `±3.78` capture-phase term, but
+that the oracle had already adjudicated this element, three sessions deep.