@woosh/meep-engine 3.1.0 → 3.2.0

package/src/DUPLICATION_AUDIT_2026_08_07/B_core_data.md

@@ -1,93 +1,93 @@
-# Domain B — core (data structures, binary, graph, cache, parser, color)
-
-Scope: `meep/src/core/` excluding `core/geom` and `core/math` (2D counterparts under `core/geom` are
-cited where they are the *other half* of a fork whose primary copy lives in my domain).
-
-Quantification method: for the whole-file forks I computed the LCS over comment-stripped,
-whitespace-normalised code lines (`shared / A vs B`). Those numbers are reproducible and are what
-the "Evidence" column cites.
-
-## Findings
-
-| # | Severity | Concept | Sites | Evidence | Verdict | Proposed common path | Effort/Risk |
-|---|---|---|---|---|---|---|---|
-| 1 | CRITICAL | **Dynamic BVH tree is forked wholesale for 2D.** Node allocator, free-list, capacity growth, all 10 node-field accessors, `insert_leaf` (SAH branch-and-bound descent), `remove_leaf`, `bubble_up_refit`, `bubble_up_update`, `balance`, `traverse`, `collect_nodes_all`, `__move_node_links`, `swap_nodes` are the same code with `ELEMENT_WORD_COUNT` 10→8 and 6→4 AABB floats. | `core/bvh2/bvh3/BVH.js:73` `class BVH` ⟷ `core/geom/2d/bvh/BVH2D.js:70` `class BVH2D`. Method-for-method: `__grow_capacity` 217/155, `__set_capacity` 240/178, `allocate_node` 300/214, `release_node` 358/270, `node_is_leaf` 369/281, `node_get/set_{user_data,child1,child2,parent,height}` 381–471 / 293–383, `node_move_aabb` 528/434, `insert_leaf` 663/557, `bubble_up_refit` 775/675, `bubble_up_update` 803/705, `remove_leaf` 845/740, `balance_height` 902 ⟷ `balance` 792, `release_all` 1291/997, `traverse` 1302/1008, `collect_nodes_all` 1340/1046, `__move_node_links` 1357/1063, `swap_nodes` 1394/1100. Column constants re-exported: `BVH.js:10-13,21,27,47` ⟷ `BVH2D.js:11-14,22,28,48`. | **UNJUSTIFIED** | **521 of 576 BVH2D code lines are shared with BVH.js (90%).** Only 7 methods are truly dimension-specific (`allocate_node`'s ±INF init, `node_get_aabb`, `node_set_aabb`, `node_set_aabb_primitive`, `node_get_surface_area`, `node_get_combined_surface_area`, `node_set_combined_aabb`) ≈ 130 lines. **The fork has already cost a real divergence:** `BVH.bubble_up_update:806` uses the Box2D-v3 SAH rotation `balance_rotate` (added with a long design comment and `balance_rotate.spec.js`), while `BVH2D.bubble_up_update:713` still calls the Box2D-v2 height-AVL `balance`; and `BVH2D.bubble_up_refit:681` balances on every refit whereas `BVH.bubble_up_refit:775` deliberately does not. The 2D tree silently never received the SAH upgrade. Also missing in 2D: `data_buffer` get/set (serialisation round-trip, with a fix comment at `BVH.js:107-112`), `size` getter, `allocate_linear`, `node_assign_children{,_only}`. | Extract a shared `BvhTreeBase` holding the topology half (allocator/free-list/capacity/child-parent-height accessors/insert/remove/refit/balance/traverse/swap), and leave the ~7 AABB methods + `ELEMENT_WORD_COUNT`/column constants as the per-dimension typed subclass surface (`BVH extends BvhTreeBase`, `BVH2D extends BvhTreeBase`). Column offsets become `static` class fields on the subclass, not string keys — no magic. Keep both public classes and their exported constants (library surface). | **High effort / High risk.** ~500 lines move; two standing spec suites (`BVH.spec.js`, `balance_rotate.spec.js`) plus every physics broadphase consumer gate it. Do it in two steps: (a) port `balance_rotate` + the missing methods into BVH2D so the two are behaviourally aligned *first*, (b) then unify. Step (a) alone is worth doing even if (b) is rejected. |
-| 2 | HIGH | **Static Morton-ordered binary tree forked for 2D** — `build()` (bottom-up level assembly), `sort_morton()` (explicit-stack quicksort on Morton codes), `__swap_leaves()`, `initialize_structure()`, `setLeafCount()`, `setLeafData()`, `getLeafBlockAddress()`, `readLeafPayload()`, and a module-private `copy_box_zero_size()` are duplicated. | `core/bvh2/binary/2/BinaryUint32BVH.js:426` `build` ⟷ `core/geom/2d/r-tree/StaticR2Tree.js:313` `build` (token-identical, 289 tokens); `BinaryUint32BVH.js:336` `sort_morton` ⟷ `StaticR2Tree.js:210` `sort_morton`; `BinaryUint32BVH.js:411` `__swap_leaves` ⟷ `StaticR2Tree.js:296`; `BinaryUint32BVH.js:35` `copy_box_zero_size` ⟷ `StaticR2Tree.js:51` (same private helper, same name, two files). | **UNJUSTIFIED** | 113 of 205 StaticR2Tree code lines shared. **A bug caused by the copy is already documented in the tree:** `StaticR2Tree.js:346-347` carries the comment "a 2D box is 4 floats \[x0,y0,x1,y1\] (copying 6 would spill into the following node's data)" — i.e. the 3D `array_copy(..., 6)` was pasted into the 2D file and had to be fixed there. Exactly the "fix in one copy misses the other" class. | Same shape as #1: a `MortonLeafTreeBase` carrying `build`/`sort_morton`/`__swap_leaves`/`copy_box_zero_size` parameterised by two `static` sizes (`BINARY_NODE_SIZE`, `LEAF_NODE_SIZE`) and one abstract `combine_bounds(dst_off, a_off, b_off)` that the subclass points at `aabb3_array_combine` / `aabb2_union_array`. | Medium effort / Medium risk. `build()` is cold (construction only), so the one virtual call per node pair is irrelevant. `sort_morton` is warm but only at build. |
-| 3 | HIGH | **Traversal-order invariant duplicated 14× and drifted.** Every hand-written BVH2 traversal repeats the same stack skeleton *and* the comment "write to stack in reverse order, so that first child ends up being visited first" — but half of them push `child1` then `child2`, which visits **child2 first**, the opposite of what the comment claims and of what the generic implementation does. | Comment-matching (child2 pushed first): `core/bvh2/bvh3/query/bvh_query_user_data_generic.js:74-76`, `core/bvh2/bvh3/query/bvh_query_leaves_generic.js:65-67`, `bvh_query_user_data_ray.js:85-86`, `bvh_query_user_data_ray_segment.js:89-90`, `bvh_query_leaves_ray.js:79-80`, `bvh_query_leaves_ray_segment.js:83-84`. Comment present but **contradicted** (child1 pushed first): `bvh_collect_user_data.js:52-54`, `bvh_query_user_data_intersects_aabb.js:74-76`, `bvh_query_user_data_intersects_sphere.js:83-85`, `bvh_query_user_data_intersects_capsule.js:92-94`, `bvh_query_user_data_intersects_frustum.js:73-75`, `compute_tight_near_far_clipping_planes.js:182-184`. | **UNJUSTIFIED** | The result *ordering* of `bvh_query_user_data_intersects_sphere` is the reverse of `bvh_query_user_data_generic` + `BVHQueryIntersectsSphere` (`core/bvh2/bvh3/query/BVHQueryIntersectsSphere.js`), which computes the same set. Since this project has a standing determinism gate, "same set, different order" is a live hazard: switching a caller between the two paths silently reorders results. The generic path with `BVHQuery*` objects already exists and is fully implemented — the specialised files are hand-inlined copies of it. | Two separate actions, both cheap: (a) **normalise the push order in the 6 contradicting files** so all 14 agree with the documented invariant (pure ordering fix, spec-guarded); (b) for the *cold* consumers among them (`compute_tight_near_far_clipping_planes`, `bvh_collect_user_data`) delete the inlined skeleton and call `bvh_query_user_data_generic` with the corresponding `BVHQuery*` object. Leave the genuinely hot ray/AABB/sphere ones inlined — that inlining is legitimate. | (a) Low effort / Low risk. (b) Low effort / Low risk, cold code only. |
-| 4 | HIGH | **`Uint32Heap4` is a whole-file copy of `Uint32Heap`** with only the arity arithmetic changed. | `core/collection/heap/Uint32Heap.js:56` `class Uint32Heap` ⟷ `core/collection/heap/Uint32Heap4.js:59` `class Uint32Heap4`. Identical bodies: `constructor` 63/62, `__capacity_grow` 101/100, `compare` 131/130, `swap` 146/145, `size`/`capacity`/`top_id`/`is_empty`/`peek_score`/`peek_min` getters, `pop_min` 274/289, `find_index_by_id` 301/316, `contains`, `clear`, `remove`, `__remove_by_index` 356/371, `update_score`, `__update_score_by_index` 391/406, `get_score`, `insert_or_update`, `insert` 447/462. Differing: `HEAP_PARENT` (`>>1` vs `>>2`), `HEAP_LEFT`/`HEAP_RIGHT` vs `HEAP_FIRST_CHILD`, `heap_down` (2 vs 4 child compares), `heap_up`'s parent shift. | **UNJUSTIFIED** | **194 of 208 code lines shared (93%).** Only 4 of 22 members carry the 4-ary difference; the storage layout (packed float32 score + uint32 id, 8 bytes/slot) is byte-identical. `__remove_by_index` is a `pop_min`-based delete that depends on `HEAP_PARENT` — if that routine is ever fixed (it is O(depth) swaps rather than a sift), the fix lands in one file only. `Uint32Heap.js:57` still carries the Blender attribution comment that `Uint32Heap4` dropped. | Shared base `Uint32ScoreHeapBase` owning storage + all id-lookup/insert/remove/update machinery, with `heap_up`/`heap_down` (and only those) overridden per arity. Both are already using `this.compare`/`this.swap` method calls in their inner loops, so no new polymorphism is introduced on the hot path — the megamorphic risk argument does not apply here (`heap_up`/`heap_down` are the *leaf* of the call chain, not the caller). | Medium effort / Low risk. `Uint32Heap.spec.js` + `Uint32Heap4.spec.js` both exist and gate it. |
-| 5 | HIGH / PROMOTION | **No canonical `hash_combine` primitive.** The `(h << 5) - h + v` (== `h*31 + v`) step is written out inline at 15+ sites in `core/` alone (74 project-wide), with **three mutually incompatible normalisations** and a shared-but-broken `(array, offset, length)` contract. | `core/collection/array/computeHashArray.js:10` (`hash \|= 0`, signed), `core/math/hash/computeHashFloatArray.js:8` (`\|= 0`), `core/collection/array/computeStridedArrayHash.js:14` (`>>> 0`, unsigned), `core/collection/array/computeStridedIntegerArrayHash.js:9` (`>>> 0`), `core/primitives/strings/computeStringHash.js:10` (`>>> 0`), `core/collection/array/typed/uint8_array_hash.js:8`, `uint16_array_hash.js:8`, `uint32_array_hash.js:8` (**neither** — the accumulator escapes int32 into a double), `core/collection/list/List.js:967`, `core/collection/table/RowFirstTable.js:146`, `core/graph/csr/CSRGraph.js:281-292`, `core/model/BoundedValue.js:180-182`. `CSRGraph.js:275` explicitly documents it as "meep's standard `(h*31 + element)` convention" — a convention with no implementation. | **PROMOTION** | Three concrete consequences, all from re-derivation rather than reuse: (i) `uint32_array_hash` never truncates, so `((hash<<5)-hash) + channel_value` with `channel_value` near 2^32 produces a non-int32 double and the "32-bit rolling hash" property is lost — then `CSRGraph.hash():285` feeds that double straight back into another combine step; (ii) signed vs unsigned finalisation means the same byte sequence hashes differently depending on which family member you call; (iii) the shared `(array, offset, length)` signature is interpreted as `length = absolute end index` by all three `uintN_array_hash` (loops run `i < length`, not `i < offset + length`, so a non-zero `offset` under-reads), and `core/collection/array/typed/sparse_typed_array_hash.js:13` accepts `offset` and then **discards it**, passing a hard-coded `0` to `computeStridedArrayHash`. All current callers pass `offset === 0`, so nothing is visibly broken today — which is exactly why it will bite later. | Add `core/math/hash/hash_combine.js` — `export function hash_combine(hash, value) { return (((hash << 5) - hash) + value) | 0; }` — and a companion `hash_finalize(h) { return h >>> 0; }`. Rewrite the 8 array/string hash functions on top of it, and fix the `offset`/`length` contract to `count` semantics in the same change (with the three `.spec.js` files as the gate). Do **not** touch the inline uses inside genuinely hot scalar loops (`List.js:967`, `RowFirstTable.js:146`) beyond making them agree on finalisation. | Medium effort / **Medium risk** — changing finalisation changes hash *values*. Anything persisting a hash (serialised caches, `RowFirstTableSpec` keys) must be checked first. Safe subset: land `hash_combine` + fix the `offset` contract without changing any finalisation. |
-| 6 | MEDIUM | **`IndexedFloatMinHeap` is a copy of `IndexedFloatMaxHeap`** with the comparison operators flipped. | `core/collection/heap/IndexedFloatMaxHeap.js:37` `class IndexedFloatMaxHeap` ⟷ `core/collection/heap/IndexedFloatMinHeap.js:37` `class IndexedFloatMinHeap`. Identical: `constructor` 38/45, `clear` 65/72, `__swap_slots` 83/90, `__grow_capacity` 151/158, `insert` 167/174, `update` 212/219, `remove` 231/238, plus `size`/`has`/`get_score`/`peek`. Differing: 6 comparison operators inside `__sift_down` 108/115, `__sift_up` 137/144, `update` 224-228, `remove` 258-261; and `pop_max` 185 ⟷ `pop_min` 192. | **JUSTIFIED (documented, but the stated reason is weaker than claimed)** | **154 of 168 code lines shared (92%).** `IndexedFloatMinHeap.js:19-23` carries an explicit rationale: "deliberately a standalone copy rather than a subclass … extracting the order-specific `__sift_*` comparisons behind an overridable method would turn the hot-loop call sites polymorphic and defeat V8 inlining." That reasoning is correct *for the subclass approach they considered*, and per house rules I will not argue against a measured perf choice. Worth recording, though: the subclass approach is not the only one — a min-heap is a max-heap over negated scores, which needs zero new polymorphism (negate in `insert`/`update`, negate on read in `peek`/`get_score`). That would collapse ~150 lines with no call-site polymorphism at all, at the cost of `-0`/NaN edge semantics. | No change recommended without a measurement. If revisited, prefer the negation wrapper over a base class. | n/a |
-| 7 | MEDIUM | **Robin-Hood open-addressing machinery duplicated** between the single-key and pair-key uint32 maps: probe loop with displacement early-exit, steal-on-insert, backward-shift deletion, power-of-two capacity + `Math.clz32` shift, load-factor growth, rehash-on-resize. | `core/collection/Uint32Map.js:63` ctor / `:126` `get` / `:198` `__insert_no_grow` / `:249` `delete` / `:326` `__resize` ⟷ `core/collection/PairUint32Map.js:62` ctor / `:106` `get` / `:168` `__insert_no_grow` / `:224` `delete` / `:297` `__resize`. | **UNJUSTIFIED** | 100 of 178 code lines shared (the LCS is depressed by identifier renames — `slot2`/`k` vs `off`/`ka` — the *algorithm* is line-for-line the same). Differences are exactly two: slot stride (2 vs 3 words) and the hash (`Math.imul(k, FIB)` vs `imul(ka, MIX_A) ^ imul(kb+1, MIX_B)`). Everything invariant-bearing — the `dist > slot_dist` early-exit, the `slot_dist < dist` steal, the `next_dist === 0` stop condition in backward-shift delete — is duplicated verbatim. These are the classic hard-to-get-right parts of Robin Hood; a fix to one will not reach the other. Note `PairUint32Map` already routes its hash through a `this.__hash(...)` **method call** inside every probe iteration, so the "monomorphic hot loop" argument that justifies #6 does not apply here. | Shared `Uint32RobinHoodMapBase` owning capacity/mask/shift/threshold/size/`__data`, the probe skeleton, steal, backward-shift delete and resize, parameterised by a `static SLOT_STRIDE` and an abstract `__hash(...)` / `__slot_matches(off, …)` pair. Both public classes and their `*_ABSENT` constants stay (library surface). | Medium effort / Medium risk. `Uint32Map.spec.js` and `PairUint32Map.spec.js` both exist. |
-| 8 | MEDIUM | **Four quicksort implementations** sharing one explicit-stack partition skeleton; two of them are already fully expressible by a third. | `core/collection/array/array_sort_quick.js:18` `array_sort_quick(data, score_function, ctx, start, end, swap_operator, swap_ctx)`; `core/collection/array/array_quick_sort_by_comparator.js:11`; `core/collection/array/array_quick_sort_by_lookup_map.js:16`; `core/collection/array/array_quick_sort_by_lookup_uint.js:15`. A fifth copy of the same skeleton is inlined at `core/bvh2/binary/2/BinaryUint32BVH.js:336` `sort_morton` and a sixth at `core/geom/2d/r-tree/StaticR2Tree.js:210`. | **UNJUSTIFIED** (for the two lookup variants) | `array_quick_sort_by_lookup_map` and `array_quick_sort_by_lookup_uint` differ from each other by **one token** (`lookup.get(x)` vs `lookup[x]`) across 35 lines, and both are exactly `array_sort_quick(data, t => lookup.get(t), …)` / `array_sort_quick(data, t => lookup[t], …)`. `array_sort_quick` already takes a score function and a context, so no closure allocation is needed. A second, sharper problem: the four copies do **not** agree on stack ownership — `array_sort_quick.js:4` and `array_quick_sort_by_comparator.js:1` each hold a *private* `const stack = []`, while the two lookup variants (`:3`) alias the **globally shared** `SCRATCH_UINT32_TRAVERSAL_STACK`, which is simultaneously the BVH traversal stack (17 other importers). Sorting from inside a BVH query callback silently corrupts that traversal; the private-array copies have no such hazard. The invariant is duplicated three ways and reconciled nowhere. | Delete the bodies of the two lookup variants and implement them as one-line delegations to `array_sort_quick` (keep both exports — library surface). Separately, decide the stack-ownership rule once: either all sorts own a private stack, or all document the shared-stack precondition the way `bvh_query_user_data_generic.js:9-14` does. | Low effort / Low risk. `array_quick_sort_by_lookup_map.spec.js`, `..._uint.spec.js`, `array_sort_quick.spec.js` all exist. |
-| 9 | MEDIUM | **Intrusive MRU doubly-linked-list splice duplicated** between the two cache implementations. | `core/cache/Cache.js:149` `__promote(element)` ⟷ `core/cache/wtinylfu/CacheRegionWTinylfu.js:78` `touch(element)` (token-identical, 68 tokens). Also `core/cache/Cache.js:481` `__removeElement` ⟷ `core/cache/wtinylfu/CacheRegionWTinylfu.js:112` `__removeElement` — same head/tail fix-up + `element.unlink()`. | **UNJUSTIFIED** | The head/tail-pointer maintenance around `CacheElement.unlink()` (`core/cache/CacheElement.js`) is the whole of both routines, and it is the part with the invariant (a node that *is* `__first` must not be re-linked; a node that *is* `__last` must move the tail back before unlinking). `CacheElementWTinylfu` **already** extends `CacheElement`, so the element type is shared — only the list head/tail holder was re-derived. | Promote the head/tail pair into a small `IntrusiveMruList` (fields `#first`/`#last`, methods `add`, `promote`, `detach`) in `core/cache/`, and have both `Cache` and `CacheRegionWTinylfu` hold one. `CacheRegionWTinylfu` keeps its weight accounting; `Cache` keeps its `data` map and signals. | Low effort / Low risk. `Cache.spec.js`, `CacheRegionWTinylfu.spec.js`, `CacheWTinylfu.fuzz.spec.js` all exist. |
-| 10 | MEDIUM | **BVH8 geometry validator duplicated** for the direct vs pool-indirect triangle addressing conventions. | `core/bvh8/bvh8_geometry_validate.js:29` `bvh8_geometry_validate_bounds` ⟷ `core/bvh8/bvh8_geometry_validate_indirect.js:29` `bvh8_geometry_validate_bounds_indirect`; plus a byte-identical private `aabb3_round_to_float32` at `bvh8_geometry_validate.js:13` ⟷ `bvh8_geometry_validate_indirect.js:13`. | **UNJUSTIFIED** | **76 of 83 code lines shared (92%).** The entire difference in the bounds walk is one line: `const triangle_index = triangle_offset + base_index_triangle + j;` vs `= pool[triangle_offset + base_index_triangle + j];`. This is a *validator* — cold, debug-only code, run once after a build — so there is no perf argument for inlining. The duplicated `aabb3_round_to_float32` helper is pure and belongs next to the other `aabb3_*` helpers. | Move `aabb3_round_to_float32` to a shared module. For the walk, pass the resolved index array explicitly: give the direct caller an identity `Uint32Array` view or, better, have `bvh8_geometry_validate` build the trivial identity pool once and call the single indirect implementation. No sentinel parameter, uniform control flow. | Low effort / Low risk. Cold path, both are already `throw`-on-violation. |
-| 11 | MEDIUM | **`ebvh_geometry_query_any_triangle_ray` is a copy of `ebvh_geometry_query_nearest_triangle_ray`** with the "keep best" bookkeeping replaced by an early return. | `core/bvh2/bvh3/ebvh_geometry_query_any_triangle_ray.js:30` ⟷ `core/bvh2/bvh3/ebvh_geometry_query_nearest_triangle_ray.js:25`. | **JUSTIFIED (hot path, and the algorithms genuinely differ)** | 70 of 80 code lines shared, but the 10 that differ are the algorithm: `any` prunes on a *fixed* `max_distance_sqr` and unwinds the stack on first hit (`stack.pointer = stack_top; return true`), `nearest` prunes on a *shrinking* `best_t * best_t` and must drain the whole stack. Occlusion/shadow rays are the hottest query in the path tracer; merging them behind a flag would put a branch in the innermost loop and would also require the "unwind and return" to become a sentinel-driven exit — a direct house-rule violation. Recorded so a future reader does not re-flag it. | No change. Consider a cross-reference comment on `..._nearest_...` mirroring the one already on `..._any_...:11-15`. | n/a |
-| 12 | MEDIUM | **Graph-layout helpers duplicated between the box and circle layouters**, including a verbatim topological-layer peel. | `core/graph/layout/box/BoxLayouter.js:361` `buildLayer` (inside `doLayerLayout:355`) ⟷ `core/graph/layout/CircleLayout.js:25` `buildLayer` (inside `doLayerLayout:19`) — token-identical, 116 tokens. `BoxLayouter.js:301` `applyClusteredLayoutStep` ⟷ `CircleLayout.js:88` `applyClusteredLayoutStep`. `BoxLayouter.js:431` `centerAABB2CollectionOn` ⟷ `CircleLayout.js:250` `centerCircleCollectionOn`. | **UNJUSTIFIED** (for `buildLayer`) / **PROMOTION** | `buildLayer` touches no geometry at all — it peels nodes whose `connections[].source` are all already laid out. It is pure graph topology and identical in both files. `applyClusteredLayoutStep` has already diverged: the cluster-translation loop honours `if (box.locked) return;` at `CircleLayout.js:135-138` but **not** at `BoxLayouter.js:341-347`, so locked boxes are moved by cluster gravity in the box layouter and not in the circle one. Same divergence in `centerCircleCollectionOn:256-259` vs `centerAABB2CollectionOn:431`. Only one of the two behaviours can be right. | Hoist `buildLayer` to `core/graph/layout/graph_peel_topological_layer.js` (takes `nodes[]`, mutates/returns the layer) and call it from both `doLayerLayout`s. Decide the `locked` semantics once and apply it to both `applyClusteredLayoutStep` copies — do that even if the functions stay separate. | Low effort / Low risk for `buildLayer`. The `locked` reconciliation is a behaviour decision, not a refactor. |
-| 13 | MEDIUM | **Ray vs ray-segment BVH queries duplicated** — the traversal is byte-identical, only the AABB predicate and two extra parameters differ. | `core/bvh2/bvh3/query/bvh_query_leaves_ray.js:27` ⟷ `bvh_query_leaves_ray_segment.js:30`; `bvh_query_user_data_ray.js:26` ⟷ `bvh_query_user_data_ray_segment.js:29` (39 of 44 code lines shared). | **JUSTIFIED (hot path) — but flag the API asymmetry** | These are the innermost traversals of the path tracer and the physics raycaster; the inlined `float32[address + n]` reads and the absence of a predicate call are the point. However the copies expose an inconsistency worth fixing on its own merits: `bvh_query_leaves_ray.js:65-69` passes **raw** direction components to `aabb3_intersects_ray`, while `bvh_query_leaves_ray_segment.js:68-70` passes **reciprocals** (`1 / direction_x`, …) to `aabb3_intersects_ray_segment` — and computes those three divisions *per node*, inside the loop, instead of once before it. | Leave the duplication. Hoist the three reciprocals out of the traversal loop in both `*_ray_segment` files, and align the two `aabb3_intersects_ray*` signatures on one convention (both raw or both reciprocal). | Low effort / Low risk. |
-| 14 | MEDIUM | **Four colour-adjustment operators are the same 20-line body** (`assert` pair → early-return on `amount === 0` → `new Color()` → `linear_srgb_to_okhsv` → scale one OkHSV channel → `okhsv_to_linear_srgb`). | `core/color/operations/color_lighten.js:15`, `color_darken.js:15`, `color_saturate.js:15`, `color_desaturate.js:15` — each also carries its own module-static `const hsv = [0,0,0]` scratch. | **UNJUSTIFIED** | The only difference is the channel index (`hsv[2]` vs `hsv[1]`) and the factor. And the factor has already drifted: `color_darken.js:29` uses `clamp01(hsv[2] * clamp01(1 - amount))` (inner clamp on the factor) while `color_desaturate.js:29` uses `clamp01(hsv[1] * (1 - amount))` (no inner clamp). They happen to agree numerically because of the outer `clamp01`, which is luck, not design — and it means a reader cannot tell which form is intended. Note also all four call `okhsv_to_linear_srgb(r, ...hsv)`, spreading an array on every call (an allocation in what is otherwise carefully allocation-free colour code). | One non-exported `color_scale_okhsv_channel(input, channel, factor)` in `core/color/operations/`, with the four public functions as three-line typed wrappers. Public API and file layout unchanged (library surface preserved); the channel index is a numeric constant, not a string key, so no magic-registry rule is violated. Replace the four `...hsv` spreads with explicit `hsv[0], hsv[1], hsv[2]` while in there. | Low effort / Low risk. |
-| 15 | LOW | `bvh_query_user_data_nearest_to_point_filtered` is `bvh_query_user_data_nearest_to_point` with a predicate on the leaf-accept step. | `core/bvh2/bvh3/query/bvh_query_user_data_nearest_to_point.js:16` ⟷ `core/bvh2/bvh3/query/bvh_query_user_data_nearest_to_point_filtered.js:28`. | **JUSTIFIED (avoiding an optional-callback sentinel)** | ~55 lines duplicated for one `if (filter(user_data))`. Unifying would mean an optional `filter` parameter that defaults to "accept everything" — precisely the `x === null ? auto : override` shape the codebase rejects, and it would add an indirect call per accepted leaf on a branch-and-bound search. The `_filtered` variant already documents the shared-stack re-entrancy contract properly (`:14-17`), which the unfiltered one does not. | No merge. Copy the re-entrancy/`SCRATCH_UINT32_TRAVERSAL_STACK` doc block onto the unfiltered variant so the contract is stated in both. | Trivial / none. |
-| 16 | LOW | Decimal and hex integer token readers duplicate a 45-line `switch` over digit characters. | `core/parser/simple/readHexToken.js:13` ⟷ `core/parser/simple/readUnsignedIntegerToken.js:13`. | **UNJUSTIFIED** | Cases `'0'`–`'9'` are identical in both (20 lines); hex adds `a-f`/`A-F` and swaps `value * 10` for `value * 16`. Cold code (a config/expression parser, not a hot loop). The copy has already produced dead code, called out in-tree: `readHexToken.js:96-100` notes the per-character `i === cursor` guard inherited from the decimal version "is dead code because i starts at cursor + 2" — the guard is still there in both. | One `char_to_digit(char)` returning `-1` for non-digits (0–15 for hex chars), used by both readers with a `radix` bound check. Removes the dead guard as a side effect. | Low effort / Low risk. Both have callers via `core/parser/simple`. |
-| 17 | LOW | `insert_after` / `insert_before` and `insert_after_or_replace` / `insert_before_or_replace` — four near-identical string splice helpers; the `_or_replace` pair re-implements the plain pair's body rather than calling it. | `core/primitives/strings/insert_after.js:8`, `insert_before.js:8`, `insert_after_or_replace.js:9`, `insert_before_or_replace.js:9`. | **UNJUSTIFIED (marginal)** | The four differ only in whether the insertion offset is `i` or `i + term.length`. All four are cold (shader-source patching). The `_or_replace` variants can't literally call the plain ones because they must distinguish "not found" from "found" without the `console.warn` side effect — but a shared `splice_at(source, position, value)` would still remove the duplicated `slice`/`+`/`slice` idiom. | One private `string_splice(source, position, value)`; the four public exports become 3–5 lines each. Keep all four exports. | Trivial / none. |
-| 18 | LOW | `futureTask` and `promiseTask` build the same `Task` from the same `resolved`/`rejected`/`error` closure trio. | `core/process/task/util/futureTask.js:10` ⟷ `core/process/task/util/promiseTask.js:10`. | **JUSTIFIED (barely) — uniform control flow** | ~35 lines shared. `futureTask` differs by a `typeof future.resolve !== 'function'` guard and by calling `future.resolve()` at the top of every `cycle()` (it *pumps* the future, `promiseTask` only waits). Factoring that out needs an optional pre-cycle hook — a sentinel parameter. Leave it. | No change. | n/a |
-| 19 | LOW | `MEASUREMENT_UNITS_SI` and `UNIT_DIMENSION_MAPPING` are the **same seven `NamedUnit` values in the same order**, exported twice from two files with the same seven imports. | `core/science/units/MEASUREMENT_UNITS_SI.js:20` ⟷ `core/science/units/UNIT_DIMENSION_MAPPING.js:21`. | **UNJUSTIFIED** | Both are `[METER, KILOGRAM, SECOND, AMPERE, KELVIN, MOLE, CANDELA]`, both are consumed by `unit_matrix_to_string` / `format_quantity`, and both encode the invariant "array index === `UnitDimension` ordinal". If the dimension order ever changes, one of the two will be missed and the other will silently mis-label every quantity. The JSDoc on each explains a *usage* difference, not a *value* difference. | Keep both exports (library surface) but make one derive from the other: `export const MEASUREMENT_UNITS_SI = UNIT_DIMENSION_MAPPING;` with the existing doc retained, so the ordering invariant has exactly one definition. | Trivial / Low risk. `MEASUREMENT_UNITS.spec.js` and `UNIT_DIMENSION_MAPPING.spec.js` both exist. |
-| 20 | LOW | Two connected-components implementations, one of them quadratic. | `core/graph/layout/computeDisconnectedSubGraphs.js:6` ⟷ `core/graph/graph_compute_disconnected_clusters.js:6`. | **UNJUSTIFIED (already acknowledged in-tree)** | Same BFS-over-a-worklist algorithm. `computeDisconnectedSubGraphs.js:2` already carries `NOTE: use graph_compute_disconnected_clusters instead where possible`, and it uses `unexplored.indexOf(node)` + `splice` inside the inner loop — O(n²) — where the other uses a `Set`. It has two live callers (`BoxLayouter.js:303`, `CircleLayout.js:90`) that pass `{connections: Connection[]}` node objects rather than a `Graph`. | Give `graph_compute_disconnected_clusters` a sibling that takes an edge-accessor over plain node objects, or make the two layouters build a `Graph`. Failing that, at minimum swap the `indexOf`/`splice` for a `Set` so the two implementations have the same complexity. | Low effort / Low risk. Layout output ordering may shift — check `CircleLayout.spec.js`. |
-| 21 | LOW | Inline 2-D length/distance re-derived next to an imported primitive that already does it. | `core/graph/layout/CircleLayout.js:288` (`Math.sqrt(dX*dX + dY*dY)` — this file already imports `v2_distance` at `:5`), `CircleLayout.js:745`, `CircleLayout.js:880`, `core/graph/layout/box/position_box_next_to_box.js:37`. Related: `BoxLayouter.js:32` `evaluateEdgeCost` uses `Vector2._distance(...)` while `CircleLayout.js:344` `evaluateEdgeCost` uses `v2_distance(...)` for the identical computation. | **UNJUSTIFIED (cold code)** | Layout runs once per graph edit, not per frame, so there is no inlining justification. Two different primitives (`Vector2._distance` and `v2_distance`) are used for the same operation in two files that otherwise mirror each other. | Use `v2_length`/`v2_distance` at the four inline sites, and pick one of the two distance primitives for both `evaluateEdgeCost` copies. | Trivial / none. |
-
-## Dismissed leads
-
-- **`core/debug/matchers/matchers.js` vs `core/process/matcher/{not,isNull,isDefined}.js`** — name collision only. `core/debug` is a Hamcrest-style DSL returning `Matcher` *objects* (`new IsNot(matcher)`); `core/process/matcher` returns bare predicate *functions* (`v => !m(v)`). Different abstractions, different consumers.
-- **`core/parser/simple/readReferenceToken.js` vs `view/tooltip/gml/parser/readReferenceToken.js`** — name collision only. One parses dotted identifier chains (`a.b.c`), the other parses `[tag: k=v, k=v]` tooltip references. Zero shared code.
-- **`core/parser/simple/DataType.js` vs `core/model/node-graph/type/DataType.js`** — name collision only. One is a 5-entry frozen string enum, the other a class with `id`/`name`/`hash`/`equals`/`toJSON`.
-- **`core/graph/layout/Connection.js` vs `core/model/node-graph/Connection.js`** — name collision only. One is `{source, target, points: Vector2[]}` with a polyline `length()`; the other is a node-graph port link with `id`, `validate()`, `PortDirection`.
-- **`core/binary/data_view/DataType2DataViewReaders.js` vs `...Writers.js`** — two 10-entry lookup tables mapping `BinaryDataType` → `"getUint8"` / `"setUint8"`. Deriving one from the other means string concatenation on method names — exactly the magic-string pattern the house rules reject. Typed tables are correct here.
-- **`core/binary/split_by_2.js` vs `split_by_3.js`** — shape-identical bit-spreading, but the masks and shift counts encode genuinely different Morton interleavings (2-way vs 3-way). Not duplication.
-- **`core/color/sRGB/linear_to_sRGB.js` vs `sRGB_to_linear.js`** — inverse transfer functions with different breakpoints (0.0031308 / 0.04045), different constants and different exponents (0.4166… / 2.4). Only the 3-channel wrapper shape matches, and that's 3 lines.
-- **`core/collection/set/compute_set_difference.js` vs `compute_set_intersection.js`** — different set operations. (Separately noted, out of scope for this audit: `compute_set_difference` computes the *symmetric* difference despite its name — a naming defect, not duplication.)
-- **`core/collection/array/binarySearchHighIndex.js` vs `binarySearchLowIndex.js`** — different return contracts (ceiling/insertion point vs floor index, `-1` on underflow). The bodies diverge in the branch structure, not just a comparator.
-- **`core/collection/Uint32MinHeap.js` vs `core/collection/heap/Uint32Heap.js`** — different payloads (bare uint32 values vs id+float32 score pairs). `Uint32MinHeap.js:1-18` documents that it *is* the result of a completed promotion (two byte-identical private copies in physics were merged into it). Already fixed.
-- **`core/collection/map/HashMap.js` vs `core/collection/Uint32Map.js`** — separate-chaining map over arbitrary keys with user-supplied hash/equality vs typed-array open addressing over uint32. No shared machinery.
-- **`setFlag`/`clearFlag`/`writeFlag` repeated across 30 files** (`core/events/signal/Signal.js:59`, `SignalHandler.js:60`, +28 in `engine/`) — three-line per-class bit accessors. Extracting them would be a mixin (magic) or would make call sites *more* verbose. Justified boilerplate.
-- **Repeated `const edge_addresses = graph.edge_addresses; …` unpacking across `core/graph/metis/native/`** (`compute_2way_params.js:17-24`, `fm_2way.js:30-37`, `grow_bisection.js:25-31`, `create_coarse_graph.js:27-32`, `match_shem.js:54-58`, `initial_kway_bfs.js:36-42`, `refine/compute_kway_params.js`) — hoisting property loads out of hot loops. This is the intended idiom, not duplication.
-- **`core/model/Observed{Integer,String,Boolean,Enum,Value}.js`** — per-type `set`/`setSilent`/`onChanged` boilerplate with type-specific asserts. Shape duplication only; explicitly protected by the "typed over magic" rule.
-- **`core/json/resolvePath.js` vs `resolvePathByArray.js`** — already correct reuse; `resolvePath` splits and delegates.
-- **`core/cache/CacheElement.js` vs `core/cache/wtinylfu/CacheElementWTinylfu.js`** — already correct reuse via `extends`.
-- **30 `binary_search_inline` pattern hits from the brief** — false positive. All but one are quicksort pivot midpoints (`(left + right) >> 1`) or unrelated bit shifts (`header >>> 1`, `triangle_mask >>>= 1`). The only real binary search in the list, `binarySearchHighIndex.js:23`, *is* the canonical primitive and has 8 external callers. Nothing bypasses it.
-- **`Color.fromBinaryBuffer` / `Quaternion.fromBinaryBuffer` / `Vector4.fromBinaryBuffer` (49-token identical group)** — per-type binary adapters reading N float32s. Shape, not logic; deliberate typed serialization surface.
-- **`core/bvh8/bvh8_convert_to_dot.js:110` vs `engine/intelligence/behavior/behavior_to_dot.js:240`** — both emit Graphviz `digraph{…}` wrappers; the ~6 shared lines are the DOT preamble/epilogue. Below the noise floor.
-
-## Notes
-
-Structural reasons duplication concentrates in this domain:
-
-1. **The 2D/3D split is implemented by forking files, not by parameterising a dimension.** Three separate
-   forks exist along exactly this seam — `BVH` ⟷ `BVH2D` (finding #1), `BinaryUint32BVH` ⟷ `StaticR2Tree`
-   (#2), and the query families that hang off each. In every case the *spatial* code is ~15% of the file
-   and the *topological* code (allocator, free list, parent/child links, stack traversal, rebalancing) is
-   ~85%, yet the fork is drawn around the whole class. Both forks have already produced measurable
-   divergence: the SAH rotation upgrade reached only the 3D tree, and an AABB word-count bug had to be
-   fixed independently in the 2D one.
-
-2. **Typed-array specialisation is used as a reason to fork the whole class rather than the storage.**
-   `Uint32Heap`/`Uint32Heap4` and `IndexedFloatMaxHeap`/`IndexedFloatMinHeap` are both 90%+ identical, and
-   in both cases the specialised part is 2–4 methods. The `IndexedFloat*` pair at least *documents* the
-   decision (`IndexedFloatMinHeap.js:19-23`); the `Uint32Heap4` pair does not, and inherits an
-   `__remove_by_index` implementation whose correctness depends on the very constant that was changed.
-
-3. **Hot-path inlining is applied without a rule for when it stops.** The BVH query directory contains a
-   complete generic implementation (`bvh_query_user_data_generic` + four `BVHQuery*` predicate classes)
-   *and* eight hand-inlined specialisations of it. Inlining the ray and sphere queries is defensible;
-   inlining `compute_tight_near_far_clipping_planes` and `bvh_collect_user_data` is not, and it is in
-   exactly those cold copies that the child-visit-order invariant silently inverted (finding #3).
-
-4. **There is a documented hash convention with no implementation.** `CSRGraph.js:275` names
-   "meep's standard `(h*31 + element)` convention", but there is no `hash_combine` in `core/math/hash/`
-   (which does contain `murmur3_32`, `squirrel3`, `lowbias32`). Fifteen sites therefore re-type the
-   expression, and the three variants of the *finalisation* step — `| 0`, `>>> 0`, and nothing at all —
-   are the direct consequence. The same re-derivation produced three copies of an `(array, offset, length)`
-   signature that no member actually honours.
-
-5. **Shared mutable scratch state is imported ad hoc.** `SCRATCH_UINT32_TRAVERSAL_STACK` has 17 importers
-   spanning BVH traversal, R-tree traversal, *and* two array sorts. The BVH consumers document the
-   no-throw/no-reentrancy precondition; the sorts do not, and two sibling sorts use private arrays instead.
-   Duplicating a primitive is one failure mode; duplicating a *precondition* across files that never
-   reference each other is the harder one to detect.
+# Domain B — core (data structures, binary, graph, cache, parser, color)
+
+Scope: `meep/src/core/` excluding `core/geom` and `core/math` (2D counterparts under `core/geom` are
+cited where they are the *other half* of a fork whose primary copy lives in my domain).
+
+Quantification method: for the whole-file forks I computed the LCS over comment-stripped,
+whitespace-normalised code lines (`shared / A vs B`). Those numbers are reproducible and are what
+the "Evidence" column cites.
+
+## Findings
+
+| # | Severity | Concept | Sites | Evidence | Verdict | Proposed common path | Effort/Risk |
+|---|---|---|---|---|---|---|---|
+| 1 | CRITICAL | **Dynamic BVH tree is forked wholesale for 2D.** Node allocator, free-list, capacity growth, all 10 node-field accessors, `insert_leaf` (SAH branch-and-bound descent), `remove_leaf`, `bubble_up_refit`, `bubble_up_update`, `balance`, `traverse`, `collect_nodes_all`, `__move_node_links`, `swap_nodes` are the same code with `ELEMENT_WORD_COUNT` 10→8 and 6→4 AABB floats. | `core/bvh2/bvh3/BVH.js:73` `class BVH` ⟷ `core/geom/2d/bvh/BVH2D.js:70` `class BVH2D`. Method-for-method: `__grow_capacity` 217/155, `__set_capacity` 240/178, `allocate_node` 300/214, `release_node` 358/270, `node_is_leaf` 369/281, `node_get/set_{user_data,child1,child2,parent,height}` 381–471 / 293–383, `node_move_aabb` 528/434, `insert_leaf` 663/557, `bubble_up_refit` 775/675, `bubble_up_update` 803/705, `remove_leaf` 845/740, `balance_height` 902 ⟷ `balance` 792, `release_all` 1291/997, `traverse` 1302/1008, `collect_nodes_all` 1340/1046, `__move_node_links` 1357/1063, `swap_nodes` 1394/1100. Column constants re-exported: `BVH.js:10-13,21,27,47` ⟷ `BVH2D.js:11-14,22,28,48`. | **UNJUSTIFIED** | **521 of 576 BVH2D code lines are shared with BVH.js (90%).** Only 7 methods are truly dimension-specific (`allocate_node`'s ±INF init, `node_get_aabb`, `node_set_aabb`, `node_set_aabb_primitive`, `node_get_surface_area`, `node_get_combined_surface_area`, `node_set_combined_aabb`) ≈ 130 lines. **The fork has already cost a real divergence:** `BVH.bubble_up_update:806` uses the Box2D-v3 SAH rotation `balance_rotate` (added with a long design comment and `balance_rotate.spec.js`), while `BVH2D.bubble_up_update:713` still calls the Box2D-v2 height-AVL `balance`; and `BVH2D.bubble_up_refit:681` balances on every refit whereas `BVH.bubble_up_refit:775` deliberately does not. The 2D tree silently never received the SAH upgrade. Also missing in 2D: `data_buffer` get/set (serialisation round-trip, with a fix comment at `BVH.js:107-112`), `size` getter, `allocate_linear`, `node_assign_children{,_only}`. | Extract a shared `BvhTreeBase` holding the topology half (allocator/free-list/capacity/child-parent-height accessors/insert/remove/refit/balance/traverse/swap), and leave the ~7 AABB methods + `ELEMENT_WORD_COUNT`/column constants as the per-dimension typed subclass surface (`BVH extends BvhTreeBase`, `BVH2D extends BvhTreeBase`). Column offsets become `static` class fields on the subclass, not string keys — no magic. Keep both public classes and their exported constants (library surface). | **High effort / High risk.** ~500 lines move; two standing spec suites (`BVH.spec.js`, `balance_rotate.spec.js`) plus every physics broadphase consumer gate it. Do it in two steps: (a) port `balance_rotate` + the missing methods into BVH2D so the two are behaviourally aligned *first*, (b) then unify. Step (a) alone is worth doing even if (b) is rejected. |
+| 2 | HIGH | **Static Morton-ordered binary tree forked for 2D** — `build()` (bottom-up level assembly), `sort_morton()` (explicit-stack quicksort on Morton codes), `__swap_leaves()`, `initialize_structure()`, `setLeafCount()`, `setLeafData()`, `getLeafBlockAddress()`, `readLeafPayload()`, and a module-private `copy_box_zero_size()` are duplicated. | `core/bvh2/binary/2/BinaryUint32BVH.js:426` `build` ⟷ `core/geom/2d/r-tree/StaticR2Tree.js:313` `build` (token-identical, 289 tokens); `BinaryUint32BVH.js:336` `sort_morton` ⟷ `StaticR2Tree.js:210` `sort_morton`; `BinaryUint32BVH.js:411` `__swap_leaves` ⟷ `StaticR2Tree.js:296`; `BinaryUint32BVH.js:35` `copy_box_zero_size` ⟷ `StaticR2Tree.js:51` (same private helper, same name, two files). | **UNJUSTIFIED** | 113 of 205 StaticR2Tree code lines shared. **A bug caused by the copy is already documented in the tree:** `StaticR2Tree.js:346-347` carries the comment "a 2D box is 4 floats \[x0,y0,x1,y1\] (copying 6 would spill into the following node's data)" — i.e. the 3D `array_copy(..., 6)` was pasted into the 2D file and had to be fixed there. Exactly the "fix in one copy misses the other" class. | Same shape as #1: a `MortonLeafTreeBase` carrying `build`/`sort_morton`/`__swap_leaves`/`copy_box_zero_size` parameterised by two `static` sizes (`BINARY_NODE_SIZE`, `LEAF_NODE_SIZE`) and one abstract `combine_bounds(dst_off, a_off, b_off)` that the subclass points at `aabb3_array_combine` / `aabb2_union_array`. | Medium effort / Medium risk. `build()` is cold (construction only), so the one virtual call per node pair is irrelevant. `sort_morton` is warm but only at build. |
+| 3 | HIGH | **Traversal-order invariant duplicated 14× and drifted.** Every hand-written BVH2 traversal repeats the same stack skeleton *and* the comment "write to stack in reverse order, so that first child ends up being visited first" — but half of them push `child1` then `child2`, which visits **child2 first**, the opposite of what the comment claims and of what the generic implementation does. | Comment-matching (child2 pushed first): `core/bvh2/bvh3/query/bvh_query_user_data_generic.js:74-76`, `core/bvh2/bvh3/query/bvh_query_leaves_generic.js:65-67`, `bvh_query_user_data_ray.js:85-86`, `bvh_query_user_data_ray_segment.js:89-90`, `bvh_query_leaves_ray.js:79-80`, `bvh_query_leaves_ray_segment.js:83-84`. Comment present but **contradicted** (child1 pushed first): `bvh_collect_user_data.js:52-54`, `bvh_query_user_data_intersects_aabb.js:74-76`, `bvh_query_user_data_intersects_sphere.js:83-85`, `bvh_query_user_data_intersects_capsule.js:92-94`, `bvh_query_user_data_intersects_frustum.js:73-75`, `compute_tight_near_far_clipping_planes.js:182-184`. | **UNJUSTIFIED** | The result *ordering* of `bvh_query_user_data_intersects_sphere` is the reverse of `bvh_query_user_data_generic` + `BVHQueryIntersectsSphere` (`core/bvh2/bvh3/query/BVHQueryIntersectsSphere.js`), which computes the same set. Since this project has a standing determinism gate, "same set, different order" is a live hazard: switching a caller between the two paths silently reorders results. The generic path with `BVHQuery*` objects already exists and is fully implemented — the specialised files are hand-inlined copies of it. | Two separate actions, both cheap: (a) **normalise the push order in the 6 contradicting files** so all 14 agree with the documented invariant (pure ordering fix, spec-guarded); (b) for the *cold* consumers among them (`compute_tight_near_far_clipping_planes`, `bvh_collect_user_data`) delete the inlined skeleton and call `bvh_query_user_data_generic` with the corresponding `BVHQuery*` object. Leave the genuinely hot ray/AABB/sphere ones inlined — that inlining is legitimate. | (a) Low effort / Low risk. (b) Low effort / Low risk, cold code only. |
+| 4 | HIGH | **`Uint32Heap4` is a whole-file copy of `Uint32Heap`** with only the arity arithmetic changed. | `core/collection/heap/Uint32Heap.js:56` `class Uint32Heap` ⟷ `core/collection/heap/Uint32Heap4.js:59` `class Uint32Heap4`. Identical bodies: `constructor` 63/62, `__capacity_grow` 101/100, `compare` 131/130, `swap` 146/145, `size`/`capacity`/`top_id`/`is_empty`/`peek_score`/`peek_min` getters, `pop_min` 274/289, `find_index_by_id` 301/316, `contains`, `clear`, `remove`, `__remove_by_index` 356/371, `update_score`, `__update_score_by_index` 391/406, `get_score`, `insert_or_update`, `insert` 447/462. Differing: `HEAP_PARENT` (`>>1` vs `>>2`), `HEAP_LEFT`/`HEAP_RIGHT` vs `HEAP_FIRST_CHILD`, `heap_down` (2 vs 4 child compares), `heap_up`'s parent shift. | **UNJUSTIFIED** | **194 of 208 code lines shared (93%).** Only 4 of 22 members carry the 4-ary difference; the storage layout (packed float32 score + uint32 id, 8 bytes/slot) is byte-identical. `__remove_by_index` is a `pop_min`-based delete that depends on `HEAP_PARENT` — if that routine is ever fixed (it is O(depth) swaps rather than a sift), the fix lands in one file only. `Uint32Heap.js:57` still carries the Blender attribution comment that `Uint32Heap4` dropped. | Shared base `Uint32ScoreHeapBase` owning storage + all id-lookup/insert/remove/update machinery, with `heap_up`/`heap_down` (and only those) overridden per arity. Both are already using `this.compare`/`this.swap` method calls in their inner loops, so no new polymorphism is introduced on the hot path — the megamorphic risk argument does not apply here (`heap_up`/`heap_down` are the *leaf* of the call chain, not the caller). | Medium effort / Low risk. `Uint32Heap.spec.js` + `Uint32Heap4.spec.js` both exist and gate it. |
+| 5 | HIGH / PROMOTION | **No canonical `hash_combine` primitive.** The `(h << 5) - h + v` (== `h*31 + v`) step is written out inline at 15+ sites in `core/` alone (74 project-wide), with **three mutually incompatible normalisations** and a shared-but-broken `(array, offset, length)` contract. | `core/collection/array/computeHashArray.js:10` (`hash \|= 0`, signed), `core/math/hash/computeHashFloatArray.js:8` (`\|= 0`), `core/collection/array/computeStridedArrayHash.js:14` (`>>> 0`, unsigned), `core/collection/array/computeStridedIntegerArrayHash.js:9` (`>>> 0`), `core/primitives/strings/computeStringHash.js:10` (`>>> 0`), `core/collection/array/typed/uint8_array_hash.js:8`, `uint16_array_hash.js:8`, `uint32_array_hash.js:8` (**neither** — the accumulator escapes int32 into a double), `core/collection/list/List.js:967`, `core/collection/table/RowFirstTable.js:146`, `core/graph/csr/CSRGraph.js:281-292`, `core/model/BoundedValue.js:180-182`. `CSRGraph.js:275` explicitly documents it as "meep's standard `(h*31 + element)` convention" — a convention with no implementation. | **PROMOTION** | Three concrete consequences, all from re-derivation rather than reuse: (i) `uint32_array_hash` never truncates, so `((hash<<5)-hash) + channel_value` with `channel_value` near 2^32 produces a non-int32 double and the "32-bit rolling hash" property is lost — then `CSRGraph.hash():285` feeds that double straight back into another combine step; (ii) signed vs unsigned finalisation means the same byte sequence hashes differently depending on which family member you call; (iii) the shared `(array, offset, length)` signature is interpreted as `length = absolute end index` by all three `uintN_array_hash` (loops run `i < length`, not `i < offset + length`, so a non-zero `offset` under-reads), and `core/collection/array/typed/sparse_typed_array_hash.js:13` accepts `offset` and then **discards it**, passing a hard-coded `0` to `computeStridedArrayHash`. All current callers pass `offset === 0`, so nothing is visibly broken today — which is exactly why it will bite later. | Add `core/math/hash/hash_combine.js` — `export function hash_combine(hash, value) { return (((hash << 5) - hash) + value) | 0; }` — and a companion `hash_finalize(h) { return h >>> 0; }`. Rewrite the 8 array/string hash functions on top of it, and fix the `offset`/`length` contract to `count` semantics in the same change (with the three `.spec.js` files as the gate). Do **not** touch the inline uses inside genuinely hot scalar loops (`List.js:967`, `RowFirstTable.js:146`) beyond making them agree on finalisation. | Medium effort / **Medium risk** — changing finalisation changes hash *values*. Anything persisting a hash (serialised caches, `RowFirstTableSpec` keys) must be checked first. Safe subset: land `hash_combine` + fix the `offset` contract without changing any finalisation. |
+| 6 | MEDIUM | **`IndexedFloatMinHeap` is a copy of `IndexedFloatMaxHeap`** with the comparison operators flipped. | `core/collection/heap/IndexedFloatMaxHeap.js:37` `class IndexedFloatMaxHeap` ⟷ `core/collection/heap/IndexedFloatMinHeap.js:37` `class IndexedFloatMinHeap`. Identical: `constructor` 38/45, `clear` 65/72, `__swap_slots` 83/90, `__grow_capacity` 151/158, `insert` 167/174, `update` 212/219, `remove` 231/238, plus `size`/`has`/`get_score`/`peek`. Differing: 6 comparison operators inside `__sift_down` 108/115, `__sift_up` 137/144, `update` 224-228, `remove` 258-261; and `pop_max` 185 ⟷ `pop_min` 192. | **JUSTIFIED (documented, but the stated reason is weaker than claimed)** | **154 of 168 code lines shared (92%).** `IndexedFloatMinHeap.js:19-23` carries an explicit rationale: "deliberately a standalone copy rather than a subclass … extracting the order-specific `__sift_*` comparisons behind an overridable method would turn the hot-loop call sites polymorphic and defeat V8 inlining." That reasoning is correct *for the subclass approach they considered*, and per house rules I will not argue against a measured perf choice. Worth recording, though: the subclass approach is not the only one — a min-heap is a max-heap over negated scores, which needs zero new polymorphism (negate in `insert`/`update`, negate on read in `peek`/`get_score`). That would collapse ~150 lines with no call-site polymorphism at all, at the cost of `-0`/NaN edge semantics. | No change recommended without a measurement. If revisited, prefer the negation wrapper over a base class. | n/a |
+| 7 | MEDIUM | **Robin-Hood open-addressing machinery duplicated** between the single-key and pair-key uint32 maps: probe loop with displacement early-exit, steal-on-insert, backward-shift deletion, power-of-two capacity + `Math.clz32` shift, load-factor growth, rehash-on-resize. | `core/collection/Uint32Map.js:63` ctor / `:126` `get` / `:198` `__insert_no_grow` / `:249` `delete` / `:326` `__resize` ⟷ `core/collection/PairUint32Map.js:62` ctor / `:106` `get` / `:168` `__insert_no_grow` / `:224` `delete` / `:297` `__resize`. | **UNJUSTIFIED** | 100 of 178 code lines shared (the LCS is depressed by identifier renames — `slot2`/`k` vs `off`/`ka` — the *algorithm* is line-for-line the same). Differences are exactly two: slot stride (2 vs 3 words) and the hash (`Math.imul(k, FIB)` vs `imul(ka, MIX_A) ^ imul(kb+1, MIX_B)`). Everything invariant-bearing — the `dist > slot_dist` early-exit, the `slot_dist < dist` steal, the `next_dist === 0` stop condition in backward-shift delete — is duplicated verbatim. These are the classic hard-to-get-right parts of Robin Hood; a fix to one will not reach the other. Note `PairUint32Map` already routes its hash through a `this.__hash(...)` **method call** inside every probe iteration, so the "monomorphic hot loop" argument that justifies #6 does not apply here. | Shared `Uint32RobinHoodMapBase` owning capacity/mask/shift/threshold/size/`__data`, the probe skeleton, steal, backward-shift delete and resize, parameterised by a `static SLOT_STRIDE` and an abstract `__hash(...)` / `__slot_matches(off, …)` pair. Both public classes and their `*_ABSENT` constants stay (library surface). | Medium effort / Medium risk. `Uint32Map.spec.js` and `PairUint32Map.spec.js` both exist. |
+| 8 | MEDIUM | **Four quicksort implementations** sharing one explicit-stack partition skeleton; two of them are already fully expressible by a third. | `core/collection/array/array_sort_quick.js:18` `array_sort_quick(data, score_function, ctx, start, end, swap_operator, swap_ctx)`; `core/collection/array/array_quick_sort_by_comparator.js:11`; `core/collection/array/array_quick_sort_by_lookup_map.js:16`; `core/collection/array/array_quick_sort_by_lookup_uint.js:15`. A fifth copy of the same skeleton is inlined at `core/bvh2/binary/2/BinaryUint32BVH.js:336` `sort_morton` and a sixth at `core/geom/2d/r-tree/StaticR2Tree.js:210`. | **UNJUSTIFIED** (for the two lookup variants) | `array_quick_sort_by_lookup_map` and `array_quick_sort_by_lookup_uint` differ from each other by **one token** (`lookup.get(x)` vs `lookup[x]`) across 35 lines, and both are exactly `array_sort_quick(data, t => lookup.get(t), …)` / `array_sort_quick(data, t => lookup[t], …)`. `array_sort_quick` already takes a score function and a context, so no closure allocation is needed. A second, sharper problem: the four copies do **not** agree on stack ownership — `array_sort_quick.js:4` and `array_quick_sort_by_comparator.js:1` each hold a *private* `const stack = []`, while the two lookup variants (`:3`) alias the **globally shared** `SCRATCH_UINT32_TRAVERSAL_STACK`, which is simultaneously the BVH traversal stack (17 other importers). Sorting from inside a BVH query callback silently corrupts that traversal; the private-array copies have no such hazard. The invariant is duplicated three ways and reconciled nowhere. | Delete the bodies of the two lookup variants and implement them as one-line delegations to `array_sort_quick` (keep both exports — library surface). Separately, decide the stack-ownership rule once: either all sorts own a private stack, or all document the shared-stack precondition the way `bvh_query_user_data_generic.js:9-14` does. | Low effort / Low risk. `array_quick_sort_by_lookup_map.spec.js`, `..._uint.spec.js`, `array_sort_quick.spec.js` all exist. |
+| 9 | MEDIUM | **Intrusive MRU doubly-linked-list splice duplicated** between the two cache implementations. | `core/cache/Cache.js:149` `__promote(element)` ⟷ `core/cache/wtinylfu/CacheRegionWTinylfu.js:78` `touch(element)` (token-identical, 68 tokens). Also `core/cache/Cache.js:481` `__removeElement` ⟷ `core/cache/wtinylfu/CacheRegionWTinylfu.js:112` `__removeElement` — same head/tail fix-up + `element.unlink()`. | **UNJUSTIFIED** | The head/tail-pointer maintenance around `CacheElement.unlink()` (`core/cache/CacheElement.js`) is the whole of both routines, and it is the part with the invariant (a node that *is* `__first` must not be re-linked; a node that *is* `__last` must move the tail back before unlinking). `CacheElementWTinylfu` **already** extends `CacheElement`, so the element type is shared — only the list head/tail holder was re-derived. | Promote the head/tail pair into a small `IntrusiveMruList` (fields `#first`/`#last`, methods `add`, `promote`, `detach`) in `core/cache/`, and have both `Cache` and `CacheRegionWTinylfu` hold one. `CacheRegionWTinylfu` keeps its weight accounting; `Cache` keeps its `data` map and signals. | Low effort / Low risk. `Cache.spec.js`, `CacheRegionWTinylfu.spec.js`, `CacheWTinylfu.fuzz.spec.js` all exist. |
+| 10 | MEDIUM | **BVH8 geometry validator duplicated** for the direct vs pool-indirect triangle addressing conventions. | `core/bvh8/bvh8_geometry_validate.js:29` `bvh8_geometry_validate_bounds` ⟷ `core/bvh8/bvh8_geometry_validate_indirect.js:29` `bvh8_geometry_validate_bounds_indirect`; plus a byte-identical private `aabb3_round_to_float32` at `bvh8_geometry_validate.js:13` ⟷ `bvh8_geometry_validate_indirect.js:13`. | **UNJUSTIFIED** | **76 of 83 code lines shared (92%).** The entire difference in the bounds walk is one line: `const triangle_index = triangle_offset + base_index_triangle + j;` vs `= pool[triangle_offset + base_index_triangle + j];`. This is a *validator* — cold, debug-only code, run once after a build — so there is no perf argument for inlining. The duplicated `aabb3_round_to_float32` helper is pure and belongs next to the other `aabb3_*` helpers. | Move `aabb3_round_to_float32` to a shared module. For the walk, pass the resolved index array explicitly: give the direct caller an identity `Uint32Array` view or, better, have `bvh8_geometry_validate` build the trivial identity pool once and call the single indirect implementation. No sentinel parameter, uniform control flow. | Low effort / Low risk. Cold path, both are already `throw`-on-violation. |
+| 11 | MEDIUM | **`ebvh_geometry_query_any_triangle_ray` is a copy of `ebvh_geometry_query_nearest_triangle_ray`** with the "keep best" bookkeeping replaced by an early return. | `core/bvh2/bvh3/ebvh_geometry_query_any_triangle_ray.js:30` ⟷ `core/bvh2/bvh3/ebvh_geometry_query_nearest_triangle_ray.js:25`. | **JUSTIFIED (hot path, and the algorithms genuinely differ)** | 70 of 80 code lines shared, but the 10 that differ are the algorithm: `any` prunes on a *fixed* `max_distance_sqr` and unwinds the stack on first hit (`stack.pointer = stack_top; return true`), `nearest` prunes on a *shrinking* `best_t * best_t` and must drain the whole stack. Occlusion/shadow rays are the hottest query in the path tracer; merging them behind a flag would put a branch in the innermost loop and would also require the "unwind and return" to become a sentinel-driven exit — a direct house-rule violation. Recorded so a future reader does not re-flag it. | No change. Consider a cross-reference comment on `..._nearest_...` mirroring the one already on `..._any_...:11-15`. | n/a |
+| 12 | MEDIUM | **Graph-layout helpers duplicated between the box and circle layouters**, including a verbatim topological-layer peel. | `core/graph/layout/box/BoxLayouter.js:361` `buildLayer` (inside `doLayerLayout:355`) ⟷ `core/graph/layout/CircleLayout.js:25` `buildLayer` (inside `doLayerLayout:19`) — token-identical, 116 tokens. `BoxLayouter.js:301` `applyClusteredLayoutStep` ⟷ `CircleLayout.js:88` `applyClusteredLayoutStep`. `BoxLayouter.js:431` `centerAABB2CollectionOn` ⟷ `CircleLayout.js:250` `centerCircleCollectionOn`. | **UNJUSTIFIED** (for `buildLayer`) / **PROMOTION** | `buildLayer` touches no geometry at all — it peels nodes whose `connections[].source` are all already laid out. It is pure graph topology and identical in both files. `applyClusteredLayoutStep` has already diverged: the cluster-translation loop honours `if (box.locked) return;` at `CircleLayout.js:135-138` but **not** at `BoxLayouter.js:341-347`, so locked boxes are moved by cluster gravity in the box layouter and not in the circle one. Same divergence in `centerCircleCollectionOn:256-259` vs `centerAABB2CollectionOn:431`. Only one of the two behaviours can be right. | Hoist `buildLayer` to `core/graph/layout/graph_peel_topological_layer.js` (takes `nodes[]`, mutates/returns the layer) and call it from both `doLayerLayout`s. Decide the `locked` semantics once and apply it to both `applyClusteredLayoutStep` copies — do that even if the functions stay separate. | Low effort / Low risk for `buildLayer`. The `locked` reconciliation is a behaviour decision, not a refactor. |
+| 13 | MEDIUM | **Ray vs ray-segment BVH queries duplicated** — the traversal is byte-identical, only the AABB predicate and two extra parameters differ. | `core/bvh2/bvh3/query/bvh_query_leaves_ray.js:27` ⟷ `bvh_query_leaves_ray_segment.js:30`; `bvh_query_user_data_ray.js:26` ⟷ `bvh_query_user_data_ray_segment.js:29` (39 of 44 code lines shared). | **JUSTIFIED (hot path) — but flag the API asymmetry** | These are the innermost traversals of the path tracer and the physics raycaster; the inlined `float32[address + n]` reads and the absence of a predicate call are the point. However the copies expose an inconsistency worth fixing on its own merits: `bvh_query_leaves_ray.js:65-69` passes **raw** direction components to `aabb3_intersects_ray`, while `bvh_query_leaves_ray_segment.js:68-70` passes **reciprocals** (`1 / direction_x`, …) to `aabb3_intersects_ray_segment` — and computes those three divisions *per node*, inside the loop, instead of once before it. | Leave the duplication. Hoist the three reciprocals out of the traversal loop in both `*_ray_segment` files, and align the two `aabb3_intersects_ray*` signatures on one convention (both raw or both reciprocal). | Low effort / Low risk. |
+| 14 | MEDIUM | **Four colour-adjustment operators are the same 20-line body** (`assert` pair → early-return on `amount === 0` → `new Color()` → `linear_srgb_to_okhsv` → scale one OkHSV channel → `okhsv_to_linear_srgb`). | `core/color/operations/color_lighten.js:15`, `color_darken.js:15`, `color_saturate.js:15`, `color_desaturate.js:15` — each also carries its own module-static `const hsv = [0,0,0]` scratch. | **UNJUSTIFIED** | The only difference is the channel index (`hsv[2]` vs `hsv[1]`) and the factor. And the factor has already drifted: `color_darken.js:29` uses `clamp01(hsv[2] * clamp01(1 - amount))` (inner clamp on the factor) while `color_desaturate.js:29` uses `clamp01(hsv[1] * (1 - amount))` (no inner clamp). They happen to agree numerically because of the outer `clamp01`, which is luck, not design — and it means a reader cannot tell which form is intended. Note also all four call `okhsv_to_linear_srgb(r, ...hsv)`, spreading an array on every call (an allocation in what is otherwise carefully allocation-free colour code). | One non-exported `color_scale_okhsv_channel(input, channel, factor)` in `core/color/operations/`, with the four public functions as three-line typed wrappers. Public API and file layout unchanged (library surface preserved); the channel index is a numeric constant, not a string key, so no magic-registry rule is violated. Replace the four `...hsv` spreads with explicit `hsv[0], hsv[1], hsv[2]` while in there. | Low effort / Low risk. |
+| 15 | LOW | `bvh_query_user_data_nearest_to_point_filtered` is `bvh_query_user_data_nearest_to_point` with a predicate on the leaf-accept step. | `core/bvh2/bvh3/query/bvh_query_user_data_nearest_to_point.js:16` ⟷ `core/bvh2/bvh3/query/bvh_query_user_data_nearest_to_point_filtered.js:28`. | **JUSTIFIED (avoiding an optional-callback sentinel)** | ~55 lines duplicated for one `if (filter(user_data))`. Unifying would mean an optional `filter` parameter that defaults to "accept everything" — precisely the `x === null ? auto : override` shape the codebase rejects, and it would add an indirect call per accepted leaf on a branch-and-bound search. The `_filtered` variant already documents the shared-stack re-entrancy contract properly (`:14-17`), which the unfiltered one does not. | No merge. Copy the re-entrancy/`SCRATCH_UINT32_TRAVERSAL_STACK` doc block onto the unfiltered variant so the contract is stated in both. | Trivial / none. |
+| 16 | LOW | Decimal and hex integer token readers duplicate a 45-line `switch` over digit characters. | `core/parser/simple/readHexToken.js:13` ⟷ `core/parser/simple/readUnsignedIntegerToken.js:13`. | **UNJUSTIFIED** | Cases `'0'`–`'9'` are identical in both (20 lines); hex adds `a-f`/`A-F` and swaps `value * 10` for `value * 16`. Cold code (a config/expression parser, not a hot loop). The copy has already produced dead code, called out in-tree: `readHexToken.js:96-100` notes the per-character `i === cursor` guard inherited from the decimal version "is dead code because i starts at cursor + 2" — the guard is still there in both. | One `char_to_digit(char)` returning `-1` for non-digits (0–15 for hex chars), used by both readers with a `radix` bound check. Removes the dead guard as a side effect. | Low effort / Low risk. Both have callers via `core/parser/simple`. |
+| 17 | LOW | `insert_after` / `insert_before` and `insert_after_or_replace` / `insert_before_or_replace` — four near-identical string splice helpers; the `_or_replace` pair re-implements the plain pair's body rather than calling it. | `core/primitives/strings/insert_after.js:8`, `insert_before.js:8`, `insert_after_or_replace.js:9`, `insert_before_or_replace.js:9`. | **UNJUSTIFIED (marginal)** | The four differ only in whether the insertion offset is `i` or `i + term.length`. All four are cold (shader-source patching). The `_or_replace` variants can't literally call the plain ones because they must distinguish "not found" from "found" without the `console.warn` side effect — but a shared `splice_at(source, position, value)` would still remove the duplicated `slice`/`+`/`slice` idiom. | One private `string_splice(source, position, value)`; the four public exports become 3–5 lines each. Keep all four exports. | Trivial / none. |
+| 18 | LOW | `futureTask` and `promiseTask` build the same `Task` from the same `resolved`/`rejected`/`error` closure trio. | `core/process/task/util/futureTask.js:10` ⟷ `core/process/task/util/promiseTask.js:10`. | **JUSTIFIED (barely) — uniform control flow** | ~35 lines shared. `futureTask` differs by a `typeof future.resolve !== 'function'` guard and by calling `future.resolve()` at the top of every `cycle()` (it *pumps* the future, `promiseTask` only waits). Factoring that out needs an optional pre-cycle hook — a sentinel parameter. Leave it. | No change. | n/a |
+| 19 | LOW | `MEASUREMENT_UNITS_SI` and `UNIT_DIMENSION_MAPPING` are the **same seven `NamedUnit` values in the same order**, exported twice from two files with the same seven imports. | `core/science/units/MEASUREMENT_UNITS_SI.js:20` ⟷ `core/science/units/UNIT_DIMENSION_MAPPING.js:21`. | **UNJUSTIFIED** | Both are `[METER, KILOGRAM, SECOND, AMPERE, KELVIN, MOLE, CANDELA]`, both are consumed by `unit_matrix_to_string` / `format_quantity`, and both encode the invariant "array index === `UnitDimension` ordinal". If the dimension order ever changes, one of the two will be missed and the other will silently mis-label every quantity. The JSDoc on each explains a *usage* difference, not a *value* difference. | Keep both exports (library surface) but make one derive from the other: `export const MEASUREMENT_UNITS_SI = UNIT_DIMENSION_MAPPING;` with the existing doc retained, so the ordering invariant has exactly one definition. | Trivial / Low risk. `MEASUREMENT_UNITS.spec.js` and `UNIT_DIMENSION_MAPPING.spec.js` both exist. |
+| 20 | LOW | Two connected-components implementations, one of them quadratic. | `core/graph/layout/computeDisconnectedSubGraphs.js:6` ⟷ `core/graph/graph_compute_disconnected_clusters.js:6`. | **UNJUSTIFIED (already acknowledged in-tree)** | Same BFS-over-a-worklist algorithm. `computeDisconnectedSubGraphs.js:2` already carries `NOTE: use graph_compute_disconnected_clusters instead where possible`, and it uses `unexplored.indexOf(node)` + `splice` inside the inner loop — O(n²) — where the other uses a `Set`. It has two live callers (`BoxLayouter.js:303`, `CircleLayout.js:90`) that pass `{connections: Connection[]}` node objects rather than a `Graph`. | Give `graph_compute_disconnected_clusters` a sibling that takes an edge-accessor over plain node objects, or make the two layouters build a `Graph`. Failing that, at minimum swap the `indexOf`/`splice` for a `Set` so the two implementations have the same complexity. | Low effort / Low risk. Layout output ordering may shift — check `CircleLayout.spec.js`. |
+| 21 | LOW | Inline 2-D length/distance re-derived next to an imported primitive that already does it. | `core/graph/layout/CircleLayout.js:288` (`Math.sqrt(dX*dX + dY*dY)` — this file already imports `v2_distance` at `:5`), `CircleLayout.js:745`, `CircleLayout.js:880`, `core/graph/layout/box/position_box_next_to_box.js:37`. Related: `BoxLayouter.js:32` `evaluateEdgeCost` uses `Vector2._distance(...)` while `CircleLayout.js:344` `evaluateEdgeCost` uses `v2_distance(...)` for the identical computation. | **UNJUSTIFIED (cold code)** | Layout runs once per graph edit, not per frame, so there is no inlining justification. Two different primitives (`Vector2._distance` and `v2_distance`) are used for the same operation in two files that otherwise mirror each other. | Use `v2_length`/`v2_distance` at the four inline sites, and pick one of the two distance primitives for both `evaluateEdgeCost` copies. | Trivial / none. |
+
+## Dismissed leads
+
+- **`core/debug/matchers/matchers.js` vs `core/process/matcher/{not,isNull,isDefined}.js`** — name collision only. `core/debug` is a Hamcrest-style DSL returning `Matcher` *objects* (`new IsNot(matcher)`); `core/process/matcher` returns bare predicate *functions* (`v => !m(v)`). Different abstractions, different consumers.
+- **`core/parser/simple/readReferenceToken.js` vs `view/tooltip/gml/parser/readReferenceToken.js`** — name collision only. One parses dotted identifier chains (`a.b.c`), the other parses `[tag: k=v, k=v]` tooltip references. Zero shared code.
+- **`core/parser/simple/DataType.js` vs `core/model/node-graph/type/DataType.js`** — name collision only. One is a 5-entry frozen string enum, the other a class with `id`/`name`/`hash`/`equals`/`toJSON`.
+- **`core/graph/layout/Connection.js` vs `core/model/node-graph/Connection.js`** — name collision only. One is `{source, target, points: Vector2[]}` with a polyline `length()`; the other is a node-graph port link with `id`, `validate()`, `PortDirection`.
+- **`core/binary/data_view/DataType2DataViewReaders.js` vs `...Writers.js`** — two 10-entry lookup tables mapping `BinaryDataType` → `"getUint8"` / `"setUint8"`. Deriving one from the other means string concatenation on method names — exactly the magic-string pattern the house rules reject. Typed tables are correct here.
+- **`core/binary/split_by_2.js` vs `split_by_3.js`** — shape-identical bit-spreading, but the masks and shift counts encode genuinely different Morton interleavings (2-way vs 3-way). Not duplication.
+- **`core/color/sRGB/linear_to_sRGB.js` vs `sRGB_to_linear.js`** — inverse transfer functions with different breakpoints (0.0031308 / 0.04045), different constants and different exponents (0.4166… / 2.4). Only the 3-channel wrapper shape matches, and that's 3 lines.
+- **`core/collection/set/compute_set_difference.js` vs `compute_set_intersection.js`** — different set operations. (Separately noted, out of scope for this audit: `compute_set_difference` computes the *symmetric* difference despite its name — a naming defect, not duplication.)
+- **`core/collection/array/binarySearchHighIndex.js` vs `binarySearchLowIndex.js`** — different return contracts (ceiling/insertion point vs floor index, `-1` on underflow). The bodies diverge in the branch structure, not just a comparator.
+- **`core/collection/Uint32MinHeap.js` vs `core/collection/heap/Uint32Heap.js`** — different payloads (bare uint32 values vs id+float32 score pairs). `Uint32MinHeap.js:1-18` documents that it *is* the result of a completed promotion (two byte-identical private copies in physics were merged into it). Already fixed.
+- **`core/collection/map/HashMap.js` vs `core/collection/Uint32Map.js`** — separate-chaining map over arbitrary keys with user-supplied hash/equality vs typed-array open addressing over uint32. No shared machinery.
+- **`setFlag`/`clearFlag`/`writeFlag` repeated across 30 files** (`core/events/signal/Signal.js:59`, `SignalHandler.js:60`, +28 in `engine/`) — three-line per-class bit accessors. Extracting them would be a mixin (magic) or would make call sites *more* verbose. Justified boilerplate.
+- **Repeated `const edge_addresses = graph.edge_addresses; …` unpacking across `core/graph/metis/native/`** (`compute_2way_params.js:17-24`, `fm_2way.js:30-37`, `grow_bisection.js:25-31`, `create_coarse_graph.js:27-32`, `match_shem.js:54-58`, `initial_kway_bfs.js:36-42`, `refine/compute_kway_params.js`) — hoisting property loads out of hot loops. This is the intended idiom, not duplication.
+- **`core/model/Observed{Integer,String,Boolean,Enum,Value}.js`** — per-type `set`/`setSilent`/`onChanged` boilerplate with type-specific asserts. Shape duplication only; explicitly protected by the "typed over magic" rule.
+- **`core/json/resolvePath.js` vs `resolvePathByArray.js`** — already correct reuse; `resolvePath` splits and delegates.
+- **`core/cache/CacheElement.js` vs `core/cache/wtinylfu/CacheElementWTinylfu.js`** — already correct reuse via `extends`.
+- **30 `binary_search_inline` pattern hits from the brief** — false positive. All but one are quicksort pivot midpoints (`(left + right) >> 1`) or unrelated bit shifts (`header >>> 1`, `triangle_mask >>>= 1`). The only real binary search in the list, `binarySearchHighIndex.js:23`, *is* the canonical primitive and has 8 external callers. Nothing bypasses it.
+- **`Color.fromBinaryBuffer` / `Quaternion.fromBinaryBuffer` / `Vector4.fromBinaryBuffer` (49-token identical group)** — per-type binary adapters reading N float32s. Shape, not logic; deliberate typed serialization surface.
+- **`core/bvh8/bvh8_convert_to_dot.js:110` vs `engine/intelligence/behavior/behavior_to_dot.js:240`** — both emit Graphviz `digraph{…}` wrappers; the ~6 shared lines are the DOT preamble/epilogue. Below the noise floor.
+
+## Notes
+
+Structural reasons duplication concentrates in this domain:
+
+1. **The 2D/3D split is implemented by forking files, not by parameterising a dimension.** Three separate
+   forks exist along exactly this seam — `BVH` ⟷ `BVH2D` (finding #1), `BinaryUint32BVH` ⟷ `StaticR2Tree`
+   (#2), and the query families that hang off each. In every case the *spatial* code is ~15% of the file
+   and the *topological* code (allocator, free list, parent/child links, stack traversal, rebalancing) is
+   ~85%, yet the fork is drawn around the whole class. Both forks have already produced measurable
+   divergence: the SAH rotation upgrade reached only the 3D tree, and an AABB word-count bug had to be
+   fixed independently in the 2D one.
+
+2. **Typed-array specialisation is used as a reason to fork the whole class rather than the storage.**
+   `Uint32Heap`/`Uint32Heap4` and `IndexedFloatMaxHeap`/`IndexedFloatMinHeap` are both 90%+ identical, and
+   in both cases the specialised part is 2–4 methods. The `IndexedFloat*` pair at least *documents* the
+   decision (`IndexedFloatMinHeap.js:19-23`); the `Uint32Heap4` pair does not, and inherits an
+   `__remove_by_index` implementation whose correctness depends on the very constant that was changed.
+
+3. **Hot-path inlining is applied without a rule for when it stops.** The BVH query directory contains a
+   complete generic implementation (`bvh_query_user_data_generic` + four `BVHQuery*` predicate classes)
+   *and* eight hand-inlined specialisations of it. Inlining the ray and sphere queries is defensible;
+   inlining `compute_tight_near_far_clipping_planes` and `bvh_collect_user_data` is not, and it is in
+   exactly those cold copies that the child-visit-order invariant silently inverted (finding #3).
+
+4. **There is a documented hash convention with no implementation.** `CSRGraph.js:275` names
+   "meep's standard `(h*31 + element)` convention", but there is no `hash_combine` in `core/math/hash/`
+   (which does contain `murmur3_32`, `squirrel3`, `lowbias32`). Fifteen sites therefore re-type the
+   expression, and the three variants of the *finalisation* step — `| 0`, `>>> 0`, and nothing at all —
+   are the direct consequence. The same re-derivation produced three copies of an `(array, offset, length)`
+   signature that no member actually honours.
+
+5. **Shared mutable scratch state is imported ad hoc.** `SCRATCH_UINT32_TRAVERSAL_STACK` has 17 importers
+   spanning BVH traversal, R-tree traversal, *and* two array sorts. The BVH consumers document the
+   no-throw/no-reentrancy precondition; the sorts do not, and two sibling sorts use private arrays instead.
+   Duplicating a primitive is one failure mode; duplicating a *precondition* across files that never
+   reference each other is the harder one to detect.