test(cliffs): the far ten were DESTROYED, not never queued (#84)

[wormeyman]

#115 handed over two threads on the far ten and named the first one unmeasured:

The whole applyCliffs framing assumes destruction. #114's exact result is consistent with destruction but does not prove it - a strict superset says nothing about whether the game's crossing field emitted them at all.

It is decidable, and it needed no capture. The two hypotheses leave different marks on the neighbours, and both rules were already ported off the disassembly:

hypothesis	what happens to a connected neighbour
destroyed by applyCliffs	Cliff::onDestroy calls destroyEnd(opposite(side)) - unconditionally
never queued by generateCliffs	the cell is simply absent; the neighbour loses that end only if updateConnections runs on it, which is gated on the neighbour sitting on its chunk's outer ring

So a disputed cell is decidable whenever it has a neighbour that is in the game's kept set, not on a chunk border, and queued with an end facing it. Then the game's own recorded orientation settles it.

2 of the far ten are decidable, and both say DESTROYED

cell	neighbour	the game's orientation	verdict
1546,1550.5	1546,1546.5	north-to-none	end gone - destroyed
1746,1538.5	1746,1542.5	east-to-none	end gone - destroyed

Across all 225 cells the game destroys, the never-queued signature appears zero times. One decidable cell sits in each of the far group's two multi-cell clusters - the 1542/1546, 1550.5..1558.5 knot and the 1746, 1530.5..1538.5 vertical run - which is the argument for reading both clusters as destruction events. The two singletons are in neither.

The counterfactual is what makes it more than reading a table. Re-run the model with the cell removed from the QUEUE rather than destroyed in it:

arm	result
the game's destruction set (baseline)	283 / 861 / 387, wrong 0
1546,1550.5 never queued	wrong 1 - north-to-south vs the game's north-to-none
1746,1538.5 never queued	wrong 1 - east-to-north vs east-to-none
both never queued	wrong 2
four far cells with no decidable neighbour	wrong 0 - unchanged

The last row is the contrast arm: this is a property of those two cells, not something removing any cell would do.

#114's exactness covers 14 of 225, and is VACUOUS for 211

The finding to carry forward. Only 14 of the 225 destroyed cells have a decidable neighbour at all - the rest have neighbours the game also destroyed, neighbours on a chunk border, or no facing end. 1531 of 1531 must not be quoted as having confirmed destruction for the whole 225.

group	n	decidable	destroyed	never queued
far (no lava within 12)	10	2	2	0
near (within 2)	9	2	2	0
mid (4 to 11)	6	0	-	-
agreed	200	10	10	0

Those 14 are exactly #114's 14 no-cascade rewrites, cell for cell. A neighbour is observable precisely when the cascade is the only thing that would have trimmed it, so the two routes must agree - which is what says the decision rule was read out of cliffConnections.ts rather than fitted to the answer.

The result is CONDITIONAL on the chunk-border gate, and that is new

The discriminator is a reading of applyCliffs' fifth-argument test, and cliffConnections.spec.ts records that gate as explicitly unscored - updateConnections fires zero times on the port's own set, so everyCell had never changed an answer.

It stays unscored. What changed is that it is no longer inert: removing a cell from the queue creates the dangling end the port's own set never has, and the gate then decides whether the neighbour trims it. With the gate off, both counterfactuals go to wrong 0 and the hypotheses become indistinguishable. The baseline is identical either way, so nothing before this could have caught a misreading.

This is the first thing that has ever depended on that gate. Planting onChunkBorder returning true fails 7 of this file's 10 tests. If the gate was misread, those two cells revert to undecidable - they do not become never-queued. Scoring it against the game is now worth doing on its own account.

Where it leaves #84

Destruction is the mechanism, so the search stays on the unmodelled half of Surface::wouldCollide and not on a crossing-field difference - worth knowing before anyone re-opens the field, which #107 already exonerated once.

Verification

pnpm run verify green - 1449 app (up 10) + 13 worker + 3 container tests, 0 warnings, exit 0. Measurement only; nothing shipping changed, recall 0.9961 / precision 0.9858 unchanged.

🤖 Generated with Claude Code

https://claude.ai/code/session_015jeznBmWiZywUc7cBw9xFU