The Decoder decoded bit 0 of kind as the PARENT FLAG, disc-wide: kind & 1 agrees
with 'has a parent' on 15493 elements, zero disagreements. So 0x3003 is 0x3002
parented, and carries no role information -- the OPTIONS rows were never a
different class, they just have a parent.
Detector now matches 0x3002 | 0x3003 as TWO LISTED VALUES, not a mask.
kind & 0xFFFE == 0x3002 would also match 0x73002/0x73003 -- 160 elements whose
0x70000 bits are undecoded -- silently, on screens neither agent has looked at.
Excluded by construction until somebody decides deliberately.
Impact measured BEFORE re-exporting: exactly two screens gain buttons, options
and options_jp, five rows each. No existing screen changes.
Verified: main_menu -> down x3 -> (A) -> OPTIONS, then down x2 moves
po_menu_btn2 -> po_menu_btn3, focus ring rendering on the highlighted row.
📌 Waiting was right. The rule I rejected -- 'carries a focus record therefore is
a menu item' -- would have reached this answer by a second inference from
structure and reclassified elements on unseen screens. The field cost one
question and needed no inference.
41f13318f4