Kaiju live selector benchmark harness #
This is a reproducible validation harness for the live-browser selector choices before implementing the full CLI collector.
It tests the selector strategy as a three-part provenance model:
CSS selector
best for browser replay
XPath selector
best for structural/source traceability
Accessibility selector
best for human and agent interpretation
The harness follows the attached instruction bundle:
- Deno v2, strict TypeScript, ESM, explicit file extensions.
@std/testing/bdd,@std/expect, andfast-checkfor tests.mitatabenchmarks withdo_not_optimize().- Realistic, behavior-driven tests instead of implementation-only assertions.
- Durable JSONL/artifact corruption checks.
Why this exists #
Before adding the full live browser collector, we need evidence that the selector tooling is reliable enough to store as provenance. This project gives us a repeatable way to test selector behavior under realistic failure modes:
- renamed classes
- removed ids
- removed stable attributes
- renamed accessible names
- hidden/non-rendered nodes
- invalid CSS identifier characters
- generated-looking ids/classes
- corrupted JSONL
- missing/truncated/hash-corrupted artifacts
- feature flag conflicts
Requirements #
- Node.js 22+
- npm
- Chromium-compatible browser
The harness uses the npm-distributed Deno binary so it can be reproduced in sandboxes where Deno is not globally installed.
If Chromium is not found automatically, set:
export CHROMIUM_PATH=/path/to/chromium
Run everything #
npm install
npm exec --yes --package deno@2.9.1 -- deno task verify
npm exec --yes --package deno@2.9.1 -- deno task report
Faster iteration #
npm exec --yes --package deno@2.9.1 -- deno task build:browser
npm exec --yes --package deno@2.9.1 -- deno task test
npm exec --yes --package deno@2.9.1 -- deno task bench
Outputs #
results/selectors_bench.json
results/selector-validation-report.md
The benchmark JSON is deliberately simple so it can be committed, compared, or pasted into a technical decision record.
Expected conclusion #
The expected conclusion is not that one selector type wins. The expected conclusion is that selector provenance needs all three selector families:
- CSS selectors are usually fastest and best for direct browser replay.
- XPath selectors are useful for structure and source traceability.
- Accessibility selectors survive many visual/layout changes and are much easier for agents to interpret.
The tests also prove that each selector family can fail under a plausible mutation, which is why the live collector should store them together rather than choosing only one.