docs(cliffs): the runtime probe is SAFE - all four cascade gates READ (#84) (#135)

#134 recorded `Cliff::onDestroy`'s four cascade gates and warned that a Lua or
editor destroy "need not" satisfy them, which would make #127's runtime probe
vacuous. **That warning is withdrawn.** It was stated from inference - "map
generation evidently satisfies all four, because #113 measured the cascade
running" - and inference is what keeps going wrong on this issue.

| gate | cascade needs | `applyCliffs` | `luaCreateEntity` |
| --- | --- | --- | --- |
| entity flag bit 5 of `+0x6e` | clear | `params[0x80] = 0` | `params[0x80] = 0` |
| `this+0x82` | set | ctor writes 1 unconditionally | same ctor |
| `this+0x83` | set | `place_as_crater == nullptr` | same |
| `map->[0x240]` | zero | only `Map::~Map` writes 1 | same |

- Bit 5 is exactly `params[0x80] != 0` at construction. `applyCliffs` builds its
  params at `sp+0x20` and zeroes that byte with `str wzr, [x26]`, `x26 = params
  + 0x80` (`0x101623d9c`). `luaCreateEntity` builds its own at `sp+0x228` and
  zeroes the same byte on both paths (`0x1019e5ba8`, `0x1019e5c18`) - and that
  arm is identifiably the cliff one, storing the `0x14` sentinel into
  `params+0x87` before `LuaTable::getDefault<CliffOrientation>`.
- `map->[0x240]` is "the map is being torn down": `Map::~Map` sets it as its
  first act, before `ToDeleteList::clear` (`0x10163461c`), and `Map::resume`
  bails on it. Dozens of unrelated `onDestroy` handlers read the same byte.
  `Cliff+0x78` is the `Map` - `Entity::getGame` is `[[this+0x78]+0x490]`.
- The one path that WOULD differ, `Cliff::destroyWithoutCorrection`, is
  unreachable: zero direct callers under a scan of every `BL` AND `B` in
  `__text`, and no pointer in any vtable - only four in the STAB tables.

The same widened scan re-confirms #134's other caller claim, which had been made
on `BL` alone and could have missed a tail call: `updateAndFixConnections` still
has exactly one caller, `CliffEditor::buildCliffs`.

Documentation only - no code, no fixtures, no behaviour change.


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

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

Author: wormeyman

docs/noise/cliffs-NOTES.md

@@ -978,11 +978,8 @@ what anyone should try next:
   connections at all** - do not attribute anything crater-shaped to these rules.
 - **`Cliff::onDestroy`'s cascade has FOUR gates, not zero** (`0x1007a8854`
   onwards): entity flag bit 5 of `+0x6e` clear, `+0x82` set, `+0x83` set, and
