@woosh/meep-engine 2.168.0 → 2.169.0

package/src/REVIEW_2026_08_06/core-collection.md

@@ -0,0 +1,376 @@
+# Correctness review — `core/collection`, `core/cache`, `core/events`, `core/fsm`, `core/function`, `core/IdPool.js`
+
+Scope: every non-spec source file under the listed directories. Every finding below was reproduced
+by executing the real modules through the project's jest harness (`npx jest --config jest.conf.json`
+from `H:/git/moh`, with a throwaway spec under `app/src/`, since removed). Observed values quoted in
+the failure scenarios are actual program output, not derivations.
+
+---
+
+## CRITICAL
+
+### COLL-1 `SortedListProjection` inserts at the wrong index — output is never sorted
+- **Severity**: CRITICAL
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/collection/list/SortedListProjection.js:47-51`
+- **Defect**: `binarySearchLowIndex` returns *the index of the largest element `<= el`* (or `-1` when
+  `el` precedes everything). `handleAddition` passes that value straight to `List.insert`, so the
+  element is placed **before** its predecessor instead of after it. The `-1` case is worse: it reaches
+  `List.insert(-1, el)`, whose `else` branch runs `this.data.splice(-1, 0, el)` — a negative splice
+  index that inserts before the *last* element — and then dispatches `on.added` with index `-1`.
+- **Failure scenario**:
+  ```js
+  const input = new List();
+  const p = new SortedListProjection(input, (a, b) => a - b);
+  p.link();
+  input.add(3); input.add(5); input.add(7); input.add(4); input.add(1);
+  ```
+  `p.output.asArray()` → `[5, 7, 4, 1, 3]` (measured). Expected `[1, 3, 4, 5, 7]`. The very first
+  two insertions happen to look right, which is why the defect hides in small cases.
+- **Fix**: insert after the found floor index, and normalise the "before everything" result:
+  `const where = binarySearchLowIndex(this.output.data, el, this.comparator); this.output.insert(where + 1, el);`
+  (`-1 + 1 === 0` gives the correct front insert). Separately, `List.insert` should reject negative
+  indices rather than forwarding them to `splice`.
+- **Confidence**: Confirmed
+
+### COLL-2 `BiMap.add` writes both directions inverted — every accessor returns `undefined`
+- **Severity**: CRITICAL
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/collection/map/BiMap.js:24-45`
+- **Defect**: `add(key, value)` does `forward.set(value, key)` and `backward.set(key, value)`, i.e.
+  `forward` ends up keyed by *value* and `backward` by *key* — the opposite of the declared field
+  types (`forward: Map<K,V>`, `backward: Map<V,K>`) and of what `getValueByKey` / `getKeyByValue`
+  read. Both accessors, and therefore the `get`/`set` Map-compatibility aliases installed on the
+  prototype, miss on every entry.
+- **Failure scenario**:
+  ```js
+  const m = new BiMap();
+  m.set('a', 1);
+  m.get('a');            // undefined   (expected 1)
+  m.getValueByKey('a');  // undefined   (expected 1)
+  m.getKeyByValue(1);    // undefined   (expected 'a')
+  ```
+  All three measured as `undefined`.
+- **Fix**: swap the two writes in `add`: `this.forward.set(key, value); this.backward.set(value, key);`.
+  Note that the single in-repo consumer, `core/binary/EncodingBinaryBuffer.js` (`writeUTF8String` /
+  `readUTF8String`), currently compensates for the inversion by calling `add(stringValue, address)`
+  and then reading it back with `getKeyByValue(stringValue)` → address and `getValueByKey(address)` →
+  string. Its two `add(...)` call sites must have their arguments swapped in the same change,
+  otherwise fixing `BiMap` breaks string interning in the encoding buffer.
+- **Confidence**: Confirmed
+
+### COLL-3 `Signal.merge` forwards the `arguments` object instead of the arguments
+- **Severity**: CRITICAL
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/events/signal/Signal.js:797-808`
+- **Defect**: the bridging handler is `function handler() { result.dispatch(arguments); }`. `dispatch`
+  is variadic (`dispatch(...args)`), so the whole `arguments` object arrives as `args[0]`. Every
+  listener on a merged signal receives one array-like object rather than the original payload.
+- **Failure scenario**:
+  ```js
+  const a = new Signal(), b = new Signal();
+  const m = a.merge(b);
+  m.add((...args) => console.log(args));
+  a.send1(42);
+  ```
+  Logged `[ { '0': 42 } ]` (measured); expected `[ 42 ]`.
+- **Fix**: `function handler() { result.dispatch(...arguments); }` (or `result.dispatch.apply(result, arguments)`).
+- **Confidence**: Confirmed
+
+---
+
+## MAJOR
+
+### COLL-4 `Deque.removeFirst` / `removeLast` on an empty deque corrupts head/tail/status
+- **Severity**: MAJOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/collection/queue/Deque.js:321-327` and `:353-360`
+- **Defect**: neither method checks `#status`. On an empty deque `removeFirst` still advances `#head`
+  past `#tail`, then `#reset_status(false)` sees `head !== tail` and sets `STATUS_NORMAL`. The deque
+  now reports itself as non-empty and `size()` computes `tail + capacity - head` — one short of the
+  whole backing array. `removeLast` fails symmetrically by moving `#tail` backwards.
+- **Failure scenario**:
+  ```js
+  const d = new Deque();      // default capacity 16
+  d.removeFirst();            // -> undefined, as documented by @returns {T|undefined}
+  d.isEmpty();                // false   (measured; expected true)
+  d.size();                   // 15      (measured; expected 0)
+  ```
+  Any drain loop written against the documented `undefined` sentinel —
+  `while ((v = q.removeFirst()) !== undefined) {...}`, or the `pop()` alias in stack usage — leaves
+  the deque permanently poisoned: a following `while (!q.isEmpty()) q.removeFirst()` spins over 15
+  phantom `undefined` slots.
+- **Fix**: return `undefined` immediately when `this.#status === STATUS_EMPTY` in both `removeFirst`
+  and `removeLast`, before touching `#head`/`#tail`.
+- **Confidence**: Confirmed
+
+### COLL-5 `BinaryHeap.pop` on an empty heap sets `length = -1`; the next `push` throws
+- **Severity**: MAJOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/collection/heap/BinaryHeap.js:160-184`
+- **Defect**: `pop()` decrements `this.length` unconditionally. On an empty heap `length` becomes
+  `-1`, `new_length !== 0` so the method falls through and writes `this.data[0] = undefined`,
+  re-growing the backing array. The subsequent `push` computes `position = this.length` (`-1`) and
+  calls `bubbleUp(-1)`, which reads `data[-1]` (`undefined`) and hands it to the score function.
+- **Failure scenario**:
+  ```js
+  const h = new BinaryHeap(x => x.score);
+  h.pop();          // -> undefined  (behaviour asserted by BinaryHeap.spec.js:23 and :34)
+  h.size();         // -1     (measured)
+  h.isEmpty();      // false  (measured)
+  h.push({score: 7});
+  // TypeError: Cannot read properties of undefined (reading 'score')   (measured)
+  ```
+  With a total score function such as `returnZero` there is no throw, but the pushed element is
+  silently lost (`size()` returns 0 afterwards). `BinaryHeap.spec.js:150` itself uses the
+  `while ((x = h.pop()) !== undefined)` drain pattern, so popping past empty is a sanctioned call.
+- **Fix**: early-return `undefined` when `this.length === 0` at the top of `pop()`.
+- **Confidence**: Confirmed
+
+### COLL-6 `FilteredListProjection.apply` uses `invokeObjectEquals`, throwing on any element without `.equals`
+- **Severity**: MAJOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/collection/list/FilteredListProjection.js:139`
+- **Defect**: the diff uses `array_set_diff(oldOutput, newOutput, invokeObjectEquals)`, and
+  `invokeObjectEquals(a, b)` is an unguarded `a.equals(b)`. Any element type without an `equals`
+  method (numbers, strings, plain objects) throws. The throw is swallowed by `Signal`'s dispatch
+  `try/catch`, so the projection just stops updating and `output` silently goes stale forever.
+  `List.patch`, which performs the identical diff, correctly uses the guarded `objectsEqual`.
+- **Failure scenario**:
+  ```js
+  const input = new List([1, 2, 3]);
+  const p = new FilteredListProjection(input, new List());
+  p.deferred = false;
+  p.link();        // output === [1,2,3] — first apply is safe because oldOutput is empty
+  input.add(4);    // second apply
+  ```
+  Measured: `Failed to dispatch handler [Function: update] TypeError: a.equals is not a function`
+  at `invokeObjectEquals.js:9` via `array_set_diff.js:30`. `p.output` stays `[1,2,3]` with no
+  visible error to the caller.
+- **Fix**: pass `objectsEqual` (from `core/function/objectsEqual.js`) instead of
+  `invokeObjectEquals`, matching `List.patch`.
+- **Confidence**: Confirmed
+
+### COLL-7 `SortedListProjection` never observes removals from the input list
+- **Severity**: MAJOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/collection/list/SortedListProjection.js:33-41`
+- **Defect**: `link()` subscribes only to `input.on.added`; `unlink()` unsubscribes only that. There
+  is no `on.removed` handler, so elements deleted from the input remain in `output` indefinitely.
+  This is independent of COLL-1 — fixing the insertion index alone still leaves the projection wrong.
+- **Failure scenario**: with COLL-1 fixed, `input.add(3); input.add(5); input.remove(0);` leaves
+  `output` as `[3, 5]` while `input` is `[5]`. Measured on the current code: after
+  `input.add(3..1); input.remove(0)`, `output` was unchanged at `[5,7,4,1,3]`.
+- **Fix**: in `link()` add `this.input.on.removed.add(this.handleRemoval, this)` with a handler that
+  locates the element in `output` (binary search on the comparator, then linear scan across the
+  equal-comparing run for identity) and removes it; mirror the unsubscribe in `unlink()`.
+- **Confidence**: Confirmed
+
+### COLL-8 `ArrayIteratorRandom.initialize` does not truncate the shuffle sequence
+- **Severity**: MAJOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/collection/array/iterator/ArrayIteratorRandom.js:23-35`
+- **Defect**: `initialize` writes `__sequence[i] = i` for `i < data.length` but never shrinks
+  `__sequence`. `array_shuffle` then permutes the full stale length and `next()` bounds its loop with
+  `sequence.length`, so re-initialising the (explicitly reusable, allocation-free) iterator with a
+  shorter array yields too many items — including `undefined` — and repeats real ones.
+- **Failure scenario**:
+  ```js
+  const it = new ArrayIteratorRandom();
+  it.initialize(['a','b','c']);
+  it.initialize(['x','y']);
+  // drain via next(result)
+  ```
+  Yielded `["x", "y", undefined]` (measured) — three items from a two-element array.
+- **Fix**: `this.__sequence.length = n;` after the fill loop (before `array_shuffle`), or pass the
+  explicit `length` argument that `array_shuffle` already supports and use it as the bound in `next`.
+- **Confidence**: Confirmed
+
+### COLL-9 `RowFirstTable.hash()` is inconsistent with `RowFirstTable.equals()`
+- **Severity**: MAJOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/collection/table/RowFirstTable.js:121-150`
+- **Defect**: `hash()` seeds from `this.data.byteLength` and taps across the whole *allocated buffer*,
+  including capacity beyond `length`. `equals()` compares only `length * bytesPerRecord` bytes. Two
+  tables that compare equal therefore hash differently whenever their capacities differ, breaking the
+  hash/equals contract for any `HashMap`/`HashSet`/`Cache` keyed by a table, and for hash-based
+  dirty-checking. (`hash()` also returns a non-int32 value because the accumulator is never masked.)
+- **Failure scenario**:
+  ```js
+  const spec = RowFirstTableSpec.get([BinaryDataType.Uint32]);
+  const a = new RowFirstTable(spec);
+  for (let i = 0; i < 20; i++) a.addRow([i]);   // grows to capacity 52
+  const b = new RowFirstTable(spec);
+  b.copy(a);
+  b.trim();                                     // capacity 20
+  a.equals(b);   // true            (measured)
+  a.hash();      // -13796099888    (measured)
+  b.hash();      // 4190943312      (measured)
+  ```
+- **Fix**: derive the hash from the live region only — seed with `this.length` (and
+  `spec.bytesPerRecord`) and bound the tap loop by `this.length * spec.bytesPerRecord >> 2` instead of
+  `this.data.byteLength >> 2`. Also `|0` the accumulator so the result is a 32-bit integer.
+- **Confidence**: Confirmed
+
+### COLL-10 `serializeRowFirstTable` / `deserializeRowFirstTable` drop the spec's endianness
+- **Severity**: MAJOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/collection/table/serializeRowFirstTable.js:8-27`,
+  `H:/git/moh/app/src/mir-engine/meep/src/core/collection/table/deserializeRowFirstTable.js:39`
+- **Defect**: the serializer writes column types, record size and record count but not
+  `spec.endianType`. The deserializer rebuilds the spec with `RowFirstTableSpec.get(types)`, which
+  defaults to `EndianType.LittleEndian`. A table built on a big-endian spec round-trips with every
+  multi-byte cell byte-swapped. (`bytesPerRecord` is read and then discarded, so there is not even an
+  incidental mismatch check.)
+- **Failure scenario**:
+  ```js
+  const spec = new RowFirstTableSpec([BinaryDataType.Uint32], EndianType.BigEndian);
+  const t = new RowFirstTable(spec);
+  t.addRow([1]);
+  // serialize into a BinaryBuffer, rewind, deserialize into a fresh table
+  t2.readCellValue(0, 0);   // 16777216   (measured; expected 1)
+  ```
+  `t2.spec.endianType` came back as LittleEndian regardless of the source spec.
+- **Fix**: write `spec.endianType` (one byte) after the type list in the serializer and pass it to
+  `RowFirstTableSpec.get(types, endianType)` on read. Bump/branch on a format marker if existing
+  payloads must stay readable.
+- **Confidence**: Confirmed
+
+### COLL-11 `FrequencySketch` keeps Caffeine's 16-counters-per-slot layout on a 32-bit table
+- **Severity**: MAJOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/cache/FrequencySketch.js:43-68`, `:172-218`
+- **Defect**: the port kept Caffeine's `long[]` addressing — `start = (hash & 3) << 2` with
+  `start + i` spanning `0..15`, and shifts of `(start + i) << 2` spanning `0..60` — but the table is a
+  `Uint32Array`, which holds only 8 four-bit counters per word. JavaScript takes shift counts mod 32,
+  so logical counters 8..15 silently alias counters 0..7 in both `incrementAt` (`0xF << offset`,
+  `1 << offset`) and `frequency` (`table[index] >>> ((start + i) << 2)`). Half the counter space is
+  unreachable and the documented width / error bound (`e / width`, 93.75% confidence) does not hold.
+- **Failure scenario**:
+  ```js
+  const s = new FrequencySketch();
+  s.ensureCapacity(1);
+  s.increment(0);        // spread(0)  & 3 === 0  -> logical counters 0..3
+  s.frequency(3);        // spread(3)  & 3 === 2  -> logical counters 8..11
+  ```
+  Measured `s.frequency(3) === 1` (table word `0x1111`); the 16-counter layout the class documents
+  gives `0`. Element 3 was never incremented. This feeds `CacheWTinylfu.__admissionDuel` /
+  `shouldPromoteToProtected` directly, so admission and promotion decisions are made on inflated
+  frequencies.
+- **Fix**: either restrict the layout to the 8 counters a `Uint32Array` actually has
+  (`start = (hash & 1) << 2`, `start + i` in `0..7`, `RESET_MASK`/`ONE_MASK` already correct for 32
+  bits), or keep 16 counters per logical slot by addressing a `Uint32Array` of `2 * length` as pairs
+  (word `= index * 2 + ((start + i) >> 3)`, shift `= ((start + i) & 7) << 2`). Update the class
+  docstring to match whichever is chosen.
+- **Confidence**: Confirmed
+
+---
+
+## MINOR
+
+### COLL-12 `Signal.contains` ignores its documented "thisArg optional" contract
+- **Severity**: MINOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/events/signal/Signal.js:101-113`
+- **Defect**: the JSDoc states `@param {*} [thisArg] if not present, will not be considered`, but the
+  call is forwarded to `signal_handler_list_find`, which requires `n.context === thisArg`. With
+  `thisArg` omitted the comparison becomes `context === undefined`, so any handler registered with a
+  context reports as absent.
+- **Failure scenario**: `const s = new Signal(); s.add(f, ctx); s.contains(f)` → `false` (measured),
+  while `s.contains(f, ctx)` → `true`. Callers using `contains` as an "is this function subscribed at
+  all?" guard will double-register.
+- **Fix**: when `thisArg === undefined`, walk the chain matching on `handle` only (a dedicated
+  `signal_handler_list_find_by_handle`, mirroring the existing
+  `findSignalHandlerIndexByHandle`/`...AndContext` pair), or correct the JSDoc to state that the
+  context is always part of the match.
+- **Confidence**: Confirmed
+
+### COLL-13 `array_contains_duplicates` ignores `end_index` when scanning forward
+- **Severity**: MINOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/collection/array/array_contains_duplicates.js:22`
+- **Defect**: the outer loop respects `end_index`, but the inner probe is
+  `source.indexOf(element, k + 1)` with no upper bound, so it reports duplicates that lie outside the
+  requested `[start_index, end_index]` window. The parameters are documented as
+  "first/last index to be included in the search".
+- **Failure scenario**: `array_contains_duplicates([1, 2, 1], 0, 1)` → `true` (measured). The window
+  `[0,1]` contains `[1, 2]`, which has no duplicates. The spec only exercises the whole-array default.
+- **Fix**: bound the probe, e.g.
+  `const p = source.indexOf(element, k + 1); if (p !== -1 && p <= end_index) return true;`
+- **Confidence**: Confirmed
+
+### COLL-14 `weightedRandomFromArray` can return a zero-weight element
+- **Severity**: MINOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/collection/array/weightedRandomFromArray.js:43-50`
+- **Defect**: zero-weight entries leave `weight_total` unchanged, so the cumulative array repeats a
+  value. `binarySearchHighIndex` returns on exact equality, which selects the *first* index holding
+  that cumulative value — the zero-weight one. The intended semantics need the first index whose
+  cumulative weight is *strictly greater* than the target.
+- **Failure scenario**:
+  `weightedRandomFromArray(['A','B'], () => 0, x => x === 'A' ? 0 : 1)` → `'A'` (measured), an element
+  whose weight is 0 and which should be unreachable. Triggered whenever the supplied `random` returns
+  exactly `0` (seeded generators commonly can) and the leading element has zero weight.
+- **Fix**: after the binary search, advance past any run of equal cumulative values —
+  `while (index < length - 1 && scratch_weights[index] === scratch_weights[index + 1]) index++;` — or
+  use a dedicated upper-bound search that never short-circuits on equality.
+- **Confidence**: Confirmed
+
+### COLL-15 `sparse_typed_array_hash` silently ignores its `offset` parameter
+- **Severity**: MINOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/collection/array/typed/sparse_typed_array_hash.js:13-25`
+- **Defect**: the function takes `offset` but hard-codes `0` in the `computeStridedArrayHash` call, so
+  the hash always starts at index 0 regardless of the requested range.
+- **Failure scenario**:
+  `sparse_typed_array_hash(new Uint8Array([9,1,2]), 1, 3)` → `79698` and
+  `sparse_typed_array_hash(new Uint8Array([7,1,2]), 1, 3)` → `81620` (both measured). The two arrays
+  are identical over the requested `[1,3)` range and must hash the same; they differ only at index 0,
+  which should have been skipped. All three in-repo callers pass `offset === 0`, so nothing live is
+  affected today — but this is public library surface.
+- **Fix**: forward the parameter: `computeStridedArrayHash(array, offset, offset + hash_evaluation_length, stride, computeHashFloat)`
+  (`computeStridedArrayHash` treats its third argument as an exclusive end index), or drop the
+  parameter from the signature if a fixed prefix is genuinely intended.
+- **Confidence**: Confirmed
+
+### COLL-16 `uint8_array_hash` / `uint16_array_hash` mis-handle a non-zero `offset`
+- **Severity**: MINOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/collection/array/typed/uint8_array_hash.js:13-33`,
+  `H:/git/moh/app/src/mir-engine/meep/src/core/collection/array/typed/uint16_array_hash.js:13-26`
+- **Defect**: the head-alignment count is derived from `length` alone (`length & 3`, `length & 1`)
+  while the cursor starts at `offset`, and the main loop's bound is `i < length`. With `offset > 0`
+  the two disagree: the word loop reads `array[i+1..i+3]` past the requested end, so bytes outside
+  the range enter the hash (and out-of-range reads coerce to `0`). The sibling `uint32_array_hash`
+  and the only in-repo caller `array_buffer_hash` treat the third argument as an exclusive end index
+  and always pass `offset === 0`; under either reading (end index or count) the 8-bit and 16-bit
+  variants are wrong for `offset > 0`.
+- **Failure scenario**:
+  `uint8_array_hash(new Uint8Array([0,0,1,2,3,7,7]), 2, 5)` → `117904870` and
+  `uint8_array_hash(new Uint8Array([0,0,1,2,3,8,8]), 2, 5)` → `134747622` (both measured). The
+  requested range `[2,5)` is `1,2,3` in both arrays, so the hashes must match; indices 5 and 6 leaked
+  in. The existing spec calls `uint8_array_hash(arr, 1, 3)` but only asserts the result is a finite
+  integer, so the defect is untested.
+- **Fix**: compute the head remainder from the range size, not the total — `const n = length - offset;
+  const overflow = n & 3;` — and run the word loop while `i + 3 < length`, handling any tail
+  byte-wise. Same shape for the 16-bit variant (`(length - offset) & 1`, loop while `i + 1 < length`).
+- **Confidence**: Confirmed
+
+### COLL-17 `HashMap`/`HashSet`/`Cache` constructed with `capacity: 0` throw
+- **Severity**: MINOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/collection/map/HashMap.js:224` and `:247, 270-290`
+- **Defect**: the constructor explicitly permits `capacity === 0` (`assert.isNonNegativeInteger`), but
+  `ceilPowerOfTwo(0)` returns `0` and `#setBinCount(0)` computes `ctz32(0) === 32`, giving
+  `__entries_allocated_count = 2 ** 32`. In development the `greaterThanOrEqual(count, 1)` assert
+  fires; in a production bundle that assert is stripped and execution reaches
+  `UintArrayForCount(2 ** 32 + 2)`, which throws `Unsupported size 4294967298`. Either way an
+  otherwise-legal argument aborts construction, and it propagates to `HashSet` and `Cache`, both of
+  which forward `capacity` untouched.
+- **Failure scenario**: `new HashMap({ capacity: 0 })` → thrown
+  `bucket count must be at least 1. Expected 0 >= 1.` (measured under the test harness);
+  `Unsupported size 4294967298` in a production build. Same for `new HashSet({capacity: 0})` and
+  `new Cache({capacity: 0})`.
+- **Fix**: clamp in the constructor — `this.#setBinCount(ceilPowerOfTwo(max2(1, capacity)))` — so a
+  zero/undersized request lands on the minimum table instead of overflowing the shift.
+- **Confidence**: Confirmed
+
+---
+
+## Checked and found clean (no findings)
+
+`IdPool`, `Uint32Map`, `PairUint32Map`, `Uint32MinHeap`, `Uint32Heap`, `Uint32Heap4`,
+`IndexedFloatMinHeap` / `IndexedFloatMaxHeap` (index/slot bookkeeping, sift directions, grow paths),
+`RingBuffer` (including the full-buffer `removeElementByIndex` shift), `Deque` apart from COLL-4
+(expand, ring arithmetic, `#remove_internal_shift_backward` on a full deque all verified),
+`HashMap` open addressing (Robin Hood probe, backward-shift delete, `rebuild` compaction, load-factor
+accounting — the bins array is provably never saturated), `HashSet`, `ArraySet`, `Stack`,
+`CuckooFilter` (alt-bucket reversibility confirmed), `union_find` (path halving), `Cache` LRU
+list/weight accounting (the pre-`data.set` eviction window is unreachable), `CacheWTinylfu` +
+`CacheRegionWTinylfu` + `wtinylfuDecisions`, `LoadingCache`, `Signal` add/remove/dispatch generation
+tracking and once-handler removal, `SignalBinding`, `SimpleStateMachine(Description)`,
+`FunctionCompiler`, `array_sort_quick` / `array_quick_sort_by_*`, `array_set_diff(_sorting)`,
+`array_shuffle`, `binarySearchHighIndex`, and the remaining `array/` and `array/typed/` helpers.

