fabi/Syplheed-Reborn
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

test: lock in the twin invariant -- 0 unrelated pairs disc-wide, 1 known collapse

Browse Source 
twin_mirror_audit applies the capture-derived rule to all 166 containers: of 34
equal-count twin pairs, 18 are exact X-mirrors, 15 related another way, 1
identical, 0 unrelated. Two calibration fixes were needed first (authored halves
need a tolerance, and a mirrored pair may be stored in another vertex order).
The one collapse, n206_01/_02, is a grouped-pool pair -- the path distinct
assignment excludes -- so it names the next target. Added a disc-gated
regression test; refreshed the stale ignore message on the consistency test.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Claude (auto-RE)
2026-08-12 03:44:29 +00:00
parent 55e1fe3783
commit fd34d350f2
4 changed files with 227 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
docs/re/structures/xbg7-mesh.md
View File

@@ -930,6 +930,36 @@ of one buffer, a resource landing on a **mirrored** copy would be a real defect
and would look identical to a correct decode in every count-based metric. Only a
capture (or the twin-pair invariant) can catch it.
### The twin invariant, checked disc-wide (2026-08-12)
The capture gave a rule that needs no capture to apply: a `…_01`/`…_02` pair of
equal vertex count should decode to **mirrored** geometry, never to the same
buffer. `examples/twin_mirror_audit.rs` applies it to all 166 containers:
| twin pairs of equal vertex count | 34 |
|---|---|
| exact X-mirror | **18** |
| related another way (Y/Z mirror, or the same cloud in another vertex order) | 15 |
| identical — a collapse | **1** |
| unrelated — no relation at all | **0** |
Two calibration notes, because the first run of this audit got both wrong.
Comparing quantised keys **exactly** reported four false "unrelated" pairs
(`e101_eng_01/_02`): the halves are authored, not bit-negated, so they differ in
the last digits — a tolerance is required. And a mirrored pair may be stored in a
**different vertex order**, so the multiset has to be compared mirrored as well
as directly. With both fixed, nothing on the disc is unrelated.
The single collapse is `n206_01`/`n206_02` (`Stage_S08`), both anchored at
`0x33b6e54` while the container holds a second direct copy at `0x342d984` and
mirrors at `0x33b7754`/`0x342e284`. It survives because both twins are
**grouped-pool** resources (4 sub-meshes), and distinct assignment excludes that
path — so this is the concrete next target, and the fix direction is to extend
distinctness across grouped models.
`tests/mesh_consistency_disc.rs::twin_pairs_do_not_share_a_buffer` locks this in:
no twin pair may share a buffer, with `n206` the one asserted exception.
Not settled: `e106_brg_01_b_02` ≡ `e106_brg_01_l` (51 verts). A second 51-vertex
`vbase` exists in the logs but is **not** from this container, and the container
holds three near-identical 51-vertex runs, so the pair has no oracle yet.