feat(cliffs): port the ORE -> CLIFF rejection (#84 item 1) (#100)

#99 characterised the rule and stopped short of porting it, flagging one open
sub-question: whether driving it from our own resource model, rather than the
game's entities, is accurate enough. It is - and it costs exactly one cell.

Scored across all three oracle regions, driving `makeVulcanusOreRejection` off
the same field stack the ore overlay paints from:

| region | game | placed | fires | false rejections | surplus |
| --- | --- | --- | --- | --- | --- |
| [0,0] | 283 | 283 | 0 | 0 | 2 -> 2 |
| [1500,1500] | 885 | 900 | 20 | 0 | 42 -> 22 |
| [-1200,800] | 401 | 387 | 0 | 0 | 1 -> 1 |

Precision at [1500,1500] 0.953 -> 0.975 with the 858 true positives untouched.
**Recall is not touched anywhere**, which was the gate: this rule may only ever
cost precision.

Three variants were scored and the two that lose are kept in the spec rather
than dismissed in a comment, because #88/#90 already paid for that lesson here:

| variant | fires | correct of 31 | false rejections |
| --- | --- | --- | --- |
| base box, ores only (SHIPPED) | 20 | 20 | 0 |
| base box + geyser | 21 | 20 | 1 |
| per-orientation box | 23 | 21 | 2 |

The geyser arm is strictly HARMFUL - one more false rejection and not one
additional correct suppression - so it is implemented behind `includeGeyser`,
defaulting off. The per-orientation rotbb box catches one more true cell and
pays two kept cliffs for it; higher `correct` is exactly the trap.

Not claimed: the mechanism is still open (the disassembly says cliffs are placed
before any resource entity exists), and 11 of the 31 stay unexplained with the
box deliberately not widened to cover them. The spec pins that 11.

Lands as `CliffBands.cellRejects`, an opaque per-cell predicate beside
`tileCollides` - so the shared cliff core stays planet-agnostic, and the model
the specs score is the model the renderer ships. The predicate enumerates no
entities: the overlapping tiles follow in closed form (2 tiles for an ore
against the lava rejection's ~30), guarded by a wider brute-force scan.


Claude-Session: https://claude.ai/code/session_01GyN97UwFQmwZs1cg4QHS1c

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>

Author: wormeyman

docs/noise/vulcanus-cliffs-NOTES.md

@@ -45,6 +45,18 @@
 >   the three regions, measured as the boolean `crossesCliff` reads rather than as
 >   a value. That closes the clamp-vacuity worry properly.
 >
+> ## UPDATE 3, 2026-08-02: the ore rule is PORTED and SHIPS
+>
+> The last section, **`## The rule is PORTED, and driving it from our own ore
+> model costs one cell`**, supersedes the previous one's closing warning not to
+> port this against our own resource positions without measuring that arm. The
+> arm is measured: **zero false rejections across all three oracle regions**, and
+> `[1500,1500]`'s surplus falls 42 -> 22 (precision 0.953 -> 0.975) with recall
+> untouched. It ships as `CliffBands.cellRejects`, ores only, base collision box.
+> The geyser arm and the per-orientation box were both scored and both LOSE - see
+> the table there before re-proposing either. 11 of the 31 remain unexplained and
+> the box is deliberately not widened to cover them.
+>
 > ## UPDATE, 2026-08-02: the FIELD is exonerated; the residual is two defects
 >
 > The last section, **`## The residual is TWO defects, and the field is not
@@ -1534,3 +1546,80 @@ without checking that arm separately.** The 31/0 score above uses the GAME's
 resource entities as the input, which isolates the rule from the accuracy of the
 resource port; driving it from `renderVulcanusResources` is a second question and
 has not been measured.
+
+## The rule is PORTED, and driving it from our own ore model costs one cell (#84 item 1, 2026-08-02)
+
+The section above closes with "driving it from `renderVulcanusResources` is a
+second question and has not been measured." It is measured now, and the answer
+is that it is safe: `test/cliffOreRejection.spec.ts` scores the shipped
+predicate - `makeVulcanusOreRejection`, driven off `buildResources`, the same
+field stack the ore overlay paints from - across all three oracle regions.
+
+| region | game | port placed | fires | **false rejections** | surplus |
+| --- | --- | --- | --- | --- | --- |
+| `[0,0]` | 283 | 283 | 0 | 0 | 2 -> 2 |
+| `[1500,1500]` | 885 | 900 | 20 | **0** | 42 -> **22** |
+| `[-1200,800]` | 401 | 387 | 0 | 0 | 1 -> 1 |
+
+Precision at `[1500,1500]` goes 0.953 -> **0.975** with the 858 true positives
+untouched. **Recall is not touched anywhere**, which was the gate: this rule may
+only ever cost precision, and a cell removed that the game kept would be the one
+outcome worth refusing.
+
+Driving it from our own ore model rather than the game's entities costs exactly
+**one** cell - the fixture-driven geometry explains 21 of the 31, the port-driven
+one 20. That is the whole price of the substitution the section above flagged.
+
+### Three variants were scored, and the two that lose are in the spec
+
+Not dismissed in a comment, because #88/#90 already paid for that lesson here -
+the best-scoring collision model was the wrong one.
+
+| variant | fires | correct of 31 | false rejections |
+| --- | --- | --- | --- |
+| **base box, ores only (SHIPPED)** | 20 | 20 | **0** |
+| base box + geyser | 21 | 20 | 1 |
+| per-orientation box | 23 | 21 | 2 |
+| per-orientation + geyser | 24 | 21 | 3 |
+
+- **The geyser arm is strictly harmful**, not merely risky: one more false
+  rejection and *not one* additional correct suppression. Its placements are
+  salt-dependent (46-63 over eight salts against the game's 56) and its box is
+  14x the ores', so a geyser in the wrong place sweeps a wide area. It is
+  implemented behind `includeGeyser`, defaulting off, so the arm stays scored
+  rather than deleted.
+- **The per-orientation rotbb box catches one MORE true cell and pays two kept
+  cliffs for it.** Higher `correct` is exactly the trap: recall is the half that
+  must not be traded. Note this means the ore rule and the lava rejection use
+  *different* cliff rectangles - the base `collision_box` and the per-orientation
+  one respectively - which is only defensible because the ore mechanism is open
+  and the base box is the shape it was measured with. If the mechanism is ever
+  found, revisit this first.
+
+### What is NOT claimed
+
+**11 of the 31 are still unexplained** and the box is deliberately not widened
+until they fall out: 10 are #99's run remainders and 1 is the cell our ore model
+misses. `test/cliffOreRejection.spec.ts` pins that 11 so the gap stays tracked.
+
+The **mechanism is still open**. This ships a characterised empirical rule -
+one-way, additive, local, box-shaped - and the disassembly still says cliffs are
+computed and placed before any resource entity exists, so whatever the engine is
+really doing, it is not the collision test this models.
+
+### Where it lives
+
+`CliffBands.cellRejects`, a second optional per-cell predicate beside
+`tileCollides` in `cliffPlacement.ts`, applied at the same site. It is
+deliberately opaque - the shared cliff core stays planet-agnostic, and a
+planet-specific, mechanism-open rule does not leak into it. It hangs there rather
+than filtering `placedCells`' output so that **the model the specs score is the
+model the renderer ships**; every spec drives `makeCliffPlacementFromFields`
+directly, so a filter further out would score a different thing than it renders.
+
+Two cheapnesses worth knowing: the predicate never enumerates entities (it solves
+the two rectangles for the tiles whose centres can overlap - exactly 2 tiles for
+an ore, 4x3 for a geyser, against the lava rejection's ~30), and it reuses the
+composite's `VulcanusStack.resources` rather than building a second DAG. The
+derived window is guarded by a brute-force scan a tile wider on every side, not
+trusted.

docs/superpowers/specs/2026-08-02-ore-cliff-rejection-design.md

@@ -0,0 +1,117 @@
+# Porting the ORE -> CLIFF rejection (issue #84, item 1)
+
+**Date:** 2026-08-02
+**Status:** implemented, measured, shipped on `feat/cliff-ore-rejection`
+
+> Point-in-time design record, per `docs/superpowers/specs/` convention. Not a
+> living document - the current state of the rule lives in
+> `docs/noise/vulcanus-cliffs-NOTES.md` and `src/noise/cliffs/vulcanusOreRejection.ts`.
+
+## Problem
+
+PR #99 settled that Vulcanus resources suppress cliffs (`ORE -> CLIFF`, not the
+reverse) and characterised the rule as one-way, additive, local, and shaped like
+a box overlap against the resource entity's rectangle. It scored 21 of 31
+suppressed cells with zero false alarms in 885.
+
+It deliberately stopped short of porting it, flagging one open sub-question:
+
+> whether driving it from `renderVulcanusResources` (rather than the game's
+> entities, which is what the 31/0 score uses) is accurate enough
+
+That is this work.
+
+## Decisions, and what settled each
+
+Four forks. Each was settled by a measurement taken during implementation, not
+by preference - the numbers are in `test/cliffOreRejection.spec.ts`.
+
+| decision | chosen | what settled it |
+| --- | --- | --- |
+| geyser included? | **no**, behind `includeGeyser` | strictly harmful: +1 false rejection, +0 correct |
+| cliff rectangle | **prototype base box** | per-orientation catches +1 true cell and costs 2 kept cliffs |
+| the unexplained 10 | **not tuned away** | pinned as a gap; #88/#90's lesson |
+| where the predicate hangs | **`CliffBands.cellRejects`** | keeps the scored model and the shipped model identical |
+
+### Why recall is the gate
+
+The rule can only ever remove cells. Every cell it fires on at `[1500,1500]` is
+surplus, so it is pure precision gain - unless it removes a cliff the game kept,
+which is a false rejection and costs recall. Recall is the expensive half of this
+port (1.000/0.973/0.965), so "zero false rejections" is a hard gate, not a
+report. Both rejected variants fail exactly that gate.
+
+## Architecture
+
+```
+CliffBands.cellRejects?: (code, x, y) => boolean     // cliffPlacement.ts, beside tileCollides
+    ^ supplied by
+makeVulcanusOreRejection(resources, controls, opts)  // cliffs/vulcanusOreRejection.ts
+    ^ wired by
+renderVulcanusCliffs                                 // reads VulcanusStack.resources
+```
+
+`cellRejects` is applied in both paths of `placedCells` (chunked and unchunked),
+after the bounds test and after `tileCollides`. It is deliberately an opaque
+predicate: the cliff core is planet-agnostic engine behaviour, and this rule is
+neither planet-agnostic nor engine-confirmed.
+
+**It hangs there rather than filtering `placedCells`' output** because every spec
+drives `makeCliffPlacementFromFields` directly. A filter applied further out
+would mean the specs score an unfiltered model while the renderer ships a
+filtered one - the same class of silent divergence as the
+`worker-configuration.d.ts` drift.
+
+Like `tileCollides` it is a pure per-cell post-filter with no effect on
+neighbours, so worker tiling stays byte-identical for free.
+
+### The predicate
+
+- **Cliff box**: `+/-0.98828125 x +/-0.48828125`, the prototype `collision_box`
+  the fixture carries - *not* the per-orientation rotbb the lava rejection uses.
+- **Ore footprint**: `makeVulcanusOreFootprint`, sharing
+  `RESOURCE_PROBABILITY_THRESHOLD` with the ore overlay so the two cannot drift
+  onto different footprints. A control at `size = 0` occupies nothing, which is
+  the same lever the game was driven with.
+- **No entity enumeration.** The tiles whose centres can overlap follow in closed
+  form from the two rectangles: exactly 2 tiles for an ore, 4x3 for a geyser,
+  against the lava rejection's ~30. The derivation is guarded by a brute-force
+  scan a tile wider on every side, not trusted.
+- Reuses the composite's `VulcanusStack.resources`; `memoXY` is single-entry, so
+  a private DAG would share nothing and pay for the whole tree again.
+
+## Results
+
+| region | game | placed | fires | false rejections | surplus |
+| --- | --- | --- | --- | --- | --- |
+| `[0,0]` | 283 | 283 | 0 | 0 | 2 -> 2 |
+| `[1500,1500]` | 885 | 900 | 20 | **0** | 42 -> **22** |
+| `[-1200,800]` | 401 | 387 | 0 | 0 | 1 -> 1 |
+
+Precision at `[1500,1500]`: 0.953 -> **0.975**, true positives untouched. Driving
+from the port's own ore model instead of the game's entities costs exactly one
+cell (20 against 21).
+
+## What is deliberately not claimed
+
+- **The mechanism is open.** The disassembly still says cliffs are computed and
+  placed before any resource entity exists, so this is a characterised empirical
+  rule, not a port of a known engine path. Both the module comment and the notes
+  say so.
+- **11 of 31 are unexplained** (10 run remainders + 1 our ore model misses) and
+  the box is not widened until they fall out.
+- **The two cliff rectangles now disagree** - base box for ore, per-orientation
+  for lava. Defensible only while the ore mechanism is open; revisit first if it
+  is ever found.
+
+## Testing
+
+`test/cliffOreRejection.spec.ts`, 8 tests. Scores the shipped predicate across
+all three oracle regions; scores both rejected variants so the choice is a
+record rather than an assumption; pins the remainder at 11; guards the derived
+tile window; asserts the disable path fires zero times; and cross-checks that the
+rejection's footprint equals the ore overlay's painted pixels.
+
+Two non-vacuity guards earned their keep: the footprint cross-check was
+initially vacuous on a 64x64 window containing no ore, and `painted > 0` caught
+it.

src/noise/cliffs/cliffPlacement.ts

@@ -114,6 +114,28 @@ export interface CliffBands {
    * placed cell, and only for cells that are actually placed.
    */
   readonly tileCollides?: (x: number, y: number) => boolean;
+  /**
+   * An additional per-cell rejection, called with the cell's crossing `code` and
+   * its centre, for cells that survive the bounds test and `tileCollides`.
+   * Return `true` to drop the cell.
+   *
+   * **Deliberately opaque.** This module is planet-agnostic - the corner
+   * lattice, `crossesCliff` and the orientation table are engine behaviour - and
+   * the one rule that currently uses this hook is not engine behaviour at all
+   * but a characterised empirical one (Vulcanus's ORE -> CLIFF suppression, see
+   * `vulcanusOreRejection.ts`). Keeping it a bare predicate is what stops a
+   * planet-specific and mechanism-open rule from leaking into the shared core.
+   *
+   * It runs at the same site as `tileCollides` rather than as a filter over
+   * `placedCells`' return value so that the model the specs score is the model
+   * the renderer ships; every spec here drives `makeCliffPlacementFromFields`
+   * directly, so a filter applied further out would score a different thing than
+   * it renders.
+   *
+   * Like `tileCollides` this is a pure post-filter on the emit loop - it cannot
+   * affect a neighbouring cell, so it leaves worker tiling byte-identical.
+   */
+  readonly cellRejects?: (code: number, x: number, y: number) => boolean;
 }
 
 /** Cells per chunk axis: a 32-tile chunk over the 4-tile placement grid. */
@@ -313,6 +335,7 @@ export function makeCliffPlacementFromFields(
   const { elevation0: e0, interval } = bands;
   const smoothing = bands.smoothing ?? 0;
   const tileCollides = bands.tileCollides;
+  const cellRejects = bands.cellRejects;
 
   /**
    * `tryToAddCliff`'s rejection, as a predicate on an already-placed cell: scan
@@ -480,6 +503,7 @@ export function makeCliffPlacementFromFields(
                 // overhangs the query box.
                 if (x < x0 || x >= x1 || y < y0 || y >= y1) continue;
                 if (rejected(code, x, y)) continue;
+                if (cellRejects?.(code, x, y) === true) continue;
                 result.push({ x, y, code });
               }
             }
@@ -508,6 +532,7 @@ export function makeCliffPlacementFromFields(
           const y = cy * CLIFF_GRID_SIZE + CLIFF_CELL_CENTER_Y;
           if (x < x0 || x >= x1 || y < y0 || y >= y1) continue;
           if (rejected(code, x, y)) continue;
+          if (cellRejects?.(code, x, y) === true) continue;
           result.push({ x, y, code });
         }
       }