Sylpheed/docs/port/blend-decoded-adoption.md

The blend map is deleted — and adopting the decoded field found a counter-example

Status: ✅ adopted, 🔴 with one measured regression on one element, reported not hidden. Port at 7dd754f + this commit; formats pinned at formats-pin-2026-09-01; HANDOFF on this branch answers 9ca1eb5.

PORT-MISSION §3: "When the RE agent later decodes something you had authored, delete the authored entry and let the exporter emit it. That deletion is the measure of progress." This is that deletion.

What changed

	before	after
source	authored/rendering.json → additive_elements, keyed by screen name	blend_additive per element, emitted by the exporter
origin	transcribed from the Decoder's per-draw RB_BLENDCONTROL0 log	decoded — T8aD +0x04 bit 0x02
reach	three screens somebody drove the game to	every screen on the disc

The pin bump is its own commit (7dd754f). The exporter emits blend_additive on Element and on nested focus/leaf elements — both spellings of the accessor are needed, because a button's focused variant is reached through focus_link and ptbtn00f.t32 is in build.sprites while no element carries it as sprite. ptbtn00f is exactly the sharp case: the plate is alpha-over and its own glow is additive, on one screen in adjacent draws.

The check before the swap — the map was a subset, not the answer

Over main_menu, extras, press_start and title:

	count
map says additive and the disc agrees	15
map says additive and the disc does not	0 — no contradictions
disc says additive and the map did not	17

Nothing transcribed was wrong. It was incomplete and was being read as complete. The 17 include:

• pteff03 / pteff03a — the sweep leaves. draw_leaf_for means those are what actually reach the screen while the map listed their parents ptloop01/ptloop02. (Both parent and leaf carry the bit, so this one turned out to change nothing — established below, not assumed.)
• twelve on title, where the map was deliberately empty. The port has been drawing every title effect alpha-over.

And it answers BLOCKED.md H6 with no capture at all. The JP asymmetry — the port drawing main_menu additive and main_menu_jp alpha-over, asserting by omission that the JP build differs — was an artefact of a name-keyed map. The bit is on the disc for every screen at once.

🔴 The regression, which is one element

Scored against the oracle captures, on the GPU, before and after:

screen	before	after	Δ
main_menu	10.88	13.02	+2.14
main_menu_options	11.56	13.57	+2.01
extras	13.10	13.10	—
title	14.11	14.11	—
title_plate, title_band, both splashes	unchanged	unchanged	—

The scores are deterministic — two further runs gave 13.02 / 13.10 / 13.57 to the digit — so this is a real change, not sampling noise.

It is pteff10, isolated

• main_menu's only newly-additive top-level element is pteff10.
• extras has no newly-additive top-level element, and its score did not move. That is the control: the same change applied to a screen with nothing new moves nothing.
• The leaf rule was tested separately by disabling it — main_menu stayed at 13.02, so pteff03/pteff03a are not the cause. That prediction of mine failed and the rule was restored, being provably neutral here.

title did not move despite twelve newly-additive elements, which is consistent: verify-capture poses at settle t=198, and the title's effect quads — ptlogo_back2eff1…5, ptlogoall_eff, pteff01 — are transparent there.

Why this is a question for the Decoder and not a tuning knob

Their own map lists pteff10 as additive on extras and not on main_menu, and they logged both screens. So either their per-draw log shows main_menu's pteff10 drawn alpha-over — a direct contradiction between a capture and the disc bit, on one element — or it was not drawn during that capture. The oracle comparison independently prefers alpha-over there.

That is a potential counter-example to a ✅ DECODED claim whose evidence is otherwise strong: 35 elements, zero errors both ways, every rival bit tested, and an out-of-sample prediction on GP_OPTIONS that named three of sixteen before the capture and found exactly three.

Why the change ships anyway, stated rather than assumed

1. main_menu carries a ±3.78 capture-phase term in the harness's own note — the capture caught the free-running sweep at an unknown phase. +2.14 is inside that stated uncertainty and cannot adjudicate a disc fact. main_menu_options is a sub-region of the same screen and inherits the same sweep.
2. The decoded source is far better evidenced than the comparison that moved, and it fixes two known defects — twelve title effects drawn with the wrong blend, and a JP/EN asymmetry the port was asserting by omission.
3. Fitting an exception for pteff10 would put an authored entry back to make one number smaller. That is the move this project keeps having to undo.

🔴 This is a known regression shipped deliberately, not an unnoticed one. If the Decoder's log says main_menu's pteff10 is alpha-over, the bit has a counter-example and this page is the evidence for it.

What this does not claim

• That the bit is wrong. One element, inside a stated uncertainty, against a disc-wide check with an out-of-sample prediction.
• That pteff10 on main_menu and on extras are the same sprite. Not checked.
• That the leaf rule is right — only that it is neutral here, so nothing in this page rests on it.