Skip to content

test(cliffs): the orientation residual IS part of the over-placement (#84) - #103

Merged
wormeyman merged 1 commit into
mainfrom
cliffs/phantom-neighbour
Aug 3, 2026
Merged

test(cliffs): the orientation residual IS part of the over-placement (#84)#103
wormeyman merged 1 commit into
mainfrom
cliffs/phantom-neighbour

Conversation

@wormeyman

Copy link
Copy Markdown
Collaborator

The wrong orientations and the surplus cells have been tracked as two separate defects since #83. They are one defect.

The structure

placedCells builds one edge register per chunk, so v[cy][cx] is cell cx's left edge and cell cx-1's right edge - the same array slot, not two equal values. A spurious crossing therefore cannot be confined to one cell. It corrupts the orientation of the real cell on one side, and on the other it manufactures a whole cliff the game never placed.

Measured over all three oracle regions, rejections off so the geometry is not masked:

matched cells 1531
wrong orientations 37
of those whose disputed-edge neighbour the GAME places 0
distinct phantom neighbours 34
of those the PORT places, i.e. that are surplus cells 34 of 34

On the shipping path:

region matched wrong surplus surplus that ARE phantoms
[0,0] 281 5 2 2 of 2
[1500,1500] 858 25 22 10 of 22
[-1200,800] 386 3 1 0 of 1

At [0,0] the spurious crossings are the whole of the over-placement. And the reason 33 wrong cells do not imply 33 surplus is that the lava and ore rejections already remove 19 of the phantoms - the rejection hides the phantom while leaving the neighbour's orientation wrong, which is exactly how the two counts drifted apart and came to be read as unrelated.

What it changes

Not the design of the blocked grid-4 cliff-elevation capture - its value. That capture was being weighed against "33 wrong orientations, ~1.6% of cells", which reads like a rounding-error chase. It is also worth 12 of the 25 surplus cells, and all of [0,0]'s.

Ruled out on the way, each with a discriminating control

  • No gate in crossesCliff is marginal on the disputed edges. Scored against every crossing edge of every matched cell as control: cliffiness gap above > 0.5 (disputed min 6.8e-3 vs control 1.0e-3), the a < 0 || b < 0 early-out (disputed min elevation 15.6), boundary < e0 (disputed min 2.73 above e0). Corroborates test(cliffs): the orientation residual is not a boundary tie (#84) #102's band-margin result by a different route.
  • The asymmetric smoothing knot lattice is not a misreading. In-chunk knots at 0, 4 and 7 (hi clamped to CHUNK_CORNERS - 1) is odd enough to look like an off-by-one. The natural alternative - knots every 4 corners globally - is 8x worse: 312 wrong against 37, matched 1531 -> 1173, missing 38 -> 396. Raw (s = 0) is worse still at 677. The disassembly reading now has a measurement behind it.
  • cliffiness_basic stays exonerated, and soundly: it contains no multisample, so unlike elevation it has no grid-4 variant to have been captured in the wrong channel.

Verification

pnpm run verify green - 160 files, 1369 tests. The new spec was checked for vacuity by pointing the neighbour lookup at the wrong axis: 4 of its 5 tests fail.

Item of #84; the issue stays open.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FpXiK2MPqPFVtm5CMPNXR2

…84)

The wrong orientations and the surplus cells have been tracked as two
defects. They are one.

`placedCells` builds one edge register per chunk, so `v[cy][cx]` is cell
`cx`'s left edge and cell `cx-1`'s right edge - the same array slot, not
two equal values. A spurious crossing therefore cannot sit inside one
cell: it corrupts the orientation of the real cell on one side and
manufactures a cliff the game never placed on the other.

Over the three oracle regions, rejections off: 37 wrong orientations,
**0** whose disputed-edge neighbour the game places, 34 distinct phantom
neighbours, and **34 of 34** are cells the port emits - i.e. surplus.

On the shipping path this owns 12 of the 25 surplus cells, and at [0,0]
it owns every surplus cell there is (2 of 2). That does not change the
design of the blocked grid-4 cliff-elevation capture, it changes what it
is worth: it was being weighed against "1.6% of cells carry a wrong
orientation", which reads like a rounding-error chase.

Ruled out on the way, each with a discriminating control:

- No gate in `crossesCliff` is marginal on the disputed edges, scored
  against every crossing edge of every matched cell as control.
- The asymmetric smoothing knot lattice (in-chunk knots at 0, 4 and 7,
  `hi` clamped to CHUNK_CORNERS-1) is not a misreading. Knots every 4
  corners globally is 8x worse - 312 wrong against 37. The disassembly
  reading now has a measurement behind it.

The new spec was checked for vacuity by pointing the neighbour lookup at
the wrong axis: 4 of its 5 tests fail.

Item of #84; the issue stays open.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FpXiK2MPqPFVtm5CMPNXR2
@wormeyman
wormeyman merged commit 394dfbc into main Aug 3, 2026
2 checks passed
@wormeyman
wormeyman deleted the cliffs/phantom-neighbour branch August 3, 2026 14:14
wormeyman added a commit that referenced this pull request Aug 3, 2026
) (#108)

#107 handed over one untested hypothesis with its control named: "disputed
edges sit adjacent to rejected cells above the base rate of all crossing
edges". Run, it is not an enrichment over a base rate - it is a dichotomy,
and it refutes the STAGE at which the port applies both Vulcanus cliff
rejections.

Of the 1235 edges the port has and the game does not, **1233** sit against a
cell the game did not emit. Of the 36,103 in-region edges both sides agree
on, **0** do. A cell's edge register is the same array slot as its
neighbour's (#103), so the game's absences take their crossings with them.

**The refutation is structural, not a score.** A pure post-filter makes a
falsifiable prediction: when cell N is rejected, its surviving neighbour C
still holds the shared crossing and is emitted carrying it. Counted with the
port's own rejection predicate over the fine sweep's 41 levels, that should
happen **1,662 times**. The game does it **0 times**. The vacuity arm is the
identical counter reading the port's own post-filter output, where it fires
on all 1,662 - so the zero is a property of the game's cliffs, not a dead
branch.

`tryToAddCliff` really does ignore `wouldCollide`'s return value; the #71/#73
disassembly reading was not misread. What is refuted is the conclusion drawn
from it - "and therefore no effect on the neighbouring cells". Both doc
comments that asserted it are corrected rather than left standing.

`rejectAtCrossingStage` zeroes a rejected cell's four edge registers after
the repair sweep, before any code is read. Collapsed rule: wrong orientations
**1235 -> 693**, surplus 1366 -> 1200, matched 18130 -> 18654. At the
SHIPPING settings across the three entity regions: wrong orientations
**33 -> 21**, precision 0.9839 -> 0.9858, and the matched set IDENTICAL at
1525 - it removes wrong edges and costs no recall.

Not free: 18 more of the game's cells go missing under the collapsed rule,
because an edge taken off a survivor can leave its code non-placing. Reported
rather than buried. Nauvis is byte-identical either way (it already matched
1.0000 both directions), so this is not a regression risk there and not
corroboration from there either.

Tiling stays byte-identical - the zeroing runs over the whole chunk,
including cells outside the query box - and `tiledEquality.spec.ts`'s
Vulcanus cliff seam and chunk-boundary cases verify it rather than the
comment asserting it.

What is left is the PREDICATE, not the stage: 693 wrong and 1200 surplus
survive, and the sweep cannot measure the field where the game emits nothing
at any level.

Item of #84; the issue stays open.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01ExK3ASs5i2KMm9NwWqnZuj
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant