mirror of
https://github.com/Druthulu/BFM-decomp
synced 2026-09-28 14:59:48 -04:00
186a8b1548
REORDER_TUS := 800c2 800c2_2 800c2_3 800c3 are piped through reorder_passthrough.py into as -O2 by the Makefile — the mode that fills delay slots and emits the jr/addiu epilogue. That island landed 2026-09-01 and banked 20 functions. match_one, the oracle every drafting agent scores against, still compiled those TUs through maspsx + as -O1, so it reported a phantom LENGTH-DRIFT in the epilogue and an extra instruction. Measured on one plain-C draft of func_8005ECC0: maspsx + as -O1 closeness 5, 36 ins vs 35 'the §188 wall' reorder + as -O2 closeness 2, 35 ins vs 35 epilogue identical Cost, in the S76w wave alone: seven of eleven main agents produced correct C, saw the phantom tail, correctly identified the §182/§188 shape, consulted oracle_reorder.py — which told them 'file IMMOVABLE, no C-level work can ever close it' — and each submitted a §265 verbatim-asm body instead. They all reasoned correctly from a false premise the knowledge base gave them. The TU list is DERIVED from the Makefile, never a second copy (R51 — a derived property stored as config goes stale, which is this defect exactly). oracle_reorder.py's docstring is corrected and the cookbook carries the §182/§188 correction with the byte evidence.