Files
BFM-decomp/docs
Drew T 8d40d55c7a docs(phase-30): SS130 — an INCREMENTAL build reported BYTE-IDENTICAL for a change the CLEAN build cannot LINK
I reported func_8013B83C + func_8013BD74 as "BOTH BANKED - BYTE-IDENTICAL". That was
WRONG. My in-loop gate ran `make extract && make build` without `make clean`, and it gave
a FALSE PASS. The clean rebuild does not link at all:

    ov_SC01_077_o0.c:(.text+0x10f8): undefined reference to `$L105'
    ov_SC01_077_jr_801588CC.o: undefined reference to `func_8013C938'

- the first is a local label from the C-emitted jump table;
- the second is a PREVIOUSLY-MATCHED cluster fn going undefined (the incremental build
  reused objects that still satisfied it).

Reverted; R22 140/140; nothing lost, nothing was committed.

SS42b named the stale-object trap for a FALSE FAIL. This is its MIRROR: a FALSE PASS, on a
change that is not even linkable — false in the most convincing direction possible, a green
SHA. Anything touching config/ (carve, resegment, split) must be gated by a full
clean-fleet R22 before it is BELIEVED, let alone reported.

THREE WRONG CLASSIFICATIONS ON THIS PAIR, all corrected in the ledger:
  CC1-FAIL-UNREAD      -> it has no compile error at all
  JTBL-PAD-SPEC-DRIFT  -> I had carved ONE fn of a TWO-table span; carving both gives
                          pad spec [0,4,4] and the filter is satisfied
  "both banked"        -> the false pass above
Real class: JR-PAIR-IN-ONE-O0-OBJECT. Both bodies ARE byte-correct (match_one --o0 and
rtu_match --o0 both MATCH, 272 / 198 ins); the blocker is integrating TWO jr fns into ONE
-O0 object. Untested escape: SS81 step 1, isolate one into its own code subseg so each
object owns exactly one table.

Also records the diagnostic ladder that found it: diff the two BINARIES and bucket each
differing byte against the function's own vram range. 3,749 of 3,791 diffs were OUTSIDE the
function, first diff near the overlay START, image 57 bytes LONGER - the SS8 signature of
.rodata floating to the front. That fingerprint separates a codegen residual from a layout
effect in one build, and it is what finally redirected three wrong guesses.
2026-07-31 18:47:00 -06:00
..