The coverage ladder — measuring repos that have no coverage tool

Most guides to code coverage begin with "first, install a coverage tool." For a verification gate that has to work on a stranger's repository, that sentence is a wall: the person being asked to install something is precisely the person who has not bought in yet. Relay's answer is a ladder — four rungs, tried in order, and every one of them ends in a runnable command rather than advice.

What are the four rungs?

• Rung 1 — your own tool. If the repository already uses vitest, jest, c8, nyc, or coverage.py, Relay uses that. A tool you chose always wins over anything Relay carries.
• Rung 2 — the runtime's own coverage. A repo whose only test command is node --test needs nothing installed at all: Node 22 emits lcov itself. Relay adds the right flags and reads the result.
• Rung 3 — Relay's own instrument. No tool in the repo, no native coverage available: Relay measures with a c8 it installed for itself under ~/.relay/vendor at install time — never touching your package.json, your lockfile, or your node_modules.
• Rung 4 — a runnable command. If even that is unavailable, the advice is a single copy-paste install command for your exact stack. Never "go figure out coverage."

The precedence is tested, including the mutation: delete ~/.relay/vendor and rung-3 repositories degrade to rung 4's literal command, not to a dead end.

Isn't measuring with your own tool a conflict of interest?

It is — and that is why the receipt says so. When Relay measures with equipment you did not choose, the numbers carry a disclosure inside the signed evidence:

"instrument": {
  "name": "c8",
  "version": "10.1.3",
  "sha256": "8ce3a7707ed63963c773abcbd549d971fe285c9061a15c1f3ba8c36c2d44f4b5",
  "vendored_by": "relay"
}

Package, version, and the sha256 of the exact file that executed — measured from the process that ran, not declared by anyone. A receipt cannot name an instrument that did not run, and cannot omit one that did. In our release verification, the same instrument hash came out of two independent clean machines, which is what a pinned instrument should do.

Who keeps the vendored tool honest?

A written contract, enforced by tests rather than by memory. The pin lives in one manifest; the build goes red if the installer's embedded version drifts from it, if the manifest claims to ship a tool no installer actually stages, or if the monthly review goes thirty days overdue — with the fix written into the failure message. Vendored tools never auto-update on a user's machine; a new pin ships only inside a new release.

One consequence of rung 3 worth stating plainly: "my repo has no coverage tooling" is no longer a reason a change goes unverified. The measurement happens with your tool, the runtime's, or Relay's — and in every case the receipt tells you which. The full workflow is in the docs, and the first step never asks you to install anything: relayevals try.