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

re: n206 was fixed after all -- the audit was classifying by geometry, not buffer

Browse Source 
debug_grouped_report (why_rejected) shows n206_02's alternative pool is ACCEPTED
at pad 0 under production gates and is in the candidate list -- and the decoder
does take it: n206_02 now anchors at 0x342d984. The 'still collapsed' reading
came from the audit comparing decoded geometry, and that offset holds a direct
(unmirrored) copy, so a separated pair still looked identical. The audit now
requires a SHARED BUFFER to call it a collapse: disc-wide 18 exact mirrors, 16
related, 0 collapses, 0 unrelated -- and the regression test drops its exception.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
Claude (auto-RE)
2026-08-12 04:10:05 +00:00
parent bb0c94c0ce
commit db8104ab99
6 changed files with 159 additions and 23 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -945,13 +945,25 @@ cannot regress).
The runtime oracle is unchanged and cross-container inconsistency falls another
10 %. The suite, including the disc- and ISO-gated tests, stays green.
**It does *not* clear the `n206` collapse**, and that is informative: both twins
are grouped, the loser is re-placed past the taken pool, and no alternative pool
**validates** — so it keeps the collided decode. `n206_02` is therefore the same
class as `e106_eng_02_l` was before the cap moved: the correct block is rejected
by the validator, not lost to selection. Its correct pool is one of
`0x342d984` (direct) or `0x33b7754` / `0x342e284` (mirrored); a capture of a
stage containing `n206` would say which, and is the cheapest way to settle it.
**It clears the `n206` collapse too** — a correction to what was written here
first. `n206_02` now anchors at `0x342d984` instead of sharing `0x33b6e54` with
its twin. The earlier "no alternative pool validates" reading was wrong twice
over: `mesh::debug_grouped_report` (`examples/why_rejected.rs`) shows that pool
**ACCEPTED at pad 0** under the production gates, and `0x342d984` is in the
candidate start list. What actually misled the check was the audit itself —
it classified twins by decoded **geometry**, and `0x342d984` is a *direct*
(unmirrored) copy of `0x33b6e54`, so the pair still looked "identical" after it
had been separated.
The audit now distinguishes the two: identical geometry is only a collapse when
it comes from **one buffer**. Re-run disc-wide, of 34 equal-count twin pairs:
**18 exact X-mirror, 16 related another way, 0 identical-sharing-a-buffer, 0
unrelated** — and the regression test no longer needs its `n206` exception.
❔ Left open: whether `n206_01`/`n206_02` *should* be a mirrored pair at all. The
container holds two direct copies **and** two mirrored ones
(`0x33b7754`, `0x342e284`); our twins take the two direct copies, which is
self-consistent but unverified — `n206` appears in no captured stage.
### The twin invariant, checked disc-wide (2026-08-12)