@woosh/meep-engine 3.0.2 → 3.2.0

package/src/DUPLICATION_AUDIT_2026_08_07/A_core_math_geom.md

@@ -1,79 +1,79 @@
-# Domain A — core/geom + core/math
-
-Source root: `H:/git/moh/app/src/mir-engine/meep/src/` — all paths below are relative to it unless absolute.
-Every row was verified by opening the files. Rename shims (`@deprecated ... re-export`) were checked in bulk and
-are **not** duplication — see Dismissed leads.
-
-## Findings
-
-| # | Severity | Concept | Sites | Evidence | Verdict | Proposed common path | Effort/Risk |
-|---|---|---|---|---|---|---|---|
-| 1 | CRITICAL | **Whole dynamic-AABB-tree (Box2D-style) implemented twice, 2D fork has already diverged.** Node allocation, free list, capacity growth, SAH insertion, AVL rotation, refit, node swap, traversal. | `core/bvh2/bvh3/BVH.js` (1437 ln, class `BVH`) ⟷ `core/geom/2d/bvh/BVH2D.js` (1138 ln, class `BVH2D`). Method-for-method: `__grow_capacity` 217/155, `allocate_node` 300/214, `node_set_aabb` 501/411, `node_get_surface_area` 574/477, `node_get_combined_surface_area` 600/501, `insert_leaf` 663/557, `bubble_up_refit` 775/675, `bubble_up_update` 803/705, `remove_leaf` 845/740, `balance_height` 902 ⟷ `balance` 792, `traverse` 1302/1008, `__move_node_links` 1357/1063, `swap_nodes` 1394/1100. Column constants re-declared: `COLUMN_PARENT/CHILD_1/CHILD_2/HEIGHT/USER_DATA`, `NULL_NODE`, `ELEMENT_WORD_COUNT` exported from **both**. | `remove_leaf` (55 ln), `bubble_up_update` (35 ln), `swap_nodes`, `__move_node_links`, `traverse` are token-identical. `balance_height`/`balance` are 1206/1208 tokens with only 3 real diffs (`node_is_leaf(iA)` vs inline `iB === NULL_NODE`; `this.node_capacity` vs `this.__capacity`). **Proof of drift:** BVH.js has gained `balance_rotate` (SAH rotation, Box2D v3, BVH.js:1120), `allocate_linear` (:288), `node_assign_children` (:1249), `node_assign_children_only` (:1268) — BVH2D has **none** of them and still calls the old height-only rotation. Only truly dimensional code: AABB word layout (6 vs 4 floats, `ELEMENT_WORD_COUNT` 10 vs 8) and `aabb3_array_combine`/`aabb3_surface_area` vs `aabb2_union_array`/perimeter. | **UNJUSTIFIED** (2D/3D carve-out does not cover 1000 lines of dimension-independent pointer surgery) | Extract the topology half into a dimension-agnostic base holding `__data_uint32` links only: `core/bvh2/DynamicTreeTopology.js` with `allocate_node/release_node/node_get_*/insert_leaf/remove_leaf/bubble_up_*/balance_height/balance_rotate/swap_nodes/traverse`, parameterised at *class* level (subclass supplies `ELEMENT_WORD_COUNT`, `node_set_combined_aabb`, `node_get_surface_area`, `node_get_combined_surface_area` — 4 overrides, no runtime flags). `BVH extends`, `BVH2D extends`. | **L** / high. This is the physics broadphase; `determinism.spec.js` + the bvh3 suite are the gate. Risk is real — do it only with the 70-test BVH suite green before and after, and mirror `balance_rotate` into 2D as a *separate* commit so the behaviour change is isolated. |
-| 2 | HIGH | **Boolean and distance-returning AABB-vs-ray-segment slab tests, whose docs declare they MUST agree, are two independent copies of the same numerically-subtle NaN handling.** | `core/geom/3d/aabb/aabb3_intersects_ray_segment.js:35` `aabb3_intersects_ray_segment` ⟷ `core/geom/3d/aabb/aabb3_ray_segment_entry_distance.js:40` `aabb3_ray_segment_entry_distance` | Bodies are character-identical for 45 lines (ray-space shift, 6 slab `t`s, the three `t !== t` NaN probes, the `±Infinity` interval substitution, `max of mins / min of maxes`). They differ ONLY in the last 4 lines (`return t_box_min <= t_box_max` vs `if (t_box_min > t_box_max) return Infinity; return t_box_min`). The entry-distance doc states verbatim that the two "MUST agree on every input". The whole NaN dance is a hardening fix that was applied twice by hand. | **UNJUSTIFIED** | Delete the duplicated body: `export function aabb3_intersects_ray_segment(...) { return aabb3_ray_segment_entry_distance(...) !== Infinity; }`. No mode flag, no sentinel parameter — the miss sentinel already exists and is documented. | **S** / low. Both have specs. One extra call in a broadphase leaf test; V8 inlines it (single call site, monomorphic). |
-| 3 | HIGH | **Point-in-closed-triangle-surface classifier (BVH build + 3-ray parity majority vote) copy-pasted whole between the tetrahedral carver and the interior-point sampler.** | `core/geom/3d/tetrahedra/tetrahedral_mesh_carve_outside_surface.js`: `RAY_DIRECTIONS` :19, `build_surface_bvh` :33, `single_ray_parity_inside` :81, `point_is_inside_surface` :127. ⟷ `core/geom/3d/topology/struct/binary/query/bt_mesh_sample_interior_grid_points.js`: `RAY_DIRECTIONS` :12, `build_surface_bvh` :29, `point_is_inside` :78. | `build_surface_bvh` is 435 tokens, token-identical (only the parameter name `surface` vs `mesh` differs). The three magic ray directions (`0.97123, 0.18927, 0.14431`, …) are duplicated digit-for-digit; the module-static scratch (`ray_hit`, `ray_candidates`, `va`, `vb`, `vc`) is duplicated; the majority rule `inside_votes * 2 > RAY_COUNT` is duplicated. The second file's comment says "Same scheme as tetrahedral_mesh_carve_outside_surface" — an acknowledged copy. ~100 lines. | **UNJUSTIFIED** | New module `core/geom/3d/topology/struct/binary/query/bt_mesh_build_face_bvh.js` already exists for the BVH half — reuse it or add `bt_mesh_point_is_inside_surface(mesh, bvh, x, y, z)` beside it, plus `bt_mesh_build_surface_triangle_bvh(bvh, mesh)`. Both callers then hold a `BVH` and call the predicate. | **S–M** / low. Both call sites have specs (`tetrahedral_mesh_carve_outside_surface.spec.js`, `bt_mesh_sample_interior_grid_points.spec.js`). |
-| 4 | HIGH | **Radial-cycle splice (the core half-edge invariant "link a loop into an edge's face ring") implemented three times, with two of them behaviourally different from the exported canonical one.** | `core/geom/3d/topology/struct/binary/io/bt_radial_loop_add.js:9` `bt_radial_loop_add` (exported, canonical) ⟷ `core/geom/3d/topology/struct/binary/io/face/bt_face_poke.js:130` `_link_loop_to_edge_local` ⟷ `core/geom/3d/topology/struct/binary/io/bt_mesh_from_indexed_geometry.js:123` `link_loop_to_edge` | All three set `loop_write_edge`, read `edge_read_loop`, branch on `NULL_POINTER`. **Divergence 1:** `bt_radial_loop_add` splices *before* the base loop (`loop_read_radial_prev`); the other two splice *after* (`loop_read_radial_next`) — different resulting ring order. **Divergence 2:** `bt_mesh_from_indexed_geometry.link_loop_to_edge` omits the self-link (`radial_next = radial_prev = loop`) in the first-loop branch entirely; it works only because `BinaryTopology.loop_initialize` (BinaryTopology.js:686) happens to self-link on allocation — an undocumented dependency the other two do not have. **Divergence 3:** `bt_face_poke.js:127` comments "Replicates logic from 'link_loop_to_edge' since it is not exported" — but `bt_radial_loop_add` *is* exported and does exactly this. | **UNJUSTIFIED** | Both private copies call `bt_radial_loop_add(mesh, loop, edge)`. Pick one ring order deliberately (the `prev` splice) and document it in `bt_radial_loop_add`'s JSDoc as the mesh-wide invariant. | **S** / medium. Ring *order* is observable through `loop_read_radial_next` walks, so `bt_face_poke` and `bt_mesh_from_indexed_geometry` specs plus `bt_mesh_validate` must be re-run; a change in insertion side can flip which face a two-face edge reports first. |
-| 5 | HIGH | **Static implicit-binary-tree spatial index (morton quicksort + bottom-up bounds assembly) forked 3D→2D; the fork carries a scratch-stack indexing bug the original does not.** | `core/bvh2/binary/2/BinaryUint32BVH.js`: `sort_morton` :336, `__swap_leaves` :411, `build` :426 ⟷ `core/geom/2d/r-tree/StaticR2Tree.js`: `sort_morton` :210, `__swap_leaves` :296, `build` :313. Also `initialize_structure`, `setLeafCount`, `setLeafData`, `getLeafBlockAddress`, `readLeafPayload` mirror one-for-one. | `build` is 289 tokens, token-identical modulo `BVH_BINARY_NODE_SIZE`→`BINARY_NODE_SIZE`, `BVH_LEAF_NODE_SIZE`→`LEAF_NODE_SIZE`, `aabb3_array_combine`→`aabb2_union_array`, `array_copy(...,6)`→`array_copy(...,4)`. `sort_morton` is the same hand-rolled explicit-stack quicksort. **Fork bug:** `StaticR2Tree.js:219-226` sets `stackPointer = stack_top + 2` but then writes the two seed values to the *absolute* slots `stack[0]` / `stack[1]` instead of `stack[stack_top]` / `stack[stack_top + 1]`; `BinaryUint32BVH.js:350-351` correctly uses `stack[stackPointer++]`. Only reachable when the shared `SCRATCH_UINT32_TRAVERSAL_STACK` is entered with a non-zero pointer, but the two implementations now disagree on a shared-scratch contract. | **UNJUSTIFIED** | Same shape as finding #1 but far smaller: hoist the two dimension-free routines into `core/bvh2/binary/implicit_tree_sort_morton.js` + `implicit_tree_build_bounds.js` taking `(data, binary_node_count, leaf_count, binary_node_size, leaf_node_size, combine_fn, morton_fn)`. If the per-node indirect call is unacceptable for `build`, at minimum fix the seed-write divergence and cross-reference the two in JSDoc. | **M** / medium. Both classes have specs. Prefer fixing the stack-seed divergence first as its own change. |
-| 6 | HIGH | **Relative-epsilon degenerate-quadratic critical-point solver written three times in `core/math/spline`, deliberately bypassing the shared `solveQuadratic` because that one still uses an absolute epsilon.** | `core/math/spline/spline3_hermite_bounds.js:22`, `core/math/spline/spline3_hermite_bounds_t.js:26`, `core/math/spline/spline3_bezier_bounds.js:20`. Existing primitive: `core/math/solveQuadratic.js:15`. | All three contain the identical block `const epsilon = max3(abs(a),abs(b),abs(c)) * 1e-12; if (abs(a) <= epsilon) { if (abs(b) > epsilon) {...linear root...} } else { const b2ac = b*b - 4*c*a; if (b2ac >= 0) {...two roots, each gated on 0 < t < 1...} }` — and the *same 3-line explanatory comment* about relative vs absolute thresholds is copy-pasted verbatim into all three. `solveQuadratic` uses `Math.abs(a) < EPSILON` (absolute, `core/math/EPSILON.js`) — i.e. exactly the defect these three were fixed for. A future fix to the degeneracy rule now has to land in four places. | **UNJUSTIFIED** | Add `core/math/solve_quadratic_relative(result, result_offset, a, b, c) -> count` implementing the relative-epsilon rule, then have all three spline functions call it and reduce min/max (or min/max + argmin/argmax for `_bounds_t`). Note: `_bounds` and `_bounds_t` cannot be merged into one function without an output-mode flag — do **not** try; sharing the *root finder* is the whole win. Separately consider whether `solveQuadratic` should adopt the relative rule (behaviour change, own commit). | **M** / medium. All three have specs; the `_t` variant additionally tracks argmin/argmax so its reduction stays local. |
-| 7 | MEDIUM | **`ConvexHullShape3D` and `MeshShape3D` share five copy-pasted query methods.** | `core/geom/3d/shape/ConvexHullShape3D.js`: `compute_bounding_box` :185, `signed_distance_at_point` :241, `nearest_point_on_surface` :271, `sample_random_point_in_volume` :297, `equals` :322. ⟷ `core/geom/3d/shape/MeshShape3D.js`: `compute_bounding_box` :145, `nearest_point_on_surface` :421, `signed_distance_at_point` :474, `sample_random_point_in_volume` :522, `equals` :576. | `sample_random_point_in_volume` is token-identical (sim 1.0, 210 tok) — 256-attempt bbox rejection sampling with a bbox-centre fallback. `compute_bounding_box` is identical (6 array copies from `__bbox`). `equals` is identical (128 tok) modulo the field name `vertices`/`positions`. `nearest_point_on_surface` (378/381 tok) and `signed_distance_at_point` (353/356 tok) differ only in field names and local variable names — the per-triangle `tri3_closest_point_barycentric` scan is line-for-line the same. | **UNJUSTIFIED** (this is duplicated *logic*, not per-class typed boilerplate) | Three moves: (a) `sample_random_point_in_volume` becomes the default implementation on `AbstractShape3D` (it needs only `compute_bounding_box` + `contains_point`, both already abstract) — every convex shape gets it free; (b) `compute_bounding_box` from a cached `__bbox` likewise; (c) add `core/geom/3d/shape/util/shape3_surface_scan_nearest_point.js` exporting `surface_scan_nearest_point(out, positions, indices, px, py, pz) -> number` returning best_d2 — both `nearest_point_on_surface` and `signed_distance_at_point` become 5-line wrappers in both classes. | **S** / low. Both classes have specs (`ConvexHullShape3D.spec.js`, `MeshShape3D.spec.js`, `raycast.spec.js`). |
-| 8 | MEDIUM | **Bounding box of a flat `(x,y,z)` buffer re-inlined instead of calling `aabb3_from_v3_array`.** | `core/geom/3d/shape/ConvexHullShape3D.js:103-114` (inside `recompute`), `core/geom/3d/shape/MeshShape3D.js:251-266` (inside `recompute_cached`). Existing primitive: `core/geom/3d/aabb/aabb3_from_v3_array.js:12`. | Both write the same 12-line `Infinity`/`-Infinity` seed + per-component `if (x < mn) …; if (x > mx) …` loop, then the same `if (count === 0) { all = 0 }` normalisation. `aabb3_from_v3_array` does the identical reduction via `min2`/`max2` and `aabb3_array_set`; the only real semantic delta is the empty-input policy (primitive leaves ±Infinity; the shapes zero it). `bt_mesh_sample_interior_grid_points.js:161-175` is a third copy over the topology vertex pool. | **UNJUSTIFIED** for the shapes | Call `aabb3_from_v3_array(this.__bbox, v, v.length)` and keep the two-line empty-input normalisation at the call site (or add `aabb3_array_is_empty`). Do **not** add an "empty policy" parameter — that is exactly the sentinel the house rules forbid. | **S** / low. |
-| 9 | MEDIUM | **`Vector3.applyQuaternion` and `Vector4.applyQuaternion` inline the quaternion sandwich product that `v3_quaternion_apply` already implements — and the "inlined for speed" justification is dominated by the `set()` signal dispatch in the same method.** | `core/geom/Vector3.js:675` `applyQuaternion`, `core/geom/Vector4.js:360` `applyQuaternion`. Existing primitive: `core/geom/vec3/v3_quaternion_apply.js:28`. | The 8-line expansion (`ix/iy/iz/iw` then `_x/_y/_z`) is identical in all three, term for term. `Vector3.js:676` says "NOTE: the logic is inlines for speed" — but both methods end in `this.set(...)` (`core/geom/Vector3.js:160`, `core/geom/Quaternion.js:1314`), which runs 6 asserts, a 3-way change comparison and `onChanged.send6(...)` when handlers exist. The array round-trip a `v3_quaternion_apply` call would cost is orders of magnitude below that. Contrast `core/geom/3d/shape/PosedShape3D.js:60` `support`, which inlines the *same* expansion with a **measured, documented** justification ("V8 declines to inline v3_quat3_apply at 9-arg call sites… hottest GJK call") — that one is legitimately hot and stays. | **UNJUSTIFIED** for `Vector3`/`Vector4`; the `PosedShape3D` copy is **JUSTIFIED** (documented hot-loop scalar inlining) | `Vector3.applyQuaternion(q)` → `v3_quaternion_apply(SCRATCH, 0, this[0], this[1], this[2], q.x, q.y, q.z, q.w); return this.set(SCRATCH[0], SCRATCH[1], SCRATCH[2]);` with a module-static `SCRATCH`. Same for `Vector4` (preserving `w`). | **S** / low. `Vector3.spec.js`/`Vector4.spec.js` cover it; note `v3_quaternion_apply` uses `q*` sign inlined identically so results are bit-identical. |
-| 10 | MEDIUM | **"Normalize a 3-vector, or emit zero when degenerate" is re-derived in at least four places with three different degenerate policies — there is no scalar `v3_normalize`.** | `core/geom/vec3/v3_matrix3_rotate.js:21`, `core/geom/vec3/v3_matrix4_rotate_unit.js:21`, `core/geom/vec3/v3_matrix4_rotate_normal.js:24` (identical 20-line tails: `length > 1e-7 ? scale : write zeros`), `core/geom/3d/shape/TransformedShape3D.js:199-209` (`mag > 0 ? scale : zeros`), `core/geom/3d/shape/util/compute_signed_distance_gradient_by_sampling.js:38-48` (`mag > 0 ? scale : zeros`), `core/geom/3d/mat4/m4_transform_direction_v3_buffer.js:44` (`1 / v3_length(...)` with **no** guard at all → ±Infinity on a zero vector). Nearest existing primitive: `core/geom/vec3/v3_normalize_array.js:10` (array-in, and its policy is `n = 1` on zero — i.e. leaves the vector as-is). | The three `v3_matrix*_rotate*` tails are token-identical (158/165 tok pairs at sim 0.938) including the `1e-7` literal and the "The transform is invalid. Provide arbitrary vector." comment. Four different answers to the same degenerate question is the actual hazard, not the line count. | **PROMOTION** | Add `core/geom/vec3/v3_normalize.js` → `v3_normalize(out, out_offset, x, y, z)` writing the unit vector, and `v3_normalize_or_zero(out, out_offset, x, y, z, epsilon)` documenting the zero policy once. Have the three rotate variants, `TransformedShape3D`, and the SDF-gradient sampler call it. Leave `v3_normalize_array` alone (different, documented policy) but cross-reference it. | **S** / low. `v3_matrix3_rotate.spec.js`, `v3_matrix4_rotate_normal.spec.js` exist. |
-| 11 | MEDIUM | **`MeshShape3D` re-implements the shared finite-difference SDF-gradient sampler with a different step size and no normalisation, while every other shape delegates to it.** | `core/geom/3d/shape/MeshShape3D.js:552` `signed_distance_gradient_at_point` ⟷ `core/geom/3d/shape/util/compute_signed_distance_gradient_by_sampling.js:11`. Delegating shapes: `ConvexHullShape3D.js:267`, `CapsuleShape3D.js:115`, `CylinderShape3D.js:129`, `SphereShape3D.js:103`, `BoxShape3D.js:112`, `UnionShape3D.js:219`. | Same forward-difference structure (centre sample + 3 axis samples + `(d_axis - d_center)/h`), but `MeshShape3D` uses `h = 1e-4` vs `SAMPLE_STEP = 1e-5`, and — unlike the shared helper — does **not** normalise the resulting gradient to unit length. Six shapes agree; one does not. | **UNJUSTIFIED** | `signed_distance_gradient_at_point(result, point) { return compute_signed_distance_gradient_by_sampling(result, this, point); }` — one line, matching every sibling. | **S** / low. Changes the returned gradient magnitude for meshes; `MeshShape3D.spec.js` may assert the current unnormalised values and would need updating to the (correct) unit-gradient contract. |
-| 12 | MEDIUM | **`hammersley_sequence` is `halton_sequence` with the arguments swapped.** | `core/math/statistics/hammersley_sequence.js:21` ⟷ `core/math/statistics/halton_sequence.js:11`. | Bodies: `let result = 0; let f = 1; let n = i; while (n > 0) { f = f / R; result += f * (n % R); n = (n / R) >>> 0; } return result;` vs the same with `base`/`index` names. Character-identical after renaming. The Hammersley doc even says "Computed in closed form, as {@link halton_sequence} does." Only real delta: `halton_sequence` asserts both args are non-negative integers; `hammersley_sequence` does not (and asserts are free in prod). Note `hammersley_sequence_2d.js` is a *different*, base-2 bit-reversal path (`radical_inverse_VdC_base_2`) and is fine. | **UNJUSTIFIED** | `export function hammersley_sequence(i, R) { return halton_sequence(R, i); }` — keeps the public name (library surface) and the argument order its callers use. | **S** / low. Both have specs. |
-| 13 | MEDIUM | **`curl_noise_3d` is `curl_noise_3dt` with `w = 0`, including the six duplicated decorrelation offsets.** | `core/math/noise/curl_noise_3d.js:15` ⟷ `core/math/noise/curl_noise_3dt.js:15`. | `diff -u` shows the entire difference is the extra `w` parameter added to one component of each of the three `sdnoise3` calls. With `w = 0` the two are literally the same function. The offsets `31.341, -43.23, 12.34, -231.141, 124.123, -54.4341` are duplicated digit-for-digit — retuning one silently decorrelates the pair. | **UNJUSTIFIED** | `export function curl_noise_3d(result, x, y, z) { curl_noise_3dt(result, x, y, z, 0); }`. Passing 0 is a real time value, not a sentinel. | **S** / low. `sdnoise.spec.js` covers the underlying noise; add a same-value assertion. |
-| 14 | MEDIUM | **`m4_compose` (object args) and `m4_from_rotation_translation_scale` (array args) contain the same 45-line quaternion→matrix expansion.** | `core/geom/3d/mat4/m4_compose.js:8` ⟷ `core/geom/3d/mat4/m4_from_rotation_translation_scale.js:20`. | The `x2/y2/z2 → xx/xy/xz/yy/yz/zz/wx/wy/wz` block and all 16 `result[i] = …` writes are identical; only the operand *reads* differ (`rotation.x` vs `q[0]`, `scale.x` vs `s[0]`). The array version's doc already calls itself the "array-argument companion to m4_compose", acknowledging the fork. The codebase's own convention elsewhere (`tri3_area` scalar + `tri3_compute_normal_v3_objects` wrapper) is exactly the fix. | **UNJUSTIFIED** | Add the scalar core `m4_from_rotation_translation_scale_scalar(out, qx,qy,qz,qw, tx,ty,tz, sx,sy,sz)` in the same directory; both existing exports become 3-line unpackers. Preserves both public names (library surface). | **S** / low. `m4_from_rotation_translation_scale.spec.js` exists. |
-| 15 | MEDIUM | **The boolean segment-segment intersection test is an exact prefix of the point-returning one.** | `core/geom/2d/line/segment2_intersects_segment2_2d.js:14` ⟷ `core/geom/2d/line/segment2_segment_compute_intersection_array_2d.js:20`. | Lines 15-27 of the boolean version and 25-37 of the array version are character-identical: `s1_x/s1_y/s2_x/s2_y`, `dy_02/dx_02`, `inv_denom = 1 / (-s2_x*s1_y + s1_x*s2_y)`, `s`, `t`, then the same `s >= 0 && s <= 1 && t >= 0 && t <= 1` test. The array version adds 6 lines to compute and store the intercept. Both share the same undocumented parallel-segments behaviour (`inv_denom = ±Infinity` → `s`/`t` become `±Infinity` or `NaN`). | **UNJUSTIFIED** | Extract `segment2_segment_intersection_fractions(out, out_offset, a0_x…b1_y) -> boolean` writing `[s, t]`; both public functions become thin. Document the parallel case once. | **S** / low. Both have callers in navigation/generation; behaviour must stay bit-identical. |
-| 16 | MEDIUM | **Reading a triangular face's three vertex ids / coordinates out of a `BinaryTopology` is hand-written at ~8 non-spec sites, with inconsistent "is it actually a triangle?" checking.** | `core/geom/3d/topology/struct/binary/query/bt_mesh_face_find_path.js:80` `face_read_vertices`; `…/bt_mesh_face_find_path_polyanya.js:93` `triangle_vertices`; `…/bt_mesh_sample_interior_grid_points.js:38-44`; `core/geom/3d/tetrahedra/tetrahedral_mesh_carve_outside_surface.js:41-48`; `core/geom/3d/atlas/data/atlas_build_face_areas.js:30-40`; `core/geom/3d/topology/struct/binary/io/bt_mesh_compute_face_normals.js:35-45`; `…/io/bt_mesh_compute_vertex_quadrics.js:54-68`; `…/query/bt_mesh_find_nearest_face.js:109-119`. | Every one is `l0 = face_read_loop(f); l1 = loop_read_next(l0); l2 = loop_read_next(l1);` followed by three `loop_read_vertex` and (usually) three `vertex_read_coordinate` into three 3-element scratch buffers. `atlas_build_face_areas`, `bt_mesh_compute_face_normals` and `bt_mesh_compute_vertex_quadrics` additionally check `loop_read_next(l2) === l0` and skip non-triangles; `tetrahedral_mesh_carve_outside_surface` and `bt_mesh_sample_interior_grid_points` **do not** and will silently mis-handle an n-gon. Each site declares its own module-static scratch. | **PROMOTION** | Add `core/geom/3d/topology/struct/binary/query/bt_face_read_triangle.js` exporting `bt_face_read_triangle_vertices(out, mesh, face) -> boolean` and `bt_face_read_triangle_coordinates(out, out_offset, mesh, face) -> boolean` (9 floats), both returning `false` for a non-triangular/unallocated face. That makes the triangle check impossible to forget. | **M** / low. Purely additive; migrate call sites one at a time. |
-| 17 | MEDIUM | **Straight-line vertex-to-vertex distance re-implemented inside both pathfinders while the primitive sits in the same directory — and the two copies use different formulas.** | `core/geom/3d/topology/struct/binary/query/bt_vertex_distance_to_vertex.js:12` (existing, uses `v3_distance`) ⟷ `…/bt_mesh_face_find_path.js:100` `vertex_distance` (`Math.sqrt(dx*dx+dy*dy+dz*dz)`) ⟷ `…/bt_mesh_face_find_path_polyanya.js:103` `vid_distance_3d` (`Math.hypot`). A fourth copy is `…/bt_mesh_build_boundary_distance_field.js:79` (`Math.hypot` inline). | Same three coordinate reads + same distance, three different spellings. `Math.hypot` and `sqrt(sum of squares)` are **not** bit-identical, so a geodesic cost computed by one pathfinder is not reproducible by the other on the same mesh — relevant because both are A*-style and their costs get compared in the bench specs. | **UNJUSTIFIED** | All four call `bt_vertex_distance_to_vertex(mesh, a, b)` (it already exists and is spec'd). If the module-static scratch inside it is a re-entrancy concern for the pathfinders, give it a `_scratch`-free scalar sibling — but pick **one** formula. | **S** / low, except that switching `hypot`→`sqrt` (or vice versa) can shift A* tie-breaking; run `bt_mesh_face_find_path.shortest_path.spec.js` and the polyanya specs. |
-| 18 | MEDIUM | **`order_cycle_from` and the fan-fill of a boundary loop are copy-pasted between the two hole-closing modules.** | `core/geom/3d/topology/struct/binary/io/bt_mesh_close_boundary_holes.js:20` `order_cycle_from` + the per-cycle body at :81-132 ⟷ `core/geom/3d/topology/struct/binary/io/bt_mesh_fill_small_holes.js:13` `order_cycle_from` + :60 `fill_loop`. | `order_cycle_from` is 245 tokens, token-identical (only brace formatting differs). `fill_loop` (:60-94) is a line-for-line copy of `bt_mesh_close_boundary_holes`'s loop body: same seed-edge/start-vertex derivation, same centroid accumulation, same face+loop allocation, same `bt_radial_loop_add` wiring, same `% n` next/prev ring, same `bt_face_poke` centroid fan. `bt_mesh_fill_small_holes.js:12` and :59 both say "Same as / as close_boundary_holes does" — acknowledged copies. ~75 lines. | **UNJUSTIFIED** | Export both from a new `core/geom/3d/topology/struct/binary/io/bt_boundary_loop.js`: `bt_boundary_loop_order_from(mesh, cycle, start_vertex, out_vertices, out_edges)` and `bt_boundary_loop_fill_fan(mesh, cycle)`. `bt_mesh_close_boundary_holes` becomes a loop over cycles calling `fill_fan`; `bt_mesh_fill_small_holes` keeps its measurement/threshold logic. | **S** / low. Both have specs. |
-| 19 | MEDIUM | **`project_triangle` (isometric triangle flattening) duplicated between the two chart parameterisers.** | `core/geom/3d/atlas/param/atlas_chart_parameterize_bff.js:39` ⟷ `core/geom/3d/atlas/param/atlas_chart_parameterize_lscm.js:64`. | Same algorithm (place v0 at origin, v1 on +x, project v2, write `[len1, x3, y3]`), 236/267 tokens, sim 0.78 — the BFF copy is just a tighter rewriting with intermediate `bx/by/bz`/`cx/cy/cz` folded away. The BFF version's comment reads "(Same as LSCM.)". | **UNJUSTIFIED** | Move to `core/geom/3d/triangle/tri3_flatten_isometric.js` → `tri3_flatten_isometric(out, out_offset, ax,ay,az, bx,by,bz, cx,cy,cz)` writing `[len_ab, x_c, y_c]`, plus an indexed wrapper for the `pos, i0, i1, i2` form both callers use. This is a genuinely reusable primitive (any conformal/ARAP/LSCM/geodesic-unfolding pass wants it — `bt_mesh_face_find_path_polyanya.js:137` `unfold_apex` solves a related problem). | **S** / low. Both parameterisers have specs. |
-| 20 | MEDIUM | **`qt_collect_by_circle` and `qt_match_data_by_circle` are the same traversal, differing by one predicate conjunct; and the circle queries lost the child-pruning the box/point queries have.** | `core/geom/2d/quad-tree/qt_collect_by_circle.js:19` ⟷ `core/geom/2d/quad-tree/qt_match_data_by_circle.js:21`. Contrast `qt_collect_by_box.js:22` and `qt_collect_by_point.js:19`. | The two circle functions are 212/228 tokens at sim 0.81; the only semantic delta is `&& predicate.call(predicateContext, datum.data)` on the accept line. Stack management differs cosmetically (`while (stack_pointer-- > 0)` vs `while (stack_pointer > 0) { --stack_pointer;`). Separately: both circle variants push all four children unconditionally (`:56-61`, `:61-66`), whereas `qt_collect_by_box` (:63-83) and `qt_collect_by_point` (:58-78) compute the node's half-planes and push only the quadrants that can overlap — so the circle path descends up to 4× more nodes. Each of the four files also declares its own module-static `node_stack`, none of which is re-entrancy-safe. | **UNJUSTIFIED** for the body; the missing pruning is a genuine divergence worth fixing at the same time | Make `qt_match_data_by_circle` the single implementation and define `qt_collect_by_circle` as it with a module-static `const ACCEPT_ALL = () => true` — a real function, not a null sentinel, and monomorphic so V8 inlines it. Add the quadrant pruning (`hx`/`hy` vs `x ± radius`) while you are in there. | **S–M** / low. `qt_match_data_by_circle.spec.js` and `qt_collect_by_point.spec.js` exist; add a circle-pruning spec. |
-| 21 | MEDIUM | **Winding-agnostic point-in-tetrahedron and coordinate-form `orient3d` are file-private in `MeshShape3D` while the shared versions sit in `core/geom/3d`.** | `core/geom/3d/shape/MeshShape3D.js:646` `orient3d_with_point`, `:686` `tet_contains_point_coords`. Existing: `core/geom/3d/plane/orient3d_fast.js:22`, `core/geom/3d/tetrahedra/tetrahedron_contains_point.js:17`. | `orient3d_with_point` is `orient3d_fast` with the fourth point taken as raw scalars instead of an index — the determinant expansion (`adx*(bdy*cdz - bdz*cdy) + …`) is character-identical. `tet_contains_point_coords` is `tetrahedron_contains_point` made winding-agnostic (accepts all-nonneg **or** all-nonpos rather than assuming one convention). `MeshShape3D.js:663-671` documents this explicitly: "the existing tetrahedron_contains_point helper, by contrast, was authored against a CW convention". So the shared helper is known to be convention-locked and the better version was written privately instead of promoted. `tetrahedral_mesh_walk_towards_containing_tetrahedron.js` is a third consumer of the convention-locked one. | **PROMOTION** | Add `core/geom/3d/plane/orient3d_fast_point.js` → `orient3d_fast_point(points, a, b, c, ex, ey, ez)` and `core/geom/3d/tetrahedra/tetrahedron_contains_point_either_winding.js` (or fix `tetrahedron_contains_point` to be winding-agnostic and document the change). `MeshShape3D` then imports both. | **S** / low if added as new exports; **medium** if `tetrahedron_contains_point` is changed in place (its spec encodes the CW convention). |
-| 22 | LOW-MEDIUM | **`m4_decompose` re-derives the whole of `m4_extract_scale`.** | `core/geom/3d/mat4/m4_decompose.js:10` ⟷ `core/geom/3d/mat4/m4_extract_scale.js:11`. | Lines 11-28 of `m4_decompose` are `m4_extract_scale`'s body verbatim (three `v3_length` calls over matrix columns 0/1/2, 4/5/6, 8/9/10, with the same `m11…m33` local names). `m4_decompose` then needs the raw `m11…m33` for the rotation extraction, so only the three `v3_length` calls are strictly shareable — but a change to how scale is read (e.g. handling a reflected basis) currently has to land twice, and `m4_decompose` already carries a determinant-sign correction that `m4_extract_scale` does not. | **UNJUSTIFIED (mild)** | `m4_decompose` calls `m4_extract_scale(scratch3, 0, mat4)` for the magnitudes and keeps its own `m11…m33` reads for the rotation. Or: document in both that the reflection handling deliberately lives only in `m4_decompose`. | **S** / low. `decompose_matrix_4_array.spec.js` exists. |
-| 23 | LOW-MEDIUM | **Barycentric-weights → 3D point reconstruction re-expanded at five sites instead of a `tri3_closest_point` primitive.** | `core/geom/3d/shape/ConvexHullShape3D.js:255-258` and `:286-289`, `core/geom/3d/shape/MeshShape3D.js:446-450` and `:498-502`, `core/geom/3d/shape/Triangle3D.js:169-175` and `:214-219`. Existing: `core/geom/3d/triangle/tri3_closest_point_barycentric.js` (returns weights only). | Every site does `tri3_closest_point_barycentric(bary, 0, p, a, b, c)` then the same `u = bary[0]; w = bary[1]; t = 1 - u - w; q = u*a + w*b + t*c` expansion — and each independently names the third weight differently (`t` / `w` / `alpha_c`), which is how one of them could quietly get the ordering wrong. | **PROMOTION** | Add `core/geom/3d/triangle/tri3_closest_point.js` → `tri3_closest_point(out, out_offset, px,py,pz, ax…cz) -> number` writing the closest point and returning the squared distance. Every one of the five call sites collapses to one line, and finding #7's surface-scan helper is then trivial to build on top. | **S** / low. |
-| 24 | LOW-MEDIUM | **The two `atlas_segment_charts` variants re-declare the same tuning constants and the same roundness term, with a comment claiming they must stay local.** | `core/geom/3d/atlas/segment/atlas_segment_charts.js`: `REJECT` :10, `NORMAL_DEVIATION_REJECT` :18, `STALE_EPSILON` :25, `chart_unit_normal` :97, roundness block :~140. ⟷ `core/geom/3d/atlas/segment/atlas_segment_charts_atomic.js`: `REJECT` :7, `NORMAL_DEVIATION_REJECT` :8, `STALE_EPSILON` :9, `chart_unit_normal` :49, roundness block :~100. | `chart_unit_normal` is token-identical (49 tok). The roundness block (`if (chart_area > 0 && chart_boundary > 0 && new_boundary > 0) { old_ratio = b²/a; new_ratio = …; R = … }`) is an identical 8-line window. The three constants are identical literals; the atomic file's comment says "kept local so the two segmenters stay monomorphic" — but the file **already imports `ATLAS_SEGMENT_DEFAULTS`** from its twin (`:3`), so the monomorphism argument doesn't cover module-level `const` numbers, which are inlined by V8 regardless of which module they come from. Retuning the 0.707 cutoff in one silently desyncs the two segmenters. | **Constants + roundness: UNJUSTIFIED. The greedy traversal itself: JUSTIFIED** (different growth graph — faces vs `RegionGraph` regions; unifying would require an adjacency-accessor abstraction that genuinely does de-monomorphize the inner loop, and the author documented that trade-off). | Export `REJECT`, `NORMAL_DEVIATION_REJECT`, `STALE_EPSILON` from `atlas_segment_charts.js` alongside `ATLAS_SEGMENT_DEFAULTS` and import them in the atomic variant. Move the roundness term to `atlas_chart_roundness_delta(chart_area, chart_boundary, new_area, new_boundary)` in `core/geom/3d/atlas/segment/`. Leave the loops alone. | **S** / low. Both have specs. |
-| 25 | LOW-MEDIUM | **The spatial-hash-grid cell walk (read element AABB out of the pool) is duplicated between the circle and line queries, including the same no-deduplication behaviour.** | `core/geom/2d/hash-grid/shg_query_elements_circle.js:118-146` ⟷ `core/geom/2d/hash-grid/shg_query_elements_line.js:71-100`. | Both contain the identical 15-line block: `let node = grid.cell_get_first_node(cell_index); while (node !== NULL_POINTER) { const element = grid.node_get_element(node); const element_address = element_pool.element_word(element); const element_x0/y0/x1/y1 = element_float32[element_address + COLUMN_ELEMENT_*]; … node = grid.node_get_same_cell_next_node(node); }` — only the acceptance predicate differs (`aabb2_distance_sqr_to_point <= r2` vs `aabb2_clip_line_cohen_sutherland`). Both share the consequence that an element linked into several visited cells is appended to `result` once per cell. | **PROMOTION** (the *cell iteration* is worth sharing; the predicate is not) | Add `shg_element_read_aabb(out, out_offset, grid, element)` next to `SpatialHashGrid.js` and use it in both. Whether to also share the walk depends on whether an accept-callback is acceptable in this path — if not, at minimum share the AABB read and document the multi-cell duplicate-emission behaviour in one place. | **S** / low. Both have specs. |
-| 26 | LOW | **Shape `hash()` methods disagree on the integer mixing function even though `combine_hash` exists.** | `core/geom/3d/shape/CapsuleShape3D.js:223` and `core/geom/3d/shape/CylinderShape3D.js:207` use `((a << 5) - a + b) \| 0`; `core/geom/3d/shape/BoxShape3D.js:158`, `HeightMapShape3D.js:456`, `ConvexHullShape3D.js:335`, `MeshShape3D.js:593` use `(h * 31 + x) \| 0`; `core/geom/Vector2.js:636` uses `((x << 5) - x) + y` with no `\| 0`. Existing: `core/collection/array/combine_hash.js:8` (used by `Vector4.js:394`). | The *shape* of these methods is per-class boilerplate and deliberate (house rule) — but the *mixing logic* is not, and it is inconsistent five ways across one class family. `Vector2.hash` also omits the `\| 0`, so it can return a non-int32. `CapsuleShape3D.hash` and `CylinderShape3D.hash` are byte-identical, meaning a capsule and a cylinder with equal radius/height collide — harmless given `equals` checks `constructor`, but unintended. | **UNJUSTIFIED (logic, not shape)** | Pick one mixer and use it everywhere. `combine_hash(...)` is varargs (allocates a rest array) so it is not ideal for a per-frame path — add `core/math/hash/hash_mix2(a, b)` / `hash_mix3(a, b, c)` returning `(a * 31 + b) \| 0` etc., and have every shape's `hash()` call it. Keep the per-class `hash()` methods; only the mixer moves. | **S** / low. |
-| 27 | LOW | **BFF's `interior_angle` re-implements `v3_angle` from an indexed buffer, using the acos form rather than the atan2-stable form that also exists.** | `core/geom/3d/atlas/param/atlas_chart_parameterize_bff.js:27` `interior_angle`. Existing: `core/geom/vec3/v3_angle.js:13` (`acos(v3_cos_angle(...))`, with a `clamp(-1,1)` inside `v3_cos_angle`), `core/geom/vec3/v3_angle_stable.js:14` (`atan2(|a×b|, a·b)`). | Identical math to `v3_angle`: two edge vectors, both lengths, `acos(clamp(dot/(lu*lv), -1, 1))`. Differences: BFF returns 0 when either length `< 1e-20` (where `v3_cos_angle` returns 0 for exactly-zero length only), and BFF clamps inline (`Math.acos(Math.max(-1, Math.min(1, c)))`) rather than via `clamp`. The angles feed the Gaussian-curvature sum `Ω = 2π − Σθ`, which is precisely where the acos form loses precision for near-degenerate slivers — and `v3_angle_stable` (the atan2 form) already exists for exactly that. | **UNJUSTIFIED (small), with a follow-up** | Call `v3_angle(ux,uy,uz, vx,vy,vz)` (or `v3_angle_stable` if the sliver precision matters — that is a numerical decision, not a refactor, and should be measured against `atlas_chart_parameterize_bff.spec.js`). | **S** / low for the swap to `v3_angle`; medium if switching to the stable form (changes BFF output on sliver charts). |
-| 28 | LOW | **Two different exported functions named `compute_edge_collapse_cost` in the same package.** | `core/geom/3d/topology/simplify/compute_edge_collapse_cost.js:20` — `(victim, target, victim_edge, vertex_quadratics)`, quadric + normal-flip + boundary penalty. ⟷ `core/geom/3d/topology/simplify/decimate_edge_collapse_snap.js:139` — `(edge, quadratics, restricted_vertices)`, quadric with a topological fallback. | Not shared code — two different cost models with the same name, in sibling files, both exported. For a library this is an import hazard (`import { compute_edge_collapse_cost } from '.../simplify/...'` resolves to whichever path you happened to type) and it makes "which cost does the simplifier use?" unanswerable without opening both. Flagged by the mechanical pass as a duplicate export; it is a naming collision, not duplication. | **UNJUSTIFIED (naming)** | Rename the one in `decimate_edge_collapse_snap.js` to `edge_collapse_cost_with_topology_fallback` (keeping a deprecated alias, per the library rule) — or move it to its own file with a distinct name. No code moves. | **S** / low. |
-| 29 | LOW | **Per-vertex quadric accumulation implemented twice, once per mesh representation, with divergent feature sets.** | `core/geom/3d/topology/simplify/quadratic/build_vertex_quadrics.js:37` (TopoMesh) ⟷ `core/geom/3d/topology/struct/binary/io/bt_mesh_compute_vertex_quadrics.js:23` (BinaryTopology). | Both: derive the face's supporting plane `(n, d = -n·v0)`, `q.setFromVector4(n, d)`, add `q` to each of the three vertices' `Quadric3`. The shared kernel is ~10 lines. Genuinely different iteration (object graph vs pooled ids). **Behavioural divergence worth noting:** the TopoMesh version supports `use_triangle_area` weighting and applies a border penalty (`apply_border_penalty_to_vertex_quadrics`, default `use_border_constraints = true`); the BinaryTopology version does neither, so the two simplification stacks weight boundaries differently. | **JUSTIFIED (two mesh representations, no common iteration surface)** — but the plane-quadric kernel is a promotion candidate and the feature divergence should be documented | Add `quadric3_set_from_triangle(q, ax,ay,az, bx,by,bz, cx,cy,cz)` beside `Quadric3.js` and call it from both. Do **not** try to unify the iteration. Add a JSDoc note on the BinaryTopology version stating that area weighting and border penalties are intentionally absent (or add them). | **S** / low. |
-| 30 | LOW | **`read_frustum_corner` is `v3_copy_array` with an index instead of an offset.** | `core/geom/3d/frustum/read_frustum_corner.js:8` ⟷ `core/geom/vec3/v3_copy_array.js:8`. | Same three reads + three writes; `read_frustum_corner` computes `address = source_index * 3` first, `v3_copy_array` takes the offset directly. `v3_copy_array` additionally reads all three components before writing any (documented, so overlapping ranges are safe); `read_frustum_corner` does the same by accident of ordering but does not say so. | **UNJUSTIFIED (trivial)** | `read_frustum_corner(source, source_index, destination, destination_offset) { v3_copy_array(destination, destination_offset, source, source_index * 3); }` — keeps the public name and the index-flavoured signature. | **S** / low. |
-
-## Dismissed leads
-
-- **All `@deprecated` rename shims.** I sampled ~40 of the 7-line `import X from './x.js'; export const OldName = X;` files across `geom/3d/triangle`, `geom/3d/aabb`, `geom/3d/mat4`, `geom/3d/sphere`, `geom/2d/circle`, `geom/2d/line`, `geom/vec3`, `geom/packing/max-rect`, `geom/random`, `geom/3d/tetrahedra`, `geom/3d/topology/simplify`. Every one is a genuine alias with zero duplicated logic. This accounts for the large majority of "same concept, two files" impressions in this domain. Not duplication; correct library practice.
-- `v2_*` vs `v3_*`, `aabb2_*` vs `aabb3_*` scalar pairs (`v2_distance`/`v2_distance_sqr`, `line2_compute_segment_point_distance_sqr` ⟷ `line3_…`, `aabb2_distance_sqr_to_point` ⟷ `aabb3_unsigned_distance_sqr_to_point`, `aabb2_from_v2_buffer` ⟷ `aabb3_from_v3_array`, `v2_array_normalize` ⟷ `v3_normalize_array`) — dimensional specialisation, house-rule justified.
-- `m3_cm_compose_transform` ⟷ `m3_rm_compose_transform`, `v2_matrix3_cm_multiply` ⟷ `v2_matrix3_rm_multiply` — row-major/column-major variants, house-rule justified.
-- `m2_multiply` ⟷ `m2_multiply_transposed` ⟷ `m2_add` ⟷ `m2_sub_transposed`; `polynomial_add_into` ⟷ `polynomial_sub_into`; `aabb3_compute_distance_above_plane_max` ⟷ `_min`; `query_face_next_vertex` ⟷ `query_face_prev_vertex`; `aabb3_array_intersects_ray` ⟷ `aabb3_array_near_distance_to_intersection_ray_segment` — same *shape*, genuinely different arithmetic. No shareable kernel.
-- `v3_quaternion_apply` ⟷ `v3_quaternion_apply_inverse` — the inverse is NOT the forward with negated components; the sign pattern genuinely differs and the file documents why (`v3_quaternion_apply_inverse.js:11-18`). Justified.
-- `sh3_sample_by_direction` ⟷ `sh3_sample_irradiance_by_direction` — same coefficient layout, different convolution (radiance vs cosine-convolved irradiance) and different constants. Justified.
-- `bt_mesh_build_boundary_distance_field` ⟷ `bt_mesh_build_boundary_euclidean_distance_field` — geodesic (eikonal fast-marching) vs Euclidean clearance. Documented as different metrics; 150 lines vs 32. Not duplication.
-- `bt_mesh_is_closed` ⟷ `bt_mesh_is_manifold` — same 8-line "for every allocated edge, count faces" loop but the predicate is `!== 2` vs `> 2`; extraction would need a callback for a loop this small. Both already delegate the counting to `bt_mesh_count_edge_faces`. Justified.
-- `orient3d_robust` / `in_sphere3d_robust` / `tetrahedron_compute_signed_volume` / `TetrahedralMesh.js` "gather 4 indexed points from a flat array" boilerplate (flagged 4× by the mechanical pass) — different arities, and extracting it means either boxing into an out-array or a 12-parameter call. Justified index-expansion boilerplate.
-- `polygon2_clip_axis_halfplane` ⟷ `polygon2_clip_halfplane` — the axis version is the general one specialised to an axis-aligned edge, and its only callers are `engine/physics/narrowphase/box_box_manifold.js:511-529` and `box_triangle_contact.js:414-420`, i.e. per-contact-manifold. Genuine hot-loop specialisation. **One caveat worth a separate look:** the general version applies a `POINT_EPS = 1e-9` boundary slack and the axis version applies none, so the two disagree on vertices exactly on the clip line.
-- `PosedShape3D.support` / `#world_point_to_local` inlining `v3_quaternion_apply(_inverse)` — explicitly justified in-file with a measured reason (V8 will not inline at 9-arg call sites; hottest GJK call). Correct application of the hot-loop carve-out. (Contrast finding #9.)
-- `CapsuleShape3D.from` ⟷ `CylinderShape3D.from`, `compute_bounding_box`, `equals` — per-class typed constructor/accessor boilerplate. House-rule deliberate. (Only their `hash()` *mixer* is flagged, in finding #26.)
-- `Vector2/3/4` + `Quaternion` + `Color` `fromBinaryBuffer` / `toBinaryBuffer` / `toArray` / `set` / `constructor` families (flagged 6× by the mechanical pass) — per-class serialization and accessor boilerplate over different component counts. House-rule deliberate; unifying would need string-keyed or metaprogrammed field lists.
-- `bvh_query_leaves_ray` / `bvh_query_leaves_ray_segment` ⟷ `bvh2d_query_all_data_by_circle` — share only the generic explicit-stack tree-descent skeleton (`if (root === NULL_NODE) return 0; stack[stack_top] = root; …`); the node test and payload differ entirely. Not a shareable unit without a visitor.
-- `tetrahedron_compute_quality` / `tetrahedral_mesh_compute_tet_quality` / `compute_tetrahedron_quality` and the volume trio — already correctly factored as indexed primitive + mesh wrapper + deprecated alias. Exemplary, not duplication.
-- `simplify/quadratic/compute_edge_collapse_cost_quadratic.js`, `bt_mesh_compute_vertex_quadratics.js`, `shape3d_voxelize_to_grid.js`, `sh_compute_K.js`, `aabb3_near_distance_to_intersection_ray_segment.js` — all rename shims (the "quadratic"→"quadric" pass).
-- `core/geom/3d/sphere/harmonics/compute_legendre_polynomial.js` — a **0-byte file** dated 2024 shadowing `core/math/compute_legendre_polynomial.js`. Not duplication; dead empty file. Worth deleting but out of scope.
-- `aabb3_intersects_ray` ⟷ `aabb3_intersects_segment3` — both separating-axis tests, but one is an infinite ray with `diff*dir >= 0` early-outs and the other inflates the box by the segment half-extent. Different tests; only stylistic resemblance.
-- `Math.sqrt(x*x+y*y+z*z)` hits (78 global, ~32 in domain) — checked the concentrations. In `tri3_area`, `tri3_incenter`, `atlas_chart_parameterize_bff/lscm`, `polygon3_compute_normal`, `bt_mesh_face_find_path`: these are per-triangle / per-vertex / per-CG-iteration inner loops, and `v3_length` is itself `Math.sqrt(x*x+y*y+z*z)` with no guard, so calling it buys nothing but a call. Justified. The ones that *matter* are the normalize-with-a-policy sites, which are finding #10.
-- `inline_lerp` hits (129 global, 27 in domain) — every one I opened is either a dot product misclassified by the pattern (`(px-ax)*nx + …` in `Triangle3D.js:191`, `bt_mesh_segment_penetrates_surface.js:44`, `bt_mesh_face_find_path.js:342`) or a per-component 3-float interpolation in a hot mesh loop (`bt_edge_split.js:55-64`, `capsule_intersects_aabb3_closed.js:57-59`). No cold-code `lerp` bypasses found.
-- `computeHashArray` ⟷ `computeHashFloatArray` — different input domains (integers vs floats needing `computeHashFloat`). Out of domain anyway (`core/collection`).
-- `halton_sequence` ⟷ `hammersley_sequence_2d` — different algorithms (general-base closed form vs base-2 bit reversal). Only the 1-D `hammersley_sequence` is a duplicate (finding #12).
-- `mie/ri_*.js` repeated 8-line data blocks, `atlas_test_fixtures.js` ⟷ `RGB_LUT_*.js` — these are numeric data tables, not code.
-- `complex_mul` ⟷ `m3_multiply` / `m4_normal_matrix3`; `linear_to_sRGB` ⟷ `aabb2_union_array`; `BVHGeometry.makeCube` ⟷ `bt_edge_create.edge_link_disk`; `plane3_lerp` ⟷ `edge_link_disk`; `read_frustum_corner` ⟷ `mat4x4_transpose_copy_to_mat4x3` — MinHash noise. Structurally similar (flat arithmetic over indexed arrays), semantically unrelated.
-
-## Notes
-
-Why duplication accumulates here, structurally:
-
-1. **The "scalar arguments, caller-owned output buffer" convention has no composition story for *policies*.** Every primitive is `f(out, out_offset, …scalars)`, which is excellent for allocation-freedom and terrible for sharing decisions like "what do we do when the length is zero" or "how relative should the degeneracy epsilon be". So the arithmetic gets reused (`v3_length`, `v3_dot`, `tri3_area` are called everywhere) while the *policy* around it gets retyped — findings #6, #10, #11 are all the same failure. The fix is not more helpers; it is naming the policy (`v3_normalize_or_zero`, `solve_quadratic_relative`) so it has somewhere to live.
-
-2. **Dimensional forks start as copies and are never re-synced.** `BVH2D` and `StaticR2Tree` were each created by copying a 3D file and deleting a `z`. Because the copy is complete rather than layered, every later improvement to the 3D side (SAH rotation, linear allocation, the stack-seed fix) lands in one place only. Both forks are now measurably behind their originals. The house rule that 2D/3D scalar specialisation is justified is right for `v2_dot` vs `v3_dot`; it does not extend to 1100-line classes whose pointer machinery never touches a coordinate.
-
-3. **Private helpers get re-derived because the public one is not discoverable from where you are standing.** `bt_face_poke` wrote its own radial splice with a comment saying the function it wanted "is not exported" — while `bt_radial_loop_add` sat exported two directories up. `bt_mesh_face_find_path` wrote `vertex_distance` while `bt_vertex_distance_to_vertex` sat in the *same directory*. `MeshShape3D` wrote its own SDF gradient while six sibling shapes call the shared one from `./util/`. With ~1000 files in this domain and a naming scheme that encodes the *operand type* rather than the *operation*, grep-by-concept genuinely does not work.
-
-4. **The good news, which shapes the recommendations:** the domain is already unusually disciplined about the *renaming* half of this problem — hundreds of `@deprecated` re-export shims mean old names never became second implementations. The remaining duplication is almost entirely (a) pre-shim forks that predate that discipline, and (b) private helpers that should have been promoted. Both are addressable incrementally; none of the findings above except #1 requires touching more than a handful of files.
+# Domain A — core/geom + core/math
+
+Source root: `H:/git/moh/app/src/mir-engine/meep/src/` — all paths below are relative to it unless absolute.
+Every row was verified by opening the files. Rename shims (`@deprecated ... re-export`) were checked in bulk and
+are **not** duplication — see Dismissed leads.
+
+## Findings
+
+| # | Severity | Concept | Sites | Evidence | Verdict | Proposed common path | Effort/Risk |
+|---|---|---|---|---|---|---|---|
+| 1 | CRITICAL | **Whole dynamic-AABB-tree (Box2D-style) implemented twice, 2D fork has already diverged.** Node allocation, free list, capacity growth, SAH insertion, AVL rotation, refit, node swap, traversal. | `core/bvh2/bvh3/BVH.js` (1437 ln, class `BVH`) ⟷ `core/geom/2d/bvh/BVH2D.js` (1138 ln, class `BVH2D`). Method-for-method: `__grow_capacity` 217/155, `allocate_node` 300/214, `node_set_aabb` 501/411, `node_get_surface_area` 574/477, `node_get_combined_surface_area` 600/501, `insert_leaf` 663/557, `bubble_up_refit` 775/675, `bubble_up_update` 803/705, `remove_leaf` 845/740, `balance_height` 902 ⟷ `balance` 792, `traverse` 1302/1008, `__move_node_links` 1357/1063, `swap_nodes` 1394/1100. Column constants re-declared: `COLUMN_PARENT/CHILD_1/CHILD_2/HEIGHT/USER_DATA`, `NULL_NODE`, `ELEMENT_WORD_COUNT` exported from **both**. | `remove_leaf` (55 ln), `bubble_up_update` (35 ln), `swap_nodes`, `__move_node_links`, `traverse` are token-identical. `balance_height`/`balance` are 1206/1208 tokens with only 3 real diffs (`node_is_leaf(iA)` vs inline `iB === NULL_NODE`; `this.node_capacity` vs `this.__capacity`). **Proof of drift:** BVH.js has gained `balance_rotate` (SAH rotation, Box2D v3, BVH.js:1120), `allocate_linear` (:288), `node_assign_children` (:1249), `node_assign_children_only` (:1268) — BVH2D has **none** of them and still calls the old height-only rotation. Only truly dimensional code: AABB word layout (6 vs 4 floats, `ELEMENT_WORD_COUNT` 10 vs 8) and `aabb3_array_combine`/`aabb3_surface_area` vs `aabb2_union_array`/perimeter. | **UNJUSTIFIED** (2D/3D carve-out does not cover 1000 lines of dimension-independent pointer surgery) | Extract the topology half into a dimension-agnostic base holding `__data_uint32` links only: `core/bvh2/DynamicTreeTopology.js` with `allocate_node/release_node/node_get_*/insert_leaf/remove_leaf/bubble_up_*/balance_height/balance_rotate/swap_nodes/traverse`, parameterised at *class* level (subclass supplies `ELEMENT_WORD_COUNT`, `node_set_combined_aabb`, `node_get_surface_area`, `node_get_combined_surface_area` — 4 overrides, no runtime flags). `BVH extends`, `BVH2D extends`. | **L** / high. This is the physics broadphase; `determinism.spec.js` + the bvh3 suite are the gate. Risk is real — do it only with the 70-test BVH suite green before and after, and mirror `balance_rotate` into 2D as a *separate* commit so the behaviour change is isolated. |
+| 2 | HIGH | **Boolean and distance-returning AABB-vs-ray-segment slab tests, whose docs declare they MUST agree, are two independent copies of the same numerically-subtle NaN handling.** | `core/geom/3d/aabb/aabb3_intersects_ray_segment.js:35` `aabb3_intersects_ray_segment` ⟷ `core/geom/3d/aabb/aabb3_ray_segment_entry_distance.js:40` `aabb3_ray_segment_entry_distance` | Bodies are character-identical for 45 lines (ray-space shift, 6 slab `t`s, the three `t !== t` NaN probes, the `±Infinity` interval substitution, `max of mins / min of maxes`). They differ ONLY in the last 4 lines (`return t_box_min <= t_box_max` vs `if (t_box_min > t_box_max) return Infinity; return t_box_min`). The entry-distance doc states verbatim that the two "MUST agree on every input". The whole NaN dance is a hardening fix that was applied twice by hand. | **UNJUSTIFIED** | Delete the duplicated body: `export function aabb3_intersects_ray_segment(...) { return aabb3_ray_segment_entry_distance(...) !== Infinity; }`. No mode flag, no sentinel parameter — the miss sentinel already exists and is documented. | **S** / low. Both have specs. One extra call in a broadphase leaf test; V8 inlines it (single call site, monomorphic). |
+| 3 | HIGH | **Point-in-closed-triangle-surface classifier (BVH build + 3-ray parity majority vote) copy-pasted whole between the tetrahedral carver and the interior-point sampler.** | `core/geom/3d/tetrahedra/tetrahedral_mesh_carve_outside_surface.js`: `RAY_DIRECTIONS` :19, `build_surface_bvh` :33, `single_ray_parity_inside` :81, `point_is_inside_surface` :127. ⟷ `core/geom/3d/topology/struct/binary/query/bt_mesh_sample_interior_grid_points.js`: `RAY_DIRECTIONS` :12, `build_surface_bvh` :29, `point_is_inside` :78. | `build_surface_bvh` is 435 tokens, token-identical (only the parameter name `surface` vs `mesh` differs). The three magic ray directions (`0.97123, 0.18927, 0.14431`, …) are duplicated digit-for-digit; the module-static scratch (`ray_hit`, `ray_candidates`, `va`, `vb`, `vc`) is duplicated; the majority rule `inside_votes * 2 > RAY_COUNT` is duplicated. The second file's comment says "Same scheme as tetrahedral_mesh_carve_outside_surface" — an acknowledged copy. ~100 lines. | **UNJUSTIFIED** | New module `core/geom/3d/topology/struct/binary/query/bt_mesh_build_face_bvh.js` already exists for the BVH half — reuse it or add `bt_mesh_point_is_inside_surface(mesh, bvh, x, y, z)` beside it, plus `bt_mesh_build_surface_triangle_bvh(bvh, mesh)`. Both callers then hold a `BVH` and call the predicate. | **S–M** / low. Both call sites have specs (`tetrahedral_mesh_carve_outside_surface.spec.js`, `bt_mesh_sample_interior_grid_points.spec.js`). |
+| 4 | HIGH | **Radial-cycle splice (the core half-edge invariant "link a loop into an edge's face ring") implemented three times, with two of them behaviourally different from the exported canonical one.** | `core/geom/3d/topology/struct/binary/io/bt_radial_loop_add.js:9` `bt_radial_loop_add` (exported, canonical) ⟷ `core/geom/3d/topology/struct/binary/io/face/bt_face_poke.js:130` `_link_loop_to_edge_local` ⟷ `core/geom/3d/topology/struct/binary/io/bt_mesh_from_indexed_geometry.js:123` `link_loop_to_edge` | All three set `loop_write_edge`, read `edge_read_loop`, branch on `NULL_POINTER`. **Divergence 1:** `bt_radial_loop_add` splices *before* the base loop (`loop_read_radial_prev`); the other two splice *after* (`loop_read_radial_next`) — different resulting ring order. **Divergence 2:** `bt_mesh_from_indexed_geometry.link_loop_to_edge` omits the self-link (`radial_next = radial_prev = loop`) in the first-loop branch entirely; it works only because `BinaryTopology.loop_initialize` (BinaryTopology.js:686) happens to self-link on allocation — an undocumented dependency the other two do not have. **Divergence 3:** `bt_face_poke.js:127` comments "Replicates logic from 'link_loop_to_edge' since it is not exported" — but `bt_radial_loop_add` *is* exported and does exactly this. | **UNJUSTIFIED** | Both private copies call `bt_radial_loop_add(mesh, loop, edge)`. Pick one ring order deliberately (the `prev` splice) and document it in `bt_radial_loop_add`'s JSDoc as the mesh-wide invariant. | **S** / medium. Ring *order* is observable through `loop_read_radial_next` walks, so `bt_face_poke` and `bt_mesh_from_indexed_geometry` specs plus `bt_mesh_validate` must be re-run; a change in insertion side can flip which face a two-face edge reports first. |
+| 5 | HIGH | **Static implicit-binary-tree spatial index (morton quicksort + bottom-up bounds assembly) forked 3D→2D; the fork carries a scratch-stack indexing bug the original does not.** | `core/bvh2/binary/2/BinaryUint32BVH.js`: `sort_morton` :336, `__swap_leaves` :411, `build` :426 ⟷ `core/geom/2d/r-tree/StaticR2Tree.js`: `sort_morton` :210, `__swap_leaves` :296, `build` :313. Also `initialize_structure`, `setLeafCount`, `setLeafData`, `getLeafBlockAddress`, `readLeafPayload` mirror one-for-one. | `build` is 289 tokens, token-identical modulo `BVH_BINARY_NODE_SIZE`→`BINARY_NODE_SIZE`, `BVH_LEAF_NODE_SIZE`→`LEAF_NODE_SIZE`, `aabb3_array_combine`→`aabb2_union_array`, `array_copy(...,6)`→`array_copy(...,4)`. `sort_morton` is the same hand-rolled explicit-stack quicksort. **Fork bug:** `StaticR2Tree.js:219-226` sets `stackPointer = stack_top + 2` but then writes the two seed values to the *absolute* slots `stack[0]` / `stack[1]` instead of `stack[stack_top]` / `stack[stack_top + 1]`; `BinaryUint32BVH.js:350-351` correctly uses `stack[stackPointer++]`. Only reachable when the shared `SCRATCH_UINT32_TRAVERSAL_STACK` is entered with a non-zero pointer, but the two implementations now disagree on a shared-scratch contract. | **UNJUSTIFIED** | Same shape as finding #1 but far smaller: hoist the two dimension-free routines into `core/bvh2/binary/implicit_tree_sort_morton.js` + `implicit_tree_build_bounds.js` taking `(data, binary_node_count, leaf_count, binary_node_size, leaf_node_size, combine_fn, morton_fn)`. If the per-node indirect call is unacceptable for `build`, at minimum fix the seed-write divergence and cross-reference the two in JSDoc. | **M** / medium. Both classes have specs. Prefer fixing the stack-seed divergence first as its own change. |
+| 6 | HIGH | **Relative-epsilon degenerate-quadratic critical-point solver written three times in `core/math/spline`, deliberately bypassing the shared `solveQuadratic` because that one still uses an absolute epsilon.** | `core/math/spline/spline3_hermite_bounds.js:22`, `core/math/spline/spline3_hermite_bounds_t.js:26`, `core/math/spline/spline3_bezier_bounds.js:20`. Existing primitive: `core/math/solveQuadratic.js:15`. | All three contain the identical block `const epsilon = max3(abs(a),abs(b),abs(c)) * 1e-12; if (abs(a) <= epsilon) { if (abs(b) > epsilon) {...linear root...} } else { const b2ac = b*b - 4*c*a; if (b2ac >= 0) {...two roots, each gated on 0 < t < 1...} }` — and the *same 3-line explanatory comment* about relative vs absolute thresholds is copy-pasted verbatim into all three. `solveQuadratic` uses `Math.abs(a) < EPSILON` (absolute, `core/math/EPSILON.js`) — i.e. exactly the defect these three were fixed for. A future fix to the degeneracy rule now has to land in four places. | **UNJUSTIFIED** | Add `core/math/solve_quadratic_relative(result, result_offset, a, b, c) -> count` implementing the relative-epsilon rule, then have all three spline functions call it and reduce min/max (or min/max + argmin/argmax for `_bounds_t`). Note: `_bounds` and `_bounds_t` cannot be merged into one function without an output-mode flag — do **not** try; sharing the *root finder* is the whole win. Separately consider whether `solveQuadratic` should adopt the relative rule (behaviour change, own commit). | **M** / medium. All three have specs; the `_t` variant additionally tracks argmin/argmax so its reduction stays local. |
+| 7 | MEDIUM | **`ConvexHullShape3D` and `MeshShape3D` share five copy-pasted query methods.** | `core/geom/3d/shape/ConvexHullShape3D.js`: `compute_bounding_box` :185, `signed_distance_at_point` :241, `nearest_point_on_surface` :271, `sample_random_point_in_volume` :297, `equals` :322. ⟷ `core/geom/3d/shape/MeshShape3D.js`: `compute_bounding_box` :145, `nearest_point_on_surface` :421, `signed_distance_at_point` :474, `sample_random_point_in_volume` :522, `equals` :576. | `sample_random_point_in_volume` is token-identical (sim 1.0, 210 tok) — 256-attempt bbox rejection sampling with a bbox-centre fallback. `compute_bounding_box` is identical (6 array copies from `__bbox`). `equals` is identical (128 tok) modulo the field name `vertices`/`positions`. `nearest_point_on_surface` (378/381 tok) and `signed_distance_at_point` (353/356 tok) differ only in field names and local variable names — the per-triangle `tri3_closest_point_barycentric` scan is line-for-line the same. | **UNJUSTIFIED** (this is duplicated *logic*, not per-class typed boilerplate) | Three moves: (a) `sample_random_point_in_volume` becomes the default implementation on `AbstractShape3D` (it needs only `compute_bounding_box` + `contains_point`, both already abstract) — every convex shape gets it free; (b) `compute_bounding_box` from a cached `__bbox` likewise; (c) add `core/geom/3d/shape/util/shape3_surface_scan_nearest_point.js` exporting `surface_scan_nearest_point(out, positions, indices, px, py, pz) -> number` returning best_d2 — both `nearest_point_on_surface` and `signed_distance_at_point` become 5-line wrappers in both classes. | **S** / low. Both classes have specs (`ConvexHullShape3D.spec.js`, `MeshShape3D.spec.js`, `raycast.spec.js`). |
+| 8 | MEDIUM | **Bounding box of a flat `(x,y,z)` buffer re-inlined instead of calling `aabb3_from_v3_array`.** | `core/geom/3d/shape/ConvexHullShape3D.js:103-114` (inside `recompute`), `core/geom/3d/shape/MeshShape3D.js:251-266` (inside `recompute_cached`). Existing primitive: `core/geom/3d/aabb/aabb3_from_v3_array.js:12`. | Both write the same 12-line `Infinity`/`-Infinity` seed + per-component `if (x < mn) …; if (x > mx) …` loop, then the same `if (count === 0) { all = 0 }` normalisation. `aabb3_from_v3_array` does the identical reduction via `min2`/`max2` and `aabb3_array_set`; the only real semantic delta is the empty-input policy (primitive leaves ±Infinity; the shapes zero it). `bt_mesh_sample_interior_grid_points.js:161-175` is a third copy over the topology vertex pool. | **UNJUSTIFIED** for the shapes | Call `aabb3_from_v3_array(this.__bbox, v, v.length)` and keep the two-line empty-input normalisation at the call site (or add `aabb3_array_is_empty`). Do **not** add an "empty policy" parameter — that is exactly the sentinel the house rules forbid. | **S** / low. |
+| 9 | MEDIUM | **`Vector3.applyQuaternion` and `Vector4.applyQuaternion` inline the quaternion sandwich product that `v3_quaternion_apply` already implements — and the "inlined for speed" justification is dominated by the `set()` signal dispatch in the same method.** | `core/geom/Vector3.js:675` `applyQuaternion`, `core/geom/Vector4.js:360` `applyQuaternion`. Existing primitive: `core/geom/vec3/v3_quaternion_apply.js:28`. | The 8-line expansion (`ix/iy/iz/iw` then `_x/_y/_z`) is identical in all three, term for term. `Vector3.js:676` says "NOTE: the logic is inlines for speed" — but both methods end in `this.set(...)` (`core/geom/Vector3.js:160`, `core/geom/Quaternion.js:1314`), which runs 6 asserts, a 3-way change comparison and `onChanged.send6(...)` when handlers exist. The array round-trip a `v3_quaternion_apply` call would cost is orders of magnitude below that. Contrast `core/geom/3d/shape/PosedShape3D.js:60` `support`, which inlines the *same* expansion with a **measured, documented** justification ("V8 declines to inline v3_quat3_apply at 9-arg call sites… hottest GJK call") — that one is legitimately hot and stays. | **UNJUSTIFIED** for `Vector3`/`Vector4`; the `PosedShape3D` copy is **JUSTIFIED** (documented hot-loop scalar inlining) | `Vector3.applyQuaternion(q)` → `v3_quaternion_apply(SCRATCH, 0, this[0], this[1], this[2], q.x, q.y, q.z, q.w); return this.set(SCRATCH[0], SCRATCH[1], SCRATCH[2]);` with a module-static `SCRATCH`. Same for `Vector4` (preserving `w`). | **S** / low. `Vector3.spec.js`/`Vector4.spec.js` cover it; note `v3_quaternion_apply` uses `q*` sign inlined identically so results are bit-identical. |
+| 10 | MEDIUM | **"Normalize a 3-vector, or emit zero when degenerate" is re-derived in at least four places with three different degenerate policies — there is no scalar `v3_normalize`.** | `core/geom/vec3/v3_matrix3_rotate.js:21`, `core/geom/vec3/v3_matrix4_rotate_unit.js:21`, `core/geom/vec3/v3_matrix4_rotate_normal.js:24` (identical 20-line tails: `length > 1e-7 ? scale : write zeros`), `core/geom/3d/shape/TransformedShape3D.js:199-209` (`mag > 0 ? scale : zeros`), `core/geom/3d/shape/util/compute_signed_distance_gradient_by_sampling.js:38-48` (`mag > 0 ? scale : zeros`), `core/geom/3d/mat4/m4_transform_direction_v3_buffer.js:44` (`1 / v3_length(...)` with **no** guard at all → ±Infinity on a zero vector). Nearest existing primitive: `core/geom/vec3/v3_normalize_array.js:10` (array-in, and its policy is `n = 1` on zero — i.e. leaves the vector as-is). | The three `v3_matrix*_rotate*` tails are token-identical (158/165 tok pairs at sim 0.938) including the `1e-7` literal and the "The transform is invalid. Provide arbitrary vector." comment. Four different answers to the same degenerate question is the actual hazard, not the line count. | **PROMOTION** | Add `core/geom/vec3/v3_normalize.js` → `v3_normalize(out, out_offset, x, y, z)` writing the unit vector, and `v3_normalize_or_zero(out, out_offset, x, y, z, epsilon)` documenting the zero policy once. Have the three rotate variants, `TransformedShape3D`, and the SDF-gradient sampler call it. Leave `v3_normalize_array` alone (different, documented policy) but cross-reference it. | **S** / low. `v3_matrix3_rotate.spec.js`, `v3_matrix4_rotate_normal.spec.js` exist. |
+| 11 | MEDIUM | **`MeshShape3D` re-implements the shared finite-difference SDF-gradient sampler with a different step size and no normalisation, while every other shape delegates to it.** | `core/geom/3d/shape/MeshShape3D.js:552` `signed_distance_gradient_at_point` ⟷ `core/geom/3d/shape/util/compute_signed_distance_gradient_by_sampling.js:11`. Delegating shapes: `ConvexHullShape3D.js:267`, `CapsuleShape3D.js:115`, `CylinderShape3D.js:129`, `SphereShape3D.js:103`, `BoxShape3D.js:112`, `UnionShape3D.js:219`. | Same forward-difference structure (centre sample + 3 axis samples + `(d_axis - d_center)/h`), but `MeshShape3D` uses `h = 1e-4` vs `SAMPLE_STEP = 1e-5`, and — unlike the shared helper — does **not** normalise the resulting gradient to unit length. Six shapes agree; one does not. | **UNJUSTIFIED** | `signed_distance_gradient_at_point(result, point) { return compute_signed_distance_gradient_by_sampling(result, this, point); }` — one line, matching every sibling. | **S** / low. Changes the returned gradient magnitude for meshes; `MeshShape3D.spec.js` may assert the current unnormalised values and would need updating to the (correct) unit-gradient contract. |
+| 12 | MEDIUM | **`hammersley_sequence` is `halton_sequence` with the arguments swapped.** | `core/math/statistics/hammersley_sequence.js:21` ⟷ `core/math/statistics/halton_sequence.js:11`. | Bodies: `let result = 0; let f = 1; let n = i; while (n > 0) { f = f / R; result += f * (n % R); n = (n / R) >>> 0; } return result;` vs the same with `base`/`index` names. Character-identical after renaming. The Hammersley doc even says "Computed in closed form, as {@link halton_sequence} does." Only real delta: `halton_sequence` asserts both args are non-negative integers; `hammersley_sequence` does not (and asserts are free in prod). Note `hammersley_sequence_2d.js` is a *different*, base-2 bit-reversal path (`radical_inverse_VdC_base_2`) and is fine. | **UNJUSTIFIED** | `export function hammersley_sequence(i, R) { return halton_sequence(R, i); }` — keeps the public name (library surface) and the argument order its callers use. | **S** / low. Both have specs. |
+| 13 | MEDIUM | **`curl_noise_3d` is `curl_noise_3dt` with `w = 0`, including the six duplicated decorrelation offsets.** | `core/math/noise/curl_noise_3d.js:15` ⟷ `core/math/noise/curl_noise_3dt.js:15`. | `diff -u` shows the entire difference is the extra `w` parameter added to one component of each of the three `sdnoise3` calls. With `w = 0` the two are literally the same function. The offsets `31.341, -43.23, 12.34, -231.141, 124.123, -54.4341` are duplicated digit-for-digit — retuning one silently decorrelates the pair. | **UNJUSTIFIED** | `export function curl_noise_3d(result, x, y, z) { curl_noise_3dt(result, x, y, z, 0); }`. Passing 0 is a real time value, not a sentinel. | **S** / low. `sdnoise.spec.js` covers the underlying noise; add a same-value assertion. |
+| 14 | MEDIUM | **`m4_compose` (object args) and `m4_from_rotation_translation_scale` (array args) contain the same 45-line quaternion→matrix expansion.** | `core/geom/3d/mat4/m4_compose.js:8` ⟷ `core/geom/3d/mat4/m4_from_rotation_translation_scale.js:20`. | The `x2/y2/z2 → xx/xy/xz/yy/yz/zz/wx/wy/wz` block and all 16 `result[i] = …` writes are identical; only the operand *reads* differ (`rotation.x` vs `q[0]`, `scale.x` vs `s[0]`). The array version's doc already calls itself the "array-argument companion to m4_compose", acknowledging the fork. The codebase's own convention elsewhere (`tri3_area` scalar + `tri3_compute_normal_v3_objects` wrapper) is exactly the fix. | **UNJUSTIFIED** | Add the scalar core `m4_from_rotation_translation_scale_scalar(out, qx,qy,qz,qw, tx,ty,tz, sx,sy,sz)` in the same directory; both existing exports become 3-line unpackers. Preserves both public names (library surface). | **S** / low. `m4_from_rotation_translation_scale.spec.js` exists. |
+| 15 | MEDIUM | **The boolean segment-segment intersection test is an exact prefix of the point-returning one.** | `core/geom/2d/line/segment2_intersects_segment2_2d.js:14` ⟷ `core/geom/2d/line/segment2_segment_compute_intersection_array_2d.js:20`. | Lines 15-27 of the boolean version and 25-37 of the array version are character-identical: `s1_x/s1_y/s2_x/s2_y`, `dy_02/dx_02`, `inv_denom = 1 / (-s2_x*s1_y + s1_x*s2_y)`, `s`, `t`, then the same `s >= 0 && s <= 1 && t >= 0 && t <= 1` test. The array version adds 6 lines to compute and store the intercept. Both share the same undocumented parallel-segments behaviour (`inv_denom = ±Infinity` → `s`/`t` become `±Infinity` or `NaN`). | **UNJUSTIFIED** | Extract `segment2_segment_intersection_fractions(out, out_offset, a0_x…b1_y) -> boolean` writing `[s, t]`; both public functions become thin. Document the parallel case once. | **S** / low. Both have callers in navigation/generation; behaviour must stay bit-identical. |
+| 16 | MEDIUM | **Reading a triangular face's three vertex ids / coordinates out of a `BinaryTopology` is hand-written at ~8 non-spec sites, with inconsistent "is it actually a triangle?" checking.** | `core/geom/3d/topology/struct/binary/query/bt_mesh_face_find_path.js:80` `face_read_vertices`; `…/bt_mesh_face_find_path_polyanya.js:93` `triangle_vertices`; `…/bt_mesh_sample_interior_grid_points.js:38-44`; `core/geom/3d/tetrahedra/tetrahedral_mesh_carve_outside_surface.js:41-48`; `core/geom/3d/atlas/data/atlas_build_face_areas.js:30-40`; `core/geom/3d/topology/struct/binary/io/bt_mesh_compute_face_normals.js:35-45`; `…/io/bt_mesh_compute_vertex_quadrics.js:54-68`; `…/query/bt_mesh_find_nearest_face.js:109-119`. | Every one is `l0 = face_read_loop(f); l1 = loop_read_next(l0); l2 = loop_read_next(l1);` followed by three `loop_read_vertex` and (usually) three `vertex_read_coordinate` into three 3-element scratch buffers. `atlas_build_face_areas`, `bt_mesh_compute_face_normals` and `bt_mesh_compute_vertex_quadrics` additionally check `loop_read_next(l2) === l0` and skip non-triangles; `tetrahedral_mesh_carve_outside_surface` and `bt_mesh_sample_interior_grid_points` **do not** and will silently mis-handle an n-gon. Each site declares its own module-static scratch. | **PROMOTION** | Add `core/geom/3d/topology/struct/binary/query/bt_face_read_triangle.js` exporting `bt_face_read_triangle_vertices(out, mesh, face) -> boolean` and `bt_face_read_triangle_coordinates(out, out_offset, mesh, face) -> boolean` (9 floats), both returning `false` for a non-triangular/unallocated face. That makes the triangle check impossible to forget. | **M** / low. Purely additive; migrate call sites one at a time. |
+| 17 | MEDIUM | **Straight-line vertex-to-vertex distance re-implemented inside both pathfinders while the primitive sits in the same directory — and the two copies use different formulas.** | `core/geom/3d/topology/struct/binary/query/bt_vertex_distance_to_vertex.js:12` (existing, uses `v3_distance`) ⟷ `…/bt_mesh_face_find_path.js:100` `vertex_distance` (`Math.sqrt(dx*dx+dy*dy+dz*dz)`) ⟷ `…/bt_mesh_face_find_path_polyanya.js:103` `vid_distance_3d` (`Math.hypot`). A fourth copy is `…/bt_mesh_build_boundary_distance_field.js:79` (`Math.hypot` inline). | Same three coordinate reads + same distance, three different spellings. `Math.hypot` and `sqrt(sum of squares)` are **not** bit-identical, so a geodesic cost computed by one pathfinder is not reproducible by the other on the same mesh — relevant because both are A*-style and their costs get compared in the bench specs. | **UNJUSTIFIED** | All four call `bt_vertex_distance_to_vertex(mesh, a, b)` (it already exists and is spec'd). If the module-static scratch inside it is a re-entrancy concern for the pathfinders, give it a `_scratch`-free scalar sibling — but pick **one** formula. | **S** / low, except that switching `hypot`→`sqrt` (or vice versa) can shift A* tie-breaking; run `bt_mesh_face_find_path.shortest_path.spec.js` and the polyanya specs. |
+| 18 | MEDIUM | **`order_cycle_from` and the fan-fill of a boundary loop are copy-pasted between the two hole-closing modules.** | `core/geom/3d/topology/struct/binary/io/bt_mesh_close_boundary_holes.js:20` `order_cycle_from` + the per-cycle body at :81-132 ⟷ `core/geom/3d/topology/struct/binary/io/bt_mesh_fill_small_holes.js:13` `order_cycle_from` + :60 `fill_loop`. | `order_cycle_from` is 245 tokens, token-identical (only brace formatting differs). `fill_loop` (:60-94) is a line-for-line copy of `bt_mesh_close_boundary_holes`'s loop body: same seed-edge/start-vertex derivation, same centroid accumulation, same face+loop allocation, same `bt_radial_loop_add` wiring, same `% n` next/prev ring, same `bt_face_poke` centroid fan. `bt_mesh_fill_small_holes.js:12` and :59 both say "Same as / as close_boundary_holes does" — acknowledged copies. ~75 lines. | **UNJUSTIFIED** | Export both from a new `core/geom/3d/topology/struct/binary/io/bt_boundary_loop.js`: `bt_boundary_loop_order_from(mesh, cycle, start_vertex, out_vertices, out_edges)` and `bt_boundary_loop_fill_fan(mesh, cycle)`. `bt_mesh_close_boundary_holes` becomes a loop over cycles calling `fill_fan`; `bt_mesh_fill_small_holes` keeps its measurement/threshold logic. | **S** / low. Both have specs. |
+| 19 | MEDIUM | **`project_triangle` (isometric triangle flattening) duplicated between the two chart parameterisers.** | `core/geom/3d/atlas/param/atlas_chart_parameterize_bff.js:39` ⟷ `core/geom/3d/atlas/param/atlas_chart_parameterize_lscm.js:64`. | Same algorithm (place v0 at origin, v1 on +x, project v2, write `[len1, x3, y3]`), 236/267 tokens, sim 0.78 — the BFF copy is just a tighter rewriting with intermediate `bx/by/bz`/`cx/cy/cz` folded away. The BFF version's comment reads "(Same as LSCM.)". | **UNJUSTIFIED** | Move to `core/geom/3d/triangle/tri3_flatten_isometric.js` → `tri3_flatten_isometric(out, out_offset, ax,ay,az, bx,by,bz, cx,cy,cz)` writing `[len_ab, x_c, y_c]`, plus an indexed wrapper for the `pos, i0, i1, i2` form both callers use. This is a genuinely reusable primitive (any conformal/ARAP/LSCM/geodesic-unfolding pass wants it — `bt_mesh_face_find_path_polyanya.js:137` `unfold_apex` solves a related problem). | **S** / low. Both parameterisers have specs. |
+| 20 | MEDIUM | **`qt_collect_by_circle` and `qt_match_data_by_circle` are the same traversal, differing by one predicate conjunct; and the circle queries lost the child-pruning the box/point queries have.** | `core/geom/2d/quad-tree/qt_collect_by_circle.js:19` ⟷ `core/geom/2d/quad-tree/qt_match_data_by_circle.js:21`. Contrast `qt_collect_by_box.js:22` and `qt_collect_by_point.js:19`. | The two circle functions are 212/228 tokens at sim 0.81; the only semantic delta is `&& predicate.call(predicateContext, datum.data)` on the accept line. Stack management differs cosmetically (`while (stack_pointer-- > 0)` vs `while (stack_pointer > 0) { --stack_pointer;`). Separately: both circle variants push all four children unconditionally (`:56-61`, `:61-66`), whereas `qt_collect_by_box` (:63-83) and `qt_collect_by_point` (:58-78) compute the node's half-planes and push only the quadrants that can overlap — so the circle path descends up to 4× more nodes. Each of the four files also declares its own module-static `node_stack`, none of which is re-entrancy-safe. | **UNJUSTIFIED** for the body; the missing pruning is a genuine divergence worth fixing at the same time | Make `qt_match_data_by_circle` the single implementation and define `qt_collect_by_circle` as it with a module-static `const ACCEPT_ALL = () => true` — a real function, not a null sentinel, and monomorphic so V8 inlines it. Add the quadrant pruning (`hx`/`hy` vs `x ± radius`) while you are in there. | **S–M** / low. `qt_match_data_by_circle.spec.js` and `qt_collect_by_point.spec.js` exist; add a circle-pruning spec. |
+| 21 | MEDIUM | **Winding-agnostic point-in-tetrahedron and coordinate-form `orient3d` are file-private in `MeshShape3D` while the shared versions sit in `core/geom/3d`.** | `core/geom/3d/shape/MeshShape3D.js:646` `orient3d_with_point`, `:686` `tet_contains_point_coords`. Existing: `core/geom/3d/plane/orient3d_fast.js:22`, `core/geom/3d/tetrahedra/tetrahedron_contains_point.js:17`. | `orient3d_with_point` is `orient3d_fast` with the fourth point taken as raw scalars instead of an index — the determinant expansion (`adx*(bdy*cdz - bdz*cdy) + …`) is character-identical. `tet_contains_point_coords` is `tetrahedron_contains_point` made winding-agnostic (accepts all-nonneg **or** all-nonpos rather than assuming one convention). `MeshShape3D.js:663-671` documents this explicitly: "the existing tetrahedron_contains_point helper, by contrast, was authored against a CW convention". So the shared helper is known to be convention-locked and the better version was written privately instead of promoted. `tetrahedral_mesh_walk_towards_containing_tetrahedron.js` is a third consumer of the convention-locked one. | **PROMOTION** | Add `core/geom/3d/plane/orient3d_fast_point.js` → `orient3d_fast_point(points, a, b, c, ex, ey, ez)` and `core/geom/3d/tetrahedra/tetrahedron_contains_point_either_winding.js` (or fix `tetrahedron_contains_point` to be winding-agnostic and document the change). `MeshShape3D` then imports both. | **S** / low if added as new exports; **medium** if `tetrahedron_contains_point` is changed in place (its spec encodes the CW convention). |
+| 22 | LOW-MEDIUM | **`m4_decompose` re-derives the whole of `m4_extract_scale`.** | `core/geom/3d/mat4/m4_decompose.js:10` ⟷ `core/geom/3d/mat4/m4_extract_scale.js:11`. | Lines 11-28 of `m4_decompose` are `m4_extract_scale`'s body verbatim (three `v3_length` calls over matrix columns 0/1/2, 4/5/6, 8/9/10, with the same `m11…m33` local names). `m4_decompose` then needs the raw `m11…m33` for the rotation extraction, so only the three `v3_length` calls are strictly shareable — but a change to how scale is read (e.g. handling a reflected basis) currently has to land twice, and `m4_decompose` already carries a determinant-sign correction that `m4_extract_scale` does not. | **UNJUSTIFIED (mild)** | `m4_decompose` calls `m4_extract_scale(scratch3, 0, mat4)` for the magnitudes and keeps its own `m11…m33` reads for the rotation. Or: document in both that the reflection handling deliberately lives only in `m4_decompose`. | **S** / low. `decompose_matrix_4_array.spec.js` exists. |
+| 23 | LOW-MEDIUM | **Barycentric-weights → 3D point reconstruction re-expanded at five sites instead of a `tri3_closest_point` primitive.** | `core/geom/3d/shape/ConvexHullShape3D.js:255-258` and `:286-289`, `core/geom/3d/shape/MeshShape3D.js:446-450` and `:498-502`, `core/geom/3d/shape/Triangle3D.js:169-175` and `:214-219`. Existing: `core/geom/3d/triangle/tri3_closest_point_barycentric.js` (returns weights only). | Every site does `tri3_closest_point_barycentric(bary, 0, p, a, b, c)` then the same `u = bary[0]; w = bary[1]; t = 1 - u - w; q = u*a + w*b + t*c` expansion — and each independently names the third weight differently (`t` / `w` / `alpha_c`), which is how one of them could quietly get the ordering wrong. | **PROMOTION** | Add `core/geom/3d/triangle/tri3_closest_point.js` → `tri3_closest_point(out, out_offset, px,py,pz, ax…cz) -> number` writing the closest point and returning the squared distance. Every one of the five call sites collapses to one line, and finding #7's surface-scan helper is then trivial to build on top. | **S** / low. |
+| 24 | LOW-MEDIUM | **The two `atlas_segment_charts` variants re-declare the same tuning constants and the same roundness term, with a comment claiming they must stay local.** | `core/geom/3d/atlas/segment/atlas_segment_charts.js`: `REJECT` :10, `NORMAL_DEVIATION_REJECT` :18, `STALE_EPSILON` :25, `chart_unit_normal` :97, roundness block :~140. ⟷ `core/geom/3d/atlas/segment/atlas_segment_charts_atomic.js`: `REJECT` :7, `NORMAL_DEVIATION_REJECT` :8, `STALE_EPSILON` :9, `chart_unit_normal` :49, roundness block :~100. | `chart_unit_normal` is token-identical (49 tok). The roundness block (`if (chart_area > 0 && chart_boundary > 0 && new_boundary > 0) { old_ratio = b²/a; new_ratio = …; R = … }`) is an identical 8-line window. The three constants are identical literals; the atomic file's comment says "kept local so the two segmenters stay monomorphic" — but the file **already imports `ATLAS_SEGMENT_DEFAULTS`** from its twin (`:3`), so the monomorphism argument doesn't cover module-level `const` numbers, which are inlined by V8 regardless of which module they come from. Retuning the 0.707 cutoff in one silently desyncs the two segmenters. | **Constants + roundness: UNJUSTIFIED. The greedy traversal itself: JUSTIFIED** (different growth graph — faces vs `RegionGraph` regions; unifying would require an adjacency-accessor abstraction that genuinely does de-monomorphize the inner loop, and the author documented that trade-off). | Export `REJECT`, `NORMAL_DEVIATION_REJECT`, `STALE_EPSILON` from `atlas_segment_charts.js` alongside `ATLAS_SEGMENT_DEFAULTS` and import them in the atomic variant. Move the roundness term to `atlas_chart_roundness_delta(chart_area, chart_boundary, new_area, new_boundary)` in `core/geom/3d/atlas/segment/`. Leave the loops alone. | **S** / low. Both have specs. |
+| 25 | LOW-MEDIUM | **The spatial-hash-grid cell walk (read element AABB out of the pool) is duplicated between the circle and line queries, including the same no-deduplication behaviour.** | `core/geom/2d/hash-grid/shg_query_elements_circle.js:118-146` ⟷ `core/geom/2d/hash-grid/shg_query_elements_line.js:71-100`. | Both contain the identical 15-line block: `let node = grid.cell_get_first_node(cell_index); while (node !== NULL_POINTER) { const element = grid.node_get_element(node); const element_address = element_pool.element_word(element); const element_x0/y0/x1/y1 = element_float32[element_address + COLUMN_ELEMENT_*]; … node = grid.node_get_same_cell_next_node(node); }` — only the acceptance predicate differs (`aabb2_distance_sqr_to_point <= r2` vs `aabb2_clip_line_cohen_sutherland`). Both share the consequence that an element linked into several visited cells is appended to `result` once per cell. | **PROMOTION** (the *cell iteration* is worth sharing; the predicate is not) | Add `shg_element_read_aabb(out, out_offset, grid, element)` next to `SpatialHashGrid.js` and use it in both. Whether to also share the walk depends on whether an accept-callback is acceptable in this path — if not, at minimum share the AABB read and document the multi-cell duplicate-emission behaviour in one place. | **S** / low. Both have specs. |
+| 26 | LOW | **Shape `hash()` methods disagree on the integer mixing function even though `combine_hash` exists.** | `core/geom/3d/shape/CapsuleShape3D.js:223` and `core/geom/3d/shape/CylinderShape3D.js:207` use `((a << 5) - a + b) \| 0`; `core/geom/3d/shape/BoxShape3D.js:158`, `HeightMapShape3D.js:456`, `ConvexHullShape3D.js:335`, `MeshShape3D.js:593` use `(h * 31 + x) \| 0`; `core/geom/Vector2.js:636` uses `((x << 5) - x) + y` with no `\| 0`. Existing: `core/collection/array/combine_hash.js:8` (used by `Vector4.js:394`). | The *shape* of these methods is per-class boilerplate and deliberate (house rule) — but the *mixing logic* is not, and it is inconsistent five ways across one class family. `Vector2.hash` also omits the `\| 0`, so it can return a non-int32. `CapsuleShape3D.hash` and `CylinderShape3D.hash` are byte-identical, meaning a capsule and a cylinder with equal radius/height collide — harmless given `equals` checks `constructor`, but unintended. | **UNJUSTIFIED (logic, not shape)** | Pick one mixer and use it everywhere. `combine_hash(...)` is varargs (allocates a rest array) so it is not ideal for a per-frame path — add `core/math/hash/hash_mix2(a, b)` / `hash_mix3(a, b, c)` returning `(a * 31 + b) \| 0` etc., and have every shape's `hash()` call it. Keep the per-class `hash()` methods; only the mixer moves. | **S** / low. |
+| 27 | LOW | **BFF's `interior_angle` re-implements `v3_angle` from an indexed buffer, using the acos form rather than the atan2-stable form that also exists.** | `core/geom/3d/atlas/param/atlas_chart_parameterize_bff.js:27` `interior_angle`. Existing: `core/geom/vec3/v3_angle.js:13` (`acos(v3_cos_angle(...))`, with a `clamp(-1,1)` inside `v3_cos_angle`), `core/geom/vec3/v3_angle_stable.js:14` (`atan2(|a×b|, a·b)`). | Identical math to `v3_angle`: two edge vectors, both lengths, `acos(clamp(dot/(lu*lv), -1, 1))`. Differences: BFF returns 0 when either length `< 1e-20` (where `v3_cos_angle` returns 0 for exactly-zero length only), and BFF clamps inline (`Math.acos(Math.max(-1, Math.min(1, c)))`) rather than via `clamp`. The angles feed the Gaussian-curvature sum `Ω = 2π − Σθ`, which is precisely where the acos form loses precision for near-degenerate slivers — and `v3_angle_stable` (the atan2 form) already exists for exactly that. | **UNJUSTIFIED (small), with a follow-up** | Call `v3_angle(ux,uy,uz, vx,vy,vz)` (or `v3_angle_stable` if the sliver precision matters — that is a numerical decision, not a refactor, and should be measured against `atlas_chart_parameterize_bff.spec.js`). | **S** / low for the swap to `v3_angle`; medium if switching to the stable form (changes BFF output on sliver charts). |
+| 28 | LOW | **Two different exported functions named `compute_edge_collapse_cost` in the same package.** | `core/geom/3d/topology/simplify/compute_edge_collapse_cost.js:20` — `(victim, target, victim_edge, vertex_quadratics)`, quadric + normal-flip + boundary penalty. ⟷ `core/geom/3d/topology/simplify/decimate_edge_collapse_snap.js:139` — `(edge, quadratics, restricted_vertices)`, quadric with a topological fallback. | Not shared code — two different cost models with the same name, in sibling files, both exported. For a library this is an import hazard (`import { compute_edge_collapse_cost } from '.../simplify/...'` resolves to whichever path you happened to type) and it makes "which cost does the simplifier use?" unanswerable without opening both. Flagged by the mechanical pass as a duplicate export; it is a naming collision, not duplication. | **UNJUSTIFIED (naming)** | Rename the one in `decimate_edge_collapse_snap.js` to `edge_collapse_cost_with_topology_fallback` (keeping a deprecated alias, per the library rule) — or move it to its own file with a distinct name. No code moves. | **S** / low. |
+| 29 | LOW | **Per-vertex quadric accumulation implemented twice, once per mesh representation, with divergent feature sets.** | `core/geom/3d/topology/simplify/quadratic/build_vertex_quadrics.js:37` (TopoMesh) ⟷ `core/geom/3d/topology/struct/binary/io/bt_mesh_compute_vertex_quadrics.js:23` (BinaryTopology). | Both: derive the face's supporting plane `(n, d = -n·v0)`, `q.setFromVector4(n, d)`, add `q` to each of the three vertices' `Quadric3`. The shared kernel is ~10 lines. Genuinely different iteration (object graph vs pooled ids). **Behavioural divergence worth noting:** the TopoMesh version supports `use_triangle_area` weighting and applies a border penalty (`apply_border_penalty_to_vertex_quadrics`, default `use_border_constraints = true`); the BinaryTopology version does neither, so the two simplification stacks weight boundaries differently. | **JUSTIFIED (two mesh representations, no common iteration surface)** — but the plane-quadric kernel is a promotion candidate and the feature divergence should be documented | Add `quadric3_set_from_triangle(q, ax,ay,az, bx,by,bz, cx,cy,cz)` beside `Quadric3.js` and call it from both. Do **not** try to unify the iteration. Add a JSDoc note on the BinaryTopology version stating that area weighting and border penalties are intentionally absent (or add them). | **S** / low. |
+| 30 | LOW | **`read_frustum_corner` is `v3_copy_array` with an index instead of an offset.** | `core/geom/3d/frustum/read_frustum_corner.js:8` ⟷ `core/geom/vec3/v3_copy_array.js:8`. | Same three reads + three writes; `read_frustum_corner` computes `address = source_index * 3` first, `v3_copy_array` takes the offset directly. `v3_copy_array` additionally reads all three components before writing any (documented, so overlapping ranges are safe); `read_frustum_corner` does the same by accident of ordering but does not say so. | **UNJUSTIFIED (trivial)** | `read_frustum_corner(source, source_index, destination, destination_offset) { v3_copy_array(destination, destination_offset, source, source_index * 3); }` — keeps the public name and the index-flavoured signature. | **S** / low. |
+
+## Dismissed leads
+
+- **All `@deprecated` rename shims.** I sampled ~40 of the 7-line `import X from './x.js'; export const OldName = X;` files across `geom/3d/triangle`, `geom/3d/aabb`, `geom/3d/mat4`, `geom/3d/sphere`, `geom/2d/circle`, `geom/2d/line`, `geom/vec3`, `geom/packing/max-rect`, `geom/random`, `geom/3d/tetrahedra`, `geom/3d/topology/simplify`. Every one is a genuine alias with zero duplicated logic. This accounts for the large majority of "same concept, two files" impressions in this domain. Not duplication; correct library practice.
+- `v2_*` vs `v3_*`, `aabb2_*` vs `aabb3_*` scalar pairs (`v2_distance`/`v2_distance_sqr`, `line2_compute_segment_point_distance_sqr` ⟷ `line3_…`, `aabb2_distance_sqr_to_point` ⟷ `aabb3_unsigned_distance_sqr_to_point`, `aabb2_from_v2_buffer` ⟷ `aabb3_from_v3_array`, `v2_array_normalize` ⟷ `v3_normalize_array`) — dimensional specialisation, house-rule justified.
+- `m3_cm_compose_transform` ⟷ `m3_rm_compose_transform`, `v2_matrix3_cm_multiply` ⟷ `v2_matrix3_rm_multiply` — row-major/column-major variants, house-rule justified.
+- `m2_multiply` ⟷ `m2_multiply_transposed` ⟷ `m2_add` ⟷ `m2_sub_transposed`; `polynomial_add_into` ⟷ `polynomial_sub_into`; `aabb3_compute_distance_above_plane_max` ⟷ `_min`; `query_face_next_vertex` ⟷ `query_face_prev_vertex`; `aabb3_array_intersects_ray` ⟷ `aabb3_array_near_distance_to_intersection_ray_segment` — same *shape*, genuinely different arithmetic. No shareable kernel.
+- `v3_quaternion_apply` ⟷ `v3_quaternion_apply_inverse` — the inverse is NOT the forward with negated components; the sign pattern genuinely differs and the file documents why (`v3_quaternion_apply_inverse.js:11-18`). Justified.
+- `sh3_sample_by_direction` ⟷ `sh3_sample_irradiance_by_direction` — same coefficient layout, different convolution (radiance vs cosine-convolved irradiance) and different constants. Justified.
+- `bt_mesh_build_boundary_distance_field` ⟷ `bt_mesh_build_boundary_euclidean_distance_field` — geodesic (eikonal fast-marching) vs Euclidean clearance. Documented as different metrics; 150 lines vs 32. Not duplication.
+- `bt_mesh_is_closed` ⟷ `bt_mesh_is_manifold` — same 8-line "for every allocated edge, count faces" loop but the predicate is `!== 2` vs `> 2`; extraction would need a callback for a loop this small. Both already delegate the counting to `bt_mesh_count_edge_faces`. Justified.
+- `orient3d_robust` / `in_sphere3d_robust` / `tetrahedron_compute_signed_volume` / `TetrahedralMesh.js` "gather 4 indexed points from a flat array" boilerplate (flagged 4× by the mechanical pass) — different arities, and extracting it means either boxing into an out-array or a 12-parameter call. Justified index-expansion boilerplate.
+- `polygon2_clip_axis_halfplane` ⟷ `polygon2_clip_halfplane` — the axis version is the general one specialised to an axis-aligned edge, and its only callers are `engine/physics/narrowphase/box_box_manifold.js:511-529` and `box_triangle_contact.js:414-420`, i.e. per-contact-manifold. Genuine hot-loop specialisation. **One caveat worth a separate look:** the general version applies a `POINT_EPS = 1e-9` boundary slack and the axis version applies none, so the two disagree on vertices exactly on the clip line.
+- `PosedShape3D.support` / `#world_point_to_local` inlining `v3_quaternion_apply(_inverse)` — explicitly justified in-file with a measured reason (V8 will not inline at 9-arg call sites; hottest GJK call). Correct application of the hot-loop carve-out. (Contrast finding #9.)
+- `CapsuleShape3D.from` ⟷ `CylinderShape3D.from`, `compute_bounding_box`, `equals` — per-class typed constructor/accessor boilerplate. House-rule deliberate. (Only their `hash()` *mixer* is flagged, in finding #26.)
+- `Vector2/3/4` + `Quaternion` + `Color` `fromBinaryBuffer` / `toBinaryBuffer` / `toArray` / `set` / `constructor` families (flagged 6× by the mechanical pass) — per-class serialization and accessor boilerplate over different component counts. House-rule deliberate; unifying would need string-keyed or metaprogrammed field lists.
+- `bvh_query_leaves_ray` / `bvh_query_leaves_ray_segment` ⟷ `bvh2d_query_all_data_by_circle` — share only the generic explicit-stack tree-descent skeleton (`if (root === NULL_NODE) return 0; stack[stack_top] = root; …`); the node test and payload differ entirely. Not a shareable unit without a visitor.
+- `tetrahedron_compute_quality` / `tetrahedral_mesh_compute_tet_quality` / `compute_tetrahedron_quality` and the volume trio — already correctly factored as indexed primitive + mesh wrapper + deprecated alias. Exemplary, not duplication.
+- `simplify/quadratic/compute_edge_collapse_cost_quadratic.js`, `bt_mesh_compute_vertex_quadratics.js`, `shape3d_voxelize_to_grid.js`, `sh_compute_K.js`, `aabb3_near_distance_to_intersection_ray_segment.js` — all rename shims (the "quadratic"→"quadric" pass).
+- `core/geom/3d/sphere/harmonics/compute_legendre_polynomial.js` — a **0-byte file** dated 2024 shadowing `core/math/compute_legendre_polynomial.js`. Not duplication; dead empty file. Worth deleting but out of scope.
+- `aabb3_intersects_ray` ⟷ `aabb3_intersects_segment3` — both separating-axis tests, but one is an infinite ray with `diff*dir >= 0` early-outs and the other inflates the box by the segment half-extent. Different tests; only stylistic resemblance.
+- `Math.sqrt(x*x+y*y+z*z)` hits (78 global, ~32 in domain) — checked the concentrations. In `tri3_area`, `tri3_incenter`, `atlas_chart_parameterize_bff/lscm`, `polygon3_compute_normal`, `bt_mesh_face_find_path`: these are per-triangle / per-vertex / per-CG-iteration inner loops, and `v3_length` is itself `Math.sqrt(x*x+y*y+z*z)` with no guard, so calling it buys nothing but a call. Justified. The ones that *matter* are the normalize-with-a-policy sites, which are finding #10.
+- `inline_lerp` hits (129 global, 27 in domain) — every one I opened is either a dot product misclassified by the pattern (`(px-ax)*nx + …` in `Triangle3D.js:191`, `bt_mesh_segment_penetrates_surface.js:44`, `bt_mesh_face_find_path.js:342`) or a per-component 3-float interpolation in a hot mesh loop (`bt_edge_split.js:55-64`, `capsule_intersects_aabb3_closed.js:57-59`). No cold-code `lerp` bypasses found.
+- `computeHashArray` ⟷ `computeHashFloatArray` — different input domains (integers vs floats needing `computeHashFloat`). Out of domain anyway (`core/collection`).
+- `halton_sequence` ⟷ `hammersley_sequence_2d` — different algorithms (general-base closed form vs base-2 bit reversal). Only the 1-D `hammersley_sequence` is a duplicate (finding #12).
+- `mie/ri_*.js` repeated 8-line data blocks, `atlas_test_fixtures.js` ⟷ `RGB_LUT_*.js` — these are numeric data tables, not code.
+- `complex_mul` ⟷ `m3_multiply` / `m4_normal_matrix3`; `linear_to_sRGB` ⟷ `aabb2_union_array`; `BVHGeometry.makeCube` ⟷ `bt_edge_create.edge_link_disk`; `plane3_lerp` ⟷ `edge_link_disk`; `read_frustum_corner` ⟷ `mat4x4_transpose_copy_to_mat4x3` — MinHash noise. Structurally similar (flat arithmetic over indexed arrays), semantically unrelated.
+
+## Notes
+
+Why duplication accumulates here, structurally:
+
+1. **The "scalar arguments, caller-owned output buffer" convention has no composition story for *policies*.** Every primitive is `f(out, out_offset, …scalars)`, which is excellent for allocation-freedom and terrible for sharing decisions like "what do we do when the length is zero" or "how relative should the degeneracy epsilon be". So the arithmetic gets reused (`v3_length`, `v3_dot`, `tri3_area` are called everywhere) while the *policy* around it gets retyped — findings #6, #10, #11 are all the same failure. The fix is not more helpers; it is naming the policy (`v3_normalize_or_zero`, `solve_quadratic_relative`) so it has somewhere to live.
+
+2. **Dimensional forks start as copies and are never re-synced.** `BVH2D` and `StaticR2Tree` were each created by copying a 3D file and deleting a `z`. Because the copy is complete rather than layered, every later improvement to the 3D side (SAH rotation, linear allocation, the stack-seed fix) lands in one place only. Both forks are now measurably behind their originals. The house rule that 2D/3D scalar specialisation is justified is right for `v2_dot` vs `v3_dot`; it does not extend to 1100-line classes whose pointer machinery never touches a coordinate.
+
+3. **Private helpers get re-derived because the public one is not discoverable from where you are standing.** `bt_face_poke` wrote its own radial splice with a comment saying the function it wanted "is not exported" — while `bt_radial_loop_add` sat exported two directories up. `bt_mesh_face_find_path` wrote `vertex_distance` while `bt_vertex_distance_to_vertex` sat in the *same directory*. `MeshShape3D` wrote its own SDF gradient while six sibling shapes call the shared one from `./util/`. With ~1000 files in this domain and a naming scheme that encodes the *operand type* rather than the *operation*, grep-by-concept genuinely does not work.
+
+4. **The good news, which shapes the recommendations:** the domain is already unusually disciplined about the *renaming* half of this problem — hundreds of `@deprecated` re-export shims mean old names never became second implementations. The remaining duplication is almost entirely (a) pre-shim forks that predate that discipline, and (b) private helpers that should have been promoted. Both are addressable incrementally; none of the findings above except #1 requires touching more than a handful of files.