Measured assurance
Reproduce solver and route correctness checks, coverage floors, and bounded local benchmarks.
GrantTrace treats correctness evidence and performance measurements as two different workflows. Correctness is deterministic and enforced in the normal test suite. Benchmarks are opt-in diagnostics whose timings depend on the machine and runtime.
Correctness and oracle checks
pnpm test:assuranceThe focused suite uses fast-check with a fixed seed and explicit run counts. It enumerates every assignment in a small permission lattice and compares the solver's selected assignment and nondominated frontier with an independent brute-force oracle. It also generates bounded route catalogs and request URLs, then compares parsing, matching, specificity, ambiguity, and fail-closed behavior with a straightforward reference matcher. The oracle reimplements level ordering, dominance, URL parsing, and template matching; it does not use the production helpers that implement those decisions.
These property tests also run under pnpm test and pnpm test:coverage; the
focused command is only a faster way to reproduce this assurance layer.
Per-file coverage floors
pnpm test:coverageVitest's V8 provider enforces the existing repository-wide thresholds. Under the pinned Vitest 4.1 glob-threshold syntax, one threshold object applies to the files matched by that pattern. The config therefore gives each critical file its own singleton threshold entry so high coverage elsewhere cannot hide a critical file with weak coverage:
| Scope | Branches | Functions | Lines | Statements |
|---|---|---|---|---|
| Permission parsing, validation, canonicalization, and solving | 75% | 90% | 85% | 85% |
| Safe-route parsing and runtime route matching | 75% | 90% | 85% | 85% |
Every src/security/*.ts file | 60% | 75% | 70% | 70% |
The thresholds are review gates, not proof that unexecuted behavior is safe. Raise them when focused tests add meaningful branch coverage; do not lower them to accommodate an unrelated change.
Bounded local benchmarks
Install the repository's frozen dependencies, then run the opt-in benchmark:
pnpm benchmarkThe benchmark file is discovered through Vitest 4's separate
benchmark.include
configuration, while normal tests still include only *.test.ts files.
The benchmark uses fixed synthetic inputs and fixed iteration counts:
| Case | Workload per measured iteration | Warmup | Measured |
|---|---|---|---|
| Permission solver | 6 routes, 3 alternatives per route | 10 | 100 |
| Route URL parsing and catalog matching | One pinned REST URL against the checked-in catalog | 50 | 500 |
Both cases set time-based sampling to zero, so the runner stops after the
declared iteration counts instead of extending a run to meet a timing window.
The benchmark does not run in pnpm test, pnpm verify, or CI, and it has no
pass/fail latency threshold.
For a useful comparison, use the same machine, power profile, Node.js version, package lockfile, and command. Record the commit and raw output. Vitest can also write machine-readable output for a later same-environment comparison:
pnpm exec vitest bench --run --outputJson before.json
pnpm exec vitest bench --run --compare before.jsonDo not present a single local timing as a project guarantee. The checked-in snapshot records its date, source commit, host, runtime, workload, results, and limitations; it is not an SLA, a CI threshold, or a cross-host comparison.