@woosh/meep-engine 3.1.0 → 3.2.0

package/src/REVIEW_2026_08_06/engine-terrain.md

@@ -1,52 +1,52 @@
-# Terrain second pass (spawned from the engine/ecs review)
-
-### TERR-1 `build_height_field_geometry` produces NaN vertices on 1-cell edge tiles
-- **Severity**: MAJOR
-- **File**: `engine/graphics/geometry/buffered/build_height_field_geometry.js:23-24,39-40`
-- **Defect**: `gridX2 = size.x * resolution - 1`; `uMultiplier = (size.x / totalSize.x) / gridX2`. When a tile is one grid cell wide and `resolution === 1`, `gridX2 === 0` → multiplier `Infinity` → `u = 0 * Infinity + uConst = NaN`.
-- **Failure scenario**: `Terrain.size = (41,41)`, `resolution = 1`, default `tileSize = (10,10)`. `TerrainTileManager.initializeTiles` gives the last column/row tiles `size.x = 41 - 40 = 1`. Every vertex of those 9 edge tiles gets `NaN` position and uv; `indices.length = gridX2 * gridY2 * 6 = 0` so they render nothing. `TerrainTile.computeBoundingBox()` then yields a NaN AABB which is written into the shared `TerrainTileManager.bvh`, propagating NaN up the parent nodes so `raycastFirstSync` (terrain picking, `ClingToTerrain`) starts missing on tiles far from the edge.
-- **Fix**: guard the degenerate span (`gridX2 === 0 ? 0 : ...`) for both axes, or use `gridX1 = size.x * resolution + 1` so each axis always has >= 2 vertices.
-- **Confidence**: Confirmed (arithmetic); the BVH-wide fallout is Likely.
-
-### TERR-2 `TerrainLayers.loadTextureData` writes a completed load into a stale layer index
-- **Severity**: MAJOR
-- **File**: `engine/ecs/terrain/ecs/layers/TerrainLayers.js:199-217`
-- **Defect**: the completion handler captures only the numeric `layerIndex` and re-resolves via `this.get(index)`, never checking the layer is still the one whose load finished. `Terrain.addLayer` (`Terrain.js:684-691`) has exactly this guard, so the hazard is known.
-- **Failure scenario**: terrain built with L0..L3 (batch A in flight). `ThemeEngine.applyTerrainThemes` calls `terrain.layers.clear()`, adds two new layers, `terrain.build()` (batch B). When batch A lands: indices 0-1 overwrite slots batch B already wrote (previous map's ground textures render); indices 2-3 resolve to `undefined` and `__obtain_layer_data_at_resolution` dereferences `layer.diffuse` → TypeError inside a fulfilled handler → unhandled rejection.
-- **Fix**: capture the layer object and short-circuit, mirroring `Terrain.addLayer`.
-- **Confidence**: Likely (needs batch A still in flight).
-
-### TERR-3 `TerrainOverlay.paintSampler` passes the overlay instead of its sampler — silent no-op
-- **Severity**: MAJOR
-- **File**: `engine/ecs/terrain/overlay/TerrainOverlay.js:321`
-- **Defect**: `TerrainOverlay` has no `extends`, and its own surface is `readPoint`/`paintPoint`/`clearPoint` plus `size`/`sampler` — it defines no `width`, `height`, `read`, or `write`. `sampler2d_paint` requires all four on its destination.
-- **Failure scenario**: `destination.width` is `undefined` → `_w = Math.min(..., undefined - destinationX)` → `NaN`; both loops test `x < NaN` → false → zero iterations. `paintSampler` and `paintImage` do nothing, then set `texture.needsUpdate = true` and return as if they succeeded. Silent no-op, not a crash.
-- **Fix**: `sampler2d_paint(this.sampler, scaled_source, 0, 0, dx, dy, dWidth, dHeight);`
-- **Confidence**: Confirmed.
-
-### TERR-4 `makeTerrainWorkerProxy` never clears `useSampleCallbacks`
-- **Severity**: MINOR
-- **File**: `engine/ecs/terrain/ecs/makeTerrainWorkerProxy.js:45-55`
-- **Defect**: `setHeightSampler` iterates `globalScope.useSampleCallbacks` but never empties it, so it only grows.
-- **Failure scenario**: `Terrain.unlink()` terminates the worker with `buildTile` requests still in `WorkerProxy.__pending`; on re-`link()`, `worker.start()` re-sends them before `setHeightSampler`, so they land in `useSampleCallbacks`. They then re-run on **every** subsequent `updateHeights()` (every terrain-paint stroke), each replay a full geometry build + 21 UV-tension passes + BVH build whose result is discarded, on the single build worker.
-- **Fix**: snapshot and clear the array before dispatching.
-- **Confidence**: Confirmed.
-
-### TERR-5 `SplatMapping.removeWeightLayer` can set array-texture depth to 0
-- **Severity**: MINOR
-- **File**: `engine/ecs/terrain/ecs/splat/SplatMapping.js:423-432`
-- **Defect**: removing the only layer leaves `image.depth = 0` and sets `needsUpdate = true`. The same class refuses this in `resize` (`:503-508`) and `TerrainLayers.buildTexture` (`:407-412`), commenting that glTexStorage3D requires all dims > 0.
-- **Failure scenario**: single-layer terrain (`EngineHarness.js:507` does `splat.resize(1,1,1)`); `removeWeightLayer(0)` → next frame uploads a 0-depth `DataTexture2DArray` → `GL_INVALID_VALUE`, `splatWeightMap` left invalid.
-- **Fix**: apply the same guard as `resize`.
-- **Confidence**: Confirmed (logic); GL outcome Likely.
-
-### TERR-6 `TerrainLayers.writeLayerDataIntoTexture` bounds guard off by one layer
-- **Severity**: MINOR
-- **File**: `engine/ecs/terrain/ecs/layers/TerrainLayers.js:367`
-- **Defect**: checks the write's *start* address, not its end: should be `single_layer_byte_size * (index + 1)`.
-- **Failure scenario**: 512x512, texture built for 2 layers, third layer written before `buildTexture()` — the intended diagnostic never fires and a bare `RangeError: offset is out of bounds` is thrown from `TypedArray.set` instead.
-- **Fix**: `if (arrayData.length < single_layer_byte_size * (index + 1))`.
-- **Confidence**: Confirmed.
-
-### Corroboration
-Independently confirms **GFXT-1**: `sampler2d_paint.js:68` reads `const s_x = Math.round(x + sourceY);` — `sourceY` where `sourceX` is meant. Masked for `TerrainOverlay` (which passes `0, 0`) but wrong for any caller with `sourceX !== sourceY`.
+# Terrain second pass (spawned from the engine/ecs review)
+
+### TERR-1 `build_height_field_geometry` produces NaN vertices on 1-cell edge tiles
+- **Severity**: MAJOR
+- **File**: `engine/graphics/geometry/buffered/build_height_field_geometry.js:23-24,39-40`
+- **Defect**: `gridX2 = size.x * resolution - 1`; `uMultiplier = (size.x / totalSize.x) / gridX2`. When a tile is one grid cell wide and `resolution === 1`, `gridX2 === 0` → multiplier `Infinity` → `u = 0 * Infinity + uConst = NaN`.
+- **Failure scenario**: `Terrain.size = (41,41)`, `resolution = 1`, default `tileSize = (10,10)`. `TerrainTileManager.initializeTiles` gives the last column/row tiles `size.x = 41 - 40 = 1`. Every vertex of those 9 edge tiles gets `NaN` position and uv; `indices.length = gridX2 * gridY2 * 6 = 0` so they render nothing. `TerrainTile.computeBoundingBox()` then yields a NaN AABB which is written into the shared `TerrainTileManager.bvh`, propagating NaN up the parent nodes so `raycastFirstSync` (terrain picking, `ClingToTerrain`) starts missing on tiles far from the edge.
+- **Fix**: guard the degenerate span (`gridX2 === 0 ? 0 : ...`) for both axes, or use `gridX1 = size.x * resolution + 1` so each axis always has >= 2 vertices.
+- **Confidence**: Confirmed (arithmetic); the BVH-wide fallout is Likely.
+
+### TERR-2 `TerrainLayers.loadTextureData` writes a completed load into a stale layer index
+- **Severity**: MAJOR
+- **File**: `engine/ecs/terrain/ecs/layers/TerrainLayers.js:199-217`
+- **Defect**: the completion handler captures only the numeric `layerIndex` and re-resolves via `this.get(index)`, never checking the layer is still the one whose load finished. `Terrain.addLayer` (`Terrain.js:684-691`) has exactly this guard, so the hazard is known.
+- **Failure scenario**: terrain built with L0..L3 (batch A in flight). `ThemeEngine.applyTerrainThemes` calls `terrain.layers.clear()`, adds two new layers, `terrain.build()` (batch B). When batch A lands: indices 0-1 overwrite slots batch B already wrote (previous map's ground textures render); indices 2-3 resolve to `undefined` and `__obtain_layer_data_at_resolution` dereferences `layer.diffuse` → TypeError inside a fulfilled handler → unhandled rejection.
+- **Fix**: capture the layer object and short-circuit, mirroring `Terrain.addLayer`.
+- **Confidence**: Likely (needs batch A still in flight).
+
+### TERR-3 `TerrainOverlay.paintSampler` passes the overlay instead of its sampler — silent no-op
+- **Severity**: MAJOR
+- **File**: `engine/ecs/terrain/overlay/TerrainOverlay.js:321`
+- **Defect**: `TerrainOverlay` has no `extends`, and its own surface is `readPoint`/`paintPoint`/`clearPoint` plus `size`/`sampler` — it defines no `width`, `height`, `read`, or `write`. `sampler2d_paint` requires all four on its destination.
+- **Failure scenario**: `destination.width` is `undefined` → `_w = Math.min(..., undefined - destinationX)` → `NaN`; both loops test `x < NaN` → false → zero iterations. `paintSampler` and `paintImage` do nothing, then set `texture.needsUpdate = true` and return as if they succeeded. Silent no-op, not a crash.
+- **Fix**: `sampler2d_paint(this.sampler, scaled_source, 0, 0, dx, dy, dWidth, dHeight);`
+- **Confidence**: Confirmed.
+
+### TERR-4 `makeTerrainWorkerProxy` never clears `useSampleCallbacks`
+- **Severity**: MINOR
+- **File**: `engine/ecs/terrain/ecs/makeTerrainWorkerProxy.js:45-55`
+- **Defect**: `setHeightSampler` iterates `globalScope.useSampleCallbacks` but never empties it, so it only grows.
+- **Failure scenario**: `Terrain.unlink()` terminates the worker with `buildTile` requests still in `WorkerProxy.__pending`; on re-`link()`, `worker.start()` re-sends them before `setHeightSampler`, so they land in `useSampleCallbacks`. They then re-run on **every** subsequent `updateHeights()` (every terrain-paint stroke), each replay a full geometry build + 21 UV-tension passes + BVH build whose result is discarded, on the single build worker.
+- **Fix**: snapshot and clear the array before dispatching.
+- **Confidence**: Confirmed.
+
+### TERR-5 `SplatMapping.removeWeightLayer` can set array-texture depth to 0
+- **Severity**: MINOR
+- **File**: `engine/ecs/terrain/ecs/splat/SplatMapping.js:423-432`
+- **Defect**: removing the only layer leaves `image.depth = 0` and sets `needsUpdate = true`. The same class refuses this in `resize` (`:503-508`) and `TerrainLayers.buildTexture` (`:407-412`), commenting that glTexStorage3D requires all dims > 0.
+- **Failure scenario**: single-layer terrain (`EngineHarness.js:507` does `splat.resize(1,1,1)`); `removeWeightLayer(0)` → next frame uploads a 0-depth `DataTexture2DArray` → `GL_INVALID_VALUE`, `splatWeightMap` left invalid.
+- **Fix**: apply the same guard as `resize`.
+- **Confidence**: Confirmed (logic); GL outcome Likely.
+
+### TERR-6 `TerrainLayers.writeLayerDataIntoTexture` bounds guard off by one layer
+- **Severity**: MINOR
+- **File**: `engine/ecs/terrain/ecs/layers/TerrainLayers.js:367`
+- **Defect**: checks the write's *start* address, not its end: should be `single_layer_byte_size * (index + 1)`.
+- **Failure scenario**: 512x512, texture built for 2 layers, third layer written before `buildTexture()` — the intended diagnostic never fires and a bare `RangeError: offset is out of bounds` is thrown from `TypedArray.set` instead.
+- **Fix**: `if (arrayData.length < single_layer_byte_size * (index + 1))`.
+- **Confidence**: Confirmed.
+
+### Corroboration
+Independently confirms **GFXT-1**: `sampler2d_paint.js:68` reads `const s_x = Math.round(x + sourceY);` — `sourceY` where `sourceX` is meant. Masked for `TerrainOverlay` (which passes `0, 0`) but wrong for any caller with `sourceX !== sourceY`.

package/src/REVIEW_2026_08_06/generation.md

@@ -1,176 +1,176 @@
-# Correctness review — `meep/src/generation`
-
-Scope: every non-spec source file under
-`H:/git/moh/app/src/mir-engine/meep/src/generation/` (~12.2k LOC, 160 files).
-`REVIEW_01_ACTION_PLAN.md` items and `COORDINATES.md` conventions were read first;
-already-addressed items are not re-reported.
-
-Method: full read of the package. Determinism claims about Mulberry32 were
-verified by executing the generator (`core/math/random/seededRandom_Mulberry32.js`)
-directly under node; the measurements are quoted in the findings.
-
----
-
-### GEN-1 Theme child seeds are `random()` floats; Mulberry32 collapses them to one stream
-- **Severity**: CRITICAL
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/generation/theme/ThemeEngine.js:212`, `H:/git/moh/app/src/mir-engine/meep/src/generation/theme/TerrainTheme.js:29`
-- **Defect**: Both sites use the *output* of a `seededRandom` stream (a float in `[0,1)`) as the *seed* of a child stream. `seededRandom_Mulberry32` does `_seed += 0x6D2B79F5` and then feeds `_seed` through `Math.imul`/`^`/`>>>`, all of which apply ToInt32/ToUint32 and discard the fractional part. Every seed in `[0,1)` therefore produces a byte-identical sequence — identical to `seededRandom(0)`.
-- **Failure scenario**: `themeEngine.random.setCurrentSeed(12345)` → `initializeThemes` derives theme seed `0.9797282677609473`; with world seed `999` it derives `0.9699058223050088`. Both are passed to `Theme.initialize(grid, ecd, seed)` → `TerrainTheme.initialize` → `seededRandom(seed)`. Verified output of the first three draws for seeds `0.1234`, `0.9876` and `0` is identical: `0.26642920868471265, 0.0003297457005828619, 0.2232720274478197`. Consequently, for the shipped `AlienTheme0` / `SnowyTheme`:
-  - every `CellFilterSimplexNoise` reachable from `Theme.terrain.rules` and `Theme.nodes` (`injectBases.js:101`, `injectEnemies.js:355`, `injectTreasure.js:556`, `injectBuffObjects.js:45`, `injectPlayerCharacter.js:88`) is built from the *same* permutation table, and that table never changes with the world seed;
-  - `MarkerNodeTransformRotateRandom` and `MarkerNodeEntityProcessorRandomRotation` (`theme-1/injectDecor.js`) emit the same rotation sequence for every world seed.
-  Two runs with different world seeds produce identical theme-layer noise and identical decor rotations.
-- **Fix**: derive integer child seeds at both sites, e.g.
-  `const seed = randomIntegerBetween(this.random, 0, 0x7FFFFFFF);` in `ThemeEngine.initializeThemes` and
-  `const ruleSeed = randomIntegerBetween(random, 0, 0x7FFFFFFF);` in `TerrainTheme.initialize`.
-  (Same one-line shape; `(random() * 0x100000000) | 0` also works.)
-- **Confidence**: Confirmed
-
----
-
-### GEN-2 `GridTaskGenerateRoads` never initializes its `traversable` matcher
-- **Severity**: CRITICAL
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/generation/grid/generation/road/GridTaskGenerateRoads.js:513-608`
-- **Defect**: `build()` creates `tInitializeActions` for `this.actions` but there is no `this.traversable.initialize(grid, seed)` anywhere. `traversable` is a required `from({...})` parameter (phase 5.1) and is used by `tBuildDistanceField` (line 567, wrapped in a fresh `CellMatcherNot` that is also never initialized), by the Dijkstra expansion (lines 213, 276) and by `drawPath` (line 425). Every sibling task in the package that accepts a `CellMatcher` initializes it (`GridTaskConnectRooms.build:469`, `GridTaskBuildSourceDistanceMap.build:117`, `CellSupplierBestN.initialize:97`, `GridCellPlacementRule.initialize:91`).
-- **Failure scenario**:
-  ```js
-  const roads = GridTaskGenerateRoads.from({
-      traversable: CellMatcherLayerBitMaskTest.from(TRAVERSABLE_BIT, 'tags'),
-      actions: [GridCellActionPlaceTags.from(ROAD_BIT, 'tags')]
-  });
-  executeTaskTreeSync(roads.build(grid, ecd, 0));
-  ```
-  `tBuildDistanceField` → `buildUnsignedDistanceField` → `traversable.match(grid, 0, 0, 0)` → `GridLayerCellMatcher.__layer` is still `null` → `TypeError: Cannot read properties of null (reading 'sampler')`. `SampleGenerator0` only survives because it passes the module-level singleton `matcher_tag_traversable`, which `GridTaskConnectRooms` happens to bind first; a per-run matcher factory (the pattern review-01 §3.7 mandates) crashes. `GridTaskGenerateRoads.spec.js` misses it because it passes `CellMatcherAny.INSTANCE`, which needs no initialization.
-- **Fix**: build the negated matcher once and initialize both in an init task that `tBuildDistanceField` / `tBuildPaths` / `tDrawPaths` depend on:
-  ```js
-  const not_traversable = CellMatcherNot.from(traversable);
-  const tInitializeMatchers = actionTask(() => {
-      traversable.initialize(grid, seed);
-      not_traversable.initialize(grid, seed);
-  });
-  // tBuildDistanceField uses not_traversable; add tInitializeMatchers as a dependency of
-  // tBuildDistanceField, tBuildPaths and tDrawPaths.
-  ```
-- **Confidence**: Confirmed
-
----
-
-### GEN-3 `ThemeEngine.applyNodes` indexes samplers with fractional marker coordinates
-- **Severity**: MAJOR
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/generation/theme/ThemeEngine.js:166` (`getThemesByPosition`) and `:466`
-- **Defect**: `applyNodes` passes `node.position.x/y` — continuous grid coordinates — straight into `Sampler2D.readChannel`, which computes `index = (y * width + x) * itemSize + channel`. With a fractional coordinate the index is fractional and a typed-array read returns `undefined`, not a value.
-  - `getThemesByPosition:168`: `if (filled === 0) continue;` — `undefined === 0` is `false`, so the mask refinement is skipped entirely and *every* theme whose quadtree bounds contain the point is accepted.
-  - `applyNodes:466-470`: `influenceSum += undefined` → `NaN`, so `influenceSum > 0` is false and the code always takes the "all themes at zero influence" branch (`randomIntegerBetween`), discarding the distance-field weighting.
-  `applyTerrainThemes` and `applyCellRules` are unaffected (they iterate integer cell indices).
-- **Failure scenario**: markers produced by `GridTaskDensityMarkerDistribution` are always at fractional positions (`processArea:225`, `_x = x0 + u * width`), and they are the bulk of the marker set in `AlienGridGenerator`. Given two `AreaTheme`s whose bounds both cover grid cell (12,8) but where only theme A's mask is set there, a marker at (12.37, 8.91) reports `matchingThemeCount === 2` and is then assigned to A or B with 50/50 probability. With a single partially-filled mask, a marker at a fractional position outside the mask is themed as if it were inside. (The shipped game escapes this only because `LevelGenerator.js:169` fills one mask over the entire grid.)
-- **Fix**: quantise to the cell the marker sits in before probing the mask/distance field, e.g. in `applyNodes`
-  ```js
-  const x = Math.round(nodePosition.x);
-  const y = Math.round(nodePosition.y);
-  ```
-  and use those for both `getThemesByPosition` and `areaMask.distanceField.readChannel`. (Rounding matches `COORDINATES.md`: integer grid coordinates are cell centers.)
-- **Confidence**: Confirmed
-
----
-
-### GEN-4 `GridCellActionPlaceMarkerGroup` never initializes its children
-- **Severity**: MAJOR
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/generation/markers/GridCellActionPlaceMarkerGroup.js:11-81`
-- **Defect**: the class inherits `GridCellAction.initialize`, which only runs asserts. It never forwards to `this.children`, so the wrapped `GridCellActionPlaceMarker`s (and therefore their `transformers`, which `GridCellActionPlaceMarker.initialize:50` is responsible for) are never initialized. Every other composite in the package forwards (`GridCellActionSequence:31`, `CellActionSelectRandom:41`, `MarkerNodeEmitterFromAction:33`).
-- **Failure scenario**:
-  ```js
-  const group = GridCellActionPlaceMarkerGroup.from([
-      GridCellActionPlaceMarker.from({
-          type: 'town',
-          transformers: [MarkerNodeTransformerRecordUniqueRandomEnum.from('name', ['a', 'b'])]
-      })
-  ]);
-  group.initialize(grid, 0);
-  group.execute(grid, 1, 1, 0);
-  ```
-  `MarkerNodeTransformerRecordUniqueRandomEnum.unused` is still the class-field default `[]` (it is only filled in `initialize`), so `transform` throws `Error('All values used up')` on the very first placement. With a `MarkerNodeTransformerYRotateByFilter(CellFilterSimplexNoise…)` instead, `this.noise` is still `null` and `execute` throws `TypeError: this.noise is not a function`. The two sample call sites (`mir_generator_place_bases.js:78`, `mir_generator_place_buff_objects.js:98`) only escape because their group children carry no transformers.
-- **Fix**:
-  ```js
-  initialize(data, seed) {
-      super.initialize(data, seed);
-      const children = this.children;
-      for (let i = 0; i < children.length; i++) {
-          children[i].initialize(data, seed);
-      }
-  }
-  ```
-- **Confidence**: Confirmed
-
----
-
-### GEN-5 `CellFilterCache.execute` ignores `scale` when sampling the cache
-- **Severity**: MAJOR
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/generation/filtering/numeric/CellFilterCache.js:73-75`
-- **Defect**: `initialize` builds a `scale·w × scale·h` cache where texel `(x,y)` holds `source(x/scale, y/scale)` (lines 43-67 — the correct ratio mapping per `COORDINATES.md`). `execute` then reads `this.__cache.sampleChannelBilinear(x, y, 0)` with the raw *grid* coordinate, i.e. it applies `grid_to_texel(v, 1)` instead of `grid_to_texel(v, scale)`.
-- **Failure scenario**: 16×16 grid, `source` = the ramp filter `h(x,y) = x`, `CellFilterCache.from(source, 2)`. Cache is 32×32 with `cache[x] = x/2`. `filter.execute(grid, 10, 0, 0)` returns `5` instead of `10`. Cells `x = 0..15` sample cache texels `0..15`, i.e. only the left half of the grid's value range — the filter is magnified 2× and the right/bottom halves of the map are silently duplicated from the top-left quadrant. Any `scale !== 1` is affected; `scale === 1` is correct, which is why all current call sites (`MohFilterMinorSlope.js:22`, `MohGridFilterTechnology.js:42`, `AlienGridGenerator.js`) are unaffected.
-- **Fix**: `return this.__cache.sampleChannelBilinear(x * this.scale, y * this.scale, 0);` (or `grid_to_texel(x, this.scale)`).
-- **Confidence**: Confirmed
-
----
-
-### GEN-6 Density-distribution per-tile seeds collapse to ~2048 distinct RNG streams
-- **Severity**: MAJOR
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/generation/grid/generation/GridTaskDensityMarkerDistribution.js:343`
-- **Defect**: `const seed = Math.floor(random() * Number.MAX_SAFE_INTEGER);`. `random()` returns `k / 2^32` for an integer `k < 2^32`, so the product is `k·2^21` (± 1 ulp) — the low 21 bits are always zero. Mulberry32 then does `_seed += 0x6D2B79F5` and truncates to int32, keeping only `k mod 2^11`. Effective seed space ≈ 2^11.
-- **Failure scenario**: measured — feeding 4096 consecutive draws of `seededRandom(12345)` through this expression yields 4096 distinct raw seeds but only **1776 distinct effective int32 values**, consistent with 2048 buckets. A 128×128 grid is split into 64 tiles of 16×16 (`tile_size = 16`, lines 312/333/338), so the expected number of colliding tile pairs is `C(64,2)/2048 ≈ 0.98` — roughly 63 % of runs have at least one pair of tiles sharing an identical RNG stream. Two such tiles execute `processArea` with the same `(u, v)` sequence, the same density rolls and the same `scale.sampleRandom` draws, so wherever the density filter is locally flat they receive markers at identical intra-tile offsets — a visibly repeated decor cluster. `AlienGridGenerator` / `AlienCombatSceneGenerator` instantiate ~20 of these tasks per generation.
-- **Fix**: `const seed = randomIntegerBetween(random, 0, 0x7FFFFFFF);` (or `(random() * 0x100000000) | 0`) so the full int32 range reaches Mulberry32.
-- **Confidence**: Confirmed (entropy collapse measured; the visual repetition follows from identical streams over identical tile geometry)
-
----
-
-### GEN-7 `ThemeEngine.apply` never passes a seed to `applyNodes`
-- **Severity**: MINOR
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/generation/theme/ThemeEngine.js:633` (declaration at `:410`)
-- **Defect**: `applyNodes(grid, ecd, seed = 0)` is called as `this.applyNodes(grid, ecd)`, so its `seededRandom(seed)` is always seeded `0` regardless of `ThemeEngine.seed`. Unlike GEN-1 the stream is well-formed; it is simply constant across world seeds.
-- **Failure scenario**: two `AreaTheme`s with overlapping masks over the same region. Run the same generator with world seed `1` and world seed `2`: every marker inside the overlap is assigned to the same theme in both runs (the marker set differs, but the theme-selection draw sequence is identical), so the theme mix at boundaries never varies with the seed.
-- **Fix**: `const tNodes = this.applyNodes(grid, ecd, randomIntegerBetween(this.random, 0, 0x7FFFFFFF));` (pairs with the GEN-1 fix).
-- **Confidence**: Confirmed
-
----
-
-### GEN-8 `CellSupplierBestN` throws when `limit === 0`
-- **Severity**: MINOR
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/generation/grid/generation/grid/select/CellSupplierBestN.js:133-139`
-- **Defect**: the eviction ladder is
-  ```js
-  if (fitness_scratch.length < this.limit) { /* push */ }
-  else if (fitness_scratch[0].score < fitness) { fitness_scratch.shift(); }
-  else { continue; }
-  ```
-  With `limit === 0` the first branch is false on the very first candidate and `fitness_scratch[0]` is `undefined`. `from()` only guards with `assert.isNonNegativeInteger(limit)`, which admits 0 and is stripped in production anyway.
-- **Failure scenario**: `CellSupplierBestN.from({ fitness: CellFilterLiteralFloat.ONE, limit: 0 })` (e.g. a caller computing `limit` from a difficulty budget that evaluates to 0) → `initialize(grid, 0)` on any grid with at least one predicate-matching cell → `TypeError: Cannot read properties of undefined (reading 'score')`. The intended result is an empty selection.
-- **Fix**: make the ladder handle a zero capacity, e.g. start with `if (this.limit === 0) { return; }` before the scan loop, or change the first branch to `if (fitness_scratch.length < this.limit) { … } else if (this.limit > 0 && fitness_scratch[0].score < fitness) { … }`.
-- **Confidence**: Confirmed
-
----
-
-### GEN-9 `MarkerNodeEmitterPredicated` never initializes its predicate
-- **Severity**: MINOR
-- **File**: `H:/git/moh/app/src/mir-engine/meep/src/generation/markers/emitter/MarkerNodeEmitterPredicated.js:44-46`
-- **Defect**: `initialize(data, seed)` forwards only to `this.source`; `this.nodePredicate.initialize(grid, seed)` is never called. The `GridDataNodePredicate` interface declares `initialize(grid, seed)` and both combinators implement the recursion (`GridDataNodePredicateBinary:38`, `GridDataNodePredicateNot:34`), so the recursion exists but its root is never driven. `MarkerNodeEmitterPredicated` is the only consumer of predicates in the package.
-- **Failure scenario**: any predicate that binds per-run state on initialize — the same shape as `GridLayerCellMatcher.initialize` (resolve `layerId` → `__layer`) — keeps `__layer === null` and throws `TypeError: Cannot read properties of null` on the first `evaluate`. The two shipped predicates (`…Overlaps`, `…Any`) have empty `initialize` bodies, so no in-repo configuration fails today; the defect is only reachable from library-user predicates.
-- **Fix**:
-  ```js
-  initialize(data, seed) {
-      this.source.initialize(data, seed);
-      this.nodePredicate.initialize(data, seed);
-  }
-  ```
-- **Confidence**: Likely (contract violation confirmed by reading; no in-repo predicate exercises it)
-
----
-
-## Areas checked and found clean
-
-- **Cellular automata** (`automata/CaveGeneratorCellularAutomata.js`, `grid/generation/discrete/GridTaskCellularAutomata.js`): true double-buffered synchronous step, correct edge/corner neighbour enumeration, OOB = dead as documented, thresholds match the doc comment, `front`/`back` swap read correctly by `tWriteTags`.
-- **Coordinate conventions**: `grid_to_texel`/`texel_to_grid` used consistently by `GridCellActionWriteFilterToLayer`, `CellMatcherLayerBitMaskTest` (OOB → no match), `AbstractCellFilterSampleGridLayer`, `MarkerNodeActionPaintTerrain` (region clamped, symmetric rounding), `populateSampler2DFromCellFilter`. `ContinuousGridCellActionSetTerrainHeight`'s corner mapping is the documented deliberate deviation. Row/column stride (`index % width`, `(index / width) | 0`) is consistent everywhere including non-square grids.
-- **Grid tasks / scheduling**: `GridTaskGroup` sibling-only dependency resolution, `GridTaskSequence` chaining, `TaskGroup.addDependency` group flattening, `countTask`/`randomCountTask` initializer-time limit resolution — all consistent; no task reads a layer written by a task it does not depend on.
-- **Placement / rejection sampling**: `GridTaskExecuteRuleTimes` closes every attempted cell and terminates via `closedCount >= gridSize`; `GridTaskDensityMarkerDistribution.processArea` bounds both the iteration and the rejection budget; `GridTaskConnectRooms.tMain` makes monotone progress in `connected`; `buildPathFromDistanceMap` is strictly decreasing so it cannot loop.
-- **Weighted selection**: `random_pick_weighted_index` cumulative bound and zero-total guard are correct and shared by both selects; the RNG is not consumed on the zero-weight path.
-- **Comparators**: `byScore`/`byIndex` in `CellSupplierBestN`, the priority sort in `applyNodes`, and the layer-descriptor sort in `applyTerrainThemes` are all well-formed numeric comparators.
-- **Module-static scratch**: `GridData.marker_collection`, `CellFilterCurvature`'s normals, `CellFilterAngleToNormal.normal`, `CellFilterLookupTable.sample`, `RoadConnectionNetwork.scratch_paths`, `CellSupplierPathUpHill.scratch_neighbours`, both `evaluatedWeights` arrays — none can be re-entered by the code paths that reach them (`computeFilterSurfaceNormal` writes its result only after all sampling, as documented).
-- **Determinism sources**: no `Math.random`, `Date.now`, `performance.now` or `new Date()` anywhere in the package; every iteration over a `Map`/quadtree is insertion-ordered; `ArrayIteratorRandom` defaults to `seededRandom(0)` rather than an unseeded source.
+# Correctness review — `meep/src/generation`
+
+Scope: every non-spec source file under
+`H:/git/moh/app/src/mir-engine/meep/src/generation/` (~12.2k LOC, 160 files).
+`REVIEW_01_ACTION_PLAN.md` items and `COORDINATES.md` conventions were read first;
+already-addressed items are not re-reported.
+
+Method: full read of the package. Determinism claims about Mulberry32 were
+verified by executing the generator (`core/math/random/seededRandom_Mulberry32.js`)
+directly under node; the measurements are quoted in the findings.
+
+---
+
+### GEN-1 Theme child seeds are `random()` floats; Mulberry32 collapses them to one stream
+- **Severity**: CRITICAL
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/generation/theme/ThemeEngine.js:212`, `H:/git/moh/app/src/mir-engine/meep/src/generation/theme/TerrainTheme.js:29`
+- **Defect**: Both sites use the *output* of a `seededRandom` stream (a float in `[0,1)`) as the *seed* of a child stream. `seededRandom_Mulberry32` does `_seed += 0x6D2B79F5` and then feeds `_seed` through `Math.imul`/`^`/`>>>`, all of which apply ToInt32/ToUint32 and discard the fractional part. Every seed in `[0,1)` therefore produces a byte-identical sequence — identical to `seededRandom(0)`.
+- **Failure scenario**: `themeEngine.random.setCurrentSeed(12345)` → `initializeThemes` derives theme seed `0.9797282677609473`; with world seed `999` it derives `0.9699058223050088`. Both are passed to `Theme.initialize(grid, ecd, seed)` → `TerrainTheme.initialize` → `seededRandom(seed)`. Verified output of the first three draws for seeds `0.1234`, `0.9876` and `0` is identical: `0.26642920868471265, 0.0003297457005828619, 0.2232720274478197`. Consequently, for the shipped `AlienTheme0` / `SnowyTheme`:
+  - every `CellFilterSimplexNoise` reachable from `Theme.terrain.rules` and `Theme.nodes` (`injectBases.js:101`, `injectEnemies.js:355`, `injectTreasure.js:556`, `injectBuffObjects.js:45`, `injectPlayerCharacter.js:88`) is built from the *same* permutation table, and that table never changes with the world seed;
+  - `MarkerNodeTransformRotateRandom` and `MarkerNodeEntityProcessorRandomRotation` (`theme-1/injectDecor.js`) emit the same rotation sequence for every world seed.
+  Two runs with different world seeds produce identical theme-layer noise and identical decor rotations.
+- **Fix**: derive integer child seeds at both sites, e.g.
+  `const seed = randomIntegerBetween(this.random, 0, 0x7FFFFFFF);` in `ThemeEngine.initializeThemes` and
+  `const ruleSeed = randomIntegerBetween(random, 0, 0x7FFFFFFF);` in `TerrainTheme.initialize`.
+  (Same one-line shape; `(random() * 0x100000000) | 0` also works.)
+- **Confidence**: Confirmed
+
+---
+
+### GEN-2 `GridTaskGenerateRoads` never initializes its `traversable` matcher
+- **Severity**: CRITICAL
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/generation/grid/generation/road/GridTaskGenerateRoads.js:513-608`
+- **Defect**: `build()` creates `tInitializeActions` for `this.actions` but there is no `this.traversable.initialize(grid, seed)` anywhere. `traversable` is a required `from({...})` parameter (phase 5.1) and is used by `tBuildDistanceField` (line 567, wrapped in a fresh `CellMatcherNot` that is also never initialized), by the Dijkstra expansion (lines 213, 276) and by `drawPath` (line 425). Every sibling task in the package that accepts a `CellMatcher` initializes it (`GridTaskConnectRooms.build:469`, `GridTaskBuildSourceDistanceMap.build:117`, `CellSupplierBestN.initialize:97`, `GridCellPlacementRule.initialize:91`).
+- **Failure scenario**:
+  ```js
+  const roads = GridTaskGenerateRoads.from({
+      traversable: CellMatcherLayerBitMaskTest.from(TRAVERSABLE_BIT, 'tags'),
+      actions: [GridCellActionPlaceTags.from(ROAD_BIT, 'tags')]
+  });
+  executeTaskTreeSync(roads.build(grid, ecd, 0));
+  ```
+  `tBuildDistanceField` → `buildUnsignedDistanceField` → `traversable.match(grid, 0, 0, 0)` → `GridLayerCellMatcher.__layer` is still `null` → `TypeError: Cannot read properties of null (reading 'sampler')`. `SampleGenerator0` only survives because it passes the module-level singleton `matcher_tag_traversable`, which `GridTaskConnectRooms` happens to bind first; a per-run matcher factory (the pattern review-01 §3.7 mandates) crashes. `GridTaskGenerateRoads.spec.js` misses it because it passes `CellMatcherAny.INSTANCE`, which needs no initialization.
+- **Fix**: build the negated matcher once and initialize both in an init task that `tBuildDistanceField` / `tBuildPaths` / `tDrawPaths` depend on:
+  ```js
+  const not_traversable = CellMatcherNot.from(traversable);
+  const tInitializeMatchers = actionTask(() => {
+      traversable.initialize(grid, seed);
+      not_traversable.initialize(grid, seed);
+  });
+  // tBuildDistanceField uses not_traversable; add tInitializeMatchers as a dependency of
+  // tBuildDistanceField, tBuildPaths and tDrawPaths.
+  ```
+- **Confidence**: Confirmed
+
+---
+
+### GEN-3 `ThemeEngine.applyNodes` indexes samplers with fractional marker coordinates
+- **Severity**: MAJOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/generation/theme/ThemeEngine.js:166` (`getThemesByPosition`) and `:466`
+- **Defect**: `applyNodes` passes `node.position.x/y` — continuous grid coordinates — straight into `Sampler2D.readChannel`, which computes `index = (y * width + x) * itemSize + channel`. With a fractional coordinate the index is fractional and a typed-array read returns `undefined`, not a value.
+  - `getThemesByPosition:168`: `if (filled === 0) continue;` — `undefined === 0` is `false`, so the mask refinement is skipped entirely and *every* theme whose quadtree bounds contain the point is accepted.
+  - `applyNodes:466-470`: `influenceSum += undefined` → `NaN`, so `influenceSum > 0` is false and the code always takes the "all themes at zero influence" branch (`randomIntegerBetween`), discarding the distance-field weighting.
+  `applyTerrainThemes` and `applyCellRules` are unaffected (they iterate integer cell indices).
+- **Failure scenario**: markers produced by `GridTaskDensityMarkerDistribution` are always at fractional positions (`processArea:225`, `_x = x0 + u * width`), and they are the bulk of the marker set in `AlienGridGenerator`. Given two `AreaTheme`s whose bounds both cover grid cell (12,8) but where only theme A's mask is set there, a marker at (12.37, 8.91) reports `matchingThemeCount === 2` and is then assigned to A or B with 50/50 probability. With a single partially-filled mask, a marker at a fractional position outside the mask is themed as if it were inside. (The shipped game escapes this only because `LevelGenerator.js:169` fills one mask over the entire grid.)
+- **Fix**: quantise to the cell the marker sits in before probing the mask/distance field, e.g. in `applyNodes`
+  ```js
+  const x = Math.round(nodePosition.x);
+  const y = Math.round(nodePosition.y);
+  ```
+  and use those for both `getThemesByPosition` and `areaMask.distanceField.readChannel`. (Rounding matches `COORDINATES.md`: integer grid coordinates are cell centers.)
+- **Confidence**: Confirmed
+
+---
+
+### GEN-4 `GridCellActionPlaceMarkerGroup` never initializes its children
+- **Severity**: MAJOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/generation/markers/GridCellActionPlaceMarkerGroup.js:11-81`
+- **Defect**: the class inherits `GridCellAction.initialize`, which only runs asserts. It never forwards to `this.children`, so the wrapped `GridCellActionPlaceMarker`s (and therefore their `transformers`, which `GridCellActionPlaceMarker.initialize:50` is responsible for) are never initialized. Every other composite in the package forwards (`GridCellActionSequence:31`, `CellActionSelectRandom:41`, `MarkerNodeEmitterFromAction:33`).
+- **Failure scenario**:
+  ```js
+  const group = GridCellActionPlaceMarkerGroup.from([
+      GridCellActionPlaceMarker.from({
+          type: 'town',
+          transformers: [MarkerNodeTransformerRecordUniqueRandomEnum.from('name', ['a', 'b'])]
+      })
+  ]);
+  group.initialize(grid, 0);
+  group.execute(grid, 1, 1, 0);
+  ```
+  `MarkerNodeTransformerRecordUniqueRandomEnum.unused` is still the class-field default `[]` (it is only filled in `initialize`), so `transform` throws `Error('All values used up')` on the very first placement. With a `MarkerNodeTransformerYRotateByFilter(CellFilterSimplexNoise…)` instead, `this.noise` is still `null` and `execute` throws `TypeError: this.noise is not a function`. The two sample call sites (`mir_generator_place_bases.js:78`, `mir_generator_place_buff_objects.js:98`) only escape because their group children carry no transformers.
+- **Fix**:
+  ```js
+  initialize(data, seed) {
+      super.initialize(data, seed);
+      const children = this.children;
+      for (let i = 0; i < children.length; i++) {
+          children[i].initialize(data, seed);
+      }
+  }
+  ```
+- **Confidence**: Confirmed
+
+---
+
+### GEN-5 `CellFilterCache.execute` ignores `scale` when sampling the cache
+- **Severity**: MAJOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/generation/filtering/numeric/CellFilterCache.js:73-75`
+- **Defect**: `initialize` builds a `scale·w × scale·h` cache where texel `(x,y)` holds `source(x/scale, y/scale)` (lines 43-67 — the correct ratio mapping per `COORDINATES.md`). `execute` then reads `this.__cache.sampleChannelBilinear(x, y, 0)` with the raw *grid* coordinate, i.e. it applies `grid_to_texel(v, 1)` instead of `grid_to_texel(v, scale)`.
+- **Failure scenario**: 16×16 grid, `source` = the ramp filter `h(x,y) = x`, `CellFilterCache.from(source, 2)`. Cache is 32×32 with `cache[x] = x/2`. `filter.execute(grid, 10, 0, 0)` returns `5` instead of `10`. Cells `x = 0..15` sample cache texels `0..15`, i.e. only the left half of the grid's value range — the filter is magnified 2× and the right/bottom halves of the map are silently duplicated from the top-left quadrant. Any `scale !== 1` is affected; `scale === 1` is correct, which is why all current call sites (`MohFilterMinorSlope.js:22`, `MohGridFilterTechnology.js:42`, `AlienGridGenerator.js`) are unaffected.
+- **Fix**: `return this.__cache.sampleChannelBilinear(x * this.scale, y * this.scale, 0);` (or `grid_to_texel(x, this.scale)`).
+- **Confidence**: Confirmed
+
+---
+
+### GEN-6 Density-distribution per-tile seeds collapse to ~2048 distinct RNG streams
+- **Severity**: MAJOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/generation/grid/generation/GridTaskDensityMarkerDistribution.js:343`
+- **Defect**: `const seed = Math.floor(random() * Number.MAX_SAFE_INTEGER);`. `random()` returns `k / 2^32` for an integer `k < 2^32`, so the product is `k·2^21` (± 1 ulp) — the low 21 bits are always zero. Mulberry32 then does `_seed += 0x6D2B79F5` and truncates to int32, keeping only `k mod 2^11`. Effective seed space ≈ 2^11.
+- **Failure scenario**: measured — feeding 4096 consecutive draws of `seededRandom(12345)` through this expression yields 4096 distinct raw seeds but only **1776 distinct effective int32 values**, consistent with 2048 buckets. A 128×128 grid is split into 64 tiles of 16×16 (`tile_size = 16`, lines 312/333/338), so the expected number of colliding tile pairs is `C(64,2)/2048 ≈ 0.98` — roughly 63 % of runs have at least one pair of tiles sharing an identical RNG stream. Two such tiles execute `processArea` with the same `(u, v)` sequence, the same density rolls and the same `scale.sampleRandom` draws, so wherever the density filter is locally flat they receive markers at identical intra-tile offsets — a visibly repeated decor cluster. `AlienGridGenerator` / `AlienCombatSceneGenerator` instantiate ~20 of these tasks per generation.
+- **Fix**: `const seed = randomIntegerBetween(random, 0, 0x7FFFFFFF);` (or `(random() * 0x100000000) | 0`) so the full int32 range reaches Mulberry32.
+- **Confidence**: Confirmed (entropy collapse measured; the visual repetition follows from identical streams over identical tile geometry)
+
+---
+
+### GEN-7 `ThemeEngine.apply` never passes a seed to `applyNodes`
+- **Severity**: MINOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/generation/theme/ThemeEngine.js:633` (declaration at `:410`)
+- **Defect**: `applyNodes(grid, ecd, seed = 0)` is called as `this.applyNodes(grid, ecd)`, so its `seededRandom(seed)` is always seeded `0` regardless of `ThemeEngine.seed`. Unlike GEN-1 the stream is well-formed; it is simply constant across world seeds.
+- **Failure scenario**: two `AreaTheme`s with overlapping masks over the same region. Run the same generator with world seed `1` and world seed `2`: every marker inside the overlap is assigned to the same theme in both runs (the marker set differs, but the theme-selection draw sequence is identical), so the theme mix at boundaries never varies with the seed.
+- **Fix**: `const tNodes = this.applyNodes(grid, ecd, randomIntegerBetween(this.random, 0, 0x7FFFFFFF));` (pairs with the GEN-1 fix).
+- **Confidence**: Confirmed
+
+---
+
+### GEN-8 `CellSupplierBestN` throws when `limit === 0`
+- **Severity**: MINOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/generation/grid/generation/grid/select/CellSupplierBestN.js:133-139`
+- **Defect**: the eviction ladder is
+  ```js
+  if (fitness_scratch.length < this.limit) { /* push */ }
+  else if (fitness_scratch[0].score < fitness) { fitness_scratch.shift(); }
+  else { continue; }
+  ```
+  With `limit === 0` the first branch is false on the very first candidate and `fitness_scratch[0]` is `undefined`. `from()` only guards with `assert.isNonNegativeInteger(limit)`, which admits 0 and is stripped in production anyway.
+- **Failure scenario**: `CellSupplierBestN.from({ fitness: CellFilterLiteralFloat.ONE, limit: 0 })` (e.g. a caller computing `limit` from a difficulty budget that evaluates to 0) → `initialize(grid, 0)` on any grid with at least one predicate-matching cell → `TypeError: Cannot read properties of undefined (reading 'score')`. The intended result is an empty selection.
+- **Fix**: make the ladder handle a zero capacity, e.g. start with `if (this.limit === 0) { return; }` before the scan loop, or change the first branch to `if (fitness_scratch.length < this.limit) { … } else if (this.limit > 0 && fitness_scratch[0].score < fitness) { … }`.
+- **Confidence**: Confirmed
+
+---
+
+### GEN-9 `MarkerNodeEmitterPredicated` never initializes its predicate
+- **Severity**: MINOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/generation/markers/emitter/MarkerNodeEmitterPredicated.js:44-46`
+- **Defect**: `initialize(data, seed)` forwards only to `this.source`; `this.nodePredicate.initialize(grid, seed)` is never called. The `GridDataNodePredicate` interface declares `initialize(grid, seed)` and both combinators implement the recursion (`GridDataNodePredicateBinary:38`, `GridDataNodePredicateNot:34`), so the recursion exists but its root is never driven. `MarkerNodeEmitterPredicated` is the only consumer of predicates in the package.
+- **Failure scenario**: any predicate that binds per-run state on initialize — the same shape as `GridLayerCellMatcher.initialize` (resolve `layerId` → `__layer`) — keeps `__layer === null` and throws `TypeError: Cannot read properties of null` on the first `evaluate`. The two shipped predicates (`…Overlaps`, `…Any`) have empty `initialize` bodies, so no in-repo configuration fails today; the defect is only reachable from library-user predicates.
+- **Fix**:
+  ```js
+  initialize(data, seed) {
+      this.source.initialize(data, seed);
+      this.nodePredicate.initialize(data, seed);
+  }
+  ```
+- **Confidence**: Likely (contract violation confirmed by reading; no in-repo predicate exercises it)
+
+---
+
+## Areas checked and found clean
+
+- **Cellular automata** (`automata/CaveGeneratorCellularAutomata.js`, `grid/generation/discrete/GridTaskCellularAutomata.js`): true double-buffered synchronous step, correct edge/corner neighbour enumeration, OOB = dead as documented, thresholds match the doc comment, `front`/`back` swap read correctly by `tWriteTags`.
+- **Coordinate conventions**: `grid_to_texel`/`texel_to_grid` used consistently by `GridCellActionWriteFilterToLayer`, `CellMatcherLayerBitMaskTest` (OOB → no match), `AbstractCellFilterSampleGridLayer`, `MarkerNodeActionPaintTerrain` (region clamped, symmetric rounding), `populateSampler2DFromCellFilter`. `ContinuousGridCellActionSetTerrainHeight`'s corner mapping is the documented deliberate deviation. Row/column stride (`index % width`, `(index / width) | 0`) is consistent everywhere including non-square grids.
+- **Grid tasks / scheduling**: `GridTaskGroup` sibling-only dependency resolution, `GridTaskSequence` chaining, `TaskGroup.addDependency` group flattening, `countTask`/`randomCountTask` initializer-time limit resolution — all consistent; no task reads a layer written by a task it does not depend on.
+- **Placement / rejection sampling**: `GridTaskExecuteRuleTimes` closes every attempted cell and terminates via `closedCount >= gridSize`; `GridTaskDensityMarkerDistribution.processArea` bounds both the iteration and the rejection budget; `GridTaskConnectRooms.tMain` makes monotone progress in `connected`; `buildPathFromDistanceMap` is strictly decreasing so it cannot loop.
+- **Weighted selection**: `random_pick_weighted_index` cumulative bound and zero-total guard are correct and shared by both selects; the RNG is not consumed on the zero-weight path.
+- **Comparators**: `byScore`/`byIndex` in `CellSupplierBestN`, the priority sort in `applyNodes`, and the layer-descriptor sort in `applyTerrainThemes` are all well-formed numeric comparators.
+- **Module-static scratch**: `GridData.marker_collection`, `CellFilterCurvature`'s normals, `CellFilterAngleToNormal.normal`, `CellFilterLookupTable.sample`, `RoadConnectionNetwork.scratch_paths`, `CellSupplierPathUpHill.scratch_neighbours`, both `evaluatedWeights` arrays — none can be re-entered by the code paths that reach them (`computeFilterSurfaceNormal` writes its result only after all sampling, as documented).
+- **Determinism sources**: no `Math.random`, `Date.now`, `performance.now` or `new Date()` anywhere in the package; every iteration over a `Map`/quadtree is insertion-ordered; `ArrayIteratorRandom` defaults to `seededRandom(0)` rather than an unseeded source.