package/src/REVIEW_2026_08_06/core-math.md

@@ -0,0 +1,221 @@
+# Correctness review — `meep/src/core/math/`
+
+Scope: 203 non-spec source files under `H:/git/moh/app/src/mir-engine/meep/src/core/math/`.
+All findings below were reproduced by executing the actual modules under node 24 (ESM).
+
+---
+
+### MATH-1 Simplex noise truncates instead of floors the lattice cell index
+- **Severity**: CRITICAL
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/math/noise/sdnoise.js:199`, `:278-279`, `:429-431`, `:686-689`
+- **Defect**: All four simplex-noise variants derive the integer lattice cell with `x | 0` / `xs | 0`, which truncates **toward zero**. The reference implementation (Gustavson/McEwan `sdnoise1234.c`) uses `FASTFLOOR`. For any coordinate whose skewed value is negative and non-integral the wrong cell is selected, the corner offsets `x0/x1/...` leave their valid range, and the field becomes discontinuous (1D: unbounded). The sibling module `noise/create_simplex_noise_2d.js:88` already carries a comment explaining exactly this hazard and uses `Math.floor`; `sdnoise.js` was never fixed.
+- **Failure scenario**:
+  - `sdnoise1(d, -0.9)` → **-22.0446** (`d[0] = 139.88`). Documented/reference range is `[-1, 1]`. In 1D the reference explicitly does *not* clamp `t1` because `|x1| <= 1` "always" — with truncation `x1 = -1.9`, `t1 = 1 - 3.61 = -2.61`, `t41 = 46.4`, and the corner contribution explodes. Sampling `x ∈ [-5, 5]` at 1e5 points gives a range of **[-323.81, +242.86]**; the same sweep over `[0, 5]` gives `[-0.173, 0.401]`.
+  - `sdnoise3(d, x, 0.3, 0.7)` swept over `x ∈ [-3, 3]` at 2e5 points has a maximum step between adjacent samples of **0.2335** (at x ≈ -1.75); the identical sweep over `x ∈ [1, 7]` has max step **0.00154**. Simplex noise is C¹-continuous, so a 150× jump is a discontinuity, not sampling resolution. Same for `sdnoise2` (0.355 vs 7.5e-5) and `sdnoise4` (0.722 vs 0.00106).
+  - Real caller: `engine/graphics/particles/particular/engine/simulator/SimulationStepCurlNoiseAcceleration.js:59` → `core/math/noise/curl_noise_3d.js:18` samples `sdnoise3` at `x - 231.141, ..., z - 54.4341`, i.e. permanently in the broken negative region for typical world coordinates.
+- **Fix**: Replace every `x | 0` / `xs | 0` cell computation in `sdnoise.js` with `Math.floor(...)` (the existing `& 0xff` / `& 255` wraps already handle negative indices correctly). Note the pinned regression values in `sdnoise.spec.js:111,124,160,173` were captured from the buggy field and must be re-derived after the fix.
+- **Confidence**: Confirmed
+
+---
+
+### MATH-2 `hammersley_sequence` seeds the radical-inverse iteration with `i/count`, producing duplicates
+- **Severity**: CRITICAL
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/math/statistics/hammersley_sequence.js:10`
+- **Defect**: The loop body is the correct incremental Halton "next value" step (Wikipedia *Halton sequence*, fast method: `x = d-n; y = d/b; while x<=y: y/=b; n = (b+1)y - x`), which requires the iteration to start from `t = 0` and be applied `i` times to yield the `i`-th radical inverse. The code instead initialises `t = i / count`, which is not a valid state of that recurrence, so the returned values are not a radical inverse and the set is not low-discrepancy — it contains repeats.
+- **Failure scenario**: `hammersley_sequence(i, 2, 8)` for `i = 0..7` produces
+  `[0, 0.625, 0.125, 0.5625, 0.625, 0.3125, 0.5625, 0.4375]` — only **6 distinct values out of 8** (0.625 and 0.5625 each appear twice). The van der Corput / base-2 Halton sequence (what the sibling `halton_sequence(2, i)` correctly returns) is `[0, 0.5, 0.25, 0.75, 0.125, 0.625, 0.375, 0.875]`. Base 3 is equally wrong: produced `[0, 0.4583, 0.9167, 0.4861, 0.9444, 0.2176, 0.9722, 0.1466]` vs correct `[0, 1/3, 2/3, 1/9, 4/9, 7/9, 2/9, 5/9]`.
+  Two samples landing on the same value defeats the entire purpose of a low-discrepancy sequence (the doc line 2 says "Low discrepancy sequence").
+- **Fix**: `let t = 0;` (the `count` parameter then becomes unused for this coordinate — the `i/count` term is the *first* Hammersley coordinate, which belongs in the caller alongside this radical inverse, exactly as `hammersley_sequence_2d.js:15-16` already does). Alternatively delegate to `halton_sequence(R, i)`, which is both correct and O(log i) rather than O(i).
+- **Confidence**: Confirmed
+
+---
+
+### MATH-3 `computeStatisticalPercentile` selects the order statistic one rank too high
+- **Severity**: MAJOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/math/statistics/computeStatisticalPercentile.js:23-24`
+- **Defect**: `start = floor(n * low)` is a half-open lower bound while `end = ceil(n * high)` is used as an **inclusive** upper index. Both are one greater than the correct 0-based rank; only clamping to `n-1` hides it at `high = 1`. For a point query (`low === high === p`) the returned element is the one at index `floor(p*n)` instead of the `p`-th order statistic.
+- **Failure scenario**: With `values = [1,2,3,4,5,6,7,8,9,10]`:
+  - `computeStatisticalPercentile(values, 0.9, 0.9)` → **10**. 10 is the *maximum* (100th percentile). Nearest-rank definition (Hyndman & Fan type 1): index `ceil(0.9*10) - 1 = 8` → **9**.
+  - `computeStatisticalPercentile(values, 0.5, 0.5)` → **6**, while `computeStatisticalMedian(values)` on the same data returns **5**. The library disagrees with itself about the 50th percentile.
+  - `computeStatisticalPercentile(values, 0, 0.4)` → **3**; the bottom 40 % of the data is `[1,2,3,4]`, whose (lower) median is **2** — the range wrongly includes index 4 (value 5, the 50th-percentile element).
+- **Fix**: Use `ceil(n·p) - 1` for both bounds:
+  `const start = clamp(Math.ceil(n * percentile_low) - 1, 0, n - 1);`
+  `const end = clamp(Math.ceil(n * percentile_high) - 1, 0, n - 1);`
+  Verified this keeps both existing spec cases green (`(0, 0.5) → 2`, `(0.5, 1) → 7`) while fixing `(0.5, 0.5) → 5` and `(0.9, 0.9) → 9`.
+- **Confidence**: Confirmed
+
+---
+
+### MATH-4 `roundFair` never rounds a negative number up
+- **Severity**: MAJOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/math/random/roundFair.js:9`
+- **Defect**: `number % 1` in JavaScript keeps the sign of the dividend, so for a negative input `mantissa` is negative. `random()` returns a value in `[0, 1)`, so `roll > mantissa` is unconditionally true and the function always takes the `Math.floor` branch. The documented contract — "a fraction is rounded up or down with probability equal to the fraction", i.e. an unbiased stochastic rounding with `E[roundFair(x)] === x` — is violated.
+- **Failure scenario**: `roundFair(-2.3, Math.random)` returns **-3** for every draw (verified: `()=>0.9 → -3`, `()=>0.1 → -3`; mean over 10 000 `Math.random` draws = **-3.0**). Expected: -3 with probability 0.3 and -2 with probability 0.7, mean **-2.3**. Positive control `roundFair(2.3, Math.random)` gives mean 2.2967, so the positive path is correct.
+- **Fix**: Use the Euclidean fraction: `const mantissa = number - Math.floor(number);` (or `euclidean_modulo(number, 1)`, which already exists in this package). With `-2.3` that gives `0.7`, and `roll > 0.7` (probability 0.3) → `floor = -3`, else → `ceil = -2`, mean -2.3.
+- **Confidence**: Confirmed
+
+---
+
+### MATH-5 `fract` truncates toward zero and wraps at 2³¹
+- **Severity**: MAJOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/math/fract.js:9`
+- **Defect**: `const whole = v >> 0;` performs `ToInt32`, which (a) truncates toward zero rather than flooring and (b) wraps modulo 2³². The JSDoc explicitly cites the GLSL `fract` reference page and states the result "is calculated as x - floor(x)".
+- **Failure scenario**:
+  - `fract(-0.1)` → **-0.1**; GLSL/documented `x - floor(x)` → **0.9**. `fract(-0.25)` → -0.25 vs 0.75.
+  - `fract(1e10)` → **8589934592**; expected **0**. (`1e10 >> 0 === 1410065408`.)
+  - `fract(2147483648.5)` → **4294967296.5**; expected **0.5**.
+  The 2³¹ wrap is wrong under *any* reading of the contract — the result is not even in `(-1, 1)`.
+- **Fix**: `return v - Math.floor(v);`. Note `fract.spec.js:7-9` currently pins the truncating behaviour (`fract(-0.1) === -0.1`, `fract(-1.1) === -0.1`) and must be updated with the fix, not used as justification for the current code.
+- **Confidence**: Confirmed
+
+---
+
+### MATH-6 `squirrel3` does not use 32-bit wrapping multiplication, so it is not the cited hash and collides
+- **Severity**: MAJOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/math/hash/squirrel3.js:13`, `:18` (also `:15`, `:19`)
+- **Defect**: The cited Squirrel3 (Eiserloh, GDC 2017) is defined over `unsigned int` with wrapping multiplies and *logical* right shifts. Here `value * BIT_NOISE1` and `hash *= BIT_NOISE3` are IEEE-754 double multiplies: an int32 operand times a ~2³² constant produces up to ~2⁶⁰, far beyond the 53-bit mantissa, so the low bits are **rounded away** before `ToInt32` takes them. Additionally `hash >> 8` (lines 15, 19) is an arithmetic shift where the reference uses a logical shift, so for negative intermediates different bits are mixed in.
+- **Failure scenario**: `squirrel3(0)` → **436901382**; a faithful 32-bit implementation (`Math.imul` + `>>>`) gives **436901570**. `squirrel3(1)` → 1910996822 vs reference 725778245. More consequentially, the reference is a bijection on 32 bits: over the 200 000 consecutive inputs `0..199999` it produces **200 000 distinct outputs**, whereas `squirrel3` produces only **199 763** — 237 collisions purely from the lost mantissa bits. (This is almost certainly the cause of the "low entropy" note in the file's own header comment.)
+- **Fix**: `let hash = Math.imul(value | 0, BIT_NOISE1);` … `hash = Math.imul(hash, BIT_NOISE3);`, and change both `>> 8` to `>>> 8`. Any callers persisting these hashes must be re-keyed.
+- **Confidence**: Confirmed
+
+---
+
+### MATH-7 `m2_svd` / `m2_polar_decomp` emit factors in the opposite storage convention to their input
+- **Severity**: MAJOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/math/linalg/m2/m2_svd.js:7-19`, `H:/git/moh/app/src/mir-engine/meep/src/core/math/linalg/m2/m2_polar_decomp.js:8`, `H:/git/moh/app/src/mir-engine/meep/src/core/math/linalg/m2/m2_polar_decomp_noS.js:5`
+- **Defect**: The input `m` is read as transposed storage (`m2_polar_decomp_noS.js:20` computes `y = m[2] - m[1]`, i.e. `A01 - A10`, the negation of taichi's `A[1,0] - A[0,1]`), but `U`, `V` and `R` are written in plain row-major. Consequently the documented reconstruction identities do not hold when evaluated with this package's own `m2_multiply`/`m2_transpose`. The two polar docs already contradict each other (`m = S * R` vs `m = R * S`) and neither is the relation that actually holds.
+- **Failure scenario**:
+  - `m = [1, -2, 5, 3]`. After `m2_svd(U, S, V, sig, m)`, computing `U·Σ·Vᵀ` exactly as `m2_svd.spec.js:16-20` does yields **`[1, 5, -2, 3]`** — the transpose of `m`, not `m`. The doc (`m2_svd.js:7`) asserts `m = U * Σ * V^T`. The existing spec only checks reconstruction for symmetric inputs (`[1,0,0,1]`, `[2,0,0,3]`, `[2,1e-7,1e-7,3]`), where a transpose is invisible; the one asymmetric case `[1,-2,5,3]` checks only singular-value ordering.
+  - `m = [1, 2, 3, 4]`. `m2_polar_decomp(R, S, m)` gives `R = [0.98058, 0.19612, -0.19612, 0.98058]`, `S = [0.58835, 2.15728, 2.15728, 4.51067]`. `m2_multiply(x, S, R)` (the documented `m = S * R`) yields **`[0.15385, 2.23077, 1.23077, 4.84615]`** — neither `m` nor `mᵀ`. The relation that actually holds is `m2_multiply(x, R, S) = [1, 3, 2, 4] = mᵀ`.
+  - Downstream consequence (outside this package but caused by it): `engine/physics/mls-mpm/MLS_MPM.js:373-374` stores `F` in transposed layout (`m2_multiply(F, p.F, m2_temp0)` is only correct under that convention) and then writes back `m2_multiply(m2_temp0, svd_u, sig); m2_multiply_transposed(p.F, m2_temp0, svd_v)`, which stores the untransposed `U Σ Vᵀ` into a transposed slot — i.e. the plastically-clamped deformation gradient is transposed on every substep whenever `F` is non-symmetric (any shear).
+- **Fix**: Pick one convention and make it total. Cheapest correct change that preserves the taichi port: transpose the emitted rotations so all five arrays share the input's storage — write `R = [c, -s, s, c]` in `m2_polar_decomp_noS`, mirror it in the two `V` branches of `m2_svd.js:79-91`, and swap the operand order of `m2_multiply(U, U, V)` at `m2_svd.js:95`. Then add an asymmetric-input reconstruction case to `m2_svd.spec.js` (e.g. `[1,-2,5,3]`) so the invariant is pinned, and reconcile the three JSDoc blocks.
+- **Confidence**: Confirmed
+
+---
+
+### MATH-8 `ParameterLookupTable.toBinaryBuffer` picks an item-count width one bit too small at exact powers of two
+- **Severity**: MAJOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/math/lookup/ParameterLookupTable.js:110-122`
+- **Defect**: The width is chosen from `Math.log2(itemCount)`, but the number of bits needed to store `itemCount` is `floor(log2(itemCount)) + 1`. At an exact power of two the test is off by one and too narrow a field is selected; `DataView.setUint8`/`setUint16` then silently truncate modulo the field.
+- **Failure scenario**: A table with exactly **256** entries: `log2(256) = 8`, so `itemCountByteSize = 1` and `buffer.writeUint8(256)` writes **0**. `fromBinaryBuffer` then reads `itemCount = 0` and reconstructs an **empty** table — total silent data loss on round-trip. Same at 65 536 entries (`writeUint16(65536) → 0`). 255 and 257 entries round-trip correctly, so the failure is exactly at the boundaries.
+- **Fix**: Compare against the value, not the log: `if (itemCount <= 0xFF) ... else if (itemCount <= 0xFFFF) ... else if (itemCount <= 0xFFFFFFFF) ...`.
+- **Confidence**: Confirmed
+
+---
+
+### MATH-9 `copysign` flips the sign when the sign source is `+0`
+- **Severity**: MINOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/math/copysign.js:9-14`
+- **Defect**: The sign is decided by `(x > 0 && y > 0) || (x < 0 && y < 0)`. When `y` is `+0` (or `NaN`) neither disjunct holds, so the `else` branch negates `x`. C99 `copysign` takes the *sign bit* of `y`; the sign bit of `+0` is clear, so the result must be `+|x|`.
+- **Failure scenario**: `copysign(3, 0)` → **-3**; C99/`tgmath.h` (which the JSDoc cites as the source) gives **+3**. `copysign(-3, 0)` → **+3** (correct by accident). `copysign(3, NaN)` → -3, where C gives +3. `copysign(3, -0)` → -3 (correct). The existing spec never passes `0` as `y`.
+- **Fix**: `return (y < 0 || Object.is(y, -0)) ? -Math.abs(x) : Math.abs(x);`
+- **Confidence**: Confirmed
+
+---
+
+### MATH-10 `softmax` overflows to `NaN` for large inputs
+- **Severity**: MINOR
+- **File**: `H:/git/moh/app/src/mir-engine/meep/src/core/math/statistics/softmax.js:12`, `:19`
+- **Defect**: `Math.exp` is applied to the raw components. `Math.exp(z) === Infinity` for `z > 709.78`, and `Infinity / Infinity === NaN`. The standard formulation (and every reference implementation, cf. the linked Wikipedia article's "numerical stability" note) subtracts `max(z)` first — mathematically identical because `softmax(z) === softmax(z - c)` for any constant `c`.
+- **Failure scenario**: `softmax([1000, 1], 0, 2)` → **NaN**; the correct value is **1** (to within double precision). `softmax([800, 801], 1, 2)` → **NaN**; correct value **0.7311**.
+- **Fix**: Compute `let max = -Infinity; for (j…) max = Math.max(max, z[j]);` then use `Math.exp(z[i] - max)` and `sum += Math.exp(z[j] - max)`.
+- **Confidence**: Confirmed
+
+---
+
+## Checked and found correct (recorded so they are not re-reviewed)
+
+- `linalg/lu_factor_linear_system.js` / `lu_solve_linear_system.js` — faithful port of VTK `LUFactorLinearSystem`/`LUSolveLinearSystem`; the column-major index map `A[j*size+i] ≡ A[i][j]` is applied consistently in every loop, including the row interchange and the `scale[maxI] = scale[j]` step.
+- `idct_1d.js` / `idct_2d.js` — element-for-element match with the ffmpeg AAN `idct_1d`. `idct_2d` deliberately omits ffmpeg-exr's extra `*0.5`: the only caller is the JPEG decoder (`engine/asset/loaders/image/jpeg/idct8x8_float.js`), and the JPEG convention is exactly `1/2` per dimension. Verified DC round-trip: `F(0,0) = 8` → `f(x,y) = 1`.
+- `linalg/solve_linear_system_GEPP_2x2.js` — exhaustively walked every zero-pattern branch (single, double, singular); column-swap/row-swap bookkeeping and the final un-swap of `x` are correct in all cases.
+- `linalg/eigen/matrix_symmetric_3x3_eigen.js` — Numerical Recipes cyclic Jacobi; rotation formulas, third-index update, eigenvector accumulation and ascending sort all correct; `r = 3 - p - q` is valid for all three plane pairs.
+- `linalg/givens/givens_rotation_coefficients.js` — both branches satisfy `-s·a + c·b = 0` and `c² + s² = 1`.
+- `noise/create_simplex_noise_2d.js` — correct Fisher–Yates (`r = i + ~~(random()*(256-i))`, range `[i, 255]`), correct `Math.floor`, all `perm[]` indices bounded by 511.
+- `spline/computeCatmullRomSpline.js`, `computeCatmullRomSplineUniformDistance.js`, `computeNonuniformCatmullRomSplineSample.js` — Wikipedia centripetal Catmull–Rom barycentric form; endpoint interpolation exact at `f = 0` and `f = 1`.
+- `spline/interpolate_bicubic.js` — algebraically identical to the standard `p1 + 0.5t(p2-p0 + t(2p0-5p1+4p2-p3 + t(3(p1-p2)+p3-p0)))`.
+- `solveCubic.js` — the trigonometric branch's `acos(3q/(pm))` argument is provably in `[-1,1]` whenever `ratio < 0`, so no clamp is needed.
+- `physics/kinematics/computeInterceptPoint.js` — `(V·V - s²)t² + 2(V·D)t + D·D = 0` and the smallest-non-negative-root selection are both correct.
+- `compute_legendre_polynomial.js` — exact match with Green's *Spherical Harmonic Lighting* reference.
+- `modified_bessel_i0.js` — term recurrence `T_k = T_{k-1}·y/k²` matches `Σ (x²/4)^k/(k!)²`.
+- `random/randomIntegerBetween.js`, `random/random_pick_weighted_index.js`, `random/seededRandom_Mulberry32.js`, `random/seededRandom_MersenneTwister.js` — inclusive/uniform bucketing, cumulative-weight search bounds, and both generator kernels verified. (Mulberry32's unbounded `_seed` accumulator was measured: after seeding at 2⁶⁰ the distinct-output count over 100 000 draws is 99 996 vs 99 999 at seed 0 — not a reportable degradation.)
+- `statistics/computeStatisticalVariance.js` (population divisor `n`) and `statistics/computeStatisticalMedian.js` (lower median on even counts) are both **intentional**, pinned by their specs — not defects.
+- `physics/brdf/*`, `physics/pdf/*`, `physics/irradiance/*` — `D_GGX` matches Filament's listing, `pdf_GGX` is self-consistent with it on the α parameterisation, `cone_cosine_from_roughness` is the exact inverse of `reflection_sample_weight`'s spherical gaussian, `pdf_normal` is the correct `N(0,σ)` density, and `ior_to_reflectivity`/`reflectivity_to_ior` are exact mutual inverses.
+- `physics/mie/ri_*.js` — lookup positions are supplied in nanometres, so `ParameterLookupTable.sample(wavelength_nm, …)` interpolates on the right axis.
+
+---
+
+## Unspecced files
+
+67 source files under `core/math/` have no adjacent `*.spec.js`:
+
+```
+DEG_TO_RAD.js
+EPSILON.js
+FLT_EPSILON_16.js
+FLT_EPSILON_32.js
+FLT_EPSILON_64.js
+GOLDEN_RATIO.js
+NumericType.js
+PI.js
+PI2.js
+PI_HALF.js
+PI_RECIPROCAL.js
+RAD_TO_DEG.js
+build_gaussian_kernel_2d.js
+euclidean_modulo.js
+fabsf.js
+hash/lowbias32.js
+idct_1d.js
+idct_2d.js
+interval/intersects1D.js
+interval/separation1D.js
+linalg/lu_factor_linear_system.js
+linalg/m2/m2_polar_decomp.js
+linalg/m2/m2_polar_decomp_noS.js
+linalg/sparse/spm_matvec.js
+linalg/sparse/spm_matvec_transpose.js
+lookup/ParameterLookupTable.js
+lookup/ParameterLookupTableFlags.js
+mix.js
+modified_bessel_i0.js
+noise/curl_noise_3d.js
+noise/curl_noise_3dt.js
+physics/brdf/diffuse_GGX.js
+physics/brdf/fresnel_Schlick.js
+physics/brdf/fresnel_Schlick_optimized.js
+physics/brdf/fresnel_Schlick_original.js
+physics/bsdf/bsdf_schlick.js
+physics/ior_to_reflectivity.js
+physics/mie/MIE_PARTICLES_STANDARD.js
+physics/mie/MIE_PARTICLES_STANDARD_PRECOMPUTED.js
+physics/mie/lorenz_mie_coefs.js
+physics/mie/ri_air.js
+physics/mie/ri_ammonium_sulfate.js
+physics/mie/ri_brine.js
+physics/mie/ri_dust.js
+physics/mie/ri_pollen.js
+physics/mie/ri_smoke.js
+physics/mie/ri_soot.js
+physics/mie/ri_water.js
+physics/pdf/pdf_normal.js
+physics/reflectivity_to_ior.js
+random/generate_halton_jitter.js
+random/randomBytes.js
+random/random_pick_weighted_index.js
+random/seededRandom.js
+spline/catmull_rom_compute_T.js
+spline/computeNonuniformCaltmullRomSplineDerivative.js
+spline/computeNonuniformCatmullRomSplineSample.js
+spline/interpolate_bicubic.js
+spline/spline3_hermite_intersection_spline3_hermite_2d.js
+spline/spline3_hermite_intersects_spline3_hermite.js
+spline/v3_computeCatmullRomSplineUniformDistance.js
+sqr.js
+statistics/computeStatisticalMedian.js
+statistics/computeStatisticalStandardDeviation.js
+statistics/generate_hammersley_jitter.js
+statistics/hammersley_sequence.js
+statistics/hammersley_sequence_2d.js
+```
+
+Of the 10 findings, 4 land in unspecced files (`hammersley_sequence.js`, `ParameterLookupTable.js`, `m2_polar_decomp*.js`); the other 6 land in files whose specs exist but only exercise the working half of the input domain (`sdnoise.spec.js` never samples negative coordinates for 1/3/4D, `fract.spec.js` pins the bug, `copysign.spec.js` never passes `y = 0`, `m2_svd.spec.js` reconstructs only symmetric inputs, `roundFair.spec.js` never passes a negative, `computeStatisticalPercentile.spec.js` never makes a point query).