Drew T
1.5 KiB
§191 — WHAT THIS HARVEST DID NOT BANK (4 rejected, 4 narrowed) — recorded so it is not re-derived
The harvest ran 10 readers over 247 wave-R/S verdicts, then one adversarial verifier per candidate,
defaulting to REJECT: 18 candidates → 10 CONFIRMED, 4 WEAK, 4 REJECTED. Two verifiers rebuilt their
target from the ROM because the .s had been pruned on bank; one re-ran a four-form A/B rather than trust
the reader's sweep; one caught the src/800.c:5430 comment being wrong about its own mechanism.
Narrowed to their surviving core (banked above only in the corrected form, with the falsified half
named): func_80182E2C — roughly a third of the submitted rule was false · func_801836D4 — the
headline technique is byte-falsified, only the corrected form survives · func_801859F4 — bank only the
second half, as a sharpening of §164-73/§164-74 and a bound on §165-21, never as a new "LUID tie-break"
law · gfx2D_BG0_OBJ_4D8 — a register __asm__("$N") pin gets no caller-save, so the target's own spill
block must be hand-written as C statements (fragment byte-proof only, since the merged function is not
banked).
The standing rule this harvest reinforces: a reader's rule and a verifier's rule are different artifacts. Every confirmed entry above changed shape under verification — bounds added, a mechanism re-attributed, a sub-claim refuted — and the ones that did not survive were rejected for exactly the reasons §179 predicted: not banked, or banked C contradicting the narrative written about it.