fix(mesh): raise the connectivity cap 0.28 -> 0.42 on runtime evidence

Swept against the 46 capture-named Stage_S02 buffers with distinct assignment in
place: 0.28 anchors 40 exactly and leaves 4 unclaimed; 0.42 anchors 45 and leaves
none; nothing above 0.42 improves further, so it is the least permissive value
that captures the whole gain. 589 more resources decode, nothing is lost. The
cross-container consistency proxy worsens (46 -> 62) -- it cannot see a
systematic mis-anchor, and where the two disagree the capture wins. Suite green.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-08-12 03:25:50 +00:00
parent d83bdd3b68
commit 7f1ac41563
3 changed files with 63 additions and 24 deletions

View File

@@ -874,6 +874,39 @@ and the two assertions that encoded the old convention were updated, each with
the reason in place; the full suite including the disc- and ISO-gated ship tests
is green.
### ✅ Fixed: the connectivity cap is 0.42 (2026-08-12)
With distinct assignment in place the cap was swept again against the 46
capture-named buffers. It saturates:
| cap | exact anchors | unclaimed | resources decoded | shared inconsistent |
|---|---|---|---|---|
| 0.28 (old) | 40 | 4 | 5 480 | 46 |
| 0.35 | 42 | 3 | 5 955 | 56 |
| **0.42 (now)** | **45** | **0** | 6 069 | 62 |
| 0.45 | 45 | 0 | 6 093 | 62 |
| 0.60 | 45 | 0 | — | — |
Nothing above 0.42 anchors anything more, so **0.42 is the least permissive value
that captures the whole measured gain** — 45 of the ship's 46 drawn buffers get
exactly the right resource, none is left unclaimed, and 589 more resources decode
than at 0.28 with nothing lost.
The one metric that worsens is cross-container consistency (46 → 62). That is the
*proxy*, and this file already documents why it is the weaker witness: a
systematic mis-anchor is invisible to it because it is consistent. Where the two
disagree, the capture wins. Full suite green including the disc- and ISO-gated
ship tests.
**Still open — grouped composites.** `_rou_f105_break` (the f105 destruction
model) claims **twelve consecutive** drawn buffers, each matching one of its
sub-mesh vertex counts exactly, while `f105_bdy_01_m`, `f105_bdy_03_m`,
`f105_eng_01_m` — resources of exactly those sizes — are anchored elsewhere.
Distinct assignment does not touch this: the grouped-pool path is excluded. The
question is the twins' question again — does the container hold two copies of
each of those buffers, or one that both names should share? The same
mirror/duplicate test would answer it.
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.