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

re: the twins' correct block validates -- distinctness is a real fix; eng_02_l is not

Browse Source 
debug_try_anchor asks validate_block directly at the capture-proven offsets. Both
119-vert twin buffers are accepted by both twins (so the correct block lost the
first-match race, and a distinct assignment fixes it); the drawn 51-vert bridge
buffer is accepted by both bridge resources; eng_02_l's proven offset is rejected
outright, even with the pad widened to 64 -- a validator gap, not a selection one.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Claude (auto-RE)
2026-08-12 02:17:55 +00:00
parent 76a433f75c
commit 51723af59a
3 changed files with 107 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -674,6 +674,36 @@ An assignment that is distinct by construction — each candidate used at most o
offsets actually validate for their resources is the next thing to test; if they
do, distinctness alone is the fix.
**5. Do the proven offsets validate? Two of three — and that splits the fix.**
`mesh::debug_try_anchor(bytes, name, vb, max_pad)` asks `validate_block` directly
(`examples/try_anchor.rs`):
| resource | proven offset | verdict |
|---|---|---|
| `e106_bdy_01_l` / `e106_bdy_02_l` | `0x3b3ee8` **and** `0x3c55d8` | **accepted for both, at both** (v=119, idx=246, pad=0) |
| `e106_brg_01_l` / `e106_brg_01_b_02` | `0x40e418` | **accepted for both** (v=51, idx=126, pad=0) |
| `e106_eng_02_l` | `0x44a32c` | **rejected** — and still rejected with the pad widened to 64 |
So the twin case is exactly what it looked like: the correct block is perfectly
acceptable and simply lost the first-match race, and a **distinct assignment**
(each candidate buffer claimed by at most one resource) fixes it — the two
resources have two accepted offsets between them. The bridge pair is weaker:
`0x40e418` is accepted by both, our current `0x40de48` is accepted too, so
distinctness would separate them but not choose correctly.
`eng_02_l` is a different failure: the offset the engine drew from is **not
acceptable at all**, so no selection policy can reach it. That is the
"residual" class this file describes above, now with one member pinned to a
concrete offset for the first time.
❔ **An open discrepancy, recorded not explained.** The capture's `DRAW` lines
carry an `indices=` field that does not agree with the descriptor's index count:
the 119-vertex twin draws log `indices=21` where our marker says 246, and the
44-vertex draw logs `indices=12`. Whether that field is an index *count* of a
sub-range, a different unit, or a Xenia-side artifact is unknown — it may matter
for `eng_02_l`, whose block validation is exactly what an index-count mismatch
would break.
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.