test(cliffs): four of the ten ore remainders are the onDestroy CASCADE (#84)

[wormeyman]

vulcanusOreRejection.ts records box overlap as explaining 21 of the 31 cells the ore suppresses, the other ten as "run remainders", and the cascade half of that question as REFUTED.

That refutation is about a different cascade. It tested #108's crossing-stage mechanism - a rejection zeroes the cell's edge registers, a neighbour's code changes, re-test to a fixpoint - and its conclusion ("rejected cells do not turn neighbours rejectable") still stands.

The applyCliffs cascade is a different thing: Cliff::onDestroy takes the facing end of every connected neighbour, and a neighbour left with no end at all is destroyed outright. It was read out of the binary in #113, after #110 ran, and nothing had re-run the remainder question against it.

Replayed entirely on the game's own data

Nothing of the port's field, ore model or geyser roll appears in this measurement:

• start from the game's ALL resources OFF cliff set - 892 cells with the game's own orientations
• destroy the cells whose base collision box overlaps one of the game's own resource entity positions, at the prototype half-extents the fixture itself carries
• compare against the game's resources ON set - 861 cells

arm	matched	wrong	surplus
control - destroy the lever's own 31	861	0	0
direct overlap only, no cascade	856	5	10
direct overlap + onDestroy cascade	859	2	6

• Direct overlap fires on 21 cells and every one is in the lever's 31 - precision 1.000, re-derived with no data of ours.
• The cascade closes 4 of the 10 remainders and 3 of the 5 orientation errors.
• Recall 21/31 = 0.677 → 25/31 = 0.806, with no new parameter and no wider box.
• missing is 0 in both arms, so no cell the game kept is ever removed. That is what separates a mechanism from a bigger rectangle - a box wide enough to reach those four would also reach cells the game kept, and test(cliffs): the ore rule is NOT entity collision, and it acts at the destroy stage (#84) #124 established the box is not the engine's collision test to begin with.

The control is load-bearing, and so is one flag

The control says the ore-off world minus those 31 cells is the ore-on world, orientations included. Without it none of the other rows mean anything.

Getting it exact needs noUpdateConnections: true: the game's dumped set is POST-pipeline, so running updateConnections over it again double-applies the pass and trims ends that legitimately survived. Forget it and the control scores wrong = 13 - which reads like a defect in the cascade model and is an artifact of the harness. Any future experiment that starts from a dumped set rather than from our own queue has the same hazard, so it is written down.

The six that remain

1546,1550.5  1546,1554.5  1606,1590.5  1606,1594.5  1622,1614.5  1626,1614.5

Two are the pair #123 attributed to the geyser, and 1546,1550.5 is the one cell in this entire residual whose destruction the game's own orientations directly witness (#124's n=1). So the best-evidenced destruction in the whole investigation is still unexplained by any rule.

What this does NOT change

Nothing shipping. The renderer rejects at the crossing stage and does not run applyCliffConnections at all - see ## The queue has a CONSUMER for why that is deliberate. This is a statement about the RULE and about which of its remainders now have a mechanism. The stale "cascade REFUTED" line in vulcanusOreRejection.ts is corrected in place rather than left to mislead.

Verification

pnpm run verify green - 1465 app (up 4) + 13 worker + 3 container tests, 0 warnings, exit 0.

🤖 Generated with Claude Code

https://claude.ai/code/session_015jeznBmWiZywUc7cBw9xFU