mirror of
https://github.com/Druthulu/BFM-decomp
synced 2026-09-26 13:33:34 -04:00
Drew T
8d4f2a38cb
Max-effort re-measurement of the three jr refusals I ledgered earlier this session.
Two of the three verdicts were FALSE. Every number below is SHA vs config/check.<ov>.sha
from a clean tree, with the restore re-verified.
func_8018057C / ov_SC01_009 : jr_isolate_all is BYTE-NEUTRAL
-> "JR-ISOLATE-BREAKS-BYTES" RETRACTED; original failure not reproducible.
func_80191C50 / ov_SC06_018 : isolate NEUTRAL -> carve DIVERGED
(got 1b1667ea, want cbbc4f44) -> the ONE real instrument failure. CONFIRMED.
func_8017BEBC / ov_SC04_004 : carve is BYTE-NEUTRAL (body-free)
-> failure is the TEMPLATED BODY, the OPPOSITE of what SS125 first claimed.
Re-probed once more from a verified-clean tree: still gate-fail. Reclassified
BODY-TEMPLATE-GATE-FAIL.
So the tidy "two apparent walls are ONE tooling problem" conclusion was wrong: they
are two different problems, and the third target has no demonstrated problem at all.
ROOT CAUSE, and it is mine not the tools': a grep-of-the-build-log gate inside a driver
that did not revert on abort. config/overlays.mk is SHARED, so target 1's half-applied
isolate was still in the tree while target 3 was measured. Separately reproduced the
SS42b stale-object trap head-on: `git checkout -- config/` WITHOUT a re-extract turned a
byte-identical overlay into [FAIL] got 8f28aa77 / want 38a3d919 (Phase-20's R22
corollary, live).
SS125 rewritten. The METHOD (split the carve from the body, one build) is kept and is
what refuted this section's own first conclusion; what is added is the instrument rules
that make its answer trustworthy: compare the SHA against config/check, never grep the
log; re-extract after every config change AND every revert; a driver that aborts a
target must revert it before the next; verify the BASELINE against canonical too.
Meta-lesson recorded: SS53 says a 0% from the wrong TOOL manufactures a doctrine — this
is the same failure one level up, a verdict from the wrong MEASUREMENT, and my own
diagnostic script is an instrument subject to R35 like any other.
Ledger corrected in place (3 entries, superseding the earlier misattributions), so the
scheduled repair is the right one. No source/config change; no bank affected; the fleet
is untouched at 140/140 (last full R22 this session, HEAD commit:1263).