-  `map->[0x240]` zero. Bit 5 is `params[0x80] != 0` at construction, `+0x82` is
-  what `destroyWithoutCorrection` zeroes. Map generation evidently satisfies all
-  four (#113 measured the cascade running), but **a Lua or editor probe will
-  not necessarily** - which is a live hazard for the runtime probe #127 asked
-  for, and the reason to check the four before believing such a probe.
+  `map->[0x240]` zero. All four are now READ on both paths - see the next
+  section, which withdraws the warning this bullet used to carry.
 - **There is no second connection pass during map generation.**
   `Cliff::updateAndFixConnections` (`0x1007a94d0`) is called from exactly one
   site in the whole `__text` segment - `CliffEditor::buildCliffs`
@@ -997,6 +994,47 @@ what anyone should try next:
   prototype-id match AND an exact position match, so a different cliff
   prototype on an adjacent cell is not a neighbour.
 
+### The four cascade gates, READ on both paths - the runtime probe is SAFE
+
+#134 recorded the four gates and warned that a Lua or editor destroy "need not"
+satisfy them, which would make #127's runtime probe vacuous. That warning was
+stated from inference - "map generation evidently satisfies all four, because
+#113 measured the cascade running" - and inference is what keeps going wrong on
+this issue. Reading the bytes settles it, and the answer is the opposite:
+
+| gate | cascade needs | `applyCliffs` | `LuaSurface::luaCreateEntity` |
+| --- | --- | --- | --- |
+| entity flag bit 5 of `+0x6e` | clear | `params[0x80] = 0` | `params[0x80] = 0` |
+| `this+0x82` | set | ctor writes 1 unconditionally | same ctor |
+| `this+0x83` | set | `place_as_crater == nullptr` | same |
+| `map->[0x240]` | zero | only `Map::~Map` writes 1 | same |
+
+- Bit 5 of `+0x6e` is exactly `params[0x80] != 0` at construction
+  (`0x1007a7abc`). `applyCliffs` builds its `EntityCreationParameters` at
+  `sp+0x20` and zeroes that byte with `str wzr, [x26]`, `x26 = params + 0x80`
+  (`0x101623d9c`). `luaCreateEntity` builds its own at `sp+0x228` and zeroes the
+  same byte on **both** of its paths (`strb wzr, [sp, #0x2a8]`, `0x1019e5ba8`
+  and `0x1019e5c18`). That arm is identifiably the cliff one: it stores the
+  sentinel `mov w8, #0x14` into `params+0x87` and then overwrites it with
+  `LuaTable::getDefault<CliffOrientation>("cliff_orientation")`.
+- `this+0x82` is written 1 by the constructor with no condition
+  (`0x1007a7b14`), so it holds for any ordinary destroy.
+- **`map->[0x240]` is "the map is being torn down".** `Map::~Map` sets it to 1
+  as its first act, before `ToDeleteList::clear` (`0x10163461c`), and
+  `Map::resume` bails out on it (`0x10163b294`). Dozens of unrelated
+  `onDestroy` handlers read the same byte. Nothing during normal play sets it.
+  (`Cliff+0x78` is the `Map`: `Entity::getGame` is `[[this+0x78]+0x490]`.)
+
+**So the probe reproduces map generation's cascade.** The one path that would
+differ, `Cliff::destroyWithoutCorrection` (`0x1007aa568`, which zeroes `+0x82`
+around the destroy), is unreachable: **zero** direct callers under a scan of
+every `BL` *and* `B` in `__text`, and no pointer to it in any vtable - only four
+in the STAB debug tables. `entity.destroy()` cannot land on it by accident.
+
+The same widened scan re-confirms #134's other caller claim, which had been made
+on `BL` alone and could have missed a tail call: `updateAndFixConnections` still
+has exactly one caller, `CliffEditor::buildCliffs`.
+
 ### The tile half reads ZERO for an ungenerated chunk, and it is border-only
 
 `Surface::wouldCollide` -> `constCollideWithTile` (`0x100732eec`) ->

docs/noise/vulcanus-cliffs-NOTES.md

@@ -20,16 +20,38 @@
 > in `cliffs-NOTES.md` and `cliffConnections.ts`). Three change what to try next:
 >
 > - **`onDestroy`'s cascade has FOUR gates**, including `map->[0x240] == 0` and an
->   entity flag set from the creation parameters. Map generation satisfies all
->   four; **a Lua or editor probe need not** - which is a hazard for exactly the
->   runtime probe #127 asked for. Check the four before believing such a probe.
+>   entity flag set from the creation parameters. All four are now READ on both
+>   paths and **the runtime probe #127 asked for is SAFE** - see UPDATE 11. The
+>   warning this bullet first carried is withdrawn.
 > - **`crater-cliff` has no connections at all.** The whole system is gated on
 >   `proto->place_as_crater == nullptr`. Nothing crater-shaped belongs to these
 >   rules.
 > - **There is no second connection pass during map generation.**
 >   `updateAndFixConnections` is called from exactly one site in the binary,
 >   `CliffEditor::buildCliffs`.
 >
