blend-bit-vs-oracle.txt entry 2: ptbtn00 alpha-over, ptbtn00f ADDITIVE -- the
PRESS (A) plate and its own highlight, one bit apart. Entry 4, the whole title, is
alpha-over throughout including ptlogo_back2/ptlogo_back2eff, which independently
kills the "frame-shaped and mostly transparent means additive" rule I declined to
adopt.
Bands are now per DRAW OP rather than per paint-order entry: one band per element
cannot express base alpha-over with its own focus record additive.
The change reported zero three times and each zero had a different cause.
First, additive_elements was assigned to `view` in three places and to `overlay` in
none, and the plate is an overlay -- every other decoded rule on that page goes to
both.
Second, I then measured that the element is never drawn, suppressing its sprite at
six times across the cycle for 0 px every time, and was one commit from filing "the
port never draws the plate highlight" as a defect. That sweep was invalid: I varied
--time while passing --loop-phase=0 in every run, and --loop-phase pins exactly the
clock a looping record runs on. Six samples of one phase.
Third, swept properly, ptbtn00f contributes 0 px at phase 0 and 22-29k px at phases
20-100 -- and verify-capture's title_plate row poses at loop-phase 0. The row that
validates the plate is blind to the plate's pulse by construction. It correctly
reports 13.03 / 0.09 % unchanged while the fix moves 26 319 px at phase 20. Stated
in the tool next to the pose.
Not verified against the oracle: every title-plate capture we hold is at the blind
phase, so no capture here can confirm the port now draws it right. Asked.
d45b23ebbe