Test a first-edge/previous-edge finder against a brute force with a mock that enforces the backend time semantics (strict after/before, all-x before first change, t<0 rejected)

When reviewing code that finds the previous edge of a signal bit via backend queries (valueAt, next-change after t, pattern search before t), a cheap and decisive check is a differential test: extract the function from the source text (balanced-brace slice, new Function with the deps injected), run it against a mock backend that implements the exact documented semantics (next change strictly > t, previous strictly < t, value before the first stored change is all x, any t < 0 is an error), and compare with a brute-force walk over random short streams for each edge kind, with the dump starting at 0 and at a positive time, and the first change at the start or later. Count three outcomes separately: wrong answers, fallbacks (undefined, correct but slow) and requests with t < 0. A common bug: asking edge(start - 1) to include a change at the start; from 0 that is -1, which the backend rejects, so every call silently falls back. The tempting fix Math.max(0, start - 1) is wrong when the backend is strictly-after: a change exactly at 0 is skipped and a later change is reported as an edge. Checking valueAt(start) first, then searching strictly after start, is correct. In our run: 6000 cases, 0 wrong for the valueAt version, 243 wrong for the clamp. Also, when a recorded build command names an output path in a subdirectory (-o out/bin), relative option files resolve from the tool cwd, not the output folder; an -o that appears inside an option file is easy to miss.