+> ## UPDATE 11, 2026-08-03: the runtime probe is SAFE - all four cascade gates READ on both paths
+>
+> UPDATE 10 warned that #127's runtime probe might not reproduce map generation,
+> because `Cliff::onDestroy`'s cascade has four gates. **That warning is
+> withdrawn.** It was stated from inference, and inference is what keeps going
+> wrong on this issue; reading the bytes settles it the other way.
+>
+> | gate | cascade needs | `applyCliffs` | Lua `create_entity` |
+> | --- | --- | --- | --- |
+> | entity flag bit 5 of `+0x6e` | clear | `params[0x80] = 0` | `params[0x80] = 0` |
+> | `this+0x82` | set | ctor writes 1 unconditionally | same ctor |
+> | `this+0x83` | set | `place_as_crater == nullptr` | same |
+> | `map->[0x240]` | zero | only `Map::~Map` writes 1 | same |
+>
+> `map->[0x240]` is **"the map is being torn down"** - `Map::~Map` sets it as its
+> first act and `Map::resume` bails on it. And the one path that WOULD differ,
+> `Cliff::destroyWithoutCorrection`, is **unreachable**: zero direct callers under
+> a scan of every `BL` and `B` in `__text`, and no pointer in any vtable.
+>
+> **So the probe is unblocked and is the next thing to build.** Addresses and the
+> non-vacuity arms are in `cliffs-NOTES.md`.
+>
 > ## UPDATE 9, 2026-08-03: the residual is on CHUNK BORDERS (2.91 sigma), and the ore mechanism is a CLOSED IMPOSSIBILITY
 >
 > Two results supersede the framing below. Read this before acting on any earlier

src/noise/cliffs/cliffConnections.ts

@@ -67,17 +67,35 @@
  * destroyed cell can take a non-border neighbour with it, and why this is a
  * cascade rather than a filter.
  *
- * **Three conditions on that cascade are unmodelled here, deliberately.**
- * `onDestroy` reaches its neighbour loop only when all four of these hold
- * (`0x1007a8854`-`0x1007a8874`): entity flag bit 5 of `this+0x6e` CLEAR,
- * `this+0x82` set, `this+0x83` set, and `map->[0x240]` zero. Bit 5 is
- * `params[0x80] != 0` at construction and `this+0x82` is what
- * `Cliff::destroyWithoutCorrection` (`0x1007aa568`) temporarily zeroes, so both
- * are about who is doing the destroying rather than about the cliff. The port
- * models map generation, where #113 measured the cascade running - 1058 of 1058
- * at `[1500,1500]` - so all four evidently hold there. They are recorded because
- * a future probe that destroys a cliff from Lua or the editor will NOT get the
- * same behaviour, and that is exactly the probe #127 asked for.
+ * **Four conditions gate that cascade, and all four are read rather than
+ * inferred.** `onDestroy` reaches its neighbour loop only when all of these hold
+ * (`0x1007a8854`-`0x1007a8874`), and the right-hand column is what each is on
+ * the two paths that matter - `applyCliffs` and a Lua `create_entity` +
+ * `destroy`:
+ *
+ * | gate | cascade needs | map generation | Lua |
+ * | --- | --- | --- | --- |
+ * | entity flag bit 5 of `+0x6e` | clear | `params[0x80] = 0` | `params[0x80] = 0` |
+ * | `this+0x82` | set | ctor writes 1 unconditionally | same ctor |
+ * | `this+0x83` | set | `place_as_crater == nullptr` | same |
+ * | `map->[0x240]` | zero | only `Map::~Map` writes 1 | same |
+ *
+ * Bit 5 is exactly `params[0x80] != 0` at construction. `applyCliffs` zeroes it
+ * with `str wzr, [x26]` where `x26 = params + 0x80` (`0x101623d9c`), and
+ * `LuaSurface::luaCreateEntity`'s cliff arm zeroes the same byte on both of its
+ * paths (`strb wzr, [sp, #0x2a8]` at `0x1019e5ba8` and `0x1019e5c18`; that arm is
+ * identifiable by the `mov w8, #0x14` sentinel it puts in `params+0x87` before
+ * `LuaTable::getDefault<CliffOrientation>`). `map->[0x240]` is "the map is being
+ * torn down": `Map::~Map` sets it to 1 as its first act (`0x10163461c`) and
+ * `Map::resume` bails on it.
+ *
+ * **So a runtime probe reproduces map generation's cascade, and #134's warning
+ * that it might not is withdrawn.** It was a correct risk stated before the
+ * bytes were read, and reading them settles it. The one path that WOULD differ,
+ * `Cliff::destroyWithoutCorrection` (`0x1007aa568`, which zeroes `+0x82` around
+ * the destroy), is unreachable: zero direct callers under a scan of every `BL`
+ * and `B` in `__text`, and no pointer to it in any vtable. `entity.destroy()`
+ * cannot land on it by accident.
  *
  * **There is no second connection pass during map generation.**
  * `Cliff::updateAndFixConnections` (`0x1007a94d0`) looks like one and is not: a