The derived-offset recompute swept the whole func_8013D53C family: 119 banked / 0 failed on top of
the 4 earlier; func_8013D53C is now stubbed in ZERO overlays. R22 clean-fleet 140/140 BYTE-IDENTICAL;
tools-health OK; dedup 1886/0; 0 NON_MATCHING (G4).
RECIPE (and it is NOT the return-axis recipe — sampling caught this):
§84 derived-offset -> per-member literal recompute AND the gate_stage ladder.
With the recompute alone the sample was 0/8; through the ladder it was 3/3, then 119/119.
Had I reused the return-axis recipe (plain harvest_verify, which banked 272/272 there) I would
have swept 123 members to zero banks and mis-concluded the fix was wrong. Probe-before-scale.
METRIC FINDING worth carrying: this harvest moved instr +29,280 AND distinct-code +27,840, while the
return-axis harvest moved instr +26,928 and distinct-code +0. §84-class members are byte-VARIANTS so
each is a new unique function; propagation-class members were already counted once via their shared
exemplar. => §84-class work moves the RE-COMPLETENESS number; propagation moves only the DISPLAY one.
Session fleet: 80.6 -> 81.0% instr · 68.2 -> 68.8% distinct-code · 89.18 -> 89.30% fn-count.
Drew T
015ebff536