@woosh/meep-engine 3.1.0 → 3.2.0

package/src/DUPLICATION_AUDIT_2026_08_07/I_generation_view.md

@@ -1,74 +1,74 @@
-# Domain I — generation + view + editor
-
-Scope: `meep/src/generation/**`, `meep/src/view/**`, `meep/editor/**`.
-Every row below was verified by opening the cited files. `*.spec.js`, `prototype*.js`, `test*.js` excluded.
-
----
-
-## Findings — generation
-
-| # | Severity | Concept | Sites | Evidence | Verdict | Proposed common path | Effort/Risk |
-|---|---|---|---|---|---|---|---|
-| G1 | HIGH | Uniform-cost grid BFS/Dijkstra (open heap + `closed` BitSet + distance relaxation) written three times; the `inOpen` membership-mirror optimisation landed in only two of them | `src/generation/grid/generation/util/buildDistanceMapToObjective.js:15` `buildDistanceMapToObjective` (relax 85–92) · `src/generation/grid/generation/discrete/layer/GridTaskBuildSourceDistanceMap.js:66` `build` (heap 93, `inOpen` 107, `processNeighbor` 145, expansion 193–208) · `src/generation/grid/generation/road/GridTaskGenerateRoads.js:104` `buildPaths` (heap 121, `inOpen` 129, relax 282–297) | The JSDoc comment *"membership mirror of the open heap, O(1) replacement for linear heap.contains scans"* appears **verbatim** at `GridTaskBuildSourceDistanceMap.js:104` and `GridTaskGenerateRoads.js:126` — a copy-paste of a performance fix. `buildDistanceMapToObjective` never received it; it dodges the problem with a different heap (`Uint32Heap.insert_or_update`) instead. Three different heap types (`Uint32Heap`, `BinaryHeap`, `BinaryHeap`), three different relaxation shapes, one algorithm. `GridTaskBuildSourceDistanceMap` additionally hardcodes the 4-neighbourhood as index arithmetic (`±1`, `±width`) instead of a mask, so it silently cannot be switched to 8-way | UNJUSTIFIED | One `grid_build_distance_field({distances, open, closed, grid, neighbourhoodMask, traversable, onVisit})` in `generation/grid/generation/util/`, built on `Uint32Heap` (which already has `insert_or_update`, removing the need for the mirror entirely). `buildDistanceMapToObjective` becomes a thin `onVisit` wrapper; the road builder passes its heuristic-free variant | Medium effort / Medium risk — three call sites with different early-exit semantics; needs a generation-output regression test |
-| G2 | MEDIUM | 2D rotation of a local offset by `rotation` radians, inlined 8× — `core/geom/vec2/` has **no** `v2_rotate` | `src/generation/filtering/numeric/util/CellFilterDisplaced.js:33-40` `execute` · `src/generation/markers/GridActionRuleSet.js:176-180` `process` · `src/generation/markers/GridCellActionPlaceMarker.js:156-167` `buildBaseNode` · `src/generation/markers/transform/MarkerNodeTransformerOffsetPosition.js:34-41` `transform` · `src/generation/placement/action/GridCellActionPlaceTags.js:87-103` `execute` · `src/generation/placement/action/util/GridCellDisplacedAction.js:41-48` `execute` · `src/generation/placement/GridCellPlacementRule.js:104-113` `execute` · `src/generation/rules/cell/CellMatcherGridPattern.js:94-107` `match` | Byte-identical four-line body at all 8 sites (`const sin = Math.sin(rotation); const cos = Math.cos(rotation); const rotated_local_x = local_x * cos - local_y * sin` / `..._y = local_x * sin + local_y * cos;`) — even the missing semicolon after `* sin` is reproduced everywhere. `core/geom/vec2/` contains only `v2_matrix3_cm_multiply`/`_rm_multiply`; there is no rotate-by-angle primitive. Downstream handling then diverges: `CellMatcherGridPattern:109` and `GridCellActionPlaceTags:106` `Math.round` the result, the other six do not | PROMOTION | `core/geom/vec2/v2_rotate.js` — `v2_rotate(result, result_offset, x, y, angle)` (result-first, matching the house convention), plus `v2_rotate_cos_sin` for the `GridActionRuleSet` loop that rotates many offsets by the same angle. Note in JSDoc that callers own the rounding decision | Low effort / Low risk — pure extraction, no behaviour change |
-| G3 | MEDIUM | Weighted random selection over `CellFilter` weights implemented three times, one bypassing `random_pick_weighted_index` with a different prefix-sum convention | `src/generation/markers/actions/probability/MarkerNodeActionSelectWeighted.js:56` `execute` · `src/generation/placement/action/random/weighted/CellActionSelectWeightedRandom.js:78` `execute` · `src/generation/theme/ThemeEngine.js:411` `applyNodes` (454–485) | Sites 1 and 2 are the same 30-line body — module-scope `evaluatedWeights` array, `weightFilter.execute(...)`, `if (weightValue > 0) totalWeight += weightValue`, identical `//if the weight is negative, we clamp it to 0` comment, `random_pick_weighted_index(...)`, identical `index === -1` early-out. Only the position source differs (`node.position.x/y` vs `x,y`). Site 3 hand-rolls the same selection with an **exclusive** prefix sum (`themeInfluence[j] = influenceSum;` *before* `influenceSum += influence`, line 469–471) and `binarySearchLowIndex`, where the core primitive uses an **inclusive** prefix sum and `binarySearchHighIndex`. Both are individually correct, but the two conventions cannot be swapped, so a fix to one never transfers | UNJUSTIFIED | Extract `cell_filter_weights_pick(random, weightedElements, grid, x, y)` in `generation/filtering/` returning the picked index (owning the CDF scratch, the negative-weight clamp and the `-1` contract). Sites 1 and 2 call it; site 3 switches to `random_pick_weighted_index` with the inclusive convention | Low effort / Low risk — three specs already exist |
-| G4 | MEDIUM | Sobel 3×3 tap + gradient magnitude duplicated verbatim; the shared helper already exists next door and is not used | `src/generation/filtering/numeric/complex/CellFilterSobel.js:35` `execute` (39–55) · `src/generation/filtering/numeric/process/computeCellFilterGradient.js:12` `computeCellFilterGradient` (15–31) | Lines 39–55 of `CellFilterSobel.execute` and lines 15–31 of `computeCellFilterGradient` are identical character-for-character including the `//read surrounding points`, `// compute gradients` and `//normalize vector` comments and the `2.0 *` literals. `CellFilterSobel` keeps the magnitude and discards the direction; `computeCellFilterGradient` keeps the direction and discards the magnitude. The sibling family got this right: `CellFilterCurvature` and `CellFilterAngleToNormal` both delegate to `process/computeFilterSurfaceNormal.js` | UNJUSTIFIED | Add `generation/filtering/numeric/process/computeCellFilterSobel.js` writing raw `dX, dY` into a `result` pair. `CellFilterSobel.execute` returns `v2_length(dX, dY)`; `computeCellFilterGradient` divides by it. Both `Math.sqrt(dX*dX + dY*dY)` sites also bypass `core/geom/vec2/v2_length` | Low effort / Low risk |
-| G5 | MEDIUM | The 4-way and 8-way grid neighbourhood masks are re-declared per class, while `ORTHOGONAL_NEIGHBOURHOOD_MASK` exists with zero importers and one copy is dead | `src/engine/grid/ORTHOGONAL_NEIGHBOURHOOD_MASK.js:6` · `src/generation/grid/generation/discrete/GridTaskConnectRooms.js:44` `neighbourhoodSearchMask` and `:57` `neighbourhoodDrawMask` · `src/generation/grid/generation/road/GridTaskGenerateRoads.js:456` `neighbourhoodSearchMask` and `:469` `neighbourhoodDrawMask` | The two `neighbourhoodSearchMask` fields are element-for-element `[0,-1, -1,0, 1,0, 0,1]` — identical to `ORTHOGONAL_NEIGHBOURHOOD_MASK`, which a repo-wide grep shows has **no importer at all**. The two `neighbourhoodDrawMask` fields hold the same 8 offsets in different orders (`ConnectRooms`: `-1,-1 / 0,-1 / 1,-1 …`; `GenerateRoads`: `-1,-1 / 1,-1 / 0,-1 …`) — and `GridTaskGenerateRoads.neighbourhoodDrawMask` is **never read** (grep: only the declaration), i.e. it is a stale copy carried over from `GridTaskConnectRooms` | UNJUSTIFIED (constants only — see Dismissed for the loop bodies) | Import `ORTHOGONAL_NEIGHBOURHOOD_MASK` for the 4-way case and add a sibling `MOORE_NEIGHBOURHOOD_MASK` next to it for the 8-way case; delete the dead `neighbourhoodDrawMask` on `GridTaskGenerateRoads`. Keep them as per-instance overridable fields defaulting to the shared constants | Low effort / Low risk |
-| G6 | MEDIUM | Rasterising a `CellFilter` into a `Sampler2D` at a scale is written twice | `src/generation/filtering/numeric/CellFilterCache.js:37` `initialize` (55–68) · `src/generation/filtering/numeric/util/populateSampler2DFromCellFilter.js:9` `populateSampler2DFromCellFilter` (17–35) | Same nested `for y / for x`, same `grid_x`/`grid_y` scale division, same `writeChannel(x, y, 0, v)`. Only the scale is expressed differently (`1/this.scale` vs `result.width / grid.width` — algebraically the same when the sampler is `scale ×` the grid). `populateSampler2DFromCellFilter` also carries the `generation/COORDINATES.md` ratio-mapping comment that `CellFilterCache` lacks, so the two would silently drift if that convention were ever revised | UNJUSTIFIED | Split the loop out of `populateSampler2DFromCellFilter` into `write_cell_filter_to_sampler2d(result, filter, grid)` (no `ensureInitialized` inside — the seed-0 initialise at `populateSampler2DFromCellFilter.js:14` is what currently blocks direct reuse); both callers use it | Low effort / Low risk |
-| G7 | LOW | `CellFilterPower` re-derives the base class's two-child evaluation instead of implementing `operation()` | `src/generation/filtering/numeric/math/CellFilterPower.js:28` `execute` · base at `src/generation/filtering/core/CellFilterBinaryOperation.js:31` `execute` | All 8 other `CellFilterBinaryOperation` subclasses (`Add`/`Subtract`/`Multiply`/`Divide`/`Max2`/`Min2`/`Step`/`And`) implement `operation(left, right)`; `CellFilterPower` alone overrides `execute` with a hand-copied `this.left.execute(...)` / `this.right.execute(...)` pair. Any future change to the base `execute` (memoisation, assertions, a rotation-propagation fix) silently skips this one node | UNJUSTIFIED | Replace the `execute` override with `operation(value, power) { return Math.pow(value, power); }` and add the `get dataType()` the sibling algebra nodes carry | Trivial / Trivial |
-| G8 | LOW | Two boolean algebras over the *identical* `(grid, x, y, rotation) → bool` domain, joined by adapters in both directions | `src/generation/rules/logic/CellMatcherAnd.js:6` `match` · `src/generation/filtering/boolean/logic/CellFilterAnd.js:30` `operation` · adapters `src/generation/filtering/CellFilterCellMatcher.js:41` `execute` and `src/generation/rules/CellMatcherFromFilter.js:28` `match` | `CellFilterAnd` is boolean-typed (`dataType === DataType.Boolean`) over the same signature `CellMatcher` already covers, and the `CellFilterCellMatcher`/`CellMatcherFromFilter` pair converts freely between the two, so `CellFilterAnd.from(a, b)` is expressible as `CellFilterCellMatcher.from(CellMatcherAnd.from(CellMatcherFromFilter.from(a), CellMatcherFromFilter.from(b)))`. `CellFilterAnd` is the *only* member of the boolean-filter branch (`filtering/boolean/logic/` has one file) and has no non-spec consumer, whereas the `CellMatcher` side is complete (`And`/`Or`/`Not`/`Any`/`Decorator`) and is what every grid task uses | UNJUSTIFIED (documentation-level) | Do not delete (public library surface, house rule). Add a JSDoc note on `CellFilterAnd` naming `CellMatcherAnd` as the canonical boolean combinator and the adapters as the bridge, so nobody grows a parallel `CellFilterOr`/`CellFilterNot` branch | Trivial / Trivial |
-
----
-
-## Findings — view + editor
-
-| # | Severity | Concept | Sites | Evidence | Verdict | Proposed common path | Effort/Risk |
-|---|---|---|---|---|---|---|---|
-| V1 | HIGH | `ImageView` and `VideoView` are the same pooled media element view; the pooling backend was upgraded in one and left behind in the other | `src/view/elements/image/ImageView.js:52` `constructor`, `:108` `destroy`, `:128` `__setSize`, `:138` `__setSource` · `src/view/elements/video/VideoView.js:66` `constructor`, `:120` `destroy`, `:146` `__setSize`, `:156` `__setSource` | Constructors are identical from the `src` resolution through cache-key construction, attribute copying, `pool.release(cacheKey)`, the `classList` loop and `this.size.onChanged.add(this.__setSize, this)`; `__setSize` and `__setSource` are byte-identical. The only intended difference is the tag (`'img'` vs `"video"`). Two unintended divergences: (a) `ImageView` uses `ImmutableObjectPool` (`:24-27`) and releases correctly (`:114-118` `if (!added) pool.release(key)`), while `VideoView` still uses a hand-rolled `Cache` of element arrays (`:14-18`, `:38-57`) whose `destroy` at `:132` only releases the pooled key inside `else if (elements.length < 100)` — once a bucket is full, neither the element nor the pooled `HTMLElementCacheKey` is returned; (b) `ImageView:61` null-guards the `url` argument (`src = ''`), `VideoView:75` does not, so a null URL yields `src="undefined"` | UNJUSTIFIED | `MediaElementView` base under `src/view/elements/` owning the constructor, `destroy`, `__setSize`, `__setSource` and the `ImmutableObjectPool`, parameterised by tag. `ImageView`/`VideoView` become `super('img')` / `super('video')` shells (both are public exports, so keep the class names and the `isVideoView` marker) | Low effort / Medium risk — `VideoView` gains `ImmutableObjectPool` semantics; check nothing depends on the video element surviving in the `Cache` |
-| V2 | HIGH | The `NumericInterval` min ≤ max invariant is enforced three different ways in three different interval editors | `src/view/controller/controls/NumericIntervalControl.js:33` `surrogate2model` (42–48) · `editor/view/ecs/components/common/NumericIntervalController.js:44` and `:54` (write handlers) · `editor/ecs/component/editors/NumericIntervalEditor.js:42` `sync_down` (53–59) and `:72` `validate` | Three incompatible behaviours for the same invariant. (1) collapses the interval — `if (min > max) { maxController.setValue(min); interval.set(min, min); }`. (2) widens — `interval.set(v, max2(v, vMax…))` / `interval.set(min2(v, vMin…), v)`. (3) refuses the write — `if (v0 <= v1) interval.set(v0, v1)` — plus a `blur` listener that restores the old value. Editing "min" past "max" therefore does three different things depending on which panel you opened. (2) and (3) even build the same widget from the same `NumberController`, differing only in layout and the clamp rule | UNJUSTIFIED | One `NumericIntervalController` (the `editor/view/ecs/components/common/` one, already `NumberController`-based) owning a single documented clamp policy; `NumericIntervalEditor.build` returns it, and the dat.gui `NumericIntervalControl` either wraps it or is dropped in favour of it. Whichever policy is chosen must be stated in JSDoc on `NumericInterval` itself | Medium effort / Medium risk — user-visible behaviour change in two of the three panels; pick the policy deliberately |
-| V3 | HIGH | Two-way "model ↔ widget" sync with a re-entrancy lock is hand-rolled in eight editors, half of them without the lock; `FieldValueAdapter` already exists as the seam that would collapse the `Observed*Editor` family into the `primitive/*Editor` family | `editor/ecs/component/editors/ObservedIntegerEditor.js:6` `build` vs `editor/ecs/component/editors/primitive/NumberEditor.js:6` `build` · `editor/ecs/component/editors/ObservedStringEditor.js:6` `build` vs `editor/ecs/component/editors/primitive/StringEditor.js:6` `build` · `editor/ecs/component/editors/ObservedBooleanEditor.js:5` `build` vs `editor/ecs/component/editors/primitive/BooleanEditor.js:6` `build` · also `editor/ecs/component/editors/geom/Vector1Editor.js:20-47`, `editor/ecs/component/editors/geom/QuaternionEditor.js:19-59`, `editor/ecs/component/editors/common/makeV3_editor.js:35-66`, `editor/ecs/component/editors/NumericIntervalEditor.js:27-62` | Every one of these is the same shape: `let lock = false;` + `sync_up()` (model → widget) + `sync_down()` (widget → model), each opening with `if (lock) { return; } lock = true;` and closing with `lock = false;`, wired as `ctrl.on.linked.add(sync_up); ctrl.value.onChanged.add(sync_down); ctrl.bindSignal(<model>.onChanged, sync_up);`. The Observed↔primitive pairs differ *only* in how the value is read and written (`instance.getValue()`/`instance.set()` + `bindSignal(instance.onChanged, …)` versus `field.adapter.read(parent, field.name)`/`.write(…)` with no change signal) — and the guard is present in `ObservedIntegerEditor`/`ObservedStringEditor`/`NumberEditor` but absent in `StringEditor` and `BooleanEditor`, so the protocol is not even applied consistently. `editor/ecs/component/FieldValueAdapter.js:3` is already the abstraction for "read/write a field on a parent"; it just lacks an observed variant that also exposes a change signal | UNJUSTIFIED | Add `ObservedFieldValueAdapter extends FieldValueAdapter` (read/write via `getValue`/`set`, plus a `change_signal(object, field_name)` accessor returning `onChanged` or `Signal.NONE`), then delete `ObservedBooleanEditor`/`ObservedIntegerEditor`/`ObservedStringEditor` and register the `primitive/` editors for those types. Hoist the lock+sync wiring into a single `bind_two_way(view, read, write, change_signal)` helper used by every remaining editor | Medium effort / Medium risk — touches the type registry; the `Observed*` classes are internal to the editor so removal is safe, but registration order must be checked |
-| V4 | HIGH | `GroupView` re-implements `View`'s child list, bypassing the link/unlink lifecycle | `src/view/elements/Group.js:3` `GroupView` — `this.children = []` at `:9`, `add(view)` at `:11`, `remove(view)` at `:17`, `update()` at `:25` · base at `src/view/View.js:107` `children`, `:365` `addChild`, `:433` `removeChild` · sole consumer `editor/view/ecs/components/TerrainController.js:131-133` | `View` already declares `children = []` (`View.js:107`), and `View.addChild` (`:365`) does four things: asserts the child is not already linked, sets `child.parent = this`, calls `child.link()` when the parent is linked, then pushes and appends. `GroupView` shadows the same `children` field with its own array and its `add()` only does `push` + `appendChild` — `parent` is never set and `link()` is never called, so any child added through `GroupView.add()` never fires `on.linked` and `View.link()` at `:303-308` (which walks `this.children`) will never reach it either. `GroupView.update()` calls `c.update()`, which is not a method on `View` at all. `TerrainController.js:131-133` adds a `LabelView` and a size control this way | UNJUSTIFIED | Delete `GroupView`; `TerrainController` uses `EmptyView.group([...], { classList: ['group'] })` (`src/view/elements/EmptyView.js:80`), which goes through `addChild` and preserves the lifecycle. If the `.group` CSS class is load-bearing, pass it in the options | Low effort / Low risk — one consumer; `GroupView` is a default export so keep a deprecation note if external users are a concern |
-| V5 | HIGH | `ScalarParameterLUTController` and `ColorParameterLUTController` are two ~400-line copies of the same LUT keyframe-marker strip | `editor/view/ecs/components/particles/ScalarParameterLUTController.js:119` `buildMarker`, `:229` local `MarkerView`, `:303` `createMarker`, `:310` `resizeMarkerPool`, `:320` `updateMarkers`, `:357` `update` · `editor/view/ecs/components/particles/ColorParameterLUTController.js:45` `buildMarker`, `:18` local `MarkerView`, `:334` `createMarker`, `:341` `resizeMarkerPool`, `:351` `updateMarkers`, `:384` `update` | Both files declare their own module-local `class MarkerView extends View`, their own `buildMarker(markers, model, update, canvas[, selection])` and their own `createMarker` / `resizeMarkerPool` / `updateMarkers` / `update` quartet. Inside `buildMarker`, the following are identical in both: the `pMarker`/`pGlobal` `PointerDevice` pair, the `dragAnchor` capture on `pGlobal.on.down`, `handleMove`'s dead-marker guard (`if (markerIndex === -1) { pMarker.stop(); pGlobal.stop(); return; }`), the `positionDelta = delta.x / canvas.width` + `clamp01(oldPosition + positionDelta)` position drag, the middle-mouse delete (`lut.positions.splice(markerIndex, 1); lut.data.splice(markerIndex * lut.itemSize, lut.itemSize);`), and the `dragStart` handler including `dragScale = lut.valueMax - lut.valueMin; if (dragScale === 0) { dragScale = 0.1; }`. `resizeMarkerPool` is byte-identical apart from the parent view (`self` vs `vGradient`). The smoking gun: **`let dragging = false;` is declared and assigned but never read in both files** (`Scalar:130`, `Color:56`) — dead code faithfully carried across the copy. Genuinely different: the value axis only (scalar Y-drag + line plot vs. colour swatch + gradient + selection) | UNJUSTIFIED | Extract `ParameterLUTMarkerStrip` (or a `buildLutMarker` + `LutMarkerPool` pair) into `editor/view/ecs/components/particles/`, owning `MarkerView`, position dragging, deletion, pool sizing and the `setFlag(WriteMode) → addValue → clearFlag(WriteMode)` insert. The two controllers supply a value-axis strategy (drag response + marker decoration + canvas draw) | Medium effort / Medium risk — pointer-drag code with no test coverage; extract in one step and exercise both panels manually |
-| V6 | MEDIUM | The generic N-numeric-field two-way-bound control already exists in the editor; three dat.gui controls re-implement it, and a fourth path exists inside `DatGuiController` | `editor/ecs/component/editors/common/makeV3_editor.js:11` `make_row_editor` (the generic version) · `src/view/controller/controls/Vector2Control.js:4` `constructor` (32–77) · `src/view/controller/controls/Vector3Control.js:4` `constructor` (35–83) · `src/view/controller/controls/NumericIntervalControl.js:4` `constructor` (33–84) · `editor/ecs/component/editors/geom/Vector1Editor.js:7` `build` · `editor/view/ecs/components/DatGuiController.js:115-154` (`add`, `isVector2 \|\| isVector3` branch) | `make_row_editor(props, value, change_signal)` is already parameterised over an arbitrary list of field names and drives `Vector2Editor` (`['x','y']`), `Vector3Editor`, `Vector4Editor` (`['x','y','z','w']`) and `QuaternionEditor`. The three `src/view/controller/controls/*` classes each hand-roll the same thing against dat.gui: `modelChanged(modelNew, modelOld)` is **byte-identical** in all three (`NumericIntervalControl.js:70`, `Vector2Control.js:63`, `Vector3Control.js:69`), as is the `modelWriteLock`/`controllerWriteLock` pair and the `this.on.linked.add(function () { model2surrogate(); }); this.model.process(modelChanged);` tail. `Vector1Editor` is `make_row_editor(['x'], v1)` written out longhand. `DatGuiController.add` contains yet another vector path via a get/set proxy and a dat.gui folder | UNJUSTIFIED | Promote `make_row_editor` out of `makeV3_editor.js` into its own module (the filename lies about its contents) and make the three `src/view/controller/controls/*` classes thin wrappers: `Vector2Control` = `['x','y']`, `Vector3Control` = `['x','y','z']`, `NumericIntervalControl` = `['min','max']` + the V2 clamp policy. Replace `Vector1Editor.build` with `make_row_editor(['x'], v1)` | Medium effort / Medium risk — the three controls render through dat.gui, so either they keep a dat.gui backend behind the shared binding logic or the widget changes appearance |
-| V7 | MEDIUM | The terrain brush's UV footprint and its UV→texel conversion are each derived independently in the base tool and both subclasses | `editor/tools/paint/TerrainPaintTool.js:117` `updateOverlay` (120–143) · `editor/tools/paint/TerrainHeightPaintTool.js:169` `paint` (178–193) + `make_mod_action` `:27` (31–41) · `editor/tools/paint/TerrainTexturePaintTool.js:93` `paint` (103–121, 145–155) | `TerrainHeightPaintTool.paint:183-193` and `TerrainTexturePaintTool.paint:111-121` contain the identical 11-line UV-rect derivation (`uv_x = brushPosition.x / terrainSize.x` … `uv_y1 = uv_y + uv_h / 2`), and `make_mod_action:31-41` and `TerrainTexturePaintTool.paint:145-155` contain the identical 8-line UV→integer-texel conversion (`h_x0 = uv_x0 * W` … `y1 = Math.floor(h_y1)`), differing only in whether `W/H` come from `samplerHeight` or `splat.size`. `TerrainPaintTool.updateOverlay:129-143` computes the *same* rect a third time in overlay space (`brushRadius = brushSize / 2`). All three must agree or the on-screen brush preview stops matching what is painted — and the base class already owns `__brushPosition`, `settings.brushSize` and `this.terrain` | UNJUSTIFIED | Two protected helpers on `TerrainPaintTool`: `computeBrushUVRect(result)` and `static uvRectToTexelRect(result, uv_rect, width, height)`. `updateOverlay` and both `paint` implementations consume them | Low effort / Low risk — pure extraction inside one class hierarchy |
-| V8 | MEDIUM | Stack-based quicksort skeleton written three times; `core/collection/array` already ships two variants, and the scratch-stack fix reached only one copy | `src/view/minimap/gl/MinimapMarkersGL.js:141` `__sortByZIndex` · `src/engine/graphics/particles/particular/engine/emitter/ParticleEmitter.js:736-792` · `src/engine/graphics/render/forward_plus/sort_decal_data.js:47` `sort_decal_data` · primitives at `src/core/collection/array/array_quick_sort_by_lookup_uint.js:11` and `array_sort_quick.js:17` | All three share the same loop skeleton down to the comments (`//Stack-based implementation, avoiding recursion for performance improvement`, `/* partition */`, `/* recursion */`, `//do swap`) and the same `pivotIndex = (left + right) >> 1`, `while (i <= j)`, `if (i !== j)` structure. The stack storage diverged: `ParticleEmitter:737` was migrated to the shared `SCRATCH_UINT32_TRAVERSAL_STACK` with a proper `stack_top` frame, `sort_decal_data:1` still uses a module-scope `_scratch_array` (non-reentrant), and `MinimapMarkersGL:151` allocates a fresh JS array on every sort. `ParticleEmitter:731` has the `particleCount <= 1` early-out; the other two do not (`array_quick_sort_by_lookup_uint:16` has it as `start >= end`) | UNJUSTIFIED | `MinimapMarkersGL.__sortByZIndex` should call `array_quick_sort_by_lookup_uint`-style shared code; because it swaps through `particles.swap(i, j)` rather than the key array, the right primitive is `array_sort_quick(data, score_function, ctx, start, end, swap_operator, swap_context)` (`array_sort_quick.js:17`), which already takes a custom `swap_operator`. The two engine copies are outside this domain but should follow | Low effort / Medium risk — `array_sort_quick` scores through a function call per comparison; measure against the current inline array read before committing (per the reuse-over-micro-opt rule, lead with the measurement) |
-| V9 | LOW | `LineView` duplicates `EmptyView.group` | `editor/view/ecs/components/common/LineView.js:6` `constructor` · `src/view/elements/EmptyView.js:80` `static group` | `LineView({elements, classList})` does `document.createElement('div')` + `addClass('ui-line-view')` + `classList.forEach(addClass)` + `elements.forEach(addChild)`. `EmptyView.group(elements, {classList, tag, css})` is the same construction with the class list supplied by the caller. The only unique content is the `'ui-line-view'` class string | UNJUSTIFIED | Replace `new LineView({elements, classList})` with `EmptyView.group(elements, { classList: ['ui-line-view', ...classList] })`; keep `LineView` as a one-line factory if the class-name convention is worth preserving | Trivial / Low risk — ~6 consumers |
-
----
-
-## Dismissed leads
-
-Shape-boilerplate families deliberately **not** flagged (house rule: typed verbose classes over registries/metaprogramming; the duplication here is in *shape*, not *logic*):
-
-- **`static from(...)` constructors across all of `generation/`** (12-way group in brief §A, `[49x12]`). Every one is `assert` + `new X()` + field assignment + `return r`. This is the package's declared idiom; collapsing it requires exactly the string-keyed factory the owner has ruled out.
-- **`initialize`/`execute` fan-out loops in the sequence/group nodes** — `MarkerNodeActionSequence.js:25/36`, `MarkerNodeEntityProcessorSequence.js:38/50`, `MarkerNodeTransformerSequence.js:19/29`, `MarkerNodeEmitterGroup.js:26/37`, `MarkerNodeEmitterFromAction.js:33`, `GridCellActionSequence.js:31/43`, `CellProcessingRuleSet.js:23`, `CellMatcherGridPattern.js:26`. Read them all: each is a bare `for` loop forwarding a *different* method signature on a *different* type hierarchy (`(grid,ecd,seed)`, `(data,seed)`, `(entity,node,data,ecd)`, `(data,x,y,rotation,consumer)`). There is no shared logic to extract without erasing the types.
-- **Boolean combinators `CellMatcherAnd/Or`, `MarkerNodeMatcherAnd/Or`, `GridDataNodePredicateAnd/Any`, `MarkerNodeMatcherAny/None`.** Answer to the "two matcher hierarchies?" question: there are *three*, and they are over genuinely different domains — `CellMatcher.match(grid,x,y,rotation)`, `MarkerNodeMatcher.match(node)` (no grid, no initialize), `GridDataNodePredicate.evaluate(grid,node)`. Only the `CellMatcher`/boolean-`CellFilter` overlap is a real domain collision, and that is reported as **G8**.
-- **`filtering/numeric/math/**` arithmetic nodes** (`Add`/`Subtract`/`Multiply`/`Divide`/`Negate`/`Max2`/`Min2`/`Clamp`/`SmoothStep`/`Lerp`/`InverseLerp`/`Saturate`/`OneMinus`/`Absolute`/`Step`). Checked every one: they all correctly delegate to `core/math` (`max2`, `min2`, `clamp`, `smoothStep`, `lerp`, `inverseLerp`) and carry no inline math. The only real defect in the family is `CellFilterPower` (**G7**). The `dataType`/`assert` preamble repetition is shape.
-- **`theme/TerrainLayerRule.js:25 from`, `theme/cell/CellProcessingRule.js:22 from`, `theme/cell/CellProcessingRuleSet.js:23 initialize`.** Opened all three — two-field assignment and a forwarding loop. Shape.
-- **Neighbour-mask iteration bodies** (`buildDistanceMapToObjective.js:51-75`, `buildPathFromDistanceMap.js:35-61`, `GridTaskConnectRooms.js:181-201` and `:252-272`, `GridTaskGenerateRoads.js:249-269`). The index→(x,y) decode + mask loop + double bounds check is repeated five times, but each body diverges *inside* the loop (flood-fill push, open-set seeding, distance relaxation, best-successor pick, path-network probe with a labelled `continue neighbourhood_loop`). A callback iterator would allocate a closure per cell in the hottest code in the package. **JUSTIFIED** — the shareable part is the mask constants only (**G5**).
-- **`CaveGeneratorCellularAutomata.step`** — single implementation, hand-unrolled 8-neighbour sum with hoisted row bases and validity flags. Hot inner loop, no second copy. Correct as written.
-- **`GridData.js:75 getLayerById`** — a 10-line linear scan over `layers` (typically < 10 entries) called from `initialize` paths only. `AbstractCellFilterSampleGridLayer.js:31` and `GridTaskBuildSourceDistanceMap.js:85` both call it rather than re-deriving it. Nothing to share.
-- **`GridTaskGenerateRoads.js:29 findMarkerNodeByPosition` vs `CellMatcherGridPattern.js:64 getRuleByPosition`** (brief §C, sim 0.891) — both linear `position.x/y` scans, ~10 lines, over unrelated element types in unrelated modules. Below the bar.
-- **`RoadConnection.js:79 test`** (brief §A, paired with `AnimationClipDefinition.hasTag`) — a 10-line `indexOf`-equivalent on a `number[]`. Below the bar.
-- **`core/parser/simple/readReferenceToken.js` vs `view/tooltip/gml/parser/readReferenceToken.js`** (brief §G) — read both: **not a fork.** The core one reads a dotted identifier path (`a.b.c`) into a `Token` list; the view one parses a bracketed tooltip reference `[tag: k=v, k=v]` with its own `ParserError` messages and `TooltipReferenceValue` payload. Name collision only; the view one already reuses `skipWhitespace`, `Token` and `ParserError` from core.
-- **`view/minimap/dom/MinimapCameraView.js:110-112` raw `Math.random()`** (brief §F) — checked for a seeded-RNG bypass: it is a single site, not duplication, so no row. Worth passing to whoever owns determinism, though: the jitter is accumulated into `oX/oY/oZ` (`:99-101`) while the retry at `:106` re-raycasts with the original `originX/originY/originZ`, so the whole jitter loop is inert.
-- **`editor/actions/concrete/Selection{Add,Remove,Clear}Action`, `Component{Add,Remove}Action`, `Entity{Create,Remove}Action`** — opened all six. The shared part is two lines (`this.oldState = editor.selection.clone()` / `revert: editor.selection.copy(this.oldState)`); everything else is per-action. Typed undo commands are exactly the shape the owner prefers.
-- **`editor/process/symbolic/make*SymbolicDisplay.js`** (11 files) — checked `make3DSymbolicDisplay.js`, `makeCameraSymbolicDisplay.js`, `makePositionedIconDisplaySymbol.js`: already correctly factored through `make3DSymbolicDisplay` + `buildThreeJSHelperEntity` + `synchronizeTransform`. Good reuse; nothing to report.
-- **`editor/view/ecs/components/common/AutoCanvasView.js`** — properly `extends CanvasView` and reuses `DomSizeObserver`. Good reuse.
-- **`HTMLElementCacheKey.js:122 #getAttributeContainer`** vs `AttributeGroupSpec.getAttributeByName` / `ParticleSpecification.getByName` (brief §A/§C) — three unrelated 10-line "linear scan by `.name`" loops on three different record types in three different subsystems. Below the bar.
-- **`view/controller/controls/*` importing `editor/view/ecs/components/DatGuiController.js`** — `src/` depending on `editor/` is a layering inversion, but it is not duplication; noted here so it isn't mistaken for an oversight.
-- **Seed derivation for child nodes** — `MarkerNodeActionSequence.js:32` and `MarkerNodeActionSelectWeighted.js:50` decorrelate children with `seed + i`; `MarkerNodeEntityProcessorSequence.js:45`, `GridCellActionSequence.js:39`, `MarkerNodeEmitterGroup.js:33` and `MarkerNodeTransformerSequence.js:25` pass `seed` unchanged. Only two sites use the `+ i` form, so this is a convention gap rather than duplication — but it is the same class of hazard as G1 and should be settled once (`randomSeed(random)` per child, as `TerrainTheme.js:30` and `ThemeEngine.js:215` already do).
-
----
-
-## Notes — why duplication accumulates here
-
-1. **Four parallel node hierarchies over one grid.** `CellFilter` (`grid,x,y,rot → number`), `CellMatcher` (`… → bool`), `GridCellAction` (`grid,x,y,rot → void`) and `MarkerNodeAction`/`MarkerNodeTransformer`/`MarkerNodeEmitter` (`grid,ecd,node`) all model "do something at a place on the grid" with different arity. The typed-classes-over-magic rule makes that a deliberate design, and it means every *combinator* (sequence, weighted-select, and/or/not, displaced-by-offset) gets written once per hierarchy. That is accepted. What is **not** accepted, and what every generation finding above has in common, is the *scalar math and search algorithms* getting copied along with the combinator shape — the rotation formula (G2), the CDF walk (G3), the Sobel taps (G4), the BFS (G1). The dividing line is: forwarding loops are shape, arithmetic and search are logic.
-
-2. **`markers/` and `placement/` are not superseding each other.** Both have live spec coverage and both are reachable from `ThemeEngine`; `GridCellActionPlaceMarker` (in `markers/`) even extends `GridCellAction` (in `placement/`), so the two are interleaved by design — `placement/` operates on cells and *emits* markers, `markers/` operates on the emitted nodes. There is no dead branch to delete; the duplication is confined to the two combinators reported in G3.
-
-3. **The reuse surface exists but is not discoverable from `generation/`.** `ORTHOGONAL_NEIGHBOURHOOD_MASK` has zero importers while two classes redeclare it; there is no `v2_rotate` at all despite eight callers; `computeCellFilterGradient` sits in the same package as `CellFilterSobel` and is still not used by it. The pattern is "write it where you need it, in the file you already have open".
-
-4. **`src/view` and `editor/` are mutually entangled rather than layered.** `src/view/controller/controls/*` imports `editor/view/ecs/components/DatGuiController.js`; `editor/*` imports `src/view/*` everywhere. Because there is no single owner of "widget", the same widget gets built on whichever side the author happened to be working — hence three numeric-interval editors (V2), four vector editors (V6), and a `LineView` that duplicates `EmptyView.group` (V9).
-
-5. **Two generations of infrastructure coexist, and only some call sites were migrated.** `ImmutableObjectPool` vs the older `Cache`-of-arrays (V1), `SCRATCH_UINT32_TRAVERSAL_STACK` vs per-call arrays (V8), `View.addChild` vs `GroupView.add` (V4), the `inOpen` BitSet mirror vs `Uint32Heap.insert_or_update` (G1). In every case the migration was applied to one copy and the sibling was never found — which is precisely the failure mode that makes duplication expensive rather than merely verbose.
+# Domain I — generation + view + editor
+
+Scope: `meep/src/generation/**`, `meep/src/view/**`, `meep/editor/**`.
+Every row below was verified by opening the cited files. `*.spec.js`, `prototype*.js`, `test*.js` excluded.
+
+---
+
+## Findings — generation
+
+| # | Severity | Concept | Sites | Evidence | Verdict | Proposed common path | Effort/Risk |
+|---|---|---|---|---|---|---|---|
+| G1 | HIGH | Uniform-cost grid BFS/Dijkstra (open heap + `closed` BitSet + distance relaxation) written three times; the `inOpen` membership-mirror optimisation landed in only two of them | `src/generation/grid/generation/util/buildDistanceMapToObjective.js:15` `buildDistanceMapToObjective` (relax 85–92) · `src/generation/grid/generation/discrete/layer/GridTaskBuildSourceDistanceMap.js:66` `build` (heap 93, `inOpen` 107, `processNeighbor` 145, expansion 193–208) · `src/generation/grid/generation/road/GridTaskGenerateRoads.js:104` `buildPaths` (heap 121, `inOpen` 129, relax 282–297) | The JSDoc comment *"membership mirror of the open heap, O(1) replacement for linear heap.contains scans"* appears **verbatim** at `GridTaskBuildSourceDistanceMap.js:104` and `GridTaskGenerateRoads.js:126` — a copy-paste of a performance fix. `buildDistanceMapToObjective` never received it; it dodges the problem with a different heap (`Uint32Heap.insert_or_update`) instead. Three different heap types (`Uint32Heap`, `BinaryHeap`, `BinaryHeap`), three different relaxation shapes, one algorithm. `GridTaskBuildSourceDistanceMap` additionally hardcodes the 4-neighbourhood as index arithmetic (`±1`, `±width`) instead of a mask, so it silently cannot be switched to 8-way | UNJUSTIFIED | One `grid_build_distance_field({distances, open, closed, grid, neighbourhoodMask, traversable, onVisit})` in `generation/grid/generation/util/`, built on `Uint32Heap` (which already has `insert_or_update`, removing the need for the mirror entirely). `buildDistanceMapToObjective` becomes a thin `onVisit` wrapper; the road builder passes its heuristic-free variant | Medium effort / Medium risk — three call sites with different early-exit semantics; needs a generation-output regression test |
+| G2 | MEDIUM | 2D rotation of a local offset by `rotation` radians, inlined 8× — `core/geom/vec2/` has **no** `v2_rotate` | `src/generation/filtering/numeric/util/CellFilterDisplaced.js:33-40` `execute` · `src/generation/markers/GridActionRuleSet.js:176-180` `process` · `src/generation/markers/GridCellActionPlaceMarker.js:156-167` `buildBaseNode` · `src/generation/markers/transform/MarkerNodeTransformerOffsetPosition.js:34-41` `transform` · `src/generation/placement/action/GridCellActionPlaceTags.js:87-103` `execute` · `src/generation/placement/action/util/GridCellDisplacedAction.js:41-48` `execute` · `src/generation/placement/GridCellPlacementRule.js:104-113` `execute` · `src/generation/rules/cell/CellMatcherGridPattern.js:94-107` `match` | Byte-identical four-line body at all 8 sites (`const sin = Math.sin(rotation); const cos = Math.cos(rotation); const rotated_local_x = local_x * cos - local_y * sin` / `..._y = local_x * sin + local_y * cos;`) — even the missing semicolon after `* sin` is reproduced everywhere. `core/geom/vec2/` contains only `v2_matrix3_cm_multiply`/`_rm_multiply`; there is no rotate-by-angle primitive. Downstream handling then diverges: `CellMatcherGridPattern:109` and `GridCellActionPlaceTags:106` `Math.round` the result, the other six do not | PROMOTION | `core/geom/vec2/v2_rotate.js` — `v2_rotate(result, result_offset, x, y, angle)` (result-first, matching the house convention), plus `v2_rotate_cos_sin` for the `GridActionRuleSet` loop that rotates many offsets by the same angle. Note in JSDoc that callers own the rounding decision | Low effort / Low risk — pure extraction, no behaviour change |
+| G3 | MEDIUM | Weighted random selection over `CellFilter` weights implemented three times, one bypassing `random_pick_weighted_index` with a different prefix-sum convention | `src/generation/markers/actions/probability/MarkerNodeActionSelectWeighted.js:56` `execute` · `src/generation/placement/action/random/weighted/CellActionSelectWeightedRandom.js:78` `execute` · `src/generation/theme/ThemeEngine.js:411` `applyNodes` (454–485) | Sites 1 and 2 are the same 30-line body — module-scope `evaluatedWeights` array, `weightFilter.execute(...)`, `if (weightValue > 0) totalWeight += weightValue`, identical `//if the weight is negative, we clamp it to 0` comment, `random_pick_weighted_index(...)`, identical `index === -1` early-out. Only the position source differs (`node.position.x/y` vs `x,y`). Site 3 hand-rolls the same selection with an **exclusive** prefix sum (`themeInfluence[j] = influenceSum;` *before* `influenceSum += influence`, line 469–471) and `binarySearchLowIndex`, where the core primitive uses an **inclusive** prefix sum and `binarySearchHighIndex`. Both are individually correct, but the two conventions cannot be swapped, so a fix to one never transfers | UNJUSTIFIED | Extract `cell_filter_weights_pick(random, weightedElements, grid, x, y)` in `generation/filtering/` returning the picked index (owning the CDF scratch, the negative-weight clamp and the `-1` contract). Sites 1 and 2 call it; site 3 switches to `random_pick_weighted_index` with the inclusive convention | Low effort / Low risk — three specs already exist |
+| G4 | MEDIUM | Sobel 3×3 tap + gradient magnitude duplicated verbatim; the shared helper already exists next door and is not used | `src/generation/filtering/numeric/complex/CellFilterSobel.js:35` `execute` (39–55) · `src/generation/filtering/numeric/process/computeCellFilterGradient.js:12` `computeCellFilterGradient` (15–31) | Lines 39–55 of `CellFilterSobel.execute` and lines 15–31 of `computeCellFilterGradient` are identical character-for-character including the `//read surrounding points`, `// compute gradients` and `//normalize vector` comments and the `2.0 *` literals. `CellFilterSobel` keeps the magnitude and discards the direction; `computeCellFilterGradient` keeps the direction and discards the magnitude. The sibling family got this right: `CellFilterCurvature` and `CellFilterAngleToNormal` both delegate to `process/computeFilterSurfaceNormal.js` | UNJUSTIFIED | Add `generation/filtering/numeric/process/computeCellFilterSobel.js` writing raw `dX, dY` into a `result` pair. `CellFilterSobel.execute` returns `v2_length(dX, dY)`; `computeCellFilterGradient` divides by it. Both `Math.sqrt(dX*dX + dY*dY)` sites also bypass `core/geom/vec2/v2_length` | Low effort / Low risk |
+| G5 | MEDIUM | The 4-way and 8-way grid neighbourhood masks are re-declared per class, while `ORTHOGONAL_NEIGHBOURHOOD_MASK` exists with zero importers and one copy is dead | `src/engine/grid/ORTHOGONAL_NEIGHBOURHOOD_MASK.js:6` · `src/generation/grid/generation/discrete/GridTaskConnectRooms.js:44` `neighbourhoodSearchMask` and `:57` `neighbourhoodDrawMask` · `src/generation/grid/generation/road/GridTaskGenerateRoads.js:456` `neighbourhoodSearchMask` and `:469` `neighbourhoodDrawMask` | The two `neighbourhoodSearchMask` fields are element-for-element `[0,-1, -1,0, 1,0, 0,1]` — identical to `ORTHOGONAL_NEIGHBOURHOOD_MASK`, which a repo-wide grep shows has **no importer at all**. The two `neighbourhoodDrawMask` fields hold the same 8 offsets in different orders (`ConnectRooms`: `-1,-1 / 0,-1 / 1,-1 …`; `GenerateRoads`: `-1,-1 / 1,-1 / 0,-1 …`) — and `GridTaskGenerateRoads.neighbourhoodDrawMask` is **never read** (grep: only the declaration), i.e. it is a stale copy carried over from `GridTaskConnectRooms` | UNJUSTIFIED (constants only — see Dismissed for the loop bodies) | Import `ORTHOGONAL_NEIGHBOURHOOD_MASK` for the 4-way case and add a sibling `MOORE_NEIGHBOURHOOD_MASK` next to it for the 8-way case; delete the dead `neighbourhoodDrawMask` on `GridTaskGenerateRoads`. Keep them as per-instance overridable fields defaulting to the shared constants | Low effort / Low risk |
+| G6 | MEDIUM | Rasterising a `CellFilter` into a `Sampler2D` at a scale is written twice | `src/generation/filtering/numeric/CellFilterCache.js:37` `initialize` (55–68) · `src/generation/filtering/numeric/util/populateSampler2DFromCellFilter.js:9` `populateSampler2DFromCellFilter` (17–35) | Same nested `for y / for x`, same `grid_x`/`grid_y` scale division, same `writeChannel(x, y, 0, v)`. Only the scale is expressed differently (`1/this.scale` vs `result.width / grid.width` — algebraically the same when the sampler is `scale ×` the grid). `populateSampler2DFromCellFilter` also carries the `generation/COORDINATES.md` ratio-mapping comment that `CellFilterCache` lacks, so the two would silently drift if that convention were ever revised | UNJUSTIFIED | Split the loop out of `populateSampler2DFromCellFilter` into `write_cell_filter_to_sampler2d(result, filter, grid)` (no `ensureInitialized` inside — the seed-0 initialise at `populateSampler2DFromCellFilter.js:14` is what currently blocks direct reuse); both callers use it | Low effort / Low risk |
+| G7 | LOW | `CellFilterPower` re-derives the base class's two-child evaluation instead of implementing `operation()` | `src/generation/filtering/numeric/math/CellFilterPower.js:28` `execute` · base at `src/generation/filtering/core/CellFilterBinaryOperation.js:31` `execute` | All 8 other `CellFilterBinaryOperation` subclasses (`Add`/`Subtract`/`Multiply`/`Divide`/`Max2`/`Min2`/`Step`/`And`) implement `operation(left, right)`; `CellFilterPower` alone overrides `execute` with a hand-copied `this.left.execute(...)` / `this.right.execute(...)` pair. Any future change to the base `execute` (memoisation, assertions, a rotation-propagation fix) silently skips this one node | UNJUSTIFIED | Replace the `execute` override with `operation(value, power) { return Math.pow(value, power); }` and add the `get dataType()` the sibling algebra nodes carry | Trivial / Trivial |
+| G8 | LOW | Two boolean algebras over the *identical* `(grid, x, y, rotation) → bool` domain, joined by adapters in both directions | `src/generation/rules/logic/CellMatcherAnd.js:6` `match` · `src/generation/filtering/boolean/logic/CellFilterAnd.js:30` `operation` · adapters `src/generation/filtering/CellFilterCellMatcher.js:41` `execute` and `src/generation/rules/CellMatcherFromFilter.js:28` `match` | `CellFilterAnd` is boolean-typed (`dataType === DataType.Boolean`) over the same signature `CellMatcher` already covers, and the `CellFilterCellMatcher`/`CellMatcherFromFilter` pair converts freely between the two, so `CellFilterAnd.from(a, b)` is expressible as `CellFilterCellMatcher.from(CellMatcherAnd.from(CellMatcherFromFilter.from(a), CellMatcherFromFilter.from(b)))`. `CellFilterAnd` is the *only* member of the boolean-filter branch (`filtering/boolean/logic/` has one file) and has no non-spec consumer, whereas the `CellMatcher` side is complete (`And`/`Or`/`Not`/`Any`/`Decorator`) and is what every grid task uses | UNJUSTIFIED (documentation-level) | Do not delete (public library surface, house rule). Add a JSDoc note on `CellFilterAnd` naming `CellMatcherAnd` as the canonical boolean combinator and the adapters as the bridge, so nobody grows a parallel `CellFilterOr`/`CellFilterNot` branch | Trivial / Trivial |
+
+---
+
+## Findings — view + editor
+
+| # | Severity | Concept | Sites | Evidence | Verdict | Proposed common path | Effort/Risk |
+|---|---|---|---|---|---|---|---|
+| V1 | HIGH | `ImageView` and `VideoView` are the same pooled media element view; the pooling backend was upgraded in one and left behind in the other | `src/view/elements/image/ImageView.js:52` `constructor`, `:108` `destroy`, `:128` `__setSize`, `:138` `__setSource` · `src/view/elements/video/VideoView.js:66` `constructor`, `:120` `destroy`, `:146` `__setSize`, `:156` `__setSource` | Constructors are identical from the `src` resolution through cache-key construction, attribute copying, `pool.release(cacheKey)`, the `classList` loop and `this.size.onChanged.add(this.__setSize, this)`; `__setSize` and `__setSource` are byte-identical. The only intended difference is the tag (`'img'` vs `"video"`). Two unintended divergences: (a) `ImageView` uses `ImmutableObjectPool` (`:24-27`) and releases correctly (`:114-118` `if (!added) pool.release(key)`), while `VideoView` still uses a hand-rolled `Cache` of element arrays (`:14-18`, `:38-57`) whose `destroy` at `:132` only releases the pooled key inside `else if (elements.length < 100)` — once a bucket is full, neither the element nor the pooled `HTMLElementCacheKey` is returned; (b) `ImageView:61` null-guards the `url` argument (`src = ''`), `VideoView:75` does not, so a null URL yields `src="undefined"` | UNJUSTIFIED | `MediaElementView` base under `src/view/elements/` owning the constructor, `destroy`, `__setSize`, `__setSource` and the `ImmutableObjectPool`, parameterised by tag. `ImageView`/`VideoView` become `super('img')` / `super('video')` shells (both are public exports, so keep the class names and the `isVideoView` marker) | Low effort / Medium risk — `VideoView` gains `ImmutableObjectPool` semantics; check nothing depends on the video element surviving in the `Cache` |
+| V2 | HIGH | The `NumericInterval` min ≤ max invariant is enforced three different ways in three different interval editors | `src/view/controller/controls/NumericIntervalControl.js:33` `surrogate2model` (42–48) · `editor/view/ecs/components/common/NumericIntervalController.js:44` and `:54` (write handlers) · `editor/ecs/component/editors/NumericIntervalEditor.js:42` `sync_down` (53–59) and `:72` `validate` | Three incompatible behaviours for the same invariant. (1) collapses the interval — `if (min > max) { maxController.setValue(min); interval.set(min, min); }`. (2) widens — `interval.set(v, max2(v, vMax…))` / `interval.set(min2(v, vMin…), v)`. (3) refuses the write — `if (v0 <= v1) interval.set(v0, v1)` — plus a `blur` listener that restores the old value. Editing "min" past "max" therefore does three different things depending on which panel you opened. (2) and (3) even build the same widget from the same `NumberController`, differing only in layout and the clamp rule | UNJUSTIFIED | One `NumericIntervalController` (the `editor/view/ecs/components/common/` one, already `NumberController`-based) owning a single documented clamp policy; `NumericIntervalEditor.build` returns it, and the dat.gui `NumericIntervalControl` either wraps it or is dropped in favour of it. Whichever policy is chosen must be stated in JSDoc on `NumericInterval` itself | Medium effort / Medium risk — user-visible behaviour change in two of the three panels; pick the policy deliberately |
+| V3 | HIGH | Two-way "model ↔ widget" sync with a re-entrancy lock is hand-rolled in eight editors, half of them without the lock; `FieldValueAdapter` already exists as the seam that would collapse the `Observed*Editor` family into the `primitive/*Editor` family | `editor/ecs/component/editors/ObservedIntegerEditor.js:6` `build` vs `editor/ecs/component/editors/primitive/NumberEditor.js:6` `build` · `editor/ecs/component/editors/ObservedStringEditor.js:6` `build` vs `editor/ecs/component/editors/primitive/StringEditor.js:6` `build` · `editor/ecs/component/editors/ObservedBooleanEditor.js:5` `build` vs `editor/ecs/component/editors/primitive/BooleanEditor.js:6` `build` · also `editor/ecs/component/editors/geom/Vector1Editor.js:20-47`, `editor/ecs/component/editors/geom/QuaternionEditor.js:19-59`, `editor/ecs/component/editors/common/makeV3_editor.js:35-66`, `editor/ecs/component/editors/NumericIntervalEditor.js:27-62` | Every one of these is the same shape: `let lock = false;` + `sync_up()` (model → widget) + `sync_down()` (widget → model), each opening with `if (lock) { return; } lock = true;` and closing with `lock = false;`, wired as `ctrl.on.linked.add(sync_up); ctrl.value.onChanged.add(sync_down); ctrl.bindSignal(<model>.onChanged, sync_up);`. The Observed↔primitive pairs differ *only* in how the value is read and written (`instance.getValue()`/`instance.set()` + `bindSignal(instance.onChanged, …)` versus `field.adapter.read(parent, field.name)`/`.write(…)` with no change signal) — and the guard is present in `ObservedIntegerEditor`/`ObservedStringEditor`/`NumberEditor` but absent in `StringEditor` and `BooleanEditor`, so the protocol is not even applied consistently. `editor/ecs/component/FieldValueAdapter.js:3` is already the abstraction for "read/write a field on a parent"; it just lacks an observed variant that also exposes a change signal | UNJUSTIFIED | Add `ObservedFieldValueAdapter extends FieldValueAdapter` (read/write via `getValue`/`set`, plus a `change_signal(object, field_name)` accessor returning `onChanged` or `Signal.NONE`), then delete `ObservedBooleanEditor`/`ObservedIntegerEditor`/`ObservedStringEditor` and register the `primitive/` editors for those types. Hoist the lock+sync wiring into a single `bind_two_way(view, read, write, change_signal)` helper used by every remaining editor | Medium effort / Medium risk — touches the type registry; the `Observed*` classes are internal to the editor so removal is safe, but registration order must be checked |
+| V4 | HIGH | `GroupView` re-implements `View`'s child list, bypassing the link/unlink lifecycle | `src/view/elements/Group.js:3` `GroupView` — `this.children = []` at `:9`, `add(view)` at `:11`, `remove(view)` at `:17`, `update()` at `:25` · base at `src/view/View.js:107` `children`, `:365` `addChild`, `:433` `removeChild` · sole consumer `editor/view/ecs/components/TerrainController.js:131-133` | `View` already declares `children = []` (`View.js:107`), and `View.addChild` (`:365`) does four things: asserts the child is not already linked, sets `child.parent = this`, calls `child.link()` when the parent is linked, then pushes and appends. `GroupView` shadows the same `children` field with its own array and its `add()` only does `push` + `appendChild` — `parent` is never set and `link()` is never called, so any child added through `GroupView.add()` never fires `on.linked` and `View.link()` at `:303-308` (which walks `this.children`) will never reach it either. `GroupView.update()` calls `c.update()`, which is not a method on `View` at all. `TerrainController.js:131-133` adds a `LabelView` and a size control this way | UNJUSTIFIED | Delete `GroupView`; `TerrainController` uses `EmptyView.group([...], { classList: ['group'] })` (`src/view/elements/EmptyView.js:80`), which goes through `addChild` and preserves the lifecycle. If the `.group` CSS class is load-bearing, pass it in the options | Low effort / Low risk — one consumer; `GroupView` is a default export so keep a deprecation note if external users are a concern |
+| V5 | HIGH | `ScalarParameterLUTController` and `ColorParameterLUTController` are two ~400-line copies of the same LUT keyframe-marker strip | `editor/view/ecs/components/particles/ScalarParameterLUTController.js:119` `buildMarker`, `:229` local `MarkerView`, `:303` `createMarker`, `:310` `resizeMarkerPool`, `:320` `updateMarkers`, `:357` `update` · `editor/view/ecs/components/particles/ColorParameterLUTController.js:45` `buildMarker`, `:18` local `MarkerView`, `:334` `createMarker`, `:341` `resizeMarkerPool`, `:351` `updateMarkers`, `:384` `update` | Both files declare their own module-local `class MarkerView extends View`, their own `buildMarker(markers, model, update, canvas[, selection])` and their own `createMarker` / `resizeMarkerPool` / `updateMarkers` / `update` quartet. Inside `buildMarker`, the following are identical in both: the `pMarker`/`pGlobal` `PointerDevice` pair, the `dragAnchor` capture on `pGlobal.on.down`, `handleMove`'s dead-marker guard (`if (markerIndex === -1) { pMarker.stop(); pGlobal.stop(); return; }`), the `positionDelta = delta.x / canvas.width` + `clamp01(oldPosition + positionDelta)` position drag, the middle-mouse delete (`lut.positions.splice(markerIndex, 1); lut.data.splice(markerIndex * lut.itemSize, lut.itemSize);`), and the `dragStart` handler including `dragScale = lut.valueMax - lut.valueMin; if (dragScale === 0) { dragScale = 0.1; }`. `resizeMarkerPool` is byte-identical apart from the parent view (`self` vs `vGradient`). The smoking gun: **`let dragging = false;` is declared and assigned but never read in both files** (`Scalar:130`, `Color:56`) — dead code faithfully carried across the copy. Genuinely different: the value axis only (scalar Y-drag + line plot vs. colour swatch + gradient + selection) | UNJUSTIFIED | Extract `ParameterLUTMarkerStrip` (or a `buildLutMarker` + `LutMarkerPool` pair) into `editor/view/ecs/components/particles/`, owning `MarkerView`, position dragging, deletion, pool sizing and the `setFlag(WriteMode) → addValue → clearFlag(WriteMode)` insert. The two controllers supply a value-axis strategy (drag response + marker decoration + canvas draw) | Medium effort / Medium risk — pointer-drag code with no test coverage; extract in one step and exercise both panels manually |
+| V6 | MEDIUM | The generic N-numeric-field two-way-bound control already exists in the editor; three dat.gui controls re-implement it, and a fourth path exists inside `DatGuiController` | `editor/ecs/component/editors/common/makeV3_editor.js:11` `make_row_editor` (the generic version) · `src/view/controller/controls/Vector2Control.js:4` `constructor` (32–77) · `src/view/controller/controls/Vector3Control.js:4` `constructor` (35–83) · `src/view/controller/controls/NumericIntervalControl.js:4` `constructor` (33–84) · `editor/ecs/component/editors/geom/Vector1Editor.js:7` `build` · `editor/view/ecs/components/DatGuiController.js:115-154` (`add`, `isVector2 \|\| isVector3` branch) | `make_row_editor(props, value, change_signal)` is already parameterised over an arbitrary list of field names and drives `Vector2Editor` (`['x','y']`), `Vector3Editor`, `Vector4Editor` (`['x','y','z','w']`) and `QuaternionEditor`. The three `src/view/controller/controls/*` classes each hand-roll the same thing against dat.gui: `modelChanged(modelNew, modelOld)` is **byte-identical** in all three (`NumericIntervalControl.js:70`, `Vector2Control.js:63`, `Vector3Control.js:69`), as is the `modelWriteLock`/`controllerWriteLock` pair and the `this.on.linked.add(function () { model2surrogate(); }); this.model.process(modelChanged);` tail. `Vector1Editor` is `make_row_editor(['x'], v1)` written out longhand. `DatGuiController.add` contains yet another vector path via a get/set proxy and a dat.gui folder | UNJUSTIFIED | Promote `make_row_editor` out of `makeV3_editor.js` into its own module (the filename lies about its contents) and make the three `src/view/controller/controls/*` classes thin wrappers: `Vector2Control` = `['x','y']`, `Vector3Control` = `['x','y','z']`, `NumericIntervalControl` = `['min','max']` + the V2 clamp policy. Replace `Vector1Editor.build` with `make_row_editor(['x'], v1)` | Medium effort / Medium risk — the three controls render through dat.gui, so either they keep a dat.gui backend behind the shared binding logic or the widget changes appearance |
+| V7 | MEDIUM | The terrain brush's UV footprint and its UV→texel conversion are each derived independently in the base tool and both subclasses | `editor/tools/paint/TerrainPaintTool.js:117` `updateOverlay` (120–143) · `editor/tools/paint/TerrainHeightPaintTool.js:169` `paint` (178–193) + `make_mod_action` `:27` (31–41) · `editor/tools/paint/TerrainTexturePaintTool.js:93` `paint` (103–121, 145–155) | `TerrainHeightPaintTool.paint:183-193` and `TerrainTexturePaintTool.paint:111-121` contain the identical 11-line UV-rect derivation (`uv_x = brushPosition.x / terrainSize.x` … `uv_y1 = uv_y + uv_h / 2`), and `make_mod_action:31-41` and `TerrainTexturePaintTool.paint:145-155` contain the identical 8-line UV→integer-texel conversion (`h_x0 = uv_x0 * W` … `y1 = Math.floor(h_y1)`), differing only in whether `W/H` come from `samplerHeight` or `splat.size`. `TerrainPaintTool.updateOverlay:129-143` computes the *same* rect a third time in overlay space (`brushRadius = brushSize / 2`). All three must agree or the on-screen brush preview stops matching what is painted — and the base class already owns `__brushPosition`, `settings.brushSize` and `this.terrain` | UNJUSTIFIED | Two protected helpers on `TerrainPaintTool`: `computeBrushUVRect(result)` and `static uvRectToTexelRect(result, uv_rect, width, height)`. `updateOverlay` and both `paint` implementations consume them | Low effort / Low risk — pure extraction inside one class hierarchy |
+| V8 | MEDIUM | Stack-based quicksort skeleton written three times; `core/collection/array` already ships two variants, and the scratch-stack fix reached only one copy | `src/view/minimap/gl/MinimapMarkersGL.js:141` `__sortByZIndex` · `src/engine/graphics/particles/particular/engine/emitter/ParticleEmitter.js:736-792` · `src/engine/graphics/render/forward_plus/sort_decal_data.js:47` `sort_decal_data` · primitives at `src/core/collection/array/array_quick_sort_by_lookup_uint.js:11` and `array_sort_quick.js:17` | All three share the same loop skeleton down to the comments (`//Stack-based implementation, avoiding recursion for performance improvement`, `/* partition */`, `/* recursion */`, `//do swap`) and the same `pivotIndex = (left + right) >> 1`, `while (i <= j)`, `if (i !== j)` structure. The stack storage diverged: `ParticleEmitter:737` was migrated to the shared `SCRATCH_UINT32_TRAVERSAL_STACK` with a proper `stack_top` frame, `sort_decal_data:1` still uses a module-scope `_scratch_array` (non-reentrant), and `MinimapMarkersGL:151` allocates a fresh JS array on every sort. `ParticleEmitter:731` has the `particleCount <= 1` early-out; the other two do not (`array_quick_sort_by_lookup_uint:16` has it as `start >= end`) | UNJUSTIFIED | `MinimapMarkersGL.__sortByZIndex` should call `array_quick_sort_by_lookup_uint`-style shared code; because it swaps through `particles.swap(i, j)` rather than the key array, the right primitive is `array_sort_quick(data, score_function, ctx, start, end, swap_operator, swap_context)` (`array_sort_quick.js:17`), which already takes a custom `swap_operator`. The two engine copies are outside this domain but should follow | Low effort / Medium risk — `array_sort_quick` scores through a function call per comparison; measure against the current inline array read before committing (per the reuse-over-micro-opt rule, lead with the measurement) |
+| V9 | LOW | `LineView` duplicates `EmptyView.group` | `editor/view/ecs/components/common/LineView.js:6` `constructor` · `src/view/elements/EmptyView.js:80` `static group` | `LineView({elements, classList})` does `document.createElement('div')` + `addClass('ui-line-view')` + `classList.forEach(addClass)` + `elements.forEach(addChild)`. `EmptyView.group(elements, {classList, tag, css})` is the same construction with the class list supplied by the caller. The only unique content is the `'ui-line-view'` class string | UNJUSTIFIED | Replace `new LineView({elements, classList})` with `EmptyView.group(elements, { classList: ['ui-line-view', ...classList] })`; keep `LineView` as a one-line factory if the class-name convention is worth preserving | Trivial / Low risk — ~6 consumers |
+
+---
+
+## Dismissed leads
+
+Shape-boilerplate families deliberately **not** flagged (house rule: typed verbose classes over registries/metaprogramming; the duplication here is in *shape*, not *logic*):
+
+- **`static from(...)` constructors across all of `generation/`** (12-way group in brief §A, `[49x12]`). Every one is `assert` + `new X()` + field assignment + `return r`. This is the package's declared idiom; collapsing it requires exactly the string-keyed factory the owner has ruled out.
+- **`initialize`/`execute` fan-out loops in the sequence/group nodes** — `MarkerNodeActionSequence.js:25/36`, `MarkerNodeEntityProcessorSequence.js:38/50`, `MarkerNodeTransformerSequence.js:19/29`, `MarkerNodeEmitterGroup.js:26/37`, `MarkerNodeEmitterFromAction.js:33`, `GridCellActionSequence.js:31/43`, `CellProcessingRuleSet.js:23`, `CellMatcherGridPattern.js:26`. Read them all: each is a bare `for` loop forwarding a *different* method signature on a *different* type hierarchy (`(grid,ecd,seed)`, `(data,seed)`, `(entity,node,data,ecd)`, `(data,x,y,rotation,consumer)`). There is no shared logic to extract without erasing the types.
+- **Boolean combinators `CellMatcherAnd/Or`, `MarkerNodeMatcherAnd/Or`, `GridDataNodePredicateAnd/Any`, `MarkerNodeMatcherAny/None`.** Answer to the "two matcher hierarchies?" question: there are *three*, and they are over genuinely different domains — `CellMatcher.match(grid,x,y,rotation)`, `MarkerNodeMatcher.match(node)` (no grid, no initialize), `GridDataNodePredicate.evaluate(grid,node)`. Only the `CellMatcher`/boolean-`CellFilter` overlap is a real domain collision, and that is reported as **G8**.
+- **`filtering/numeric/math/**` arithmetic nodes** (`Add`/`Subtract`/`Multiply`/`Divide`/`Negate`/`Max2`/`Min2`/`Clamp`/`SmoothStep`/`Lerp`/`InverseLerp`/`Saturate`/`OneMinus`/`Absolute`/`Step`). Checked every one: they all correctly delegate to `core/math` (`max2`, `min2`, `clamp`, `smoothStep`, `lerp`, `inverseLerp`) and carry no inline math. The only real defect in the family is `CellFilterPower` (**G7**). The `dataType`/`assert` preamble repetition is shape.
+- **`theme/TerrainLayerRule.js:25 from`, `theme/cell/CellProcessingRule.js:22 from`, `theme/cell/CellProcessingRuleSet.js:23 initialize`.** Opened all three — two-field assignment and a forwarding loop. Shape.
+- **Neighbour-mask iteration bodies** (`buildDistanceMapToObjective.js:51-75`, `buildPathFromDistanceMap.js:35-61`, `GridTaskConnectRooms.js:181-201` and `:252-272`, `GridTaskGenerateRoads.js:249-269`). The index→(x,y) decode + mask loop + double bounds check is repeated five times, but each body diverges *inside* the loop (flood-fill push, open-set seeding, distance relaxation, best-successor pick, path-network probe with a labelled `continue neighbourhood_loop`). A callback iterator would allocate a closure per cell in the hottest code in the package. **JUSTIFIED** — the shareable part is the mask constants only (**G5**).
+- **`CaveGeneratorCellularAutomata.step`** — single implementation, hand-unrolled 8-neighbour sum with hoisted row bases and validity flags. Hot inner loop, no second copy. Correct as written.
+- **`GridData.js:75 getLayerById`** — a 10-line linear scan over `layers` (typically < 10 entries) called from `initialize` paths only. `AbstractCellFilterSampleGridLayer.js:31` and `GridTaskBuildSourceDistanceMap.js:85` both call it rather than re-deriving it. Nothing to share.
+- **`GridTaskGenerateRoads.js:29 findMarkerNodeByPosition` vs `CellMatcherGridPattern.js:64 getRuleByPosition`** (brief §C, sim 0.891) — both linear `position.x/y` scans, ~10 lines, over unrelated element types in unrelated modules. Below the bar.
+- **`RoadConnection.js:79 test`** (brief §A, paired with `AnimationClipDefinition.hasTag`) — a 10-line `indexOf`-equivalent on a `number[]`. Below the bar.
+- **`core/parser/simple/readReferenceToken.js` vs `view/tooltip/gml/parser/readReferenceToken.js`** (brief §G) — read both: **not a fork.** The core one reads a dotted identifier path (`a.b.c`) into a `Token` list; the view one parses a bracketed tooltip reference `[tag: k=v, k=v]` with its own `ParserError` messages and `TooltipReferenceValue` payload. Name collision only; the view one already reuses `skipWhitespace`, `Token` and `ParserError` from core.
+- **`view/minimap/dom/MinimapCameraView.js:110-112` raw `Math.random()`** (brief §F) — checked for a seeded-RNG bypass: it is a single site, not duplication, so no row. Worth passing to whoever owns determinism, though: the jitter is accumulated into `oX/oY/oZ` (`:99-101`) while the retry at `:106` re-raycasts with the original `originX/originY/originZ`, so the whole jitter loop is inert.
+- **`editor/actions/concrete/Selection{Add,Remove,Clear}Action`, `Component{Add,Remove}Action`, `Entity{Create,Remove}Action`** — opened all six. The shared part is two lines (`this.oldState = editor.selection.clone()` / `revert: editor.selection.copy(this.oldState)`); everything else is per-action. Typed undo commands are exactly the shape the owner prefers.
+- **`editor/process/symbolic/make*SymbolicDisplay.js`** (11 files) — checked `make3DSymbolicDisplay.js`, `makeCameraSymbolicDisplay.js`, `makePositionedIconDisplaySymbol.js`: already correctly factored through `make3DSymbolicDisplay` + `buildThreeJSHelperEntity` + `synchronizeTransform`. Good reuse; nothing to report.
+- **`editor/view/ecs/components/common/AutoCanvasView.js`** — properly `extends CanvasView` and reuses `DomSizeObserver`. Good reuse.
+- **`HTMLElementCacheKey.js:122 #getAttributeContainer`** vs `AttributeGroupSpec.getAttributeByName` / `ParticleSpecification.getByName` (brief §A/§C) — three unrelated 10-line "linear scan by `.name`" loops on three different record types in three different subsystems. Below the bar.
+- **`view/controller/controls/*` importing `editor/view/ecs/components/DatGuiController.js`** — `src/` depending on `editor/` is a layering inversion, but it is not duplication; noted here so it isn't mistaken for an oversight.
+- **Seed derivation for child nodes** — `MarkerNodeActionSequence.js:32` and `MarkerNodeActionSelectWeighted.js:50` decorrelate children with `seed + i`; `MarkerNodeEntityProcessorSequence.js:45`, `GridCellActionSequence.js:39`, `MarkerNodeEmitterGroup.js:33` and `MarkerNodeTransformerSequence.js:25` pass `seed` unchanged. Only two sites use the `+ i` form, so this is a convention gap rather than duplication — but it is the same class of hazard as G1 and should be settled once (`randomSeed(random)` per child, as `TerrainTheme.js:30` and `ThemeEngine.js:215` already do).
+
+---
+
+## Notes — why duplication accumulates here
+
+1. **Four parallel node hierarchies over one grid.** `CellFilter` (`grid,x,y,rot → number`), `CellMatcher` (`… → bool`), `GridCellAction` (`grid,x,y,rot → void`) and `MarkerNodeAction`/`MarkerNodeTransformer`/`MarkerNodeEmitter` (`grid,ecd,node`) all model "do something at a place on the grid" with different arity. The typed-classes-over-magic rule makes that a deliberate design, and it means every *combinator* (sequence, weighted-select, and/or/not, displaced-by-offset) gets written once per hierarchy. That is accepted. What is **not** accepted, and what every generation finding above has in common, is the *scalar math and search algorithms* getting copied along with the combinator shape — the rotation formula (G2), the CDF walk (G3), the Sobel taps (G4), the BFS (G1). The dividing line is: forwarding loops are shape, arithmetic and search are logic.
+
+2. **`markers/` and `placement/` are not superseding each other.** Both have live spec coverage and both are reachable from `ThemeEngine`; `GridCellActionPlaceMarker` (in `markers/`) even extends `GridCellAction` (in `placement/`), so the two are interleaved by design — `placement/` operates on cells and *emits* markers, `markers/` operates on the emitted nodes. There is no dead branch to delete; the duplication is confined to the two combinators reported in G3.
+
+3. **The reuse surface exists but is not discoverable from `generation/`.** `ORTHOGONAL_NEIGHBOURHOOD_MASK` has zero importers while two classes redeclare it; there is no `v2_rotate` at all despite eight callers; `computeCellFilterGradient` sits in the same package as `CellFilterSobel` and is still not used by it. The pattern is "write it where you need it, in the file you already have open".
+
+4. **`src/view` and `editor/` are mutually entangled rather than layered.** `src/view/controller/controls/*` imports `editor/view/ecs/components/DatGuiController.js`; `editor/*` imports `src/view/*` everywhere. Because there is no single owner of "widget", the same widget gets built on whichever side the author happened to be working — hence three numeric-interval editors (V2), four vector editors (V6), and a `LineView` that duplicates `EmptyView.group` (V9).
+
+5. **Two generations of infrastructure coexist, and only some call sites were migrated.** `ImmutableObjectPool` vs the older `Cache`-of-arrays (V1), `SCRATCH_UINT32_TRAVERSAL_STACK` vs per-call arrays (V8), `View.addChild` vs `GroupView.add` (V4), the `inOpen` BitSet mirror vs `Uint32Heap.insert_or_update` (G1). In every case the migration was applied to one copy and the sibling was never found — which is precisely the failure mode that makes duplication expensive rather than merely verbose.