fix(mesh): require exact pool coverage -- found by rendering, not by a metric

Rendering assembled e106 from Stage_S02 showed the old slab: e106_bdy_03 spanning
600x1600x998 where three other containers give 276x236x941. Its anchor had slack
3, and the coverage gate tolerated up to three unreferenced tail vertices --
tolerance that was hiding a mis-anchor, since real blocks reach their last vertex
exactly (8580 of 8629). Requiring exact coverage moves it to the block the other
containers agree on and the slab disappears.

Costs 3 resources (6212 -> 6209), inconsistency 39 -> 38, capture oracle
unchanged at 46/46, suite green. Evidence: captures/e106-cover-slack-before-after.png

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-08-12 06:56:49 +00:00
parent 9d33345560
commit f340815db6
4 changed files with 58 additions and 4 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 43 KiB

View File

@@ -1042,6 +1042,35 @@ not obviously right, and both points are one env var apart
(`XBG7_PAD0_CONSISTENCY`, `XBG7_EDGE_CAP`) for anyone who wants the conservative
end.
### ✅ Fixed by *looking* at the output: exact pool coverage (2026-08-12)
Rendering the assembled `e106` from `Stage_S02` — something no metric had done —
showed the old slab back: `e106_bdy_03` spanning **600×1600×998**, a blocky mass
beside the hull. The same resource decodes to **276×236×941** in `Stage_S01`,
`Stage_S03` and `Stage_S04`. The tell was already in the data:
| container | anchor | slack | span |
|---|---|---|---|
| `Stage_S01` | `0x3c9b7c` | 0 | 276×236×941 |
| **`Stage_S02`** | `0x12d1d44` | **3** | **600×1600×998** |
| `Stage_S03` | `0x1e07b7c` | 0 | 276×236×941 |
| `Stage_S04` | `0x164337c` | 0 | 276×236×941 |
| `Stage_S06` | `0x1f05298` | 0 | 414×636×1121 |
The coverage gate tolerated up to **three** unreferenced tail vertices, and that
tolerance was hiding a mis-anchor: real blocks reach their pool's last vertex
exactly (8 580 of 8 629). Requiring exact coverage moves `Stage_S02`'s
`e106_bdy_03` to `0x2d35b7c`, slack 0, **276×236×941** — the block three other
containers agree on — and the slab disappears from the render
([`captures/e106-cover-slack-before-after.png`](../captures/e106-cover-slack-before-after.png)).
Cost: **3** resources disc-wide (6 212 → 6 209); cross-container inconsistency
39 → 38; capture oracle unchanged at 46/46 claimed, 0 unclaimed; suite green.
(`Stage_S06` still gives a third answer at slack 0, so `e106_bdy_03` is not fully
settled — but it is now consistent across four of the six containers that carry
it instead of three.)
### The anchor work has plateaued at 98.7 % — state and what is left
Four evidence-driven changes took the decoder from 5 480 to **6 212 of 6 294**