diff --git a/docs/re/structures/xbg7-mesh.md b/docs/re/structures/xbg7-mesh.md
index 9e5cd60..de74547 100644
--- a/docs/re/structures/xbg7-mesh.md
+++ b/docs/re/structures/xbg7-mesh.md
@@ -365,16 +365,39 @@ family of fixes: no threshold, no scoring, no "pick the best candidate" changes
 this, and the earlier attempt to add best-of-N selection in the grouped-pool
 anchor duly changed nothing.
 
-**The search space has to be constrained instead.** Two candidates, in order of
-how much new format knowledge they need:
+**The search space has to be constrained instead — and the fix is now pinned
+down.**
 
-1. **Per-resource data extents.** The XPR2 resource table gives each resource a
-   descriptor; if the geometry extent can be derived from it, restrict `starts`
-   to that range and the theft becomes impossible.
-2. **Monotonic anchoring.** If resources' data blocks follow descriptor order,
-   then resource *k*'s `vb` must lie after resource *k−1*'s — a cheap constraint
-   needing no new format knowledge. Testable against the 556 resources that
-   already decode consistently across containers.
+**The correct block is already in the candidate list.** Enumerating *every*
+validating candidate for `e303_wep_01` in `Stage_S02` gives exactly two:
+
+```
+vb = 18 403 456   span 1600 × 2100 × 4800   ← what the decoder takes, only because it is first
+vb = 52 257 440   span   49 ×   23 ×   42   ← correct: the same size all 11 good containers give
+```
+
+So nothing needs to be found that the scan is missing; the wrong one merely
+appears earlier in file order.
+
+**Locality picks the right one.** Recording each resource's accepted anchor in
+descriptor order shows that global **monotonicity is refuted** — only 25 of 47
+steps increase in `Stage_S01` and 130 of 248 in `Stage_S02`, i.e. no better than
+chance. But *neighbourhood* holds strongly: in `Stage_S02` this resource's
+descriptor neighbours anchor at **51 974 668** and **52 218 424**, its correct
+candidate is **52 257 440**, and the block it wrongly takes is at **18 403 456** —
+two thirds of the file away from its own family.
+
+**Proposed rule:** among candidates that validate, prefer the one **nearest the
+anchors of the neighbouring resources** (equivalently: decode in descriptor order
+and prefer candidates close to the previous resource's anchor), falling back to
+first-match when there is no neighbour yet. That needs no new format knowledge,
+and it selects `52 257 440` here.
+
+**Not implemented.** It changes the anchor for every one of the 6 294 resources,
+so it needs the before/after measurement — decoded count must not fall from
+5 480, and the inconsistency count should fall from 125 — plus the ignored test
+[`mesh_consistency_disc.rs`](../../crates/sylpheed-formats/tests/mesh_consistency_disc.rs)
+un-ignored once it passes.
 
 ### Where the mis-decode is *not*: the grouped-pool anchor