The i16[3] high-byte finding -- the most recent and most subtle result of this
stretch, and the one I corrected twice -- lived only in prose. Two commits is
exactly how long a claim can sit unasserted before it drifts. It now has a test:
tie_vertex_layout_is_selected_by_i16_3_high_byte
which reproduces the figures exactly and, importantly, asserts both directions:
(4,5) and (6,7) are above 0.85 and 0.80 in the ordinary group, (6,7) is BELOW 0.99
so it cannot silently become the constant I once mistook it for, (0,1) and (2,3)
are under 0.20, and every pair in the non-zero group is under 0.15. A future
change in either layout now fails loudly.
Also audited the rest of this session's claims against the test suite and recorded
the result in the format doc:
tie vertex element is 16 bytes asserted
layout selected by i16[3] HIGH byte asserted (this commit)
blocks self-delimiting on 0xf6 asserted per-block
packets == 0 means no block at that LOD asserted
packets[0] == 256 on 1,864 of 1,864 asserted
chunk record length uniform per chunk asserted
moby class IDs in one body slot per type asserted
collision payload verbatim in RAM NOT assertable here -- needs a savestate
tfrag patch bytes all rewritten by LOD same
morphing is unobservable in that image same
The split is deliberate: disc-readable claims are asserted against the disc,
savestate-dependent ones live in plan/pcsx2-verification.md with their method.
What is not acceptable is a disc-readable claim living only in prose -- which is
how the tie i16[3] finding spent two commits before it had a test, and how several
older claims drifted before the roadmap reconciliation caught them.
ReaperOfVeriod
9f938f47de