test(cliffs): the ore rule is NOT entity collision, and it acts at the destroy stage (#84)

[wormeyman]

#123 put 11 of the 25 missed destructions on the ore rule and named widening it as the next move. The mechanism was worth one more look first, because vulcanusOreRejection.ts has always said the rule is characterised, not ported.

Conclusion: do not widen the box.

Entity collision is excluded - verified three ways, not asserted

The file already claimed this from call ordering. All three routes are now read off the 2.1.12 arm64 slice or the game data:

1. Order. computeInternal calls generateCliffs at +0x2c - before it even builds the NoiseCache the three generateEntities passes use - and apply calls applyCliffs, applyDecoratives, applyEntities in that order.
2. Inputs. generateCliffs' entire call list is crossingsForChunk, MaybeCliffOrientation::value, tryToAddCliff. The queue has no resource input at all.
3. Masks, at the PROTOTYPE level rather than the type default. calcite, tungsten-ore and sulfuric-acid-geyser are all type = "resource" and none overrides collision_mask, so all three take {layers={resource=true}}. The cliff default is {item, meltable, object, player, water_tile, is_lower_object, is_object, cliff}. Disjoint.

Route 3 kills the variant nobody had written down: cross-chunk ordering. Chunk N's entities really are on the surface before chunk N+1's cliffs are applied, so "the resource was already there" is a genuine escape from the ordering argument - and it still cannot matter, at any box size, because the masks never intersect.

And the one entity-versus-cliff test that exists runs the other way: applyEntities calls Surface::mapGeneratorWouldCollide per queued entity and skips the entity on a hit (tbnz w0, #0x0 to the loop tail). It never destroys a cliff. That is the CLIFF -> ORE direction, which #99 measured as inert.

The stage IS measured: it is a destruction

Applying #122's discriminator to the lever's 31 cells - exactly one is decidable, and it says DESTROYED:

cell	neighbour	the game's orientation	verdict
1546,1550.5 (geyser)	1546,1546.5	north-to-none	end gone - destroyed

Treating it as never-queued contradicts the game at that neighbour; doing the same to any of the other 30 costs nothing - the contrast arm, and also the honest statement of how thin this oracle is. n = 1. It is a stage localisation, not a survey, and the spec says so in those words.

So the ore's effect enters at applyCliffs/Surface::wouldCollide, not at crossingsForChunk. Combined with the exclusions, that is a sharper open question than "the mechanism is unknown": something the resource control changes reaches Surface::wouldCollide by a route that is not the entity half.

Why this stops the widening

The box-overlap model is shaped like the resource entity's rectangle, and that shape is real - it is what distinguishes the geyser's 1.398 half-extent from the ores' 0.098. But that shape is now established not to be the engine's collision test. Widening it until the remaining cells fall out would be fitting a shape to an unexplained effect rather than modelling a code path - precisely what #88 shipped and #90 had to undo.

The recall gap is real and still worth closing. Close it by finding what the resource control actually changes.

What is NOT excluded, stated so it is not re-derived

• The geyser arm is a separate matter: includeGeyser: false is a model gap (our geyser placement rolls and misses the game's 56), not a shape question, and fixing it needs no mechanism.
• The route from autoplace_controls to Surface::wouldCollide is open. Its tile half is the obvious next suspect precisely because the entity half is now closed - which would mean a resource control changing TILES, a strong and checkable claim that nothing here tests.
• A spurious dependence through CompiledMapGenSettings - the lever perturbing the cliff field rather than the ore suppressing it - is not excluded either, though test(cliffs): the direction is ORE -> CLIFF, and it is worth 31 cells (#84) #99's spatial locality argues against it.

Also recorded

Surface::mapGeneratorWouldCollide (0x101624a44) was in neither notes file and is distinct from both other wouldCollide overloads (EntityMapGenerationTask::wouldCollide 0x101625468, tile-index based; Surface::wouldCollide 0x10160c088, the cliff one). The entity-stage call lists and both phase orderings are now in cliffs-NOTES.md.

Verification

pnpm run verify green - 1461 app (up 3) + 13 worker + 3 container tests, 0 warnings, exit 0. Measurement and documentation only; nothing shipping changed.

🤖 Generated with Claude Code

https://claude.ai/code/session_015jeznBmWiZywUc7cBw9